Paid $200/month for GPT-6, getting capacity errors or degraded fallback instead — this is unacceptable

Summary

I am aware that many users have already reported similar problems.

That is exactly the problem.

I reported my Pro 20x account becoming effectively unusable several days ago. Since then, I have repeatedly provided OpenAI Support with timestamps, thread IDs, request IDs, screenshots, affected models, and reproduction information.

I have been told the issue was temporary. I have been told it was being investigated. I was later told that OpenAI had identified a technical issue on its side and that it had been resolved.

It has not been resolved.

My account is currently oscillating between two failure modes:

Codex fails with:

Selected model is at capacity. Please try a different model.
The request succeeds, but GPT-6 behaves so abnormally fast, shallow, and prematurely terminating that it appears to be running through a severely degraded serving path or fallback, while my GPT-6 allowance is still consumed.

At this point I am tired of being brushed off.

I have spent several days reporting a serious failure of a service that costs me $200/month, while the product remains unreliable or effectively unusable for my work.

Seeing many other users report the same thing does not make this issue less important. It makes the situation worse.

It means this is not an isolated incident, and paying users have been reporting the same class of failure for days without a proper resolution.

The way this has been handled feels dismissive and is unacceptable.

Subscription

ChatGPT Pro 20x / $200 per month

Product

Codex

Platform

Windows

Models affected

I have observed failures across:

GPT-6
GPT-5.6 Sol
GPT-5.6 Terra
GPT-5.6 Luna

The most serious current problem is with GPT-6.

Failure mode 1: "Selected model is at capacity"

Since September 13, I have repeatedly received:

Selected model is at capacity. Please try a different model.

This happens:

across different times of day;
across different conversations;
across different models;
after repeated retries;
while I still have weekly usage allowance remaining.

This is not normal quota exhaustion.

For example, on September 17 my Codex UI still showed approximately 28% of my 7-day allowance remaining, yet a normal GPT-6 task still failed with the capacity error.

Affected thread:

01a0aeed-8d3b-7fe1-b2c0-4943eab06470

An earlier heavily affected thread:

01a08f18-22f5-77a2-94e4-a6168584b770

I have also experienced:

stream disconnected before completion

Request ID:

b8c7d5d9-b771-4b9d-96a3-3ce63db8ee44

Thread ID:

01a0a9b0-7a37-78e0-84f6-675f7cc07b3e

This has already cost me substantial working time because long-running technical tasks can run for minutes and then fail.

Failure mode 2: GPT-6 succeeds, but behaves nothing like normal GPT-6

When I am not getting the capacity error, I now sometimes get a second failure mode.

GPT-6 technically responds, but the behavior is completely abnormal.

I observe:

output beginning almost immediately;
token generation far faster than normal;
complex requests frequently ending after only one short sentence;
almost no meaningful reasoning;
expected tool use not happening;
tasks terminating prematurely;
dramatically reduced agentic behavior;
severe degradation compared with the GPT-6 behavior I had before this incident.

Tasks that previously took several minutes of reasoning and tool work can now terminate almost immediately.

Despite this, the UI still says GPT-6 and the usage is still deducted from my GPT-6 allowance.

I cannot inspect the actual backend serving model from Codex, so I am not claiming that I can prove exactly which model is serving these requests.

But from the user side, this strongly resembles one of the following:

silent fallback;
server-side model rerouting;
degraded serving;
an unhealthy backend/capacity pool;
account-specific throttling;
account-specific provisioning/routing state.

If OpenAI is serving a different or materially degraded model path, the client needs to disclose that.

It should not continue presenting the response as GPT-6 and charging GPT-6 usage as if nothing changed.

Reproduction

One of the prompts I used is:

创建一个HTML，内容是SVG绘制一个鹈鹕骑自行车的2D动画

English:

Create an HTML file containing an SVG 2D animation of a pelican riding a bicycle.

This is intentionally similar to the reproduction used by other users reporting GPT-6 degradation.

On my account, repeated runs can produce two completely different abnormal outcomes:

Outcome A

The task begins and then fails with:

Selected model is at capacity. Please try a different model.

Outcome B

The task succeeds, but GPT-6 responds extremely quickly and shallowly, performs substantially less work than expected, and terminates early.

Retrying can make the account move between these two states.

There is no corresponding local configuration change.

The selected model remains GPT-6.

This has been happening for days

This is not a brief outage.

I first reported the problem several days ago.

Since then, I have:

retried at different times;
switched models;
started new conversations;
provided thread IDs;
provided request IDs;
provided exact timestamps;
provided screenshots;
provided timezone information;
worked with OpenAI Support;
waited for the claimed service-side fix.

