Skip to content

Codex Pooler Vs Direct Credentials

Codex Pooler changes the client credential model. Instead of putting account-specific material in each client, operators connect upstream Codex accounts to Pools and give clients stable Pool API keys. Codex Pooler then routes supported work to eligible upstream accounts.

QuestionDirect account credentialsCodex Pooler
What does the client hold?Account-specific credential material or client-specific account setupA Pool API key that represents a Pool
How do capacity changes work?Each client may need reconfigurationOperators adjust Pool assignments, upstream lifecycle, and routing policy centrally
How is an account selected?Selection is usually fixed by client setupEligibility checks and Pool strategy choose from assigned upstream accounts
How are requests investigated?Evidence may be spread across clients and local logsAdmin UI and MCP expose sanitized metadata for visible Pools
What stays out of logs?Depends on each client and processDocs describe metadata-only request, routing, audit, and MCP evidence

Codex Pooler fits teams that already operate trusted Codex accounts and want centralized Pool policy, stable client credentials, shared capacity, account readiness checks, continuity-aware routing, and metadata-only request evidence.

It is not a way to bypass account terms or limits. Operate only accounts you are allowed to use, and give Pool API keys only to trusted clients.

Use Pool API keys for /backend-api and /v1 runtime requests. Use operator-owned MCP tokens for /mcp. Do not reuse Pool API keys for MCP, and do not use MCP tokens for runtime work.

Raw Pool API keys and raw MCP tokens are one-time secrets in the product surfaces. Public docs should use placeholders such as <pool-api-key> and <operator-mcp-token>.