Custom model providers

A custom-provider profile runs a non-OpenAI model inside the official Codex App. It has its own isolated Codex home, its own credential, and its own model list. It is not an OpenAI account and does not use one.

How it fits together

Three objects, each doing one job:

• Connection — the vendor: a name, a base URL, and a credential. One connection can serve many models.
• Model — one model on that connection: the upstream model ID, a display name, the transport it speaks, and its reasoning behavior.
• Profile — an isolated Codex App instance bound to one connection and the models you published to it.

A local gateway on 127.0.0.1 sits between the Codex App and your provider. It presents the Responses API to Codex, translates to whatever the provider speaks, and serves a catalog containing only that profile’s models.

Add a connection

1. Open Connections in the CodexUse console.
2. Enter a vendor name, the base URL, and the credential. Use the vendor’s name only — do not put the transport or a model name in it.
3. Run Verify. CodexUse makes a synthetic request and reports the exact provider error if it fails.

Add models

1. Add a model with its upstream model ID exactly as the provider spells it.
2. Choose the transport: Responses or Chat Completions. This is a property of the model, not the connection — one connection can host both.
3. Give it a display name. It defaults to the upstream ID and you can rename it without changing routing.
4. Publish it. Only published models reach a profile.

Reasoning effort

Effort values are resolved in a strict order, and CodexUse never invents them:

1. Your own override, if you set one.
2. Metadata the provider returns.
3. An exact Models.dev match on both the API URL and the model ID.
4. Otherwise: no effort parameter is sent and the provider decides.

Matching requires the URL and the ID, because the same model ID can behave differently on different providers. If a model advertises low, high, and max, the Codex picker shows exactly those three — Codex labels low as “Light”. Your selection survives a restart.

Create the profile

1. Create a profile and choose Custom provider.
2. Pick the connection, the published models, and a default.
3. Launch it. CodexUse provisions an isolated Codex home, writes the model catalog, and opens a Codex App window bound to that profile.

What stays isolated

• Each profile gets its own Codex home, its own history, and its own app state.
• The provider credential stays in the Keychain and is never written into config.toml.
• The gateway accepts a per-profile capability only, compared in constant time, so one profile cannot reach another’s models.
• The catalog served to a custom-provider profile contains only that profile’s models. No OpenAI models appear in it.
• Your normal ChatGPT app and its login are untouched.

Changing models later

Editing the published model list re-provisions the profile and needs a window restart to take effect. A valid effort selection is preserved across re-provisioning.

What this does not claim

• CodexUse is not affiliated with OpenAI, and this is not a way around OpenAI billing. A custom-provider profile does not call OpenAI at all — it calls the provider you configured, with your own credential, and you pay that provider directly.
• A profile is either an OpenAI account or a custom provider. It is never both. Your ChatGPT profiles keep using ChatGPT exactly as before.
• Hosted ChatGPT features do not work on a custom-provider profile — dictation, browser remote control, and anything that calls ChatGPT’s own backend need a ChatGPT account. Chat, tool calls, and reasoning effort do work.
• Your provider must speak the OpenAI Responses or Chat Completions shape. Providers with a bespoke protocol are not supported.
• macOS on Apple Silicon only. Intel Mac, Windows, and Linux desktop builds are not in the current release line.
• You are responsible for the third-party provider’s terms and costs, and for reviewing your own OpenAI plan terms.

Related