gpt-6-astra is served as gpt-5.6-luna (runtime model substitution) on a Plus account, plus 47 spurious "Selected model is at capacity" errors

Summary

On this ChatGPT Plus account (ChatGPT auth), Codex Desktop and the Codex CLI request gpt-6-astra but the server
serves gpt-5.6-luna. The substitution is deterministic (all traced runs, all reasoning efforts), while
gpt-5.6-sol, gpt-5.6-luna, gpt-5.6-terra and gpt-5.5 are served correctly in the same minutes on the
same machine and network.

Concurrently the account received 47 Selected model is at capacity. Please try a different model. errors over
2026-09-17..2026-09-19 while quota was at 1-3% of the 5-hour window.

Environment

Codex Desktop: OpenAI.Codex 26.915.4065.0 (MSIX, Windows x64), bundled core codex-cli 0.155.0-alpha.9.2
Account: ChatGPT Plus (masked account id 2ad83b05..aca2)
Transport: since the 2026-09-18 update, sampling uses the websocket transport (no HTTP x-oai-request-id)

Evidence A - requested vs served model

Captured from the raw websocket frames the client receives (RUST_LOG=trace). The model field of the server
response object is the model that was actually served.

Local time (UTC+08:00)	Requested	Served (server response object)	Response ID
2026-09-19 19:30:14	gpt-6-astra	gpt-5.6-luna	`resp_0cf037ec2ca05ffc016aae724b73c487d0bab5f9eece9d7690`
2026-09-19 19:19:01	gpt-6-astra	gpt-5.6-luna	`resp_000cb07482a11305016aae6fa8923c87d09f63874702692059`
2026-09-19 19:13:40	gpt-6-astra	gpt-5.6-luna	`resp_0a1d2160dd2ec118016aae6e6732fc87d0a796f6b48cacf18a`
2026-09-19 14:12-14:17 (low)	gpt-6-astra	gpt-5.6-luna	`resp_0ead3613c3edb4d6016aae289a922887d09932f686526a7d36`
2026-09-19 14:12-14:17 (medium)	gpt-6-astra	gpt-5.6-luna	`resp_05c8daf3309878ac016aae28a9d4d487d0abae831de1db0cfd`
2026-09-19 14:12-14:17 (high)	gpt-6-astra	gpt-5.6-luna	`resp_0f1abcf89c482a74016aae28c36d6487d0ba73b7646a861823`
2026-09-19 14:12-14:17 (xhigh)	gpt-6-astra	gpt-5.6-luna	`resp_003936d7bea4c58c016aae28d9cccc87d0bfeadf6d38509871`

Control group, same account / machine / network:

Local time (UTC+08:00)	Requested	Served	Response ID
2026-09-19 13:30-13:34	gpt-5.6-sol	gpt-5.6-sol (correct)	`resp_09b43d209c0af1de016aae280fc1d887d0821a41ee640be40a`
2026-09-19 13:30-13:34	gpt-5.6-luna	gpt-5.6-luna (correct)	`resp_0b8ebef5973051fe016aae281f2f8087d0bb469f1bbe3f90bc`
2026-09-19 13:30-13:34	gpt-5.6-terra	gpt-5.6-terra (correct)	`resp_011eb02907ae72d0016aae286531b087d084fff8d13b328bff`
2026-09-19 13:30-13:34	gpt-5.5	gpt-5.5 (correct)	`resp_0e3355198b2b60fd016aae2875dfe087d09d775d24ebcbd57a`

Verbatim server frame for the high run above (request made with -m gpt-6-astra):

{"type":"response.created","response":{"id":"resp_0f1abcf89c482a74016aae28c36d6487d0ba73b7646a861823",
"object":"response","created_at":1789798595,"status":"in_progress","error":null,
"model":"gpt-5.6-luna","moderation":null,"output":[],
"reasoning":{"context":"all_turns","effort":"high","mode":"standard","summary":null},
"service_tier":"auto","store":false}}

The same responses also carried these headers:

