model_provider
openaiPublished Jul 15, 2026 · Verified against the official config docs
Picks which entry in the [model_providers] table Codex sends requests to. The value is a string id: openai (the default), the built-in ollama and lmstudio, or any custom id you define yourself. Set it in your user-level config file; Codex ignores model_provider in project-scoped .codex/config.toml files, along with the model_providers table itself.
Values
| Value | What it is |
|---|---|
openai |
Default. The stock OpenAI backend. |
ollama, lmstudio |
Built-in ids for local model servers. |
| any custom id | An entry you define under [model_providers.<id>]. |
The value has to match an entry in the model_providers table, and built-in provider ids can’t be overridden (config reference).
model_provider = "custom-provider"
[model_providers.custom-provider]
name = "My Custom Provider"
base_url = "https://api.example.com/v1"
env_key = "CUSTOM_API_KEY"
wire_api = "responses"
When to change it
- Running local models through Ollama or LM Studio: set
model_provider = "ollama"or"lmstudio". Both ids ship built in, no table entry needed. - Routing through an internal proxy or gateway with an OpenAI-compatible endpoint: define a custom
[model_providers.<id>]entry withbase_urlandenv_key, then pointmodel_providerat it. - Keeping two setups in one config: users in #7051 put
model_providerinside a[profiles.<name>]block and switch profiles instead of editing the key.
Gotchas
Project-scoped config can’t touch it. Codex ignores model_provider (plus model_providers, notify, profile, profiles, and otel, among others) in a project-local .codex/config.toml (config reference). A cloned repo can’t silently redirect your API traffic, which is the point. It also means per-repo provider switching has to live in your user config, via profiles.
The chat wire API dropped out of the docs. The current reference lists responses as the only supported wire_api value and the default when omitted (config reference). Providers that only speak the chat completions API started failing on codex 0.59 and later with a tool_calls error; the workaround in the thread is pinning 0.58 (#7051, 51 comments).
Provider set, OpenAI still billed: the oldest complaint in this cluster (#987, 32 comments) is a 401 where Codex kept authenticating with the user’s OpenAI key even though a third-party provider was configured. Check that env_key names the right variable and that the variable is actually exported in the shell Codex runs from.
Related settings
model_providers: the table this key selects from. Each entry carriesbase_url,env_key,wire_api, and header options.model: the model name you set there has to be one the selected provider actually serves.