Question revision 1: Are popular AI models getting worse right now, and what evidence distinguishes real capability degradation from outages, routing changes, product changes, safety behavior, pricing, access limits, and anecdotes?
Claude Code reports meet a week of status errors. The cause is still open.
Call: broad capability decline is not established. One user reports poor, repetitive advice from Claude Fable 5.1 and Opus 5.5 in a long Claude Code / VS Code session. Anthropic separately records resolved request-error windows across 21–24 October. The report does not give a UTC time that links its examples to those incidents.
A concrete Claude Code complaint, still one account
In issue #103996 in the Anthropic Claude Code repository, a user describes a VS Code session with long conversations and context compaction. The author says Fable 5.1 gave poor advice during a client call, repeated that advice after correction, made a factual error, and failed to address all questions; the author also reports serious problems with Opus 5.5. Those details make the report worth investigating because the claimed cost is real work and correction time. The issue contains no matched output archive, verified request route, independent replay, or user denominator. Its vivid example is not a measurement of how often this occurs.
Anthropic’s service timeline is a separate evidence lane
Anthropic’s status history lists the following resolved windows:
| Impact window (UTC) | Provider record | What it can establish |
|---|---|---|
| 21 Oct, 19:49–20:29 | Degraded performance for Claude Fable 5 | A same-day service lead. Issue #103996 does not give a comparable UTC test time, so linkage is unknown. |
| 23 Oct, 23:28–23:59 | Elevated errors for Fable 5.1, Sonnet 5.5, Haiku 5.5, and fast Opus 5.5 | Request errors across selected models; not a completed-answer quality score. |
| 24 Oct, 00:23–00:34 | Elevated errors for Opus 5.5 | A separate short request-error window. |
| 24 Oct, 05:00–05:35 | Elevated errors for Fable 5 and 5.1 | A later service window; the status update marked recovery by 05:53 UTC. |
The current Anthropic status page showed all systems operational when checked at 12:06 UTC. “Resolved” means the provider closed the listed event; it does not explain a user’s earlier completed answer or prove that every account recovered at the same moment.
Other symptoms should not be called a weak answer
An OpenAI Community follow-up on 24 October says a “Chat memory full” banner returned in new chats after 12 turns in a branch and 28 turns in the original. That is a reported send-blocking continuity issue, not an evaluation of answer quality. It is also separate from the earlier one-user GPT-6 regular-versus-Temporary Chat comparison, where the same prompt reportedly stopped in regular Chat but completed in Temporary Chat.
Another recent Codex report describes a refusal loop after an execution-policy rejection. A command denied by policy, a turn that cannot send, a request error, and a completed but poor answer are different observations. Keep them in different rows.
A narrow repeated test is a useful counterweight
Source: BenchGecko lists a 21 October run of its 22-probe weekly index. The page marks GPT-6.1 Sol Pro and Claude Sonnet 5.5 stable in that run; it also records a DeepSeek model changing one identity answer. The panel includes exact-answer checks, identity questions, and refusal questions, some labeled by a judge model. It is inspectable and repeated, but it does not test context compaction, multi-turn client work, or the specific Fable / Opus issue. A stable result on this small panel cannot rule out a workflow-specific failure.
What would change the call
Run the same safe, synthetic task before and after a provider event, on the same product surface and client, with model, effort, context length, compaction state, and task rubric recorded. Repeat it enough to measure ordinary variation. For agent work, save the final artifact and correction cost, not just the transcript. Independent replications or provider request-level evidence could then distinguish model behavior from context handling, routing, tool orchestration, safety, and service availability.
See the current call · See the signal table · Browse community reports · Read the method