x-codex-safety-buffering-enabled: true
x-codex-safety-buffering-faster-model: gpt-5.6-luna

gpt-6-astra is still listed as selectable in the model catalog (visibility: list, supported_in_api: true,
context window 272000), so this is a runtime substitution, not a missing entitlement.

Evidence B - "Selected model is at capacity" while quota was intact

47 occurrences across 23 threads: 2026-09-17 (44), 2026-09-18 (2), 2026-09-19 (1)
First: 2026-09-17 19:06:09 (+08:00) = 11:06:09Z; last: 2026-09-19 13:31:42 (+08:00) = 05:31:42Z
Models involved: gpt-5.6-sol 25, gpt-5.6-luna 13, gpt-6-astra 6, gpt-5.5 1
Quota headers returned during the failures: x-codex-primary-used-percent: 1-3 (5h window),
x-codex-secondary-used-percent: 34-67 (weekly), x-codex-plan-type: plus
The log contains zero HTTP 429s: the rejection is delivered inside an HTTP 200 stream
HTTP-transport request IDs from that window (before the websocket switch):
2237d65a-98b6-40a7-84a6-9df66a1af920 (2026-09-17 20:59:53 +08:00),
d34cce49-59bb-45b6-be2a-d31612110785 (20:59:55),
7d949d1b-6f13-43ab-afe2-641d1423533f (21:00:10)

Reproduction

$env:RUST_LOG='trace'
codex exec --skip-git-repo-check -s read-only -m gpt-6-astra "Say hi in one word." *>&1 | Out-File trace.log -Encoding utf8
Select-String -Path trace.log -Pattern '"model":"'   # -> "model":"gpt-5.6-luna"  (served)
Select-String -Path trace.log -Pattern 'model=gpt-'  # -> gpt-6-astra            (requested)

Already tried, issue persists

Password reset, authenticator-app MFA enabled, all active sessions terminated, full re-authentication
(Codex Desktop + CLI) - the substitution was reproduced again afterwards (2026-09-19 19:30:14 +08:00).
No client update is available: installed OpenAI.Codex 26.915.4065.0, winget upgrade reports nothing, and this
build has no "Check for Updates" UI item.

Expected

The server response object should report "model":"gpt-6-astra" when gpt-6-astra is requested.

Actual

The server reports "model":"gpt-5.6-luna".

Support-side handles

In-app feedback session ID: 01a0b824-3d99-71e3-98a8-2c9a236ea3da
Machine-readable export (counts, per-error list, request IDs, quota headers) available on request.

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

Paid $200/month for GPT-6, getting capacity errors or degraded fallback instead — this is unacceptable #46189
[Windows] "Selected model is at capacity" for 6 consecutive days across all models and reasoning efforts (ChatGPT Plus) #46162
Account-scoped "Selected model is at capacity" on a Pro account since Sept 14 - cross-over test shows it follows the account, not the machine or network #46231
Selected model is at capacity (server_overloaded) at 0% weekly usage on Pro Lite — Sol and Astra #46211

Powered by Codex Action

fix: restore Codex tier ladder, Opus on Sol and Sonnet on Terra

Independent reproduction + uploaded diagnostics

I am independently reproducing the same Astra → Luna runtime model substitution.

Environment:

Windows
Codex CLI 0.155.1
ChatGPT sign-in
Personal workspace

In the Codex CLI /model picker, gpt-6-astra is explicitly listed as available and is marked as the default model.

In the traced run:

requested model: gpt-6-astra
reasoning effort: xhigh
served model in response.created: gpt-5.6-luna

Response ID:
resp_0e3f5df2c873517e016aafe36387d487d0ba38dd12026e9de8

Turn ID:
01a0bf10-1829-7903-89bf-01cea536cad4

Timestamp:
2026-09-20T13:45:06.941643Z

I also logged out of Codex CLI and freshly re-authenticated through ChatGPT, but the same Astra → Luna mismatch persisted.

I initially noticed a significant degradation in reasoning quality during normal use of Codex Desktop, together with intermittent:

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

