Repository navigation
[Windows 10 19045] GPT-6.1 Sol: persistent "at capacity" / HTTP 503 with 94% quota remaining (Oct 12-13), corroborating #52812 / #53407 #53559
Description
Summary
Since 2026-10-12 10:20 (UTC+8), Codex on Windows fails on all 7 available models with Selected model is at capacity. Please try a different model. and, at the HTTP layer, unexpected status 503 Service Unavailable. Still ongoing as of 2026-10-13 11:43 (UTC+8) — over 25 hours.
This is not a quota issue and not a local/network issue; the failing requests themselves carry response headers proving a 94%-remaining allowance.
Environment
- OS: Windows 10 Pro 22H2, build 19045 (same build as Codex "Selected model is at capacity" / server_overloaded on trivial first turn (Web + Windows app) #52812)
- Codex Desktop (MSIX
OpenAI.Codex) 26.930.4958.0, bundled codex-cli 0.160.0 - Account: ChatGPT Pro (
plan_type: "pro"), active until 2026-10-19 - Models:
gpt-6.1-sol(reasoning high),gpt-6-astra,gpt-6-sol,gpt-6-luna,gpt-5.6-sol,gpt-5.6-luna,gpt-5.6-terra - Log source:
~/.codex/logs_2.sqlite, tablelogs, columnfeedback_log_body
Quantified errors
| Error | 2026-10-12 | 2026-10-13 (→11:43) | Total |
|---|---|---|---|
Selected model is at capacity |
44 | 15 | 59 |
unexpected status 503 Service Unavailable |
0 | 25 | 25 |
Failed to run pre-sampling compact |
— | 17 | 17 |
Models affected: gpt-6-astra 20, gpt-6.1-sol 11, gpt-6-luna 10, gpt-6-sol 8, gpt-5.6-luna 5, gpt-5.6-sol 4, gpt-5.6-terra 1.
First occurrence 2026-10-12 10:20:19, latest 2026-10-13 11:43:49.
25 HTTP 503 timestamps on 2026-10-13 (UTC+8):
10:14:21, 10:14:34, 10:48:50, 10:50:13, 11:17:45, 11:21:47, 11:22:24, 11:23:23, 11:26:13, 11:26:34, 11:28:00, 11:29:03, 11:29:18, 11:31:25, 11:31:31, 11:32:03, 11:32:31, 11:32:57, 11:34:21, 11:41:29, 11:42:40, 11:42:45, 11:42:49, 11:43:28, 11:43:35
Server-side vs client-side (last 60 minutes)
| Direction | Log signature | Count |
|---|---|---|
| Server rejected | unexpected status 503 |
23 |
| Client/transport failure | error sending request |
0 |
| Client timeout | is_timeout=true |
0 |
| WS fallback | Falling back from WebSockets to HTTPS transport |
0 |
| WS closed | websocket ... closed |
0 |
A 503 is a complete HTTP response → the request reached OpenAI and was rejected server-side.
Raw log excerpt
[2026-10-13 11:43:35] WARN codex_core::responses_retry
retries=1 max_retries=5 sampling_error=unexpected status 503 Service Unavailable:
An error occurred while processing your request. You can retry your request,
or contact us through our help center at help.openai.com if the error persists.
[2026-10-13 11:36:31] INFO codex_core::session::turn
session_run:run_turn: Turn error: Selected model is at capacity. Please try a different model.
[2026-10-13 10:14:34] WARN codex_core::responses_retry
compact_error=unexpected status 503 Service Unavailable: ...
Proof the account is not rate-limited
GET https://chatgpt.com/backend-api/wham/usage:
{"plan_type":"pro",
"rate_limit":{"allowed":true,"limit_reached":false,
"primary_window":{"used_percent":6,"limit_window_seconds":604800}},
"credits":{"has_credits":true,"overage_limit_reached":false,"balance":"62381.9437950000"},
"spend_control":{"reached":false},
"rate_limit_reached_type":null}Response headers attached to the failing requests themselves (2026-10-13 11:43:46):
x-codex-plan-type = pro
x-codex-primary-used-percent = 6 # 94% of the 7-day window unused
x-codex-credits-has-credits = True
x-codex-credits-balance = 62381.9437950000
x-codex-primary-window-minutes = 10080
x-codex-secondary-used-percent = 0
(Compare #52812: x-codex-primary-used-percent = 7, x-codex-credits-balance = 62500.)
Proof the local environment is healthy
| Test | Result |
|---|---|
TLS handshake to chatgpt.com:443 |
20/20 success, avg 129 ms, jitter 23 ms |
wss://chatgpt.com/backend-api/codex/responses Upgrade |
HTTP/1.1 101, held 62 s without being dropped |
| 5 MB download | 5.5 MB/s |
| Domestic-site control | 39 / 47 ms |
| Local transport errors (last 60 min) | 0 |
A local proxy DNS misconfiguration was found and fixed before this report (handshake improved 5131 ms → 129 ms); the 503s continued afterwards.
Already tried (all ineffective)
Switching across all 7 models · new threads · full client restart · machine reboot · re-login · changing egress region · reducing per-request payload size.
Request IDs
| Time (UTC+8) | request id | cf-ray |
|---|---|---|
| 2026-10-13 11:43:46 | ea86d99e-cdb3-4593-b8aa-865448246d7e |
a49b5a090de8d1d7-ICN |
| 2026-10-13 10:25:59 | e7348878-4aea-4ece-ac9a-024090660d8f |
a49ae7e13839f255-KHH |
| 2026-10-13 10:25:15 | 5f95e6f1-79e6-4408-8f9a-50300f96156a |
a49ae6b19f6bf24c-KHH |
Related reports (corroboration)
#52812 (same Windows build 19045, failure on a two-character prompt, internal classification codex_error_info: server_overloaded, error rate 0.1% → 4.5% over 6 days) · #53407 (GPT-6.1 Sol xhigh, 2026-10-10–12) · #46149 (Pro x20, 65% remaining, raw upstream "Our servers are currently overloaded") · #46969 (Pro x20, 86% remaining) · #43752 (Pro 20x, Windows, unusable one week) · #45901 · #38157 (Pro 20x provisioned at 5x capacity)
Ask
- Correlate the request IDs above and confirm whether this is
server_overloadedand/or account-level mis-routing to a constrained capacity pool. - Provide root cause and ETA.
- Consider automatic retry/queueing/degraded fallback instead of a hard user-facing error after tool work has already completed.
Activity
github-actions commentedon Oct 13, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
kriouerlia commentedon Oct 13, 2026
Update 2026-10-13 (UTC+8) — still failing, now with a pinned egress IP
The failure has continued after the initial report. Cumulative since 2026-10-12 10:20:
Selected model is at capacity× 66 (was 59)unexpected status 503 Service Unavailable× 36 (was 25)gpt-6.1-solNew occurrence: 17:07:04 → 17:10:19 (UTC+8) — 10× HTTP 503 plus 7×
at capacitywithin about three minutes. UI showedSelected model is at capacity→Reconnecting 2/5→ the rawunexpected status 503 …line →stopped after 0 s.New datapoint — the failures persist with a stable egress. I pinned Codex/ChatGPT traffic to a single node and verified with
chatgpt.com/cdn-cgi/trace:Every 503 in this batch carries a
cf-rayending in-ICN, i.e. they all went out through that same pinned egress, with zero client-side transport errors in the same window (error sending request0,is_timeout=true0, WebSocket fallback 0). So this is not a changing-IP or unstable-network artifact.New request IDs (all
-ICN):3f3c5562-be23-4ef9-b2c5-abc76287f51fa49c1a0ecbfde9f7-ICN1ef00d92-468e-479f-963e-ab20034c73fba49c188808bb3060-ICNdf62eb8a-746c-4b2d-a93a-2336a10b443aa49c11521b8a7513-ICN09ccd500-aa40-4db2-b7b9-246c153522c1a49c110df926e9f9-ICNbf379b24-98da-44cd-bfca-c797b2ea3196a49c0f9ab8ede9fc-ICNcf-raysamples from the 17:07–17:10 batch (all-ICN):a49d33bd8b8dd1dd,a49d33e0d84530fd,a49d34331d6ea732,a49d35cdf9218c03,a49d3621aef3d160,a49d368539775503Quota unchanged and still ample:
x-codex-plan-type = pro,x-codex-primary-used-percent = 6(7-day window),x-codex-credits-has-credits = True,x-codex-credits-balance ≈ 62381.94,limit_reached = false,spend_control.reached = false.Reference for the classification: #52812 reports the same symptom on the same Windows build (19045) with OpenAI's internal field
codex_error_info: server_overloaded.kriouerlia commentedon Oct 13, 2026
Update 2 — 2026-10-13 17:17 (UTC+8): still failing
Cumulative since 2026-10-12 10:20:
Selected model is at capacity× 72 (first 10-12 10:20:19, latest 10-13 17:17:00)unexpected status 503 Service Unavailable× 47 (first 10-13 10:14:21, latest 10-13 17:11:38)Latest two occurrences at 17:16:57 and 17:17:00. Egress stayed pinned the whole time (
ip=82.117.226.117,loc=KR,colo=ICN), with zero client-side transport errors in the same window.New request IDs (all
-ICN):32964625-48da-4a76-830c-22bb8c692557a49d422d69055a03-ICN9a892a2f-e855-46c2-b874-0da1c9c0972ca49d420dce91b7e8-ICNQuota unchanged and still ample:
x-codex-plan-type = pro,x-codex-primary-used-percent = 6,x-codex-credits-has-credits = True,x-codex-credits-balance ≈ 62381.94,limit_reached = false,spend_control.reached = false.Total outage duration so far: over 30 hours, continuing.
kriouerlia commentedon Oct 14, 2026
Update 3 — 2026-10-14 (UTC+8): third day, still failing
The outage has now continued into a third day. This morning (Oct 14) alone: 3 more
Selected model is at capacityand 8 moreunexpected status 503.Running totals since 2026-10-12 10:20:
Selected model is at capacityunexpected status 503 Service UnavailableRequest IDs from this morning (all
-ICN):281993b6-844e-4ba3-96aa-e89d41633b78,d28506aa-4818-4897-bf74-0e89766a5376,c4d4db62-af67-427a-9bf3-d33d2c01a13f.Measured impact on working throughput (daily Codex token usage, Beijing time):
That is roughly an 87% drop in daily token throughput and 72% in turns, on the same account, machine and workload. The concrete casualty was a weekly operations report that has failed to generate since Monday and is still undelivered.
Quota remains ample throughout:
x-codex-primary-used-percent = 6→7over the whole period,credits.balanceunchanged at62381.943795,limit_reached = false.For reference, the support case for this account confirms a server-overload error in the backend records for one of the supplied requests, and that the request passed the usage-limit check (case 17131973).
Louis-L-14 commentedon Oct 14, 2026
has this issus been fixed now?
RepressedAlliance commentedon Oct 14, 2026
Independent corroboration from two Windows desktop tasks, with an important distinction between root-turn errors and child-agent HTTP errors. This supplements our earlier report in #32020: #32020 (comment)
I inspected the existing logs_2.sqlite using a read-only SQLite connection and matched child sessions to their root threads using session_meta.source.subagent.thread_spawn.parent_thread_id. No tasks were interrupted or diagnostic prompts injected.
Snapshot of retained log rows on 2026-10-14 (not all-time totals; logging/retention can omit earlier events):
Counts are log events, not unique requests or independent outages. UUID substrings and encoded payloads containing the digits 503 were excluded. The 503 matches require target codex_core::responses_retry and the actual text
unexpected status 503 Service Unavailable.Sanitized examples (UTC):
The retry messages contain:
stream disconnected - retrying sampling request (1/5 ...); sampling_error=unexpected status 503 Service Unavailable: An error occurred while processing your request.The root errors are separately recorded by codex_core::session::turn as:
Turn error: Selected model is at capacity. Please try a different model.Both roots also failed after the recorded effort became Medium:
This rules out lowering effort as a reliable workaround in this observation, not every possible effect of effort on failure probability.
Differences/limits compared with this issue:
Please correlate these turn IDs with serving telemetry. The evidence corroborates the coexistence of actual HTTP 503 retries and terminal capacity errors in active work, including Medium effort, but does not prove that image count, account restrictions, or a specific region caused it. Full task content, local paths, credentials, and raw encoded payloads are omitted.
RepressedAlliance commentedon Oct 14, 2026
Broader retrospective audit: this affects more than the two new chats in my preceding comment.
User-reported onset: the disruption became noticeable/frequent over the last few days, after previously usable workflows. This is a user observation; I have not established the first-ever occurrence or a version-regression boundary.
Method: read existing session JSONL files for nine known affected/reference chats, selecting actual event_msg/task_complete terminal errors since 2026-10-10 00:00 UTC. Excluded events predating each session's creation and deduplicated turn IDs, so copied fork history is not counted twice. Quoted error text in prompts, assistant prose and tool output was not counted. This is a bounded retrospective audit, not a census of every account conversation or subagent.
At this snapshot, 8/9 inspected chats had matching terminal failures:
Per-chat counts (task labels are deliberately generic):
Useful timestamp anchors:
This strengthens the evidence that the problem is not confined to a single chat or exclusively to image work. It also shows selective/intermittent behavior: a contemporaneous fresh web/document workflow is completing work while the other fresh chats continue to fail. It does not identify why requests differ or prove a particular serving pool, image-payload threshold, account restriction, or regression.
Please assess this alongside the actual HTTP 503 records from both affected task trees in my preceding comment. Those 503 log-event counts and these terminal-turn counts are different measurements and should not be added together as independent failures. No running tasks were interrupted, no new diagnostic model calls were made, and no private task contents or credentials are included.
lvy010 commentedon Oct 15, 2026
+1