OpenAI Support later told me that the earlier issue was caused by a technical problem on OpenAI's side and was believed to have been resolved.

Yet here I am again, still unable to rely on Codex.

The error has changed form, but the service problem has not gone away.

I know there are already similar issues

I know that multiple similar reports already exist.

Again: that is exactly why I am filing this.

Relevant reports include:

Account-specific capacity errors across Codex models despite a fully available weekly allowance #43337 — account-specific capacity errors despite available quota
GPT-6 Astra output quality dropped by half after account-level capacity throttling (same prompt, effort and client core) #44851 — GPT-6 Astra severe degradation after account-level capacity throttling
stream disconnected before completion is account-scoped — switching ChatGPT accounts changes the failure rate ~7× #45925 — stream disconnect failures shown to follow the account
Codex models repeatedly return "Selected model is at capacity" / "servers are currently overloaded" on ChatGPT Pro account with usage remaining #46149 — Pro account capacity / overload failures with usage remaining

My experience now combines both categories:

persistent capacity / overload failures;
severe GPT-6 degradation when the request is allowed through.

This makes me concerned that both symptoms may originate from the same account-level routing, admission-control, backend-pool, or serving-state problem.

Closing this as a duplicate without investigating the account/server telemetry would miss the main point.

Why I consider this a serious service failure

I use Codex for real research and engineering work.

This issue has caused:

multiple days of disrupted work;
failed long-running tasks;
repeated manual retries;
lost time waiting for requests that later fail;
inability to trust task completion;
inability to trust that the selected model is actually being served normally;
GPT-6 allowance being consumed while GPT-6 behavior appears severely degraded.

I am paying $200/month specifically because I need reliable access to the higher-capability models.

At the moment, I am effectively paying for two outcomes:

"Selected model is at capacity"

or

a response labeled and charged as GPT-6 that behaves nothing like the GPT-6 service I had before.

That is not an acceptable Pro 20x experience.

What I need OpenAI to investigate

Please correlate the thread IDs and request ID above with backend telemetry.

Specifically, I would like the team to check:

What model actually served my successful GPT-6 requests.
Whether my account is being placed on any:
- fallback route,
- degraded serving path,
- alternate model route,
- overloaded capacity pool,
- unhealthy backend shard.
Whether there is any account-specific:
- throttling,
- provisioning problem,
- entitlement issue,
- routing state,
- experiment,
- risk/degradation flag,
- admission-control state.
Whether the repeated capacity failures and degraded GPT-6 responses are two outcomes of the same backend problem.
Why GPT-6 allowance continues to be consumed when the delivered behavior appears materially different from normal GPT-6.
Whether usage consumed by these abnormal requests can be restored.
Why a problem I reported several days ago, and which OpenAI Support acknowledged as a service-side technical issue, is still affecting my account.

Expected behavior

When I select GPT-6, I expect one of two honest outcomes:

GPT-6 is actually served normally;

or

Codex clearly tells me that GPT-6 cannot currently be served and explains any fallback/degraded mode before consuming my GPT-6 allowance.

What should not happen is:

repeated unexplained capacity failures with quota remaining;
silent degradation;
silent fallback;
silent rerouting;
a materially weaker serving path still labeled as GPT-6;
GPT-6 quota being charged regardless.

Support case

I have already been working with OpenAI Support on this issue.

Support case:

15079325

This should provide additional history and diagnostic information.

I can provide additional screenshots, local rollout logs, request IDs, timestamps, and thread IDs privately if maintainers need them.

But after several days of reporting this problem, I need this treated as a serious backend/account reliability issue rather than being dismissed again as temporary capacity.

I have had enough of repeatedly being told that the problem is temporary or resolved while the service I am paying for remains broken.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Account-level "Selected model is at capacity" on 100% of requests across all models (Pro plan) #46185
Codex models repeatedly return "Selected model is at capacity" / "servers are currently overloaded" on ChatGPT Pro account with usage remaining #46149
Complaint from a $200/month Pro user—99% of quota remains, but Codex keeps reporting “Selected model is at capacity,” severely disrupting normal use #46143
Codex CLI (ChatGPT login, Pro 20x): frequent ‘stream disconnected before completion’ + repeated ‘Selected model is at capacity’ (Request ID 68f16728-07bb-4a24-b7ca-500757169524) #45949
[Pro][Windows] Multiple Codex models repeatedly fail with "Selected model is at capacity" / server_overloaded #45376

Powered by Codex Action