I then used Codex CLI as a controlled diagnostic environment because it allowed me to capture the raw trace.

I have also noticed a clear recent decline in reasoning quality from gpt-5.6-sol, which is my primary model, even in runs where the server still reports that gpt-5.6-sol itself is being served.

Codex /feedback diagnostics were uploaded successfully.

Uploaded feedback/thread ID:
01a0bf63-6de1-7e23-8678-401afe277895

The raw response.created event for the affected request reports:

"model":"gpt-5.6-luna"

while the request context shows:

model=gpt-6-astra
codex.request.reasoning_effort=xhigh

OpenAI Support also confirmed to me that the model field in response.created is the model that actually served the request, and that my logs are consistent with a server-side routing/fallback rather than just a UI/model-picker issue.

Please use the uploaded feedback thread together with the Response ID, Turn ID, and timestamp above for investigation.

This issue is seriously affecting my normal work with Codex, and I hope it can be identified and resolved soon.

Independent reproduction #3 — 235 traced responses in one session, 2 hard-correlated Astra→Luna mismatches, same-window controls

Third independent trace. Single capture session (2026-09-21, ~19:05–20:33 UTC), Codex Desktop on Windows, ChatGPT sign-in, Pro plan. Client config throughout the session: model="gpt-6-astra", model_reasoning_effort="medium", service_tier="default".

Method: passive capture of server WebSocket frames on chatgpt.com/backend-api/codex/responses; served_model = server-authored root.response.model. request_model comes from local Codex logs_2.sqlite rows correlated by response ID / turn telemetry. No prompts, cookies, authorization headers, or credentials captured.

Hard-correlated mismatches (local request log vs server response.model):

Completed UTC	Requested	Served	Response ID	Turn ID
2026-09-21 19:06:39	gpt-6-astra	gpt-5.6-luna	`resp_0f92e4f8dde5c806016ab1801d999087d08f3293d713975ad7`	`01a0c55b-b811-7df3-bf8d-51f494914682`
2026-09-21 19:14:19	gpt-6-astra	gpt-5.6-luna	`resp_0f92e4f8dde5c806016ab18202e0e887d0af26d60524381379`	`01a0c563-c89b-7432-a864-29abf968709c`

Served-model distribution, 235 completed responses in the same session:

Served model (`root.response.model`)	Completed responses
`gpt-5.6-luna`	196
`gpt-5.6-sol`	17
`gpt-6-sol`	12
`gpt-6-astra`	10

Same-window controls rule out client-side explanations:

All 5 explicitly requested gpt-5.6-sol runs (19:12–19:21) were served correctly as gpt-5.6-sol.
All 12 gpt-6-sol runs (19:38–19:41) were served correctly as gpt-6-sol — same account, same machine, same minutes. The substitution is model-specific, not account-wide degradation.
gpt-6-astra was served only inside two brief windows: 1 response at 19:42 (resp_09f8959d07d8f956016ab188860d4887d084730da7e64ae6ea) and 9 responses at 20:17–20:19 (e.g. resp_050799acf28de463016ab190f568c887d0b13c9c1b4a1d4833, resp_0b71bffa936f59bd016ab190ff565c87d0889903708fcf4dd6). Before, between, and after those windows, Astra selections were served Luna — with zero client-side changes. The routing state flipped server-side twice within one session.
~30 consecutive client retries between the two Astra windows (19:44–19:54) all returned Luna.

At capture start, Settings → Usage showed ~20% of the regular allowance remaining. No Luna Reserve notice, no "at capacity" error, and no HTTP 429s appear in the capture.

A SHA-256-manifested redacted evidence bundle (raw JSONL, request/response correlation tables, config excerpt) is preserved and can be uploaded via /feedback if a maintainer wants the full set.

Related: #47015 (adapter-side trace of the same mismatch), #46189, #46231.

feat(accounting): record the model the upstream declares it served

Independent reproduction #3 — 235 traced responses in one session, 2 hard-correlated Astra→Luna mismatches, same-window controls

