Running Codex CLI against token-share.app

Why the wire format lines up

Codex CLI talks to a model provider over a configurable wire API, and the OpenAI text ids in this catalog — gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna, gpt-5.5, gpt-5.4 and gpt-5.4-mini — all record /v1/responses as their route. Setting wire_api to "responses" is what makes the two ends agree.

Authentication is a Bearer token: the gateway expects Authorization: Bearer $TOKEN_SHARE_KEY on responses-shaped requests, and Codex reads the credential from whichever environment variable you name in env_key.

Nothing else about the CLI changes. It is the same binary talking the same protocol to a different base URL, so the models it can drive are exactly the ids the catalog routes on /v1/responses.

The configuration

The block below defines a provider named token_share and launches Codex against it. base_url is the gateway root plus /v1 — Codex appends the route itself, so do not include /responses in the URL.

requires_openai_auth=false is the flag that stops the CLI from insisting on an OpenAI sign-in flow. Codex still expects an auth.json to exist on first run, which is why the snippet writes a placeholder one: the value in that file is not the credential used for requests, the env_key variable is.

Swap the --model argument for any of the six ids listed above. They take the same request shape, so switching models in Codex is a change to that one flag.

export CODEX_HOME="${CODEX_HOME:-$HOME/.codex}"
mkdir -p "$CODEX_HOME"

# The gateway key Codex will send as a Bearer token
export TOKEN_SHARE_KEY="<your-pool-api-key>"

# First-time initialization: Codex expects this file to exist
[ -f "$CODEX_HOME/auth.json" ] || {
  printf '%s\n' '{"OPENAI_API_KEY":"sk-placeholder"}' > "$CODEX_HOME/auth.json"
  chmod 600 "$CODEX_HOME/auth.json"
}

codex \
  --config 'model_provider=token_share' \
  --config 'model_providers.token_share.name="OpenAI"' \
  --config 'model_providers.token_share.base_url="https://token-share.app/v1"' \
  --config 'model_providers.token_share.wire_api="responses"' \
  --config 'model_providers.token_share.env_key="TOKEN_SHARE_KEY"' \
  --config 'model_providers.token_share.requires_openai_auth=false' \
  --model 'gpt-5.6-terra'

Which ids fit, and what a long session costs

One id in the OpenAI family does not fit this setup: stable-gpt-6-astra records /v1/messages as its route, not /v1/responses. A provider block configured with wire_api="responses" will not reach it. The same applies to gpt-image-2, which is an image model on /v1/images/generations.

Among the six that do fit, context is what usually bounds a coding session rather than price. The GPT 5.6 ids carry 372,000 tokens and emit up to 128,000; gpt-5.5, gpt-5.4 and gpt-5.4-mini carry 272,000 and emit up to 64,000. A CLI session accumulates tool output in the transcript, so the larger window is the one that runs longer before you have to start a new session.

On cost, the six span an order of magnitude after their multipliers: $0.50 / $3.00 per million for gpt-5.6-sol and gpt-5.5, $0.25 / $1.50 for gpt-5.4, $0.20 / $1.20 for gpt-5.6-terra, $0.075 / $0.45 for gpt-5.4-mini, and $0.06 / $0.36 for gpt-5.6-luna. Because switching is one flag, the practical move is to run the same task through two of them and compare both the output and the token counts before settling.

Common questions