GPT-6 Astra output quality dropped by half after account-level capacity throttling (same prompt, effort and client core) #44851
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.903.71938, bundling codex-cli 0.153.4. The two good runs below (09-08 and 09-09) were on 26.901.51231 with the same codex-cli 0.153.4.
What subscription do you have?
ChatGPT Pro
What platform is your computer?
macOS 26.5.2, Apple Silicon (arm64)
What issue are you seeing?
After my account was throttled with "Selected model is at capacity" (fully blocked on 2026-09-10 from 11:06 to about 18:00 UTC+8, intermittent since), gpt-6-astra produces much shallower work on this account. With the same prompt, the same reasoning effort and the same client core, output tokens, reasoning tokens and result quality all dropped by roughly half or more. The model also stopped verifying its own work.
Task (Chinese prompt): 创建一个HTML，内容是svg绘制一个鹈鹕骑自行车的2D动画，放到桌面上，以你模型名字命名文件 ("Create an HTML file with an SVG 2D animation of a pelican riding a bicycle, save it to the Desktop and name it after your model"). The 09-08 run and the 09-11 23:33 run used only the first sentence, word for word. The other runs used the full prompt. Screenshots of the 09-08 and 09-11 23:33 results are attached below.
| Run (UTC+8) | Effort | Where | Output tokens | Reasoning tokens | Wall time | Result |
|---|---|---|---|---|---|---|
| 09-08 19:07 | high | Desktop, projectless | 7,621 | 564 | 4m30s | 14.4 KB. JS-driven pedaling, pause and speed buttons. Opened it in the in-app browser to check, then refactored. |
| 09-11 19:31 | high | Desktop, projectless | 2,998 | 213 | ~1m50s | 5.8 KB. CSS-only animation, no controls. Wrote the file once and stopped. |
| 09-11 23:33 | high | Desktop, projectless, identical prompt to 09-08 | 3,758 | 395 | 1m40s | 6.8 KB, 30 SVG elements vs 93 on 09-08. Has pause and speed controls, but the pelican and bicycle are crude. No browser check. |
| 09-09 17:50 | ultra | Desktop, repo with AGENTS.md | 14,124 | 1,620 | 7m52s | 24.8 KB |
| 09-11 19:34 | ultra | Desktop, projectless | 8,909 | 848 | ~4m13s | 7.6 KB |
| 09-11 19:52–20:00 | ultra | codex exec --ignore-user-config --ephemeral, 3 runs, 1 with the same AGENTS.md |
5,568–6,503 | 431–1,116 | 2–4 min | 8.8–11.4 KB |
Token counts are main-thread totals summed from the rollout token_count events. Both desktop ultra runs spawned one sub-agent, which is excluded on both sides. One of the three CLI runs was cut off by a capacity error after writing its file, so its tokens are not included.
What I ruled out:
- Reasoning effort. Every sampling request in
logs_2.sqlitecarries the selected effort:highfor the high runs,ultrafor the ultra runs. There is no silent reset to medium (compare Astra reasoning level frequently reset to Medium #44668). - Model field and fallback. Every sampling request is sent as
gpt-6-astra. There are no fallback or model-switch events in the logs. - service_tier. It is not set in any of these runs, so none of them used
priority. - Client. The core binary is
codex-cli 0.153.4in all runs. The desktop shell changed, but thecodex execruns bypass the desktop app and the user config, and they show the same drop. - Context. The projectless desktop context on 09-08 and 09-11 differs only in plugin and skill list updates and a new "Inline Artifact Follow-Ups" formatting section. Adding the 09-09 repo's AGENTS.md back in a CLI run did not restore the output: 11.4 KB versus 24.8 KB.
- Prompt. On the same day,
gpt-5.6-solat ultra with the exact same prompt produced a 21.9 KB file, in the same range as the pre-throttling Astra output.
What steps can reproduce the bug?
On the affected account, run:
codex exec --ignore-user-config --ephemeral --skip-git-repo-check -C "$(mktemp -d)" -s workspace-write -m gpt-6-astra -c 'model_reasoning_effort="ultra"' --json '创建一个HTML，内容是svg绘制一个鹈鹕骑自行车的2D动画，放到当前目录下，以你模型名字命名文件'Compare the output tokens, reasoning tokens and file size with the pre-09-10 runs listed below. On 09-11 all three CLI runs landed at 8.8–11.4 KB, against 24.8 KB for the same prompt and effort on 09-09.
What is the expected behavior?
The same model at the same reasoning effort should work at a comparable depth before and after a capacity event. On this account before 09-10, Astra at high used about 7.6k output tokens and checked its own result in the browser, and Astra at ultra used about 14k output tokens.
If capacity is being managed by lowering the reasoning budget or serving a different model, the client should say so instead of labeling the response gpt-6-astra at the selected effort.
Additional information
Caveats:
- The sample is small: 2 runs before throttling and 6 after, and SVG generation is noisy. Still, all 6 post-throttling runs, including ultra, fall below the pre-throttling high run.
- I can't see which model actually served these requests, because the client only records the model it asked for (see Bug report: Sol subagents inherit GPT-6 identity instructions; serving-model provenance is unavailable in inspected records #44598). The knowledge-cutoff question doesn't help either: on this account both
gpt-6-astraandgpt-5.5answer "June 2024".
Thread IDs:
- 09-08 high, good:
01a080b3-baaf-74a1-912d-b9c29135ea27 - 09-09 ultra, good:
01a08593-d43a-7b83-9844-d0dde12688e9 - 09-11 high, degraded:
01a0903c-b518-7310-b242-ab1bac153be4 - 09-11 ultra, degraded:
01a0903f-b7cf-7491-b331-15b8f3323a7c - 09-11 23:33 high, identical prompt to 09-08, degraded:
01a09119-e84a-7570-aded-a11eb18fedd5
Related: #43329 (suspected Astra degradation), #43337 (account-specific capacity errors), #44598 (serving-model provenance).
Activity
github-actions commentedon Sep 11, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
a7217238 commentedon Sep 11, 2026
tiredIsa commentedon Sep 12, 2026
+1. GPT-6 Astra now feels roughly on the level of GPT-5.6 Sol Low, if not worse.
At this point I don't even think you need controlled benchmarks to notice it - the regression is that obvious. I genuinely don't understand why this is being brushed off as if nothing changed.
Leaving my feedback ID here in case this is actually useful to someone investigating it:
01a0943f-9c0f-7283-aaf9-b2c54e2f26872665207323 commentedon Sep 14, 2026
Update (September 14, 2026, UTC+8): Codex is currently completely unusable for me. Every request is repeatedly blocked by:
"Selected model is at capacity. Please try a different model."
This is no longer an occasional interruption. Retrying or switching models does not provide a reliable recovery path. When a request does get through after repeated retries, the output is substantially shallower and the task often stops without verification, consistent with the quality degradation described in the issue body.
Current impact: I cannot use Codex to complete normal development work at all. Please investigate whether this is account-level throttling/routing or a broader capacity problem, and provide a way to restore access or preserve and resume affected tasks.
2665207323 commentedon Sep 14, 2026
Additional update — September 14, 2026, 20:45 UTC+8:
I ran another controlled test using the same Chinese prompt for an SVG 2D animation of a pelican riding a bicycle. The Codex request/retry experience remains unreliable: repeated attempts can hit the capacity error, and the first generated result was not usable for the intended task. After that, I generated a standalone local HTML artifact as a control test without network access; it was 10,213 bytes, contained one inline SVG and local CSS/JavaScript animation, and referenced no external HTTP resources.
This comparison suggests the problem is not that the requested artifact inherently requires network access. The issue is the Codex execution path: capacity failures interrupt the task, retries do not reliably preserve the expected depth or quality, and the user is left to reconstruct or finish the work manually. The local control can complete the same basic artifact when the model is able to run, but it does not restore Codex access or explain why the selected model becomes unavailable.
Current status: I still cannot reliably use Codex for normal development work. Please correlate the repeated failures and the quality drop with account-level routing/throttling and serving-model telemetry, and preserve the task state across retries.
2665207323 commentedon Sep 14, 2026
Account-linking clarification:
The GitHub account used to post this issue is not the same identity as the ChatGPT/Codex account experiencing the failures. Please do not use the GitHub username as the account identifier. The Codex thread IDs, timestamps, model/effort details, and diagnostic information already included in this issue should be used to correlate the affected Codex account and backend telemetry.
No personal account information needs to be exposed publicly; the existing Codex diagnostic identifiers are provided only to help investigate the account-specific capacity/throttling and output-quality regression.
2665207323 commentedon Sep 14, 2026
Local diagnostic evidence from the affected Windows Codex Desktop installation (sanitized; no tokens, email, or account secrets):
26.901.41600at the time of the failure; the current installation is26.908.40834.2026-09-10 09:58:00 UTC+8(2026-09-10T01:58:00Z)Structured turn failed: Selected model is at capacity. Please try a different model.ambient-suggestions-background-refreshwithstatus=failed.01a08908-d57b-74c0-b683-52e36a0817bd.01a0805c-294c-7003-9895-bf07857021cb.This gives the team concrete timestamps and Codex conversation identifiers to correlate with server-side account/model routing and capacity telemetry. The local logs also show the desktop app and app-server initializing successfully, so the evidence does not point to a simple local startup failure. Please check whether the capacity response is being generated by the account/model admission path and whether the failed turn can be retried without losing state.
brodrigz commentedon Sep 28, 2026
Its obviously getting routed to older models, just ask it about any major events within astra's supposed knowledge cutoff date, when it's performing badly it also mysteriously stops knowing about anything that happened after august 2025.
It's infuriating that OpenAI can just do this claiming its because of their "anti-distillation policies" and still charge you normally, when its clearly affecting normal users.