Account Pool

Account Pool (Pro) lets Cursor, scripts, and other apps use your saved Codex accounts through one local OpenAI-compatible endpoint. When one account hits its limit, the next one takes over. It runs on your machine as a loopback endpoint, not a hosted proxy, so another app can reach all of those accounts through a single base URL and key.

Native API engine

Account Pool uses the unmodified CLIProxyAPI engine to call the subscription-backed Codex backend over OAuth. It no longer converts API requests into app-server turns. The private engine binds to loopback with its own random key; client keys and account selection remain owned by CodexUse.

Builds and each new engine process check the latest stable GitHub release and verify its official SHA256 checksums. Updates are stored in a private writable cache, never in the sealed app bundle. A running engine is not restarted for an update. If release discovery or download is unavailable, CodexUse warns and uses a verified bundled or cached version; integrity failures stop startup rather than silently falling back. Automatic upstream updates can change compatibility.

Saved credentials are copied into a private runtime directory, refreshed by the engine, and synchronized back only when the saved account identity and credential version still match. This does not change the global Codex sign-in. Private credential copies and the owned engine process are removed when the runtime stops normally.

Set up the pool

1. Open CodexUse → Account Pool, or run codexuse account-pool status.
2. On the Accounts tab, select the accounts you want it to use, and choose a Pick order for new requests.
3. On the Overview tab, click Generate key and copy the key. CodexUse shows it only once.
4. Make sure Accept requests is on.

The base URL appears in the Connect an app section of the Overview tab, and the CLI can inspect the same setup. Keep the exact base URL and runtime key together when you connect a client. Source checkouts prepare the verified native engine with bun run --cwd apps/backend build:runtime; no global CLIProxyAPI installation is used.

Connect a local client

Account Pool serves tools that speak OpenAI-compatible Responses or Chat Completions: scripts, editor extensions, local agent runners, and desktop apps. Read /v1/models and choose an exposed model ID.

curl http://127.0.0.1:PORT/v1/models \
  -H "Authorization: Bearer cux_pool_..."

curl http://127.0.0.1:PORT/v1/responses \
  -H "Authorization: Bearer cux_pool_..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6.1-sol",
    "input": "Summarize what changed in this repository."
  }'

curl http://127.0.0.1:PORT/v1/chat/completions \
  -H "Authorization: Bearer cux_pool_..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6.1-sol",
    "messages": [{"role": "user", "content": "Summarize what changed in this repository."}]
  }'

Both generation endpoints support JSON and stream: true SSE. /v1/responses/compact is forwarded to the engine without a fabricated fallback; the Codex account used in live verification returned upstream HTTP 404 for compaction.

Tools belong to the calling agent

Responses tools, instructions, reasoning options, and structured output items use the native engine rather than a text-only prompt. When a response contains function_call, the calling agent executes the tool and submits function_call_output with the original call_id. File access, shell execution, sandboxes, and agent hooks belong to that client; Account Pool does not run app-server built-in tools for it.

Continue a response

Send previous_response_id with the next input to replay the stored raw input and output items, including tool calls, tool results, and opaque reasoning items. Branching from an older retained response replays that response, not the latest branch. IDs expire with their session; at most 64 recent response IDs are retained per session.

store: false disables local continuation-history storage, so that response cannot be resumed by ID. Routing metadata and operational error logs remain. Clients that already submit full history can use this stateless mode. Session-affinity headers alone do not add conversation history.

Manage it from the CLI Pro

You can manage the same Account Pool settings from the terminal without opening the desktop app.

codexuse account-pool status
codexuse account-pool profiles list
codexuse account-pool keys create
codexuse account-pool sessions list

Choose the model names your client will see

On the Models tab, you choose which model IDs the pool exposes. Published IDs lists what clients see on /v1/models.

How routing works

A new pooled session can start on any eligible selected account, which spreads fresh work across your accounts instead of draining one first. Once a session starts, CodexUse keeps it on that account unless an eligible rollover is needed.

• Least used: prefer the eligible account with the most headroom right now.
• Round robin: spread new sessions evenly across the selected pool.
• Session continuity: an explicit previous response stays bound to its original account.

What happens when one account runs out

Retryable account, quota, or transport failures can move a request to another eligible account only before response bytes are sent. After streaming starts, the pool reports the failure instead of retrying and duplicating output. An explicit previous_response_id stays on its original account and is not silently replayed through another one.

What this will not fix

Account Pool helps when you truly have multiple eligible accounts to route across. If two saved accounts are really the same underlying OpenAI account, they still share the same headroom. The pool can organize that setup, but it cannot invent extra quota.

Good fits