// integration

Codex CLI with teamToken

Codex can talk to any provider, declared in one config block. Below are the exact fields, a one-command check, and the reason Codex does not start against every gateway that calls itself OpenAI-compatible.

What the tool is

Codex CLI is OpenAI's terminal agent that edits files in your project. Its provider is not fixed: declare your own in the config and the tool carries on as usual, with nothing to install and nobody's built-in provider list to wait for.

The whole config

# ~/.codex/config.toml
model = "gpt-5.3-codex"
model_provider = "teamtoken"

[model_providers.teamtoken]
name = "teamToken"
base_url = "https://api.teamtoken.store/v1"
env_key = "TEAMTOKEN_KEY"
wire_api = "responses"

The key does not live in the file. env_key names the environment variable Codex reads it from, so the config can sit in your dotfiles without becoming a secret.

Codex speaks Responses, which not every gateway does

The wire_api field looks like one setting among several, but it is about the protocol. Since 2026 Codex accepts exactly one value, responses, and that is also what applies when the field is left out. There is nothing to choose here.

Which explains a class of failures elsewhere. Codex calls /v1/responses rather than the familiar /v1/chat/completions, and "OpenAI-compatible" means only the second one at plenty of gateways. The address goes in, everything looks right, and back comes a refusal that does not say what is wrong.

We support that route: /v1/responses is accepted alongside the chat-compatible one, streaming included. So the setup is the block above and nothing else.

Checking it

export TEAMTOKEN_KEY="<your key>"
codex --model gpt-5.3-codex "what file is open right now"

An answer means both the config and the key arrived. After that you can drop --model: the value from model in the config applies on its own.

Which models to use

ModelWhen
gpt-5.3-codexthe working model here, tuned for code
codex-auto-reviewreading somebody else's diff before a merge
gpt-5.6-solwhen the task is wider than code: docs, logs, planning
gpt-5.4-minismall stuff where a heavy model is overkill

The full list comes from GET /v1/models on the same key, and --model switches models without touching the config.

Spend caps per key

An agent handed a large task spends unpredictably. Each key carries its own dollar ceiling: issue one for Codex, cap it at $30, and that is where it stops. The balance stays shared while the cap sits on that key alone.

When it does not work

It starts but nothing answers
Check that the gateway in base_url is really ours. Codex goes to /v1/responses, and a gateway that only speaks the chat-compatible route answers with a refusal that does not name the cause.
The key is not picked up
Codex reads it from the variable named in env_key. Make sure that variable is visible to the process in the same terminal, not just in another window.
Model not found
The name has to match the catalog. Check GET /v1/models; names there carry no provider prefix.
Related
Claude CodeMoving from OpenRouterImages on the same key
Get an API key