Change voice chat to different model

[kotobuki09]

Area

Proxy and routing

What are you trying to accomplish?

Quota for Chatgpt running out that can no longer use voice mode. Would like to change other model for that

What prevents this today?

No usage without codex quota

What should OpenCodex do?

Change another voice model

Example usage or interface

NA

Alternatives or workarounds

No response

Additional context

No response

Checks

• I searched existing issues and documentation.
• This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
• I removed secrets and personal data.

[Ingwannu]

Thanks for the request. Today the voice path is not an ordinary text-model route: Codex voice uses the ChatGPT /v1/live realtime transport, including bidirectional audio/transcription events. A configured chat-completions or Responses model cannot replace it merely by changing the model id.

Supporting another backend would require a provider with a documented compatible realtime audio API plus an explicit event/audio translation layer. If you have a specific provider and realtime voice model/API in mind, please add that provider/model and its public API documentation here. I am keeping this as an enhancement rather than treating quota exhaustion as a routing bug.

[lidge-jun]

Closing this as not implementable from the proxy side, with the reasoning below so it can be reopened against concrete evidence.

Why a model id cannot be swapped here

Codex voice is not a text-model route with a different name on it. It is a WebRTC realtime call: the client POSTs a call-create carrying an SDP offer, negotiates media, then joins a bidirectional sideband WebSocket for audio and transcription events. In this repository that path is src/server/live.ts, and it is deliberately a transparent bidirectional relay — it forwards SDP and the protocol negotiation headers verbatim rather than translating a request body.

Two properties of that path make a substitute model impossible to express as configuration:

1. The call-create is OpenAI-shaped, not model-shaped. It targets realtime/calls?intent=quicksilver&architecture=avas and exchanges { sdp, session? }. There is no model field to repoint at another vendor; swapping the destination would mean a different wire protocol, not a different model id.

2. The proxy already rejects routed providers here, by design. The relay returns this today:

   Built-in ChatGPT voice needs an OpenAI upstream (ChatGPT login or an OpenAI API-key provider),
   but none is configured in opencodex. Routed providers cannot serve voice call-create.
   

   That is not a missing feature behind a flag — a routed chat-completions or Responses provider has no realtime audio surface for the relay to negotiate against.

Upstream evidence (checked 2026-07-30)

• OpenAI's Realtime API documents sessions against OpenAI realtime models such as gpt-realtime over WebRTC/WebSocket/SIP. It does not document a mechanism for pointing a realtime session at a third-party model.
• openai/codex does expose a realtime model override, but it is internal and explicitly marked "Experimental / do not use" (experimental_realtime_ws_model in the config source), and the app-server thread/realtime/start model parameter selects among OpenAI realtime models. Neither is a supported provider-routing surface.
• I found no Codex release through 0.146.0 (2026-07-29) announcing a user-facing configurable voice model.

So the substitution is blocked at two layers at once: the transport is OpenAI-specific, and the only model selector that exists upstream is an experimental OpenAI-internal one.

What does help with the original problem

Your actual motivation was ChatGPT quota exhaustion, and there is a supported answer for that. The relay accepts an OpenAI API-key provider as the voice upstream, not only the ChatGPT login. Configuring the built-in openai-apikey provider lets voice bill against API credits instead of your ChatGPT plan allowance, while Codex text work keeps routing to whichever provider you prefer. That does not change the voice model, but it does decouple voice from the quota that ran out.

Reopening

Please reopen if either of these appears, and we will reconsider seriously:

• A provider with a documented public realtime audio API you want supported — name the provider, the realtime model, and link the API reference. The blocking work is an event/audio translation layer, and a concrete target spec is what makes that estimable.
• An upstream Codex change that turns realtime model selection into a supported, non-experimental setting.

Thanks for raising it, and sorry the answer here is a boundary rather than a fix. Keeping it open with no achievable next step would have been less honest than saying where the wall is — but the request itself is reasonable, and we will revisit it if the transport story changes.

[github-actions]

_{Automated translation bookkeeping — detected language: English.}