Point Codex CLI at a custom provider

Codex CLI can run against any provider that speaks the Responses API, not just the official one. The configuration is four lines — but there is one flag that turns a working setup into a confusing failure if you leave it out, and the error message does not point at the flag.

1. The whole configuration

Put this in ~/.codex/config.toml. The name after model_provider is arbitrary; it just has to match the table header below it.

model = "your-model-id"
model_provider = "custom"
disable_response_storage = true

[model_providers.custom]
base_url = "https://your-endpoint.example.com/v1"
wire_api = "responses"

Three of those lines are ordinary. base_url is the /v1 root of the provider, and wire_api = "responses" tells the client to use the Responses protocol instead of chat completions.

2. Why disable_response_storage = true is not optional

By default the Responses API expects the server to keep conversation state, so a follow-up request can refer to a previous response by id. A third-party endpoint does not offer that storage, and Codex keeps requesting it anyway.

The failure looks like this:

stream closed before response.completed

3. Check the account before you blame the config

If your provider is also OpenAI-compatible, a plain chat request tells you whether the key, the model id and the balance are fine — in about ten seconds, with no agent in the loop:

curl https://your-endpoint.example.com/v1/chat/completions \
  -H "Authorization: Bearer $YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"your-model-id","messages":[{"role":"user","content":"ping"}]}'

If that returns a normal completion, the account side is healthy and any remaining problem is in how the client talks to the provider. If it fails, fix that first — Codex will not give you a clearer error than this will.

4. What to watch once it runs

• Token burn. An agent resends its context every turn. A single task can move hundreds of thousands of tokens, so size the plan rather than the per-token rate.
• A per-request usage log. Without one you cannot separate "the model is bad at this" from "my provider is metering oddly".
• Large max_tokens. The agent asks for long completions; a provider that quietly caps output far below its advertised limit will cut edits in half.