Skip to content
Summer sale. 50% off Pro, $19.50 for life. Desktop app: Apple Silicon Mac only.SUMMER50
CodexUse

Use an aggregator like OpenRouter in the Codex App

GuideUpdated August 2026 · 5 min read

An aggregator is the most useful kind of custom provider, because one connection and one credential give you many models. The setup is the same as any provider — the difference is how you organise the models afterwards.

Short answer: add the aggregator as one connection, then add each model you care about as its own entry with the upstream ID spelled exactly as the aggregator spells it. Publish the ones you want and bind them to a profile.

Why an aggregator fits well

  • One credential covers many vendors, so you are not managing a key per model.
  • Trying a new model is adding one entry, not building a new connection.
  • Models with different transports can live on the same connection, because the transport belongs to the model rather than the connection.

Setting it up

  1. Add the aggregator as a connection: its name, its base URL, your credential. Name it after the vendor only.
  2. Verify the connection before adding models, so a bad URL or credential surfaces immediately with the provider’s own error text.
  3. Add one model entry per model, using the exact upstream ID. Aggregators usually namespace them, and the string has to match.
  4. Pick the transport per model — aggregators commonly expose both Responses and Chat Completions, and not every model supports both.
  5. Publish, then bind the published set to a profile with a sensible default.

A detail that bites people

The same model ID can behave differently on different providers, which is why reasoning-effort metadata is matched on the API URL and the model ID, never the ID alone. An aggregator’s copy of a model may advertise a different effort set than the vendor’s own endpoint. If the picker shows something unexpected, that is usually why — and you can override the values yourself.

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

Docs: Custom model providers Guide: run a custom model provider Is running a custom provider allowed? Using the Codex App without an OpenAI subscription Reasoning effort for custom models

Do I need a separate connection per model?

No. One connection per aggregator, then one entry per model on it. Separate connections are only for genuinely different vendors or endpoints.

What if a model ID has a prefix?

Use it exactly as the provider spells it, prefix included. The upstream ID is a wire value and must match; the display name is separate and you can rename it freely.

Why does the effort list differ from the vendor's own docs?

Because metadata is matched per provider URL, not per model name. An aggregator's copy can advertise a different set. Set your own values if you know better than the metadata.