Third independent trace. Single capture session (2026-09-21, ~19:05–20:33 UTC), Codex Desktop on Windows, ChatGPT sign-in, Pro plan. Client config throughout the session: model="gpt-6-astra", model_reasoning_effort="medium", service_tier="default".

Method: passive capture of server WebSocket frames on chatgpt.com/backend-api/codex/responses; served_model = server-authored root.response.model. request_model comes from local Codex logs_2.sqlite rows correlated by response ID / turn telemetry. No prompts, cookies, authorization headers, or credentials captured.

Hard-correlated mismatches (local request log vs server response.model):

Completed UTC Requested Served Response ID Turn ID
2026-09-21 19:06:39 gpt-6-astra gpt-5.6-luna resp_0f92e4f8dde5c806016ab1801d999087d08f3293d713975ad7 01a0c55b-b811-7df3-bf8d-51f494914682
2026-09-21 19:14:19 gpt-6-astra gpt-5.6-luna resp_0f92e4f8dde5c806016ab18202e0e887d0af26d60524381379 01a0c563-c89b-7432-a864-29abf968709c
Served-model distribution, 235 completed responses in the same session:

Served model (root.response.model) Completed responses
gpt-5.6-luna 196
gpt-5.6-sol 17
gpt-6-sol 12
gpt-6-astra 10
Same-window controls rule out client-side explanations:

All 5 explicitly requested gpt-5.6-sol runs (19:12–19:21) were served correctly as gpt-5.6-sol.

All 12 gpt-6-sol runs (19:38–19:41) were served correctly as gpt-6-sol — same account, same machine, same minutes. The substitution is model-specific, not account-wide degradation.

gpt-6-astra was served only inside two brief windows: 1 response at 19:42 (resp_09f8959d07d8f956016ab188860d4887d084730da7e64ae6ea) and 9 responses at 20:17–20:19 (e.g. resp_050799acf28de463016ab190f568c887d0b13c9c1b4a1d4833, resp_0b71bffa936f59bd016ab190ff565c87d0889903708fcf4dd6). Before, between, and after those windows, Astra selections were served Luna — with zero client-side changes. The routing state flipped server-side twice within one session.

~30 consecutive client retries between the two Astra windows (19:44–19:54) all returned Luna.

At capture start, Settings → Usage showed ~20% of the regular allowance remaining. No Luna Reserve notice, no "at capacity" error, and no HTTP 429s appear in the capture.

A SHA-256-manifested redacted evidence bundle (raw JSONL, request/response correlation tables, config excerpt) is preserved and can be uploaded via /feedback if a maintainer wants the full set.

Related: #47015 (adapter-side trace of the same mismatch), #46189, #46231.

Thanks for the careful reproduction. Your trace is important because it shows that Astra → Luna substitution is not an isolated event and can change dynamically within the same session. That deserves serious investigation.

One caution, though: the fact that your gpt-5.6-sol control requests were returned as gpt-5.6-sol does not necessarily mean Sol is unaffected.

On my side, Sol’s reasoning quality has clearly degraded compared with its previous behavior. I am not claiming that Sol has been proven to be substituted like Astra, but there are several independent signals worth considering:

#46747: reproducible Sol High quality regression in Codex Desktop, with logs confirming gpt-5.6-sol + High and no explicit server_overloaded, yet much worse output and heavy context replay / agent-loop overhead.
#41222: broader GPT-5.6 Sol behavioral regression in real repository work, including weaker instruction-following, loss of recent constraints, over-engineering, and unstable task scope.
#41450: controlled A/B showing that Codex orchestration/tool scheduling can amplify repeated context by more than 80%, meaning the effective behavior seen by the user can degrade substantially even when the model is still labeled Sol.
There are also lower-level community traces where response.model remains Sol while other internal engine/timing metadata appears Luna-related. Those fields are undocumented, so this is not proof of Sol → Luna substitution, but it is worth investigating.

