iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Codex CLI can use a custom model provider when its endpoint supports the Responses API behavior Codex expects. Add the provider in your user-level ~/.codex/config.toml, select it with model_provider, and supply its API key through an environment variable. “Any model” is conditional: the endpoint must expose a compatible API and serve the model ID you choose.
Configure a provider in one block
Use this as a template, not as a tested configuration for a particular router. Replace the model ID and endpoint with values supplied by your provider:
model = "<model-id>"
model_provider = "router"
[model_providers.router]
name = "Router"
base_url = "https://<provider-api-base>/v1"
env_key = "ROUTER_API_KEY"
wire_api = "responses"Set ROUTER_API_KEY in the shell or secret manager that launches Codex. Keep credentials out of configuration files that might be committed to a repository. The model ID must be one the endpoint actually offers and your account can use.
Why “any model” has limits
The current Codex configuration reference lists responses as the supported wire_api value. A provider or gateway therefore needs to implement the Responses API behavior Codex expects; an endpoint being described as “OpenAI-compatible” does not, by itself, establish compatibility. The available documentation does not establish that every model or routing service works with this setup. See Codex configuration reference.
#1 Best Overall
OpenAI’s external-model evaluations documentation discusses custom endpoints compatible with Chat Completions and names OpenRouter as a partner for third-party model evaluations. That is a separate feature and does not certify that OpenRouter—or any other endpoint in that context—works with Codex CLI’s Responses-only provider configuration. See external-model evaluations.
Put provider settings in the right config file
Save provider configuration in the user-level ~/.codex/config.toml. Codex ignores provider keys such as model_provider and model_providers in a project-local .codex/config.toml. Project configuration is also loaded only for trusted projects.
Configuration precedence runs from CLI flags and --config overrides, through trusted project config, the selected profile, user config, cloud-managed defaults, system config, and built-in defaults. Consequently, a higher-priority setting can override a value in the user config. Details are in the Codex configuration guide and configuration reference.
Check before relying on the connection
- Confirm the endpoint supports the Responses API behavior Codex requires, rather than assuming Chat Completions compatibility is sufficient.
- Use the exact model ID the endpoint serves, and verify that your account is entitled to use it.
- Check the provider’s authentication instructions and set the credential in the environment or secret manager used to launch Codex.
- Review the endpoint’s data-handling terms and any provider-specific requirements before sending work to it.
The configuration documents the supported fields, but does not show that this template has been tested against a third-party endpoint. Authentication and other gateway-specific behavior must be confirmed with that provider.
Rank #3
Do not confuse this with app-server OAuth
OpenAI’s app-server guide includes a Responses provider example using a ChatGPT-plan OAuth access token. It is an app-server integration example, not evidence that a model gateway can reuse that authentication flow or that it is the general Codex CLI setup. See the app-server guide.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
