Codex "Selected model is at capacity" / server_overloaded on trivial first turn (Web + Windows app) #52812

SUMMARY

Codex tasks start normally but fail after ~49 seconds with:

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

Internal classification reported by OpenAI Help Center: codex_error_info: server_overloaded

The failure occurs on a trivial first turn. In the primary reproduction the user's entire
prompt was a single short greeting. No tools were invoked, no files were touched, no
tool-call round-trips occurred. The request was rejected while still in its first
inference round. This rules out long-context, large-payload, tool-loop, and client-side
resource causes.

The failure is NOT account-level quota exhaustion. Local response headers captured at the
time of failure show the account had 93 percent of its window remaining:

x-codex-plan-type = pro
x-codex-primary-used-percent = 7
x-codex-credits-has-credits = True
x-codex-credits-balance = 62500
x-codex-primary-window-minutes = 10080 (7-day window, ~432000s until reset)

This report includes full client-side telemetry because the backend routing logs are not
reachable from the client.

REPRODUCTION

Surface Codex Web (chatgpt.com/codex/) + ChatGPT/Codex Windows desktop app
App version 26.1007.21434
CLI version codex-cli 0.155.1 (npm global)
OS Windows 10, build 19045
Prompt that triggered it single short message (two characters)
Network Normal network AND mobile hotspot (rules out local network path)
Control Regular ChatGPT web chats work normally during the same period
Models affected gpt-6-astra, gpt-5.6-sol, gpt-6-luna -- all three
Reasoning efforts ultra, xhigh, high, medium, low
Transport Both responses_http and responses_websocket

TIMELINE (Asia/Hong_Kong, UTC+8)

All timestamps extracted from the local SQLite log database shipped with the app at
~/.codex/logs_2.sqlite, table "logs", column "feedback_log_body", which records the full
request span for every turn.

11:47:55 thread 01a123ec-aaf8-7d73-a720-5a216a3abd6b created
11:53:48 thread 01a123f2-0d5b-7c63-b551-4789bec089d5 created (fork of 01a123ec)
11:55:09 gpt-5.6-sol -> at capacity
11:56:02 gpt-5.6-sol -> at capacity
11:56:34 gpt-5.6-sol -> at capacity (thread 01a123f2)
11:56:35 gpt-5.6-sol -> at capacity (thread 01a123ec, same second)

The reported failure time (11:56:35) is confirmed in local logs.

ERROR RATE TREND (gpt-6-astra)

Capacity errors are monotonically worsening, not a transient spike:

2026-10-04 5,776 requests 8 errors 0.1 percent
2026-10-08 849 requests 10 errors 1.2 percent
2026-10-10 279 requests 13 errors 4.5 percent

A 45x degradation over 6 days with no change in client configuration.

CAPACITY ERRORS BY MODEL

gpt-6-astra 31
gpt-5.6-sol 12
gpt-6-luna 6

Three independent model pools failing simultaneously indicates a shared upstream capacity
constraint, not a single-model issue.

ARTIFACTS

Primary session (the one that failed):

Thread ID: 01a123f2-0d5b-7c63-b551-4789bec089d5
Created: 2026-10-10 11:53:48 Asia/Hong_Kong
Root session: 01a123ec-aaf8-7d73-a720-5a216a3abd6b
Shared link: https://chatgpt.com/s/cx_6ac9d8c818508191bf3ff7999a31e695

Note on identifiers: OpenAI Help Center provided 01a1247e-1d32-7a41-ab4e-6da6ae6e09b7 as
the Session ID for this incident. Local logs show that thread was created at 14:26:47,
2.5 hours AFTER the 11:56:35 failure, so it could not have produced the error. The field
above is the verified thread.

EXPECTED

Task continues or completes normally. Capacity-based failures should either be
transparent (automatic fallback / queueing) or degrade gracefully rather than surfacing a
hard error after the task has already started and consumed work.

ACTUAL

Hard failure with "at capacity" / server_overloaded after the task has been running for
~49 seconds. The session cannot be resumed past the failure point in that turn.

ADDITIONAL OBSERVATIONS

Client-side model selection diverges from config.toml. The Windows app persists its own
model choice in ~/.codex/.codex-global-state.json
(electron-persisted-atom-state.composer-recent-model-configurations-v1) and this takes
precedence over config.toml. Users who edit config.toml to change models may silently
keep running the app-selected model. This may cause confusion when reproducing.

service_tier has no observable effect on capacity errors. priority / "Fast" is
available on all affected models for this account (default_service_tier: null), yet
capacity errors occur regardless. If priority is not expected to guarantee capacity,
that is fine, but it would help to document what it does guarantee.

Harmless but noisy warning on every new thread/fork:
WARN codex_features: unknown feature key in config: code_mode_tool_description_first
The Windows app emits a config key the CLI does not recognize. It is emitted on every
fork / thread spawn and floods the log.

Intermittent model-list timeout:
ERROR codex_models_manager: list_models{refresh_strategy=online}:
failed to refresh available models: request timed out
This can cause the model picker to fall back to a stale cached list, which may hide
newly available models during an incident.

HOW TO REPRODUCE FROM LOGS

For anyone triaging client-side, this is the query that produced the timeline above
(requires the SQLite DB shipped with the app at ~/.codex/logs_2.sqlite):

SELECT datetime(ts,'unixepoch','+8 hours') AS local_time,
level,
target,
feedback_log_body
FROM logs
WHERE feedback_log_body LIKE '%at capacity%'
ORDER BY id DESC;

Identifying which thread actually failed requires the thread_id= span field, not the
session_id field. Forked child threads inherit the parent's session_id in session_meta, so
session_id alone is ambiguous across forks.