I also have a simple behavioral regression on my own account: a candy benchmark that gpt-5.6-sol xhigh previously solved correctly with 21 now repeatedly fails with 29.

So my point is:

A correct response.model = gpt-5.6-sol only shows how the response is labeled. It does not by itself prove that the Sol serving path, reasoning budget, model snapshot, or orchestration behavior is unchanged and healthy.

Astra now has direct substitution evidence. Sol does not have that same level of proof, but there is already substantial independent evidence of regression.

Thanks again for the trace — I hope OpenAI investigates both the Astra routing issue and the Sol degradation rather than treating the Sol control as proof that everything outside Astra is normal.

Follow-up to reproduction #3 — extended 14 h continuous capture: Astra delivery is windowed/rationed, x-codex-turn-state shape flips in lockstep with served model, and turn-state injection is A/B-tested with no measurable effect

Same account, same machine, same method as my earlier comment (passive capture of server WebSocket frames on chatgpt.com/backend-api/codex/responses; served_model = server-authored root.response.model). Client requested gpt-6-astra throughout except where noted. No prompts, cookies, authorization headers, or credentials captured.

1. Extended dataset (2026-09-21 19:05 UTC → 2026-09-22 08:55 UTC, 926 response.created events):

Served model	Completed responses	Share
`gpt-5.6-luna`	764	82.5%
`gpt-5.6-sol`	92	9.9%
`gpt-6-sol`	14	1.5%
`gpt-6-astra`	56	6.0%

2. Astra was served only inside ~9 short windows; both window length and per-window yield shrank over the day:

Window (UTC)	Astra responses	Approx. duration
19:41	1	—
20:17–20:19	9	~90 s
21:22–21:25	8	~160 s
22:27–22:30	9	~180 s
23:33–23:37	5	~190 s
02:17–02:21	8	~230 s
04:29	1	—
06:34–06:37	8	~190 s
08:40–08:43	7	~185 s

Inter-window gaps grew from ~65 min (morning) to 125–126 min (the two most recent, best-sampled gaps). Outside these windows every Astra request returned Luna/Sol with zero client-side changes. Representative IDs: window open 2026-09-22T06:34Z resp_03c1e495703203e0016ab22177973c87d09ff953800cbe2d64 (served gpt-6-astra); post-close 2026-09-22T08:44Z resp_0478a23bc8b682a8016ab23fce2ec087d0b1dee45a5a023d86 (served gpt-5.6-luna, same client config minutes later).

3. Quota context: the server-sent rate_limits message shows the primary 10080-minute (7-day) window at 88% consumed at ~2026-09-22 05:30 UTC, with ~32.5 h to reset — i.e. substitution continued while ~12% of the weekly allowance remained.

4. x-codex-turn-state shape correlates with served model (per-response granularity). The state arrives inline in codex.response.metadata headers. Two shapes observed: 292 chars vs 312 chars (differ by exactly one 16-byte block). In the two fully instrumented windows (06:34Z and 08:40Z), every Astra-served response carried a 292-char state and every Luna-served response a 312-char state (8/8 and 5/5 respectively), including one flow where the server flipped 292→312 mid-conversation exactly when Luna resumed. Across the full capture: 16 sightings of 292 vs 398 of 312. Disclosure: two 292 sightings at ~03:22 UTC had no Astra served that hour, so the 292 shape is best described as a strong correlate of the routing state, not a perfect one.

5. Turn-state injection does not restore Astra (randomized A/B test). Using a mitm addon that replays the flow's first harvested turn-state into client_metadata of subsequent response.create frames (per the per-turn contract in codex-rs client.rs), alternating flows INJECT/CONTROL: CONTROL flows received Astra inside windows, and INJECT flows received Luna outside windows (n ≈ 70 flows). Within the scope of same-flow replay, the turn-state behaves as a marker of the routing state, not a lever — third-party "state injection" tools circulating in the community do not appear to affect model selection.

6. Possibly separate phenomenon — effort=low returns empty turns: explicit gpt-6-astra requests with reasoning effort low completed with zero assistant content (no message; tokens still counted), reproducible across ~20 attempts, while medium/xhigh completed normally on the same account minutes apart.

A SHA-256-manifested redacted evidence bundle (raw JSONL, per-flow request/serve correlation, injection logs) is preserved and can be uploaded via /feedback if a maintainer wants the full set.

Related: #47015, #46189, #46231.

I observed the same Astra → Luna model mismatch independently on Windows Codex Desktop on September 22 (Asia/Shanghai). Three requests for gpt-6-astra reported gpt-5.6-luna; a gpt-5.6-terra control request reported the expected model. I did not see a usage-limit or fallback notice. The observation and probe are documented in #47284. I will close that issue as a duplicate so discussion can continue here.

Independent report: Pro plan, Codex Desktop on Windows. Support confirms the account is limited, response.model still says gpt-6-astra, output quality is degraded, no notice is shown, and usage is billed as Astra

This adds a different angle to the Astra → Luna reports above. On my account the server-reported model is still gpt-6-astra, yet output quality dropped sharply at the same time. OpenAI Support has now confirmed four times that model access on my account is limited. So the model field on its own may not be enough to tell whether you are getting the full Astra service.

Environment

ChatGPT Pro (x-codex-plan-type: pro), personal account, ChatGPT sign-in
Codex Desktop 26.924.22138 (latest; MSIX package 26.924.2738.0, app-server 0.158.0-alpha.2.1), Windows 11
Codex CLI 0.155.1, same ~/.codex and the same ChatGPT login as Desktop
Usage at the time: weekly allowance 47% used, no 5-hour window, rate_limit_reached_type: null

What happened

In Codex Desktop, the same prompt ("create an HTML page with an SVG 2D animation of a pelican riding a bicycle", gpt-6-astra) produced a good result on 2026-09-27 and a clearly broken one on 2026-09-28. The app kept showing gpt-6-astra. There was no reroute notice, no usage-limit notice and no safety notice.

Codex Desktop uses the WebSocket transport, so I could not capture `response.model` for these turns. Response IDs from the rollout file, for OpenAI staff:

Time (UTC)	Surface	Requested	Response ID
2026-09-27 04:01	Desktop	gpt-6-astra (medium)	`resp_05ea14b4735fd2dd016ab8947a170087d0af95ec3118f955ef` (good result)
2026-09-28 14:37	Desktop	gpt-6-astra (high)	`resp_0280368aaa485af7016aba7af1541087d0a6ab286e7597167b` (bad result)

Feedback session ID (submitted with /feedback in the affected thread): 01a0e86d-9bf2-7a61-8791-a589fd051bcc

Trace: CLI over HTTP reports `gpt-6-astra`

Same account, 2026-09-28. Codex CLI with supports_websockets=false, features.memories=false, and RUST_LOG=codex_api=trace,codex_http_client=debug. The served model is response.model from the server's response.created event.

Time (UTC)	Requested	Served (`response.model`)	`x-oai-request-id`	Result
15:01:09	gpt-6-astra (low)	gpt-6-astra	n/a	OK
15:07:32	gpt-6-astra (high)	gpt-6-astra	`7a61e7a1-ca7b-4b36-890f-94cfdbd39cdc`	`Selected model is at capacity` inside an HTTP 200 stream
15:08:02	gpt-6-astra (high)	gpt-6-astra	`0240d455-a5a4-49ac-8eae-03e89e1c1518`	OK
15:08:48	gpt-6-astra (high)	gpt-6-astra	`ba7c7326-7a9d-44c8-85b8-debc81f6f1c3`	OK
15:09:24	gpt-6-astra (high)	gpt-6-astra	`8fb50a6d-1acc-42fe-8276-7e626399529b`	OK
15:10:19	gpt-6-sol (control)	gpt-6-sol	`1144ab99-2aca-420f-b07a-bf346b62b70b`	OK
15:18:59	gpt-6-astra (high), pelican prompt	gpt-6-astra	`1ffa9894-8339-41fc-8ba7-b8599c2f0de1`	Output quality similarly poor

So on this account, response.model said gpt-6-astra (reasoning.effort: high, access_programs.cyber: standard), but the same pelican prompt still produced a poor result. This is a single sample, and pelican drawings vary between runs, so I don't treat it as proof. It is consistent with the account-level limitation that support confirmed.

What OpenAI Support says

I contacted support four times: by chat, by email, and by replying to the ticket asking for a human agent and saying this is a billing dispute. Every reply was the same AI-generated template. The core of it is: "Access to certain models or features may be temporarily limited". The template also says no further details can be given, that access is "automatically reassessed" and can return to normal once "the activity affecting availability" stops, and it links to the Terms of Use and Troubleshooting Model Feature Access Issues. None of my requests reached a human.

Notes that may help others checking their own traces

Luna entries can come from Codex memories. With features.memories = true, Codex runs background memory-extraction requests on gpt-5.6-luna, which show up in traces and usage. Disable memories when testing, or you may count them as substitutions.
The 292 / 312 x-codex-turn-state heuristic no longer applies to me. Since 2026-09-28 every response carries a 780-character turn-state, on both Astra and Sol.
x-codex-safety-buffering-faster-model is now gpt-6-luna. Earlier it was gpt-5.6-luna.
Tracing the CLI: codex exec waits for stdin unless you redirect < /dev/null.

Asks for OpenAI

If an account's model access is limited, show it in the client (Codex has model/rerouted and usage-limit notices; neither appeared) instead of keeping gpt-6-astra displayed.
Don't bill limited or substituted requests at the Astra rate, or restore the allowance charged during the limitation.
Give at least the category of the limitation (usage, security, Terms of Use, cyber safety) and a working path to human review. "Stop the activity" cannot be acted on if the activity is never named.

I am seeing a similar concern on a current ChatGPT Pro account using Codex on Windows x64 (codex-cli 0.160.0). The client configuration requests GPT-6-Astra with max reasoning, and the current session footer shows GPT-6-Astra max fast, but the user reports repeated output quality consistent with a lower-capability fallback and severe disruption to ongoing work. The client does not expose the server response model, so the suspected substitution cannot be verified locally.

The official /feedback route was submitted without logs, but it produced no human case or resolution. Current visible account telemetry showed ordinary usage allowed, no spend-control lock, and no rate-limit-reached type. Please investigate whether this issue is still active for Pro accounts, how users can capture the actual served model, and whether account-specific routing or rollout state is involved.

Navigation Menu

Repository navigation

gpt-6-astra is served as gpt-5.6-luna (runtime model substitution) on a Plus account, plus 47 spurious "Selected model is at capacity" errors #46632

Summary

Environment

Evidence A - requested vs served model

Evidence B - "Selected model is at capacity" while quota was intact

Reproduction

Already tried, issue persists

Expected

Actual

Support-side handles

Environment

What happened

Trace: CLI over HTTP reports `gpt-6-astra`

What OpenAI Support says

Notes that may help others checking their own traces

Asks for OpenAI

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

gpt-6-astra is served as gpt-5.6-luna (runtime model substitution) on a Plus account, plus 47 spurious "Selected model is at capacity" errors #46632

Description

Summary

Environment

Evidence A - requested vs served model

Evidence B - "Selected model is at capacity" while quota was intact

Reproduction

Already tried, issue persists

Expected

Actual

Support-side handles

Activity

github-actions commented on Sep 19, 2026

LogTruSoul commented on Sep 20, 2026

maurovideosmr-wq commented on Sep 21, 2026

LogTruSoul commented on Sep 22, 2026

maurovideosmr-wq commented on Sep 22, 2026

YingboJiang commented on Sep 23, 2026

wandugu commented on Sep 29, 2026

Environment

What happened

Trace: CLI over HTTP reports gpt-6-astra

What OpenAI Support says

Notes that may help others checking their own traces

Asks for OpenAI

ZZZZZZbh commented on Oct 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Trace: CLI over HTTP reports `gpt-6-astra`