Checked 14 October 2026 · Public-source review

OpenAI marked the Codex/Work issue resolved. One saved GPT-6.1 Sol history still failed afterward.

Current call: a narrow request-path problem is reported; broad model decline is not established. OpenAI's status page marks its GPT-6.1 Sol performance incident in Codex and Work resolved at 16:36 UTC on 13 October. A user report dated after that time describes one saved reasoning item that repeatedly failed before output. The report's controls passed. That is a useful lead about one history state, not evidence that GPT-6.1 Sol broadly became less capable.

If a Codex task still fails: check the current status, keep the original conversation unchanged, and record the model, effort, client, time, context and exact error. When safe, try a small non-sensitive task in a fresh conversation with the same model and settings. A no-output error is not a wrong answer.

What changed

Provider record

One service incident is marked resolved

OpenAI lists GPT-6.1 Sol degraded performance in ChatGPT Work and Codex Web, API, CLI and VS Code. The status page reports aggregate availability; it does not identify root cause or an individual account's recovery.

User-run replay

One stored item still triggered a server error

A separate Codex issue reports failures tied to a particular saved reasoning item, with same-model and cross-model controls completing. This is one user's diagnostic; its connection to OpenAI's incident is unknown.

Separate client signal

One Windows context indicator changed after an app update

A user closed a context-window issue after their GPT-6.1 Sol indicator reached 475,000 effective tokens. No response quality was measured.

The saved-history test

The issue author reports that the original Codex session ended with a server error at 23:53 UTC on 13 October, then tested the same model through direct requests. One saved reasoning item failed before output in 4 of 4 default-tier attempts and 2 of 2 priority attempts. A neutral prompt without saved reasoning completed 4 of 4 times; keeping the other 145 saved items completed 3 of 3 default-tier and 1 of 1 priority attempts. GPT-6 Sol completed the isolated-item control 3 of 3 times.

These small repeated tests point to an input- or history-specific request failure in that account. They do not identify the backend component, show a general size limit, or measure completed-answer quality. The report does not establish that the failure shares a cause with the provider incident. The issue author also describes a manual history workaround; it is not an official fix, and this review does not recommend changing valuable conversation data based on one report.

Speed is part of the user experience, not a quality score

One Reddit comparison reports xhigh generation speeds of 22.3 tokens per second in Normal mode and 64.2 in Fast for GPT-6.1 Sol, versus 102.6 and 168.1 for GPT-5.6 Sol. The author says the samples are not a controlled scientific study; the post does not show a common task set, route, repeated variance or account-level server data. A separate user dashboard post reports GPT-6.1 Sol speeds increasing from about 22 to 40 tokens per second over time. That post has different and incomplete conditions.

OpenAI's help page says its roughly 50% speed increase refers to default text generation, not every multi-step task; it also says Support cannot verify the improvement for a particular account. These figures do not settle whether a task is slower, whether an answer is worse, or why allowance changed. Measure first-token delay, total task time, completed artifact, correction burden and usage separately.

Do not merge these signals. An outage can interrupt a task; a saved-history item can fail before output; a slow response can consume more time; a completed answer can still be correct or wrong. Only the last one is a candidate quality observation, and even then it needs a matched task and evaluation.

What to do next

Check whether the current provider status page lists your surface and model.
For a request error, keep the original conversation and note its context, model, effort, client version, time, route when visible, and exact error. Do not post private prompts, proprietary code, or session logs.
If safe, run a small non-sensitive task in a fresh conversation with the same surface, model and effort. If that works while one saved history fails, report a history-specific request issue rather than a general quality decline.
For a completed answer that seems worse, repeat the same task under the same settings and score the output and correction burden. Record speed and allowance as separate results.

Sources

Return to the current verdict · Read the method