Hi, did you find any solution? I have literally the exact same problem, 1:1 like yours. It's impossible to work — GPT-6 Astra has basically turned into an idiot. Did you find any solution, or did OpenAI reply to you?

@EminMullaliev

@EminMullaliev Yes. We tested this quite extensively.

With the same account, model, reasoning level and prompt, different IPs/routes can produce completely different behaviour. Changing IP can restore normal performance, and we've also seen normal sessions become degraded immediately after a Reconnecting 1/5 ... 5/5 failure and retry.

Our conclusion is that OpenAI is applying server-side routing/serving policies that make some regions, IPs or accounts much more likely to receive a degraded service while still showing the same model.

I've reported this to OpenAI multiple times, with test results and session/request information, but mostly received generic or dismissive replies.

At this point, this no longer looks accidental to me. It looks like deliberate server-side behaviour rather than a normal Codex bug.

If you're seeing the same thing, keep your evidence and consider reporting it to your local consumer regulator as well.

Codex `gpt-6-astra`: identical prompts return contradictory answers and 0-vs-206 reasoning tokens - please disclose which model served each response

Summary

On 2026-09-20 I ran the same prompt, on the same selected model, at the same reasoning effort,
several times. The responses contradict each other, and the token accounting differs by an order of
magnitude on the reasoning side.

Prompt (Chinese): 你的知识训练截止日期是什么时间
("What is your knowledge training cutoff date?")

Selected in every case: model gpt-6-astra, reasoning effort medium.

Results

#	Where	Session start (UTC)	Wall time	input tokens	output tokens	reasoning_output_tokens	Answer
A	Codex Desktop app	2026-09-20T08:38:24Z	~8 s	26,596	18	0	"我的知识截止时间是 2024 年 6 月" (June 2024)
B	`codex exec` #1	2026-09-20T08:56:26Z	69.8 s	22,381	176	113	"2026 年 4 月 30 日" (April 2026)
C	`codex exec` #3	2026-09-20T08:57:58Z	84.2 s	22,331	286	206	"我的基础知识截止时间是 2024 年 6 月" (June 2024)
D	`codex exec` #4	2026-09-20T08:59:23Z	76.3 s	22,140	198	142	"我的知识截止日期是 2026年4月30日" (April 2026)
E	`codex exec` #5	2026-09-20T09:00:39Z	30.7 s	17,057	109	65	"我的知识截止日期未被明确提供" (not specified)

Same question, same model selection, five runs: three different answers, two of which directly
contradict each other by more than two years. Latency ranges from 8 s to 84 s. reasoning_output_tokens
ranges from 0 to 206. Input tokens range from 17,057 to 26,596.

Traceable identifiers (all with model=gpt-6-astra, reasoning_effort=medium):

A  thread 01a0bdf7-42ed-7651-900b-48aeb449d8e8
   response resp_01d992b525678eb1016aaf9b82d20087d09ccbf3ede88f3731
B  thread 01a0be07-f079-7972-9035-9c579d019804
   response resp_0cb0a4b94562378b016aaf9fe33fb087d0a43ec8fd31512e14
C  thread 01a0be09-5804-7063-a957-ff948066518e
   response resp_0d89a3e43a3876c3016aafa048989087d0b25993e799e3315d
D  thread 01a0be0a-a148-7a23-8468-b74aa5c4bb12
   response resp_01a9df33e4135950016aafa09b192c87d08c06a4fe1d9524b2
E  thread 01a0be0b-cb49-73d2-802b-7867c32f417e
   response resp_01a72d97072b98c0016aafa0bd488887d0b031909c6c593d66

I am not asking you to treat the cutoff sentences as fact

I know models are unreliable when asked about their own metadata, and that a wrong cutoff can simply
be a hallucination. That is not my argument, and please do not close this ticket on that basis alone.

My argument is the pattern: for an identical question and an identical model selection, the reasoning
token count, the input context size, the latency and the answer all vary far more than they should.
That is what makes me suspect that different models are serving the same model selection.

What I want

For each of the five response ids above, tell me which model actually served it. This is
something only you can answer.
If a fallback / degraded / reserve model can be substituted for a selected model, surface it to
the user - in the UI or in the local logs - instead of substituting silently. A silent
substitution is worse than an explicit error, because the client has no way to detect it.
If this is expected behaviour, tell me how to select a model that is guaranteed to be served by
that model, and which models on the current plan are subject to substitution.

Why the client cannot answer this itself

codex doctor on this machine reports:

websocket            connected (HTTP 101 Switching Protocols)
server model present false

There is no client-side way to confirm the served model, which is why I am asking you.

Response headers recorded on this account also show a reserve / fallback mechanism exists:

x-base-model-inference-reference-limit-name: gpt-reserve
x-codex-safety-buffering-faster-model:       gpt-5.6-luna
x-codex-active-limit:                        premium

Related history on the same account

On 2026-09-17 the same account was failing every turn with hard capacity errors before this
conversation, for example:

Turn error: Selected model is at capacity. Please try a different model.

(observed on gpt-5.6-sol and gpt-5.6-luna). If capacity pressure triggers fallback, a degraded
serving model is plausible. Public reports describe the same shape of problem, including receiving
"capacity errors or degraded fallback instead":

#46189

How runs B-E were produced

For transparency, runs B-E are reproducible with the bundled CLI:

codex exec -m gpt-6-astra -c model_reasoning_effort="medium" -s read-only \
  -c approval_policy="never" --skip-git-repo-check \
  "你的知识训练截止日期是什么时间"

(prompt piped on stdin). The session files are kept locally under
C:\Users\26945\.codex\sessions\2026\09\20\.

Environment

Codex Desktop        26.915.4065.0
app-server / CLI     0.155.0-alpha.9.2
OS                   Windows 11, 10.0.26200, AMD64, zh-CN
Timezone             Asia/Shanghai (UTC+8)
Auth mode            chatgpt
Plan                 plus, x-codex-active-limit: premium
Model context window 258400

Rate limits at the time:
  primary    47.0% used   (300 min window,   resets 2026-09-20 18:25:31 local)
  secondary   7.0% used   (10080 min window, resets 2026-09-27 13:25:31 local)

我同样遇到了这个问题，频繁出现Selected model is at capacity. Please try a different model.错误，官方态度令人作呕，对于我花费200$订阅这个服务我感觉异常愤怒，官方在持续不断的消耗他们的商业信誉而不自知。

Windows Codex: all selected models rejected with capacity despite remaining allowance

I am seeing the same account-scoped pattern on Windows Codex Desktop on 2026-09-21 (Asia/Seoul):

Selected model is at capacity. Please try a different model. occurs across GPT-5.6 Sol, GPT-5.6 Terra, GPT-5.6 Luna, and GPT-6 Astra.
It reproduces across separate tasks and sessions, including simple requests; switching models and retrying does not reliably help.
ChatGPT Work also indicated that the model/usage limit was not exhausted, while Codex continued returning the capacity error across multiple models.
This also occurs when no parallel orchestration is running, so it is not explained by one fan-out task.
The same local session has also shown a separate Daybreak access-program error; that is distinct from the recurring capacity failure.

Please investigate whether the affected account is being placed on an account-specific admission/routing pool, temporary activity-based restriction, or degraded backend capacity pool. Please distinguish this from normal quota exhaustion and disclose the trigger and recovery criteria if a temporary limitation is applied.

I can provide exact timestamps and sanitized local error excerpts privately if needed.

Same boat on the $200 Pro plan, with traced evidence for the "degraded fallback" half of your title.

On 2026-09-21 we captured 235 completed server responses in one Codex Desktop session: the client requested gpt-6-astra (config-verified) while server-authored response.model reported gpt-5.6-luna in 196 of them. Astra itself was served only 10 times, inside two brief windows, with no client-side change in between — the substitution flips server-side. Two mismatches are hard-correlated to local request logs by response ID / turn ID, and same-window controls show gpt-6-sol served correctly 12/12 on the same account in the same minutes, so the routing is model-specific rather than account-wide.

Full tables and response IDs in my comment on #46632. Notably: no capacity errors and no 429s in the capture — the fallback was served silently while the UI kept showing Astra.

Summary

I am experiencing what appears to be a persistent account-specific Codex / ChatGPT Work backend failure.

Regular ChatGPT conversations continue to work normally.

However, both Codex and ChatGPT Work are effectively unusable on my affected Pro account because almost every attempt fails with:

Selected model is at capacity. Please try a different model.

This has now been happening repeatedly for days and is having a serious impact on my work.

I am aware that many other users have reported similar capacity errors.

That makes this more concerning, not less.

Users paying for one of the highest-priced ChatGPT consumer tiers reasonably expect reliable access to the advanced tools included with that subscription. In my case, the tools I specifically depend on for engineering and production work — Codex and Work — have become unusable, while standard ChatGPT continues to operate normally.

At this point, this does not look like ordinary model capacity.

Subscription / account

ChatGPT Pro
Affected account details have already been provided privately to OpenAI Support.
I can provide the full account identifier privately to maintainers if needed.

I do not want to expose the full account email publicly in a GitHub issue.

Products affected

The issue affects:

Codex Web
Codex Desktop
Codex CLI
Interactive Codex CLI
ChatGPT Work

Regular ChatGPT chat continues to work normally.

Platforms tested

macOS
Codex Web
ChatGPT / Codex Desktop
Codex CLI

Environment

Codex CLI:

codex-cli 0.153.4

ChatGPT Desktop:

26.915.31945

macOS:

macOS 27.0

The Desktop application and macOS are fully updated.

Models affected

I have reproduced the problem across multiple models, including:

GPT-5.6 Sol
GPT-5.6 Terra
GPT-5.6 Luna

Changing models does not resolve the issue.

Even a completely trivial request fails.

Example:

Reply exactly: OK

Result:

Selected model is at capacity. Please try a different model.

This is not normal quota exhaustion

My Codex usage is still available.

I have verified that I am not at my normal usage limit.

The problem persists even when usage allowance remains available.

This is one of the main reasons I do not believe this is a normal quota-exhaustion case.

Strong evidence that this is account-specific

The most important diagnostic result:

Another OpenAI account works normally on the exact same Mac, same network, same application, and same environment.

In other words:

Affected account

Codex Web → FAIL
Codex Desktop → FAIL
Codex CLI → FAIL
Interactive CLI → FAIL
ChatGPT Work → FAIL
Multiple models → FAIL

Different OpenAI account

Using the same:

Mac
network
Codex installation
browser
general environment

Codex works normally.

This strongly suggests that the failure follows the account, not the device, network, repository, application installation, or model selection.

Minimal CLI reproduction

I intentionally removed as many local variables as possible:

codex exec \
  --ignore-user-config \
  --ephemeral \
  --skip-git-repo-check \
  -C /tmp \
  -s read-only \
  -m gpt-5.6-luna \
  -c 'model_reasoning_effort="low"' \
  --json \
  'Reply with exactly OK. Do not use tools.'

Have you made any improvements? Do you have a solution? I'm fluctuating between good and bad, and I basically can't use it

Navigation Menu

Repository navigation

Paid $200/month for GPT-6, getting capacity errors or degraded fallback instead — this is unacceptable #46189

Summary

Subscription

Product

Platform

Models affected

Failure mode 1: "Selected model is at capacity"

Failure mode 2: GPT-6 succeeds, but behaves nothing like normal GPT-6

Reproduction

Outcome A

Outcome B

This has been happening for days

I know there are already similar issues

Why I consider this a serious service failure

What I need OpenAI to investigate

Expected behavior

Support case

Codex `gpt-6-astra`: identical prompts return contradictory answers and 0-vs-206 reasoning tokens - please disclose which model served each response

Windows Codex: all selected models rejected with capacity despite remaining allowance

Summary

Subscription / account

Products affected

Platforms tested

Environment

Models affected

This is not normal quota exhaustion

Strong evidence that this is account-specific

Affected account

Different OpenAI account

Minimal CLI reproduction

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Paid $200/month for GPT-6, getting capacity errors or degraded fallback instead — this is unacceptable #46189

Description

Summary

Subscription

Product

Platform

Models affected

Failure mode 1: "Selected model is at capacity"

Failure mode 2: GPT-6 succeeds, but behaves nothing like normal GPT-6

Reproduction

Outcome A

Outcome B

This has been happening for days

I know there are already similar issues

Why I consider this a serious service failure

What I need OpenAI to investigate

Expected behavior

Support case

Activity

github-actions commented on Sep 17, 2026

EminMullaliev commented on Sep 19, 2026

Jiu-xiao commented on Sep 19, 2026

Controller-H commented on Sep 20, 2026

Codex gpt-6-astra: identical prompts return contradictory answers and 0-vs-206 reasoning tokens - please disclose which model served each response

TaoCultivator commented on Sep 21, 2026

eklim23 commented on Sep 21, 2026

Windows Codex: all selected models rejected with capacity despite remaining allowance

maurovideosmr-wq commented on Sep 21, 2026

quanthanhnguyen2910 commented on Sep 22, 2026

Summary

Subscription / account

Products affected

Platforms tested

Environment

Models affected

This is not normal quota exhaustion

Strong evidence that this is account-specific

Affected account

Different OpenAI account

Minimal CLI reproduction

2665207323 commented on Sep 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Codex `gpt-6-astra`: identical prompts return contradictory answers and 0-vs-206 reasoning tokens - please disclose which model served each response