[macOS][Pro 20x $200] Chat → New voice chat is gated by exhausted Codex/Work quota while web Voice works
Summary
On a ChatGPT Pro 20x / $200 per month account, ordinary Voice launched from Chat → New voice chat in the macOS desktop app is gated by the exhausted Codex/Work usage pool.
This is not a report that a delegated Work or Codex task should remain available after agentic usage is exhausted. No Work or Codex task was started or delegated. The problem is that the base GPT-Live conversation itself is blocked in Desktop Chat.
The same account, with the same exhausted Codex/Work pool, can use ordinary Voice normally on chatgpt.com. This same-account A/B result points to a desktop-specific Voice routing or entitlement-enforcement problem rather than an account-wide Voice cap.
Environment
- Desktop app version:
26.803.41515 - Subscription: ChatGPT Pro 20x / $200 per month
- Platform: macOS, Apple Silicon (
arm64) - Date reproduced: August 8, 2026
Actual behavior
Before opening Voice, I select Chat, not Work and not Codex, in the desktop app.
I then open the standalone New voice chat entry point and begin a plain conversational Voice exchange. GPT-Live initially starts and responds, but the Voice window displays:
You're out of Codex and Work usage Add credits to keep going now, or wait for usage to reset on Aug 11, 11:58 AM
The same Voice window displays an Add Credits button, and the ordinary Voice conversation cannot continue normally.
The captured screenshot shows all of these at the same time:
- window title:
New voice chat - successful initial GPT-Live response:
Aquí estoy. Te escucho. - composer text:
Work with ChatGPT - banner:
You're out of Codex and Work usage - reset time: Aug 11, 11:58 AM
Add Creditsbutton
Chat-selector / composer inconsistency
Immediately before starting Voice, the top Chat/Work selector is set to Chat. After New voice chat opens, the resulting Voice window nevertheless shows the composer text Work with ChatGPT, even though I did not select Work or Codex.
OpenAI Support suggested this might indicate that the app is entering a task-capable Work/Codex Voice mode. If the app is silently changing the selected experience or routing Chat → New voice chat into Work/Codex Voice, that silent routing is itself the behavior being reported.
The composer placeholder should not override the explicitly selected Chat experience or cause the base ordinary Chat Voice conversation to require Codex/Work credits.
Same-account A/B test requested by OpenAI Support
I completed the web comparison requested by Support while the Codex/Work usage pool remained exhausted:
- ChatGPT web:
Chat → Voiceworks normally and the GPT-Live conversation continues. - macOS desktop app 26.803.41515:
Chat → New voice chatstarts, then shows the Codex/Work exhaustion banner andAdd Creditsgate.
No Work or Codex task was started or delegated in either test.
This shows that the account's GPT-Live entitlement is active and working. The failure is specific to the desktop Chat Voice path.
Steps to reproduce
- Sign in to a ChatGPT Pro 20x / $200 account.
- Exhaust the account's Codex/Work usage allowance so the desktop app reports that Codex and Work usage is unavailable until reset.
- In the desktop app, select Chat, not Work or Codex.
- Do not start or open a Work task or Codex task.
- Open the standalone
New voice chatentry point. - Begin a normal conversational Voice exchange without requesting task delegation.
- Observe that GPT-Live initially responds.
- Observe
You're out of Codex and Work usageand theAdd Creditsbutton inside the Voice window. - On the same account and while the same Codex/Work limit remains exhausted, open Voice in Chat on
chatgpt.com. - Observe that web Voice continues normally.
Expected behavior
The underlying ordinary GPT-Live Voice conversation should remain available under the documented Pro 20x Voice entitlement even when Codex/Work usage is exhausted.
If the Voice conversation attempts to launch or coordinate an operation that actually requires Work or Codex usage, that specific delegated task may be blocked, require credits, or wait for reset. Exhausting the agentic pool should not block the base Voice-in-Chat conversation.
A reasonable fallback would be:
Voice can continue, but Work/Codex tasks cannot be started until agentic usage resets or credits are added.
If the desktop app intentionally converts every Chat → New voice chat session into Work/Codex Voice, the UI and documentation should state that limitation clearly and provide a way to start ordinary Desktop Chat Voice without using the agentic pool.
Official documentation supporting the expected behavior
1. Using Codex with your ChatGPT plan
https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan
Under Usage limits by plan, OpenAI states:
Ordinary Chat Voice uses separate caps and does not consume Codex usage.
The same paragraph distinguishes task work in Voice in Work/Codex from ordinary Chat Voice.
2. ChatGPT Learn pricing
https://learn.chatgpt.com/docs/pricing#chatgpt-voice-in-desktop
The pricing page separately states that:
- ChatGPT Voice on desktop uses a separate, plan-dependent allowance.
- Pro 20x ($200/month): Unlimited voice access.
- Tasks started through Voice use the existing Codex usage budget.
- GPT-Live manages the live conversation, while GPT-5.6 Terra starts and coordinates tasks.
That describes separate accounting for the live conversation and any task work initiated through it.
3. ChatGPT Voice
https://help.openai.com/en/articles/20001274-chatgpt-voice
The Voice article distinguishes two experiences:
- Voice in Chat: ordinary real-time conversation, available in Desktop Chat and on web, iOS, and Android.
- Voice in Work and Codex: task and agent coordination, available as a standalone experience only in the desktop app.
It also documents ChatGPT Pro ($200/month): Unlimited access to GPT-Live-1.
Because standalone Voice in Work and Codex is not available on web, the working web A/B test is necessarily ordinary Voice in Chat. The same ordinary Voice entitlement works on web but is routed to the Codex/Work gate in desktop Chat.
4. ChatGPT Work and Codex
https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex
The documented procedure for Voice with Work or Codex is to open the desktop app and choose Work or Codex. Voice uses the tools and permissions of the selected experience. The same article says ordinary Chat remains available by selecting Chat from the top toggle.
I selected Chat.
5. ChatGPT release notes
https://help.openai.com/en/articles/6825453-chatgpt-release-notes
The August 7, 2026 update states that GPT-Live in ChatGPT Voice supports file uploads and Projects. Therefore, file/project capability or a task-capable desktop interface does not by itself establish that a user selected Work or Codex; ordinary Chat Voice can also operate with files and Project context.
User impact and requested resolution
The desktop app is my normal workflow. Web Voice is useful as a diagnostic comparison, but it is not an adequate replacement for the desktop experience included with the subscription.
Please:
- Confirm whether this is a known desktop Voice routing or entitlement defect.
- Provide an account-side or desktop workaround that restores ordinary Voice in Chat without requiring Codex/Work credits.
- Identify the desktop app version containing a fix, when available.
- Preserve and correlate the existing feedback diagnostics listed below.
Diagnostic and support references
- OpenAI feedback/report ID:
019fe2f4-d18d-72b2-8a61-034ec5f8bad9 - OpenAI Support has escalated the report to a specialist.
- A screenshot is available through the feedback report showing the exact UI state described above.
Related issue searched before filing
Closest issue found: #35242 — Voice Chat being limited on Pro 20x.
That report describes Voice failing after several hours and references a five-hour limit. This issue is a narrower, directly visible cross-entitlement reproduction:
- Codex/Work usage is already exhausted;
- a newly opened Chat → New voice chat immediately receives the Codex/Work credit gate;
- the same account's ordinary web Voice works normally at the same time.
If maintainers determine that #35242 shares the same root cause, the reports can be consolidated.
This is not a request to increase Codex usage. It is a request to restore the separately documented ordinary Chat Voice entitlement in the desktop app.
5 Comments
Merged into the issue title and body on August 8, 2026.
Having the same issue on Windows 11.
Reproduced again — August 19, 2026, 5:29 AM ET
The desktop behavior has become more explicit and more severe. From the ChatGPT desktop interface, the available Voice control now fails before an ordinary Voice conversation starts and displays:
No Work task or Codex task was selected, started, or delegated. The app routes the Voice entry directly to the Codex/Work usage gate and provides no ordinary Voice-in-Chat fallback.
This current behavior conflicts with OpenAI’s published distinctions:
The task-usage rule is not disputed. The defect is that the base live conversation is blocked before any task exists. The correct fallback is to keep ordinary GPT-Live Voice available and disable only Work/Codex task-start or task-coordination actions while the agentic pool is exhausted.
The current screenshot was supplied to OpenAI Support under Case 12900360. Existing in-product Feedback ID:
019fe2f4-d18d-72b2-8a61-034ec5f8bad9.also same issue on windows 11
I can reproduce this issue on a newer Windows Desktop build, and I performed a fairly extensive elimination test because initially I suspected a local configuration or microphone problem.
Environment
Windows 10 Pro 22H2, build 19045
ChatGPT Plus
ChatGPT version shown in Help > About ChatGPT: 26.818.61809
Microsoft Store/MSIX package: OpenAI.Codex 26.818.8289.0
Release date shown in About dialog: 2026-08-24
The behavior is essentially identical to this issue:
Chat selected
→ start Voice
→ session is routed through Work/Codex realtime
→ Work/Codex usage is affected
The Voice button itself is NOT missing. It remains visible in normal Chat. The problem is what happens after pressing it.
Same-account A/B test
I tested the exact same ChatGPT account, PC, microphone, network, and time period.
Windows Desktop:
Chat selected → Voice → incorrect Work/Codex routing
chatgpt.com in Edge:
Chat selected → Voice → normal ChatGPT Voice works correctly
I directly completed a normal browser Voice session successfully.
This effectively rules out:
It also strongly points to a Desktop-specific routing problem.
Desktop log evidence
The affected Desktop Voice flow calls Codex thread-scoped realtime methods including:
method=thread/realtime/listVoices
method=thread/realtime/start
and successful attempts produce:
realtime_session_started hostId=local
realtime_session_updated ... rendererWindowAppearance=avatarOverlay
Some attempts fail with:
"thread <id> does not support realtime conversation"
followed by:
"Error starting realtime voice"
and:
"[avatar-overlay-realtime] Failed to start realtime in the avatar overlay"
So this is not only a UI labeling problem. The affected Voice flow is actually invoking the Codex/Work realtime thread route.
Additional UI/filesystem evidence
When I start Voice from a brand-new normal Chat conversation, the Recent list can show an automatically generated local path similar to:
C:\Users\<username>\Documents\Codex\2026-08-26\realtime-voice-chat-*
Multiple entries such as:
realtime-voice-chat
realtime-voice-chat-2
realtime-voice-chat-3
...
also appeared as Codex projects.
I did not intentionally create these projects. They were generated while reproducing Desktop Voice.
Local-state elimination
I initially suspected stale local Codex state.
I completely isolated/regenerated:
~\.codex\.codex-global-state.json
The Desktop app regenerated clean state, but the Chat → Work/Codex Voice routing problem remained.
Therefore the known stale realtime Voice thread pointer/local global-state class of problem does not explain this case.
I also tested Codex feature configuration.
The bundled codex.exe reports:
realtime_conversation under development false
There was originally no explicit realtime_conversation=true in my ~/.codex/config.toml.
As a controlled A/B test, I explicitly added:
realtime_conversation = false
and restarted the Desktop app without starting Voice.
Despite that, the Desktop startup log still reported:
Features enabled enabledFeatures="..., realtime_conversation"
followed by successful:
experimentalFeature/enablement/set
So the Desktop frontend enables its realtime feature independently of the local Codex CLI/config.toml setting.
I reverted the diagnostic config change afterward.
Electron/Statsig observation
The Desktop Electron profile contains Statsig evaluation cache data whose source is Network, and startup successfully calls:
POST /backend-api/wham/statsig/bootstrap
This makes a simple stale local feature cache/config explanation less likely.
I am NOT claiming the server-side Statsig assignment itself is necessarily wrong; the bug may instead be in how the Desktop client interprets the routing/handoff state.
Clean reinstall/reset elimination
Before collecting these logs I had already performed:
Windows app Terminate + Reset
full uninstall
Windows reboot
Microsoft Store cache reset (wsreset.exe)
fresh Microsoft Store reinstall
fresh normal Chat test
The issue persisted.
Therefore this does not appear to be ordinary MSIX package corruption.
AutoHotkey elimination
Earlier in the day I had experimented with AutoHotkey only to invoke the visible Voice UI.
However:
So AHK may have exposed the existing behavior during testing, but the evidence does not support it as the cause.
Why I believe this is a routing defect
The combined evidence currently looks like:
Normal Chat explicitly selected
→ user presses normal Chat Voice button
→ Desktop opens/uses the native realtime/avatar overlay
→ Codex thread/realtime APIs are invoked
→ a local realtime-voice-chat Codex workspace may be created
→ Work/Codex quota is used or can gate the session
while the same account on chatgpt.com uses normal Chat Voice correctly.
This also appears consistent with:
#38507 - Chat Voice incorrectly gated by exhausted Codex usage
#39986 - macOS Chat Voice launches as Work/Codex
The important part of my report is that this still reproduces on:
ChatGPT Desktop: 26.818.61809
Windows MSIX: 26.818.8289.0
and the Desktop logs provide direct evidence of thread/realtime/start being used during the affected flow.
Expected behavior
Chat selected → Voice must remain normal ChatGPT Voice.
It should not:
If useful, I can provide the specific timestamped Desktop log excerpts and screenshots showing: