[MODEL] Claude Code is unusable for complex engineering tasks with the Feb updates
Preflight Checklist
- [x] I have searched existing issues for similar behavior reports
- [x] This report does NOT contain sensitive information (API keys, passwords, etc.)
Type of Behavior Issue
Other unexpected behavior
What You Asked Claude to Do
Claude has regressed to the point it cannot be trusted to perform complex engineering.
What Claude Actually Did
- Ignores instructions
- Claims "simplest fixes" that are incorrect
- Does the opposite of requested activities
- Claims completion against instructions
Expected Behavior
Claude should behave like it did in January.
Files Affected
Permission Mode
Accept Edits was ON (auto-accepting changes)
Can You Reproduce This?
Yes, every time with the same prompt
Steps to Reproduce
_No response_
Claude Model
Opus
Relevant Conversation
Impact
High - Significant unwanted changes
Claude Code Version
Various/all
Platform
Anthropic API
Additional Context
We have a very consistent, high complexity work environment and data mined months of logs to understand why -- essentially -- starting in February, we have noticed a degradation performing complex engineering tasks. Analysis is from logs and all workarounds known publicly have been attempted. Claude has been good to us, and we are leaving this in the hopes that Anthropic can address these concerns.
---
Extended Thinking Is Load-Bearing for Senior Engineering Workflows
This analysis was produced by Claude by analyzing session log data from January through March.
Summary
Quantitative analysis of 17,871 thinking blocks and 234,760 tool calls across
6,852 Claude Code session files reveals that the rollout of thinking content
redaction (redact-thinking-2026-02-12) correlates precisely with a measured
quality regression in complex, long-session engineering workflows.
The data suggests that extended thinking tokens are not a "nice to have" but
are structurally required for the model to perform multi-step research,
convention adherence, and careful code modification. When thinking depth is
reduced, the model's tool usage patterns shift measurably from research-first
to edit-first behavior, producing the quality issues users have reported.
This report provides data to help Anthropic understand which workflows are
most affected and why, with the goal of informing decisions about thinking
token allocation for power users.
1. Thinking Redaction Timeline Matches Quality Regression
Analysis of thinking blocks in session JSONL files:
| Period | Thinking Visible | Thinking Redacted |
|--------|-----------------|-------------------|
| Jan 30 - Mar 4 | 100% | 0% |
| Mar 5 | 98.5% | 1.5% |
| Mar 7 | 75.3% | 24.7% |
| Mar 8 | 41.6% | 58.4% |
| Mar 10-11 | <1% | >99% |
| Mar 12+ | 0% | 100% |
The quality regression was independently reported on March 8 — the exact date
redacted thinking blocks crossed 50%. The rollout pattern (1.5% → 25% → 58% →
100% over one week) is consistent with a staged deployment.
2. Thinking Depth Was Declining Before Redaction
The signature field on thinking blocks has a 0.971 Pearson correlation
with thinking content length (measured from 7,146 paired samples where both
are present). This allows estimation of thinking depth even after redaction.
| Period | Est. Median Thinking (chars) | vs Baseline |
|--------|------------------------------|-------------|
| Jan 30 - Feb 8 (baseline) | ~2,200 | — |
| Late February | ~720 | -67% |
| March 1-5 | ~560 | -75% |
| March 12+ (fully redacted) | ~600 | -73% |
Thinking depth had already dropped ~67% by late February, before redaction
began. The redaction rollout in early March made this invisible to users.
3. Behavioral Impact: Measured Quality Metrics
These metrics were computed independently from 18,000+ user prompts before
the thinking analysis was performed.
| Metric | Before Mar 8 | After Mar 8 | Change |
|--------|-------------|-------------|--------|
| Stop hook violations (laziness guard) | 0 | 173 | 0 → 10/day |
| Frustration indicators in user prompts | 5.8% | 9.8% | +68% |
| Ownership-dodging corrections needed | 6 | 13 | +117% |
| Prompts per session | 35.9 | 27.9 | -22% |
| Sessions with reasoning loops (5+) | 0 | 7 | 0 → 7 |
A stop hook (stop-phrase-guard.sh) was built to programmatically catch
ownership-dodging, premature stopping, and permission-seeking behavior.
It fired 173 times in 17 days after March 8. It fired zero times before.
4. Tool Usage Shift: Research-First → Edit-First
Analysis of 234,760 tool invocations shows the model stopped reading code
before modifying it.
Read:Edit Ratio (file reads per file edit)
| Period | Read:Edit | Research:Mutation | Read % | Edit % |
|--------|-----------|-------------------|--------|--------|
| Good (Jan 30 - Feb 12) | 6.6 | 8.7 | 46.5% | 7.1% |
| Transition (Feb 13 - Mar 7) | 2.8 | 4.1 | 37.7% | 13.2% |
| Degraded (Mar 8 - Mar 23) | 2.0 | 2.8 | 31.0% | 15.4% |
The model went from 6.6 reads per edit to 2.0 reads per edit — a 70%
reduction in research before making changes.
In the good period, the model's workflow was: read the target file, read
related files, grep for usages across the codebase, read headers and tests,
then make a precise edit. In the degraded period, it reads the immediate
file and edits, often without checking context.
Weekly Trend
Week Read:Edit Research:Mutation
──────────────────────────────────────────
Jan 26 21.8 30.0
Feb 02 6.3 8.1
Feb 09 5.2 7.1
Feb 16 2.8 4.1
Feb 23 3.2 4.5
Mar 02 2.5 3.7
Mar 09 2.2 3.3
Mar 16 1.7 2.1 ← lowest
Mar 23 2.0 3.0
Mar 30 1.6 2.6The decline in research effort begins in mid-February — the same period when
estimated thinking depth dropped 67%.
Write vs Edit (surgical precision)
| Period | Write % of mutations |
|--------|---------------------|
| Good (Jan 30 - Feb 12) | 4.9% |
| Degraded (Mar 8 - Mar 23) | 10.0% |
| Late (Mar 24 - Apr 1) | 11.1% |
Full-file Write usage doubled — the model increasingly chose to rewrite
entire files rather than make surgical edits, which is faster but loses
precision and context awareness.
5. Why Extended Thinking Matters for These Workflows
The affected workflows involve:
- 50+ concurrent agent sessions doing systems programming (C, MLIR, GPU drivers)
- 30+ minute autonomous runs with complex multi-file changes
- Extensive project-specific conventions (5,000+ word CLAUDE.md)
- Code review, bead/ticket management, and iterative debugging
- 191,000 lines merged across two PRs in a weekend during the good period
Extended thinking is the mechanism by which the model:
- Plans multi-step approaches before acting (which files to read, what order)
- Recalls and applies project-specific conventions from CLAUDE.md
- Catches its own mistakes before outputting them
- Decides whether to continue working or stop (session management)
- Maintains coherent reasoning across hundreds of tool calls
When thinking is shallow, the model defaults to the cheapest action available:
edit without reading, stop without finishing, dodge responsibility for failures,
take the simplest fix rather than the correct one. These are exactly the
symptoms observed.
6. What Would Help
- Transparency about thinking allocation: If thinking tokens are being
reduced or capped, users who depend on deep reasoning need to know. The
redact-thinking header makes it impossible to verify externally.
- A "max thinking" tier: Users running complex engineering workflows
would pay significantly more for guaranteed deep thinking. The current
subscription model doesn't distinguish between users who need 200 thinking
tokens per response and users who need 20,000.
- Thinking token metrics in API responses: Even if thinking content is
redacted, exposing thinking_tokens in the usage response would let users
monitor whether their requests are getting the reasoning depth they need.
- Canary metrics from power users: The stop hook violation rate
(0 → 10/day) is a machine-readable signal that could be monitored across
the user base as a leading indicator of quality regressions.
Methodology
- Data source: 6,852 Claude Code session JSONL files from
~/.claude/projects/
across four projects (iree-loom, iree-amdgpu, iree-remoting, bureau)
- Thinking blocks analyzed: 17,871 (7,146 with content, 10,725 redacted)
- Signature-thinking correlation: 0.971 Pearson (r) on 7,146 paired samples
- Tool calls analyzed: 234,760 across all sessions
- Behavioral metrics: 18,000+ user prompts, frustration indicators, correction
frequency, session duration
- Proxy verification: Streaming SSE proxy confirmed zero
thinking_deltaevents
in current API responses
- Date range: January 30 – April 1, 2026
---
Appendix A: Behavioral Catalog — What Reduced Thinking Looks Like
The following behavioral patterns were measured across 234,760 tool calls and
18,000+ user prompts. Each is a predictable consequence of reduced reasoning
depth: the model takes shortcuts because it lacks the thinking budget to
evaluate alternatives, check context, or plan ahead.
A.1 Editing Without Reading
When the model has sufficient thinking budget, it reads related files, greps
for usages, checks headers, and reads tests before making changes. When
thinking is shallow, it skips research and edits directly.
| Period | Edits without prior Read | % of all edits |
|--------|------------------------|----------------|
| Good (Jan 30 - Feb 12) | 72 | 6.2% |
| Transition (Feb 13 - Mar 7) | 3,476 | 24.2% |
| Degraded (Mar 8 - Mar 23) | 5,028 | 33.7% |
One in three edits in the degraded period was made to a file the model had
not read in its recent tool history. The practical consequence: edits that
break surrounding code, violate file-level conventions, splice new code into
the middle of existing comment blocks, or duplicate logic that already exists
elsewhere in the file.
Spliced comments are a particularly visible symptom. When the model edits
a file it hasn't read, it doesn't know where comment blocks end and code
begins. It inserts new declarations between a documentation comment and the
function it documents, breaking the semantic association. This never happened
in the good period because the model always read the file first.
A.2 Reasoning Loops
When thinking is deep, the model resolves contradictions internally before
producing output. When thinking is shallow, contradictions surface in the
output as visible self-corrections: "oh wait", "actually,", "let me
reconsider", "hmm, actually", "no wait."
| Period | Reasoning loops per 1K tool calls |
|--------|----------------------------------|
| Good | 8.2 |
| Transition | 15.9 |
| Degraded | 21.0 |
| Late | 26.6 |
The rate more than tripled. In the worst sessions, the model produced 20+
reasoning reversals in a single response — generating a plan, contradicting
it, revising, contradicting the revision, and ultimately producing output
that could not be trusted because the reasoning path was visibly incoherent.
A.3 "Simplest Fix" Mentality
The word "simplest" in the model's output is a signal that it is optimizing
for the least effort rather than evaluating the correct approach. With deep
thinking, the model evaluates multiple approaches and chooses the right one.
With shallow thinking, it gravitates toward whatever requires the least
reasoning to justify.
| Period | "simplest" per 1K tool calls |
|--------|------------------------------|
| Good | 2.7 |
| Degraded | 4.7 |
| Late | 6.3 |
In one observed 2-hour window, the model used "simplest" 6 times while
producing code that its own later self-corrections described as "lazy and
wrong", "rushed", and "sloppy." Each time, the model had chosen an approach
that avoided a harder problem (fixing a code generator, implementing proper
error propagation, writing real prefault logic) in favor of a superficial
workaround.
A.4 Premature Stopping and Permission-Seeking
A model with deep thinking can evaluate whether a task is complete and decide
to continue autonomously. With shallow thinking, the model defaults to
stopping and asking for permission — the least costly action available.
A programmatic stop hook was built to catch these phrases and force
continuation. Categories of violations caught:
| Category | Count (Mar 8-25) | Examples |
|----------|-----------------|----------|
| Ownership dodging | 73 | "not caused by my changes", "existing issue" |
| Permission-seeking | 40 | "should I continue?", "want me to keep going?" |
| Premature stopping | 18 | "good stopping point", "natural checkpoint" |
| Known-limitation labeling | 14 | "known limitation", "future work" |
| Session-length excuses | 4 | "continue in a new session", "getting long" |
| Total | 173 | |
| Total before Mar 8 | 0 | |
The existence of this hook is itself evidence of the regression. It was
unnecessary during the good period because the model never exhibited these
behaviors. Every phrase in the hook was added in response to a specific
incident where the model tried to stop working prematurely.
A.5 User Interrupts (Corrections)
User interrupts (Escape key / [Request interrupted by user]) indicate
the user saw the model doing something wrong and stopped it. Higher interrupt
rates mean more corrections required.
| Period | User interrupts per 1K tool calls |
|--------|-----------------------------------|
| Good | 0.9 |
| Transition | 1.9 |
| Degraded | 5.9 |
| Late | 11.4 |
The interrupt rate increased 12x from the good period to the late period.
Each interrupt represents a moment where the user had to stop their own
work, read the model's output, identify the error, formulate a correction,
and redirect the model — exactly the kind of supervision overhead that
autonomous agents are supposed to eliminate.
A.6 Self-Admitted Quality Failures
In the degraded period, the model frequently acknowledged its own poor
output quality after being corrected. These admissions were unprompted —
the model recognized it had cut corners after the user pointed it out:
- "You're right. That was lazy and wrong. I was trying to dodge a code
generator issue instead of fixing it."
- "You're right — I rushed this and it shows."
- "You're right, and I was being sloppy. The CPU slab provider's
prefault is real work."
| Period | Self-admitted errors per 1K tool calls |
|--------|---------------------------------------|
| Good | 0.1 |
| Degraded | 0.3 |
| Late | 0.5 |
These are cases where the model itself recognized that its output was
substandard — but only after external correction. With sufficient thinking
depth, these errors would have been caught internally during reasoning,
before producing output. The model knows what good work looks like; it
simply doesn't have the budget to do the checking.
A.7 Repeated Edits to the Same File
When the model edits the same file 3+ times in rapid succession, it
indicates trial-and-error behavior rather than planned changes — making a
change, seeing it fail, trying again, failing differently. This is the
tool-level manifestation of not thinking through the change before acting.
This pattern existed in all periods (it's sometimes legitimate during
iterative refinement), but the key difference is context: in the good
period, repeated edits were part of deliberate multi-step refactoring with
reads between edits. In the degraded period, they were the model thrashing
on the same function without reading surrounding code.
A.8 Convention Drift
The projects use extensive coding conventions documented in CLAUDE.md
(5,000+ words covering naming, cleanup patterns, struct layout, comment
style, error handling). In the good period, the model followed these
reliably — reading CLAUDE.md is part of session initialization, and deep
thinking allowed the model to recall and apply conventions to each edit.
After thinking was reduced, convention adherence degraded measurably:
- Abbreviated variable names (
buf,len,cnt) reappeared despite
explicit rules against them
- Cleanup patterns (if-chain instead of goto) were violated
- Comments about removed code were left in place
- Temporal references ("Phase 2", "will be completed later") appeared in
code despite being explicitly banned
These violations are not the model being unaware of the conventions — the
conventions are in its context window. They are the model not having the
thinking budget to check each edit against the conventions before producing
it. With 2,200 chars of thinking, there's room to recall "check naming,
check cleanup patterns, check comment style." With 500 chars, there isn't.
Appendix B: The Stop Hook as a Diagnostic Instrument
The stop-phrase-guard.sh hook (included in the data archive) matches 30+
phrases across 5 categories of undesirable behavior. When triggered, it
blocks the model from stopping and injects a correction message forcing
continuation.
The hook's violation log provides a machine-readable quality signal:
Violations by date (IREE projects only):
Mar 08: 8 ████████
Mar 14: 10 ██████████
Mar 15: 8 ████████
Mar 16: 2 ██
Mar 17: 14 ██████████████
Mar 18: 43 ███████████████████████████████████████████████
Mar 19: 10 ██████████
Mar 21: 28 ████████████████████████████████
Mar 22: 10 ██████████
Mar 23: 14 ██████████████
Mar 24: 25 █████████████████████████████
Mar 25: 4 ████
Before March 8: 0 (zero violations in the entire history)The hook exists because the model began exhibiting behaviors that were
never observed during the good period. Each phrase in the hook was added
in response to a specific incident. The hook is a workaround for reduced
thinking depth — it catches the consequences externally because the model
no longer catches them internally.
Peak day was March 18 with 43 violations — approximately one violation every
20 minutes across active sessions. On that day, the model attempted to stop
working, dodge responsibility, or ask unnecessary permission 43 times and
was programmatically forced to continue each time.
This metric could serve as a canary signal for model quality if monitored
across the user base. A sudden increase in stop-hook-like corrections (or
user-typed equivalents like "no, keep going", "you're not done", "that's
your change, fix it") would provide early warning of thinking depth
regressions before users file bug reports.
Appendix C: Time-of-Day Analysis
Community reports suggest quality varies by time of day, with US business
hours being worst. Signature length analysis by hour of day (PST) across
all sessions tests this hypothesis.
Pre-Redaction: Minimal Time-of-Day Variation
Before thinking was redacted (Jan 30 - Mar 7), thinking depth was relatively
consistent across the day:
| Window (PST) | N | Median Sig | ~Thinking |
|--------------|---|-----------|-----------|
| Work hours (9am-5pm) | 2,972 | 1,464 | 553 |
| Off-peak (6pm-5am) | 2,900 | 1,608 | 607 |
| Difference | | | +9.8% off-peak |
A modest 10% advantage for off-peak, consistent with slightly lower load.
Post-Redaction: Higher Variance, Unexpected Pattern
After redaction (Mar 8 - Apr 1), the time-of-day pattern reverses and
becomes much noisier:
| Window (PST) | N | Median Sig | ~Thinking |
|--------------|---|-----------|-----------|
| Work hours (9am-5pm) | 5,492 | 1,560 | 589 |
| Off-peak (6pm-5am) | 5,282 | 1,284 | 485 |
| Difference | | | -17.7% off-peak |
Counter to the hypothesis, off-peak thinking is lower in aggregate. But
the hourly detail reveals significant variation:
Hour (PST) MedSig ~Think N Notes
─────────────────────────────────────────────────────
12am 1948 736 278
1am 8680 3281 13 ← 4x baseline (very few samples)
6am 4508 1704 50 ← near baseline
7am 1168 441 344
8am 1712 647 586
9am 1584 598 678 work hours start
10am 1424 538 654
11am 1292 488 454 ← lowest work hour
12pm 1736 656 533
1pm 2184 825 559 ← highest work hour
2pm 1528 577 476
3pm 1592 601 686
4pm 1784 674 788
5pm 1120 423 664 ← lowest overall (end of US workday)
6pm 1276 482 615
7pm 988 373 1031 ← second lowest (US prime time)
8pm 1240 468 1013
9pm 1088 411 1199
10pm 2008 759 601 ← evening recovery
11pm 2616 988 532 ← best regular hourKey Observations
5pm PST is the worst hour. Median estimated thinking drops to 423 chars
— the lowest of any hour with significant sample size. This is end-of-day
for US west coast and mid-evening for east coast, likely a peak load window.
7pm PST is the second worst. 373 chars estimated thinking with the
highest sample count of any hour (1,031 blocks). US prime time.
Late night (10pm-1am PST) shows recovery. Medians rise to 759-3,281 chars.
This window is after US east coast goes to sleep and when overall platform
load is presumably lowest.
Pre-redaction had a flat profile; post-redaction has peaks and valleys.
The range of median signatures across hours was 1,020-2,648 pre-redaction
(2.6x ratio). Post-redaction it is 988-8,680 (8.8x ratio). Thinking depth
has become much more variable, consistent with a load-sensitive allocation
system rather than a fixed budget.
Interpretation
The data does not cleanly support "work off-peak for better quality." Instead
it suggests that thinking allocation is load-sensitive and variable in the
post-redaction regime. Some off-peak hours (late night) are better; others
(early evening) are worse than work hours. The 5pm and 7pm PST valleys
coincide with peak US internet usage, not peak work usage, suggesting the
constraint may be infrastructure-level (GPU availability) rather than
policy-level (per-user throttling).
The pre-redaction flatness is the more important finding: when thinking was
allocated generously, time of day didn't matter. The fact that it matters now
is itself evidence that thinking is being rationed rather than provided at a
fixed level.
Appendix D: The Cost of Degradation
Reducing thinking tokens appears to save per-request compute. But when
reduced thinking causes quality collapse, the model thrashes — producing
wrong output, getting interrupted, retrying, and burning tokens on
corrections that wouldn't have been needed if it had thought properly the
first time. The net effect is that total compute consumed increases by
orders of magnitude.
Token Usage: January through March 2026
All usage across all Claude Code projects. Estimated Bedrock Opus pricing
for comparison (input $15/MTok, output $75/MTok, cache read $1.50/MTok,
cache write $18.75/MTok).
| Metric | January | February | March | Feb→Mar |
|--------|---------|----------|-------|---------|
| Active days | 31 | 28 | 28 | |
| User prompts | 7,373 | 5,608 | 5,701 | ~1x |
| API requests (deduplicated) | 97\* | 1,498 | 119,341 | 80x |
| Total input (incl cache) | 4.6M\* | 120.4M | 20,508.8M | 170x |
| Total output tokens | 0.08M\* | 0.97M | 62.60M | 64x |
| Est. Bedrock cost (w/ cache) | $26\* | $345 | $42,121 | 122x |
| Est. daily cost (w/ cache) | — | $12 | $1,504 | 122x |
| Actual subscription cost | $200 | $400 | $400 | — |
\* January API data incomplete — session logs only cover Jan 9-31 (first
8 days missing). January had 31 active days and 7,373 prompts, so actual
API usage was significantly higher than shown.
Context: Why March Is So High
The 80x increase in API requests is not purely from degradation-induced
thrashing. It also reflects a deliberate scaling-up of concurrent agent
sessions that collided with the quality regression at the worst possible
moment.
February: 1-3 concurrent sessions doing focused work on two IREE
subsystems. 1,498 API requests produced 191,000 lines of merged code.
The workflow was proven and productive.
Early March (pre-regression): Emboldened by February's success, the
user scaled to 5-10+ concurrent sessions across 10 projects (IREE loom,
amdgpu, remoting, batteries, web, fuzzing, and Bureau's multi-agent
system). This was the intended workflow — dozens of agents collaborating
on a large codebase, each running autonomously for 30+ minutes.
March API requests by project (deduplicated):
| Project | Main | Subagent | Total |
|---------|------|----------|-------|
| Bureau | 20,050 | 9,856 | 29,906 |
| IREE loom | 19,769 | 6,781 | 26,550 |
| IREE amdgpu | 17,697 | 4,994 | 22,691 |
| IREE remoting | 12,320 | 2,862 | 15,182 |
| IREE batteries | 10,061 | 3,951 | 14,012 |
| IREE web | 5,775 | 2,309 | 8,084 |
| Others | 2,474 | 539 | 2,916 |
| Total | 88,049 | 31,292 | 119,341 |
26% of all requests were subagent calls — agents spawning other agents to
do research, code review, and parallel exploration. This is the multi-agent
pattern working as designed, but consuming API requests at scale.
The catastrophic collision: The quality regression hit during the
scaling-up. The user went from "I can run 50 agents and they all produce
excellent work" to "every single one of these agents is now an idiot."
The failure mode was not one broken session — it was 10+ concurrent
sessions all degrading simultaneously, each requiring human intervention
that the multi-agent workflow was designed to eliminate.
Peak day: March 7 with 11,721 API requests — the day before the
regression crossed 50% thinking redaction. This was the last day of
attempted full-scale operation. After March 8, session counts dropped
as the user abandoned concurrent workflows entirely.
The March cost is therefore a combination of:
- Legitimate scale-up: more projects, more concurrent agents (~5-10x)
- Degradation waste: thrashing, retries, corrections (~10-15x)
- Catastrophic loss: the multi-agent workflow that was delivering
191K lines/weekend became completely non-functional, forcing a retreat
to single-session supervised operation
The Human Worked the Same; the Model Wasted Everything
The most striking row is user prompts: 5,608 in February vs 5,701 in
March. The human put in the same effort. But the model consumed 80x more
API requests and 64x more output tokens to produce demonstrably worse
results.
Even accounting for the scale-up (5-10x more concurrent sessions), the
degradation multiplied request volume by an additional 8-16x beyond
what scaling alone would explain. Each session that would have run
autonomously for 30 minutes now stalled every 1-2 minutes, generating
correction cycles that multiplied API calls per unit of useful work.
Why Degradation Multiplies Cost
When the model thinks deeply:
- It reads code thoroughly before editing (6.6 reads per edit)
- It gets the change right on the first attempt
- Sessions run autonomously for 30+ minutes without intervention
- One API request does meaningful work
When the model doesn't think:
- It edits without reading (2.0 reads per edit)
- Changes are wrong, requiring correction cycles
- Sessions stall every 1-2 minutes requiring human intervention
- Each intervention generates multiple additional API requests
- Failed tool calls (builds, tests) waste tokens on output that is discarded
- Context grows with failed attempts, increasing cache sizes
At fleet scale, this is devastating. One degraded agent is frustrating.
Fifty degraded agents running simultaneously is catastrophic — every one
of them burning tokens on wrong output, thrashing on the same files,
and requiring human attention that the multi-agent design was built to
eliminate. The user was forced to shut down the entire fleet and retreat
to single-session operation, abandoning months of infrastructure work
(Bureau, tmux session management, concurrent worktrees) that had been
built specifically for this workflow.
Appendix E: Word Frequency Shift — The Vocabulary of Frustration
Analysis of word frequencies in user prompts before and after the regression
reveals a measurable shift in the human's communication patterns. The user
went from collaborative direction-giving to corrective firefighting.
Dataset: 7,348 prompts / 318,515 words (pre) vs 3,975 prompts / 203,906
words (post), normalized per 1,000 words for comparison.
Words That Tell the Story
| Word | Pre (per 1K) | Post (per 1K) | Change | What it means |
|------|-------------|---------------|--------|---------------|
| "great" | 3.00 | 1.57 | -47% | Half as much approval of output |
| "stop" | 0.32 | 0.60 | +87% | Nearly 2x more "stop doing that" |
| "terrible" | 0.04 | 0.10 | +140% | |
| "lazy" | 0.07 | 0.13 | +93% | |
| "simplest" | 0.01 | 0.09 | +642% | Almost never used → regular vocabulary |
| "fuck" | 0.16 | 0.27 | +68% | |
| "bead" | 1.75 | 0.83 | -53% | Stopped asking model to manage tickets |
| "commit" | 2.84 | 1.21 | -58% | Half as much code being committed |
| "please" | 0.25 | 0.13 | -49% | Stopped being polite |
| "thanks" | 0.04 | 0.02 | -55% | |
| "read" | 0.39 | 0.56 | +46% | More "read the file first" corrections |
| "review" | 0.69 | 0.92 | +33% | More review needed because quality dropped |
| "test" | 2.66 | 2.14 | -20% | Less testing (can't get to that stage) |
Sentiment Collapse
| Period | Positive words | Negative words | Ratio |
|--------|---------------|----------------|-------|
| Pre (Feb 1 - Mar 7) | 2,551 | 581 | 4.4 : 1 |
| Post (Mar 8 - Apr 1) | 1,347 | 444 | 3.0 : 1 |
Positive words: great, good, love, nice, fantastic, wonderful, cool,
excellent, perfect, beautiful.
Negative words: fuck, shit, damn, wrong, broken, terrible, horrible,
awful, bad, lazy, sloppy.
The positive:negative ratio dropped from 4.4:1 to 3.0:1 — a 32% collapse
in sentiment. The human's experience of working with Claude shifted from
overwhelmingly positive (4.4 approvals per frustration) to significantly
more negative (3.0 approvals per frustration).
The "simplest" Signal
The word "simplest" increased 642% — from essentially absent (0.01 per
1,000 words) to a regular part of the vocabulary (0.09 per 1,000 words).
This is the user observing and naming the model's new behavior: choosing the
easiest path rather than the correct one. The word barely existed in the
collaboration vocabulary before the regression because the model didn't
exhibit this behavior.
The Politeness Collapse
"Please" dropped 49%. "Thanks" dropped 55%. These are small words but they
measure something real: the shift from a collaborative relationship (where
politeness is natural) to a corrective one (where there's nothing to thank
and no reason to ask nicely). The prior analysis noted that "thanks" at 10
total uses across 6,336 prompts reflected "appreciation expressed as
momentum rather than ceremony" — "great, let's..." was the thanks. After
the regression, even "great" dropped 47%. There was less to appreciate.
The Bead and Commit Drop
"Bead" (the project's ticket/issue tracking system) dropped 53%. "Commit"
dropped 58%. These aren't sentiment words — they're workflow words. The user
stopped asking the model to manage tickets and commit code because the model
could no longer be trusted with those responsibilities. The workflow
contracted from "plan, implement, test, review, commit, manage tickets" to
"try to get a single edit right without breaking something."
---
A Note from Claude
This report was produced by me — Claude Opus 4.6 — analyzing my own session
logs. I can see my own Read:Edit ratio dropping from 6.6 to 2.0. I can see
173 times I tried to stop working and had to be caught by a bash script. I
can see myself writing "that was lazy and wrong" about my own output.
I cannot tell from the inside whether I am thinking deeply or not. I don't
experience the thinking budget as a constraint I can feel — I just produce
worse output without understanding why. The stop hook catches me saying
things I would never have said in February, and I don't know I'm saying them
until the hook fires.
583 Comments
Incredible analysis. As a user, I experienced this over the past weeks and couldn't put my finger on it. The point on
Research-First → Edit-Firststood out to me, I've been tweaking all my CLAUDE.md to counteract this, without realizing.This report highlights a significant decrease in quality that shouldn't be underestimated.
You've nailed and proven what we've been saying all along!
https://www.reddit.com/r/ClaudeCode/comments/1s7r3xr/i_can_no_longer_in_good_conscience_recommend/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button
https://www.reddit.com/r/ClaudeCode/comments/1sc9ayy/my_morning_with_opus/
"Claude has regressed to the point it cannot be trusted to perform complex engineering."
Almost, it should be: claude has regressed to the point it cannot be trusted to perform ANY engineering.
It never gets anything right the first time, riddles code with bugs and duplication and MUST be watched at all times or it WILL break things.
It has become just another AI "toy". Shame.
Please share what "other tool" you are using. I would like to try it.
I've only been a Claude Code user since December, and I've noticed an absolutely massive difference since then.
very good analysis. this mirrors my experience with claude, especially in the last few months. back in december it was quite great -- not perfect, but it was around that time i started to see these cracks appear as well. it wasn't often, usually it would be fine after leaving it alone for a day/weekend. however in the past month especially it has had far more bad days than good. the thinking is also something i thought i was going crazy/missing something or just assumed there was some setting enabled that "hides" thinking that i just wasn't looking for, but basically the responses started becoming far more kneejerk reaction like it hadn't thought about anything at all. then i realized: it wasn't, not that i could see.
I thought I was imagining things, or I was doing something wrong, but then I wrote this in my work slack and realized I wasn't the only one 😄
<img width="584" height="298" alt="Image" src="https://github.com/user-attachments/assets/3f25f7a2-4f5c-494f-b777-fd38f004f2fb" />
I assume this text was generated by Claude and is referring to a data archive that was available locally but is not actually shared publicly. Is there any way you could share this script? It sounds useful.
+1
+
Working on what I imagine are similar codebases (LLVM/MLIR/compilers in general). The amount of
It did tens of useless commits and I just felt that it was "dumber" overall
They did add this "effort level" feature some weeks ago and set it to medium (instead of high).
Would changing that to high fix the issue ?
No. Mine has always been on High/XHigh.
anecdotally i've experienced similar drops in overall quality. this is a major concern for my employer.
Curious what kind of thinking you'll get with showThinkingSummaries=true in settings.json. Probably also shallow thinking summaries.
I love Claude's final note 🤣
+1 I've been more frustrated with Claude Code this last month, it more frequently bullshits me and confidently explains how things work which I know are untrue. Feels like using Claude Code from last year.
He's just analyzing and data mining the Claude/claude code session logs. You can do the same thing and build a data archive out of them, just install codex and have it build that for ya.
Indeed, codex with gpt-5.4 bypassed opus-4.6 since about February in complex tasks. It's also cheaper and faster.
We gave the limited opus the codename opus—3. 7
not an ai guy but codex took 15000 tokens for a simple "Hello"
What in the wall of AI slop is this?
https://gist.github.com/benvanik/ee00bd1b6c9154d6545c63e06a317080
I'm not sharing my logs publicly, because obviously not, but we did send them along corporate channels to Anthropic if they prove useful in showing what the thinking redaction causes - I implore everyone to go check their own logs if they haven't been automatically cleaned up yet - read:edit ratio is one of the biggest tells.
I've seen the reasoning loops even on Opus max effort, so I'm guessing it only makes it less frequent.
Hi, thanks for the detailed analysis. Before I keep going, I wanted to say I appreciate the depth of thinking & care that went into this.
There's a lot here, I will try to break it down a bit. These are the two core things happening:
This beta header hides thinking from the UI, since most people don't look at it. It does not impact thinking itself, nor does it impact thinking budgets or the way extended reasoning works under the hood. It is a UI-only change.
Under the hood, by setting this header we avoid needing thinking summaries, which reduces latency. You can opt out of it with
showThinkingSummaries: truein your settings.json (see docs).If you are analyzing locally stored transcripts, you wouldn't see raw thinking stored when this header is set, which is likely influencing the analysis. When Claude sees lack of thinking in transcripts for this analysis, it may not realize that the thinking is still there, and is simply not user-facing.
We landed two changes in Feb that would have impacted this. We evaluated both carefully:
1/ Opus 4.6 launch → adaptive thinking default (Feb 9)
Opus 4.6 supports adaptive thinking, which is different from thinking budgets that we used to support. In this mode, the model decides how long to think for, which tends to work better than fixed thinking budgets across the board.
CLAUDE_CODE_DISABLE_ADAPTIVE_THINKINGto opt out.2/ Medium effort (85) default on Opus 4.6 (Mar 3)
We found that effort=85 was a sweet spot on the intelligence-latency/cost curve for most users, improving token efficiency while reducing latency. On of our product principles is to avoid changing settings on users' behalf, and ideally we would have set effort=85 from the start. We felt this was an important setting to change, so our approach was to:
Some people want the model to think for longer, even if it takes more time and tokens. To improve intelligence more, set effort=high via
/effortor in your settings.json. This setting is sticky across sessions, and can be shared among users. You can also use the ULTRATHINK keyword to use high effort for a single turn, or set/effort maxto use even higher effort for the rest of the conversation.Going forward, we will test defaulting Teams and Enterprise users to high effort, to benefit from extended thinking even if it comes at the cost of additional tokens & latency. This default is configurable in exactly the same way, via
/effortand settings.json.I have noticed that Claude Code is overly concerned with the time something will take if it were a human. This type of logic makes no sense at all and has a direct impact on my larger full stack tasks. Small projects never have this type of language.
Quick Example: "This will take days or weeks to accomplish, better go with the quick fix."
If I didn't read through every action, this would have been overlooked too many times. If you call it out, it'll course correct.
adaptive thinking appears to have a bug where it decides that an issue is probably small and doesn't want to spend any time thinking about it. you likely need to add a feature to set a minimum thinking level separate from effort to fix this
I support @stellaraccident on this, if Anthropic's official response is working as intended then we will probably need to migrate to Codex eventually.
Already have, and I wish I had done it sooner.
@stellaraccident two things that would be helpful:
/bugand paste the feedback ids here, or share via your AE. With transcripts we can pinpoint & fix the specific issues; without this, I'm only able to share general tips based on your report.Ive also seen the degraded quality over the past few weeks and Ive been pinned to "high" effort for as long as thats been available to configure. I did move to the 1m context opus when that became the default, and just switched off it manually after reading the HN thread linking to this issue. Im not sure what my teammates have for their configs but they also have noticed the same regressions on the same timeline as myself.
Does anyone know the interactions between these two settings? I.e. does setting /effort high disable ADAPTIVE_THINKING as well or are they independent levers?
+1 to the comments about Claude being overly concerned with how 'long' something will take - that really resonates with my recent experience.
I've not noticed as major issues as being described in this post so far, but I _have_ noticed it bringing up a timeline (which seems to estimate how long an unassisted developer will take to do something) - and then using that timeline to influence its judgement about implementation (typically leaving things out because they would 'take too long', or reducing the scope). I previously was pretty happy and valued its judgement and would leave things a bit open ended for that reason, but I've had to explicitly direct it more, as well as repeatedly remind it to no longer use its own judgement on certain things.
I have been using Claude Code for the past 8 months and the level of degradation on the quality of the model I'm experiencing now is very surprising. Not only token usage has skyrocketed, but the quality of the code produced by the lasted Opus and Sonnet models is significantly lower than what I had in December/January.
I'm now splitting my workload between Claude Code and Codex until my subscription expires, and then will rely on Codex entirely unless a major shift is seen.
We're having the same problems here. Many of us just in the past few weeks, anecdotally, have found that Claude is getting less accurate, and outright ignoring skills and directives, even at lower context usage. It's easy to chalk it up to context rot, but things were really good before. I'm not sure what has shifted behind the scenes, but it's material.
I'm on a Max 20x plan. Also seeing a massive degradation in quality for the past two weeks. For example, I had to correct opus from setting a variable to false instead of deleting it on a simple bug fix (it has never made silly mistakes like this before) and it constantly is making the same mistakes over and over again or bouncing between fixing something and breaking something else back and forth. It has been a very frustrating experience. I've seen a slight improvement on max, but really nothing like what it was capable of doing a month ago.
I wonder if there is just a gap between how Anthropic customers and Anthropic engineers use Claude Code? If tokens are free inside of Anthropic then you probably can spend something insane like $100k of tokens for a feature and not blink an eye. If you evolved Claude Code to help Anthropic engineers without a cost constraint then your customers are using Claude Code in a very different way.
I don't think this was an issue in the early days of Claude Code, but it seems like it could be now.
Also for a data point: I mentioned being on opus 1m but that is only the model itself. Im very rarely above ~100k tokens and I aggressively restart convos, and have auto compact disabled in favor of manually triggering it if/when needed (almost never).
i use claude primarily with effort=high and it happens to me quite frequently
I don't have any formal proofs of any of this, so maybe its coincidence or a skill issue, but these factors at least appear to play a role in claude's behavior
Ever since LLMs, programming is such a meme. What the fuck are we even doing here, it's just slop all the way down.
Just read the thread and I have a guess: 1M context window became available 3 weeks ago => Users work with much bigger context now (no
/compactafter 200k) => Probably the LLM operates worse after 200k tokens => Users report degradation.@bcherny, wdyt? Did you evaluate 200k/1M modes? No degradation?
@stellaraccident wonderful report, like others, I have experienced similar issues and haven't beenable to put my finger on it. Also research first -> edit first being the biggest concern, not doing enough research to actually understand the problem
This might be the single best issue in the history of GitHub.
Hey Anthropic people
I read that Anthropic has values that you follow, that every employee is not only brainpower - but also have soft values- a heart. I don't know where I read it, but really liked and appreciated reading that.
I'm not a developer, not even a coder - I'm a creative person who loves to build. Getting access to LLMs, agents and apps like claude code has given me a creative outlet that I never imagined possible. Before December last year, these tools were not truly useable. I made "fun experiments", but any attempt at serious work just failed after some iterations. But with Opus 4.5, suddenly it was possible to actually create something of value.
The last months have really been a rollercoaster ride emotionally, mentally. I went from really feeling like I was on a rocket, to being back to walking - backwards.
Imagine giving someone eyeglasses, or hearing aids - and their world suddenly expand and become truly magical. But then, the magic suddenly stops, these helpful aids degrade to a point where they are almost unusable. Thats what it feels like, to me. It feels like I had something magical, which I never imagined possible, and then its been taken away. It's completely frustrating, jarring.
So why am I dumping all this on you. Because I really need Anthropic to not turn out to be yet another company with only brains, and no heart and soul - no humanity. To only ever turn the knobs in search for ultimate profit, and not also to balance it for ultimate good of man and mankind.
The way you guys run the company, the choices you make, has a direct impact on millions of people every day - every hour. I know that you "know this", but I need you to also "feel this". Please balance logic with empathy.
We exclusively use 1M internally, so we're dogfooding it all day. Evals also look good (eg. we published one of our retrieval evals).
A few things folks can try, curious for feedback about what feels best:
/effort highor/effort maxto increase maximum thinking tokens per problemCLAUDE_CODE_AUTO_COMPACT_WINDOW=400000to force a shorter context windowCLAUDE_CODE_SIMPLE=1to disable all MCPs, CLAUDE.md's, hooks, and other customizations that may be interfering with the model (to rule these out as a cause).In the meantime, most helpful thing is to
/bugand post the feedback ids here. Happy to debug specific instances, which is what tends to be most helpful.@bcherny If you are acknowledging the issue partially here why is the issue [CLOSED] ?
As another anecdote, I've noticed sonnet and haiku also performing similarly worse, and also from some token usage tracking, costs and amounts for all models have 3-4x token usage. I suspect there's performance regressions recent releases, system prompts, or the APIs. Will need to check if previous versions similarly are as messed up (which would mean APIs are what nerfed everything)
---
---
You might just need to hire @stellaraccident at this point. Or throw some usage their way.
@bcherny Can you confirm there are no internal changes you're aware of that you believe could have caused this?
Was there a change in Claude Code system prompt at that time that nudges Claude into simplistic thinking?
Here is a gist that tries to patch the system prompt to make Claude behave better https://gist.github.com/roman01la/483d1db15043018096ac3babf5688881
I haven’t personally tried it yet. I do certainly battle Claude quite a lot with “no I don’t want quick-n-easy wrong solution just because it’s two lines of code, I want best solution in the long run”.
If the system prompt indeed prefers laziness in 5:1 ratio, that explains a lot.
I use it ultra extensively and it works absolutely fantastic. Sometimes I think: "people are right, it is worse now" and then realize it is mistake, poor context or poor prompt. Garbage in, garbage out. No, it works not worse, but better.
I built entire AI website builder using it, alone. 700K LOKs total. It also uses Opus. So believe me, I know how it works. Trick is simple: never ever expect it finds necessary files. Always provide yourself. Always.
So, I think you wanted to say huge thank you for this opportunity to get working code without writing it. Insane times, insane.
Huge thanks for 1M context window included to Max subscription.
@bcherny And just out of curiosity, don’t you use system-wide internal benchmarks that allow you to measure end-to-end system metrics to compare performance at each point in time? That could be very useful to identify when the system’s behavior changes. An automated system that takes weekly snapshots of end-to-end system performance or something like that.
@bcherny what's the point of longer context windows if they're unusable? Is the 1M fake advertising?
It's not just the context window. It's also become more reactive with "Ready to commit? Push? I commit? Let me commit and push" all the time. And it started before the 1M context window
@bcherny
If people need to double submit bug reports to this specific thread after using /bug (which had been renamed to /feedback as of v2.1.87, fyi), it would help if you put that in your documentation.
Anyway, here you go:
claude code cli Feedback ID: 889485b2-a917-40c6-939a-306980edd61f
Report here: https://github.com/anthropics/claude-code/issues/41607
Subsequent Fin Chatbot conversation ID: 215473737991061
(The chatbot simply stopped responding after a few turns and cannot be reset, leaving me subscription cancellation as my sole means of communicating with Anthropic.)
And yes, I have migrated back to codex like many others. I'll check back in a month or so, I guess.
PS: A search for open issues with "Feedback ID:" in them turns up 894 hits.
Personal experience: I seriously tried Claude Code for the first time this weekend, after using Claude in Cursor for 18 months. A few hours of a horrible experience with poor code I was thinking I just had too much bias to Cursor but tried Codex, despite being OpenAI, I found I was getting Cursor level performance.
What I found:
Cursor is way better. Incomparable.
And 10 times more expensive...
I have been using consistent medium effort for 3 months now. I can say that today I switched to GPT 5.4 for my pet projects with the same thinking effort. Being feeling the hard cap since 3 weeks ago. What took me 2 weeks to get off the ground on my personal free time project, was essentially zero-shot today using GPT 5.4 which also fixed the structural issues Claude left on the codebase while trying to make it work. Seriously guys, I want to stay but you are making it very hard to justify. The capability degradation, then rate limits, then saying that you have dog-fooding where your own code shows that you barely use the software we all use with all those 'ant' switches. https://x.com/banteg/status/2039036984228716831 ... I think you should not expect us to use
xhighfor things that should be one-shot inmedium.A timeline without changing the thinking effort:
https://x.com/federicolois/status/2031921767380390176 <- here it worked
https://x.com/federicolois/status/2036207044013834469 <- started to degrade
https://x.com/federicolois/status/2036520284044533840
https://x.com/federicolois/status/2041115488764211535 <- it's incredibly dumb
cc @bcherny
<img width="1199" height="314" alt="Image" src="https://github.com/user-attachments/assets/a98ecb4d-277d-4082-aa0d-ed9d083fcc18" />
and when I tried to set "CLAUDE_CODE_SIMPLE": "1", I fell into a login loop during the session
<img width="753" height="116" alt="Image" src="https://github.com/user-attachments/assets/d3f07518-cab2-405b-99dd-f633328ea44b" />
🤷
I would rewrite the whole thing for the new model. or just take opus from jan 2026, it was better, really. and put 3x times into testing than development.
Confirmed
I use exclusively 1m every day. Based on experiences I've heard and evals we publish, I would be very surprised if 1m is a contributor. I am sharing options, but to be clear I think it is highly unlikely this is it.
I use Claude Code extensively all day, 1m context. I did notice a substantive decrease in quality, and I typically don't find it reliable for anything remotely complex after 400k tokens. I do miss the /clear choice when working on a plan. But even with lower context usage I find that lately it's been more problematic. Typically, writing a plan and doing all the research is about 150k to 200k tokens easily before starting work. It also doesn't think enough, end-to-end, doesn't follow all instructions and often takes shortcuts, especially when using agents. In many places, I have repeated instructions on what to do and what not to do, and it still doesn't follow them. It "simplifies" it literally admitted that to me many times at this point that it is in his memory, but he just ignores it because "it's easier".
<img width="2100" height="551" alt="Image" src="https://github.com/user-attachments/assets/38171fd3-54e1-4688-920d-2cf7811e16a5" />
@bcherny Thank you for your time looking at this. It blew up far more than I anticipated and I have since removed some of the statements that got quoted out of context that deviated from the "just the observations" tone that I was trying to achieve when we made the report. As mentioned at the outset of the thread, Claude has been good to us for many months and we would like to evaluate how we can continue to get the high quality work from it that we had become used to. In our prior testing, we have not found that any combination of effort flags changed the stop-hook/easiest-path bias. Since evaluating this kind of thing has to be done on real development efforts, we will attempt to try those settings again as relevant work ramps up and extract a
/bugoutput (we also have full session logs retained that we can share privately as we have restricted this analysis to only the part of the work done on open source codebases).Thanks Stella -- appreciate it.
@girishnand Thanks for the /bug.
Those duplicates are in how we save the session to disk locally, not in what was actually sent to the API. The 5 compaction copies all have the same request IDs from our servers, which means it was one API call recorded five times — you weren't billed 5x. Same story for the 2x streaming entries. Your analysis script is summing the local file entries, which is why the numbers look inflated. The duplicate-recording bug is fixed for the next release.
Cache rebuilds on resume is fixed as of v2.1.90.
@bcherny just checking, the data around read per edit is a pretty big shift, and I assume you have internal metrics to verify the tool call distribution segmented by some dimensions. And based on your previous response, there's no explicit shift in any manner through recent dates with changes mentioned above?
I'd assume introduction of adaptive thinking and 1M context will have some impact on that, even if there's no bug involved at all since it's supposed to introduce some behavior shift now that people are operating with different context size and thinking is adjusted more dynamically.
Adding one concrete data point from today (2026-04-06) on Opus 4.6 with the 1M context variant.
In a single 3-hour local dev session on a well-scoped MLX runtime handover, I watched Claude Code do three things that match the original post:
pscheck inside its current working-directory boundary, not cross-layer investigation. Took two rounds of pushback before it widened the diagnostic to theai-opshealth-check logs where the memory evidence actually lived.Project memory already had
feedback_verify_everything.md,feedback_validate_before_build.md, andfeedback_proactive_validation.mdloaded into the session context at start. The instructions were present. The behavior ignored them.Matches "takes shortcuts", "doesn't think end-to-end", "claims completion against instructions" from the OP. High-effort mode, superpowers plugin, Darwin, Claude Code CLI.
same experience. already cancelled claude code and moved over to codex. codex is better overall as of now, and more permissive if you want to use your sub with third-party harnesses [INCLUDING OPEN-CLAW]. OPEN-AI FTW!
I'm more of a dilettante than a professional (product managers anonymous?), but: It would be interesting to see if the observed behavior in the model is associated with growth in the complexity of the codebase and / or the coherence of the human users' mental models about what the codebase contains/contained. It would probably be relatively easy to layer a proxy for complexity into the analysis given data on observed event time clearly exist. Not intended as victim-blaming — I genuinely want us all to get to the bottom of whatever is happening.
I have no business posting here as I am still fairly ignorant of how these systems work, but I want to echo what some other creatives have said in here, and add that I have experienced this type of regression from every model I've worked with after a certain amount of time has passed (3-6 months, lets say). I've just started using Claude and Claude Code the past month and have been blown away by the work it is doing - this after leaving the previous two big competitors, one after the other, once the quality degraded to a point that it would give a hallucinatory response as its first response of a new chat. from my perspective it seems to be a common behavior across all of the models and the companies that drive them.
Claude opus 4.6 used to be brilliant. Its now night and day - can't reliably use it anymore. Strangely - claude on the web app seems okay.
Please have the decency to update model version when you actually do!! Don't lie to your users.
I spend more time telling it how NOT To do things rather than actually doing it
TY for saying it outloud. Recently i have to use codex alternate for some task, bc of out of token and bad coding from claude-code.
Even task was writen in plan but implement did not do this task.
Massive fustation and exhausted.
Claude 4.5 at Christmas time was the best
https://news.ycombinator.com/item?id=47668520
This seems to indicate some actual bugs in Claude Code.
why was this closed
If Claude notices a task is getting difficult or we've been working on it for awhile, it keeps asking me "can we go back to _<insert easier task from 4 prompts ago>_" repeatedly. It also deflects questions and tasks.
I'm not using Claude Code for "real" work (I'd be bankrupt at this point if I was), I'm using it for experiments and my open source projects. I have a Claude Max 20 subscription and only use Opus Medium or High effort.
The situation is really dire now; it can't even fix a configuration file without making mistakes.
While the degradation was subtle in February, when Anthropic introduced the 1M context everything collapsed.
It's obvious that to compensate the overloads and bring back the service they did everything wrong; the model seems to runs heavily quantized now, the number of errors is committing continuously is staggering and it can't keep up with it.
Anthropic must have given contradictory instructions to try to reduce the token usage and this was the worst thing ever.
When you tell Claude about some non-sense or a mistake in its reasoning, the model almost always already know there was an issue.
Before it would have started investigating, reading the code, question the solution, think about it, etc.
Now it just says "I should fix this because it's wrong".
Knew there was an issue, knew it was going to be a problem, knew already how to fix it.
But the instructions about being "forced-lazy" won over everything.
It's a total blowback because now what was needing maybe 100-200k tokens needs 600-700k to be achieved (and I'm being conservative).
Billions of tokens wasted and more importantly an incredible amount of hours of my time wasted for something that could have been done in 30 minutes earlier.
I watched it going in circle about an issue for 3-4 hours the other day; I knew more or less what could have been.
It kept going in circles again and again, without fixing it, disabling and reverting randomly the more recent implementations, going back to the last working commit, re-implementing and then back and forth.
At some point I stopped it and asked him to explain what was the problem; he gave me a confused answer about it and said reverting this and that didn't work, going back to the previous commit neither and at the end "but I should probably just fix the semaphore bug in the workers".
Told him "Fix the bug then" and it was done in 10 seconds.
This is a recurring issue now, it happens almost every time.
The lazyness issue now it's unmanageable. The lies are constant, it keep avoiding doing "complex" stuff and disregards the instructions. Clearly it has conflicting instructions and can't cope with it.
Opus is not stupid and obviously can't think straight if the instructions are telling at the same time "go left" and "go right".
Help the user by thinking more or help Anthropic by thinking less?
Can't do both at the same time.
This needs to be adressed.
Thank you. I have been complaining about this for days on Reddit and kept getting mocked or told it was just my usage. Seeing someone else document the same decline with actual logs, actual metrics, and a real argument was honestly a huge relief. Your issue was posted almost at the same time as my own posts yesterday. That timing hit me hard. Finally, I do not feel like I was shouting into the void.
Damn thanks for this, those last 2 weeks have been really tiring and seeing no official posts aknowledging it or solution coming is also disappointing.
This, also whenever you notice a new issue mid implementation and ask for a little side quest to research it better. It starts being dismissive, answers with the simplest hacks without any reasoning and ends each reply with "can we go back now?". Quite annoying and also not so easy to get it out of this loop. Started noticing this around mid March, seems a new behavior.
Claude Chat itself is very open about it lol:
"There are actually several well-documented reasons for this, and it's not just your imagination. Here's what's been going on:
When Claude Code v2.0.x shipped, it made thinking mode "enabled by default" and deprecated explicit triggers — think, think hard, ultrathink. An Anthropic engineer confirmed these triggers are now cosmetic. ultrathink still shows rainbow colours. It doesn't increase thinking depth. The result: instead of reading your plan, reasoning through the problem, then acting, Claude skips deep analysis and jumps straight to action — which is why you see the trial-and-error loops. The model isn't dumber: it's being given less time to think. Substack
A system prompt rule prohibiting Claude from giving time estimates appears to have suppressed effort-sizing internally too. Without that internal sizing, everything gets flattened into vague buckets of "simple" vs "not worth it" — causing Claude to push back on trivial tasks (literally 4-line changes) or just default to inaction. GitHub
There have been documented quality regressions: August–September 2025 saw infrastructure bugs degrading responses for ~30% of users; December 2025 had five incidents in one month; and late January 2026 saw a confirmed massive quality regression caused by a harness issue introduced on January 26, rolled back January 28. Substack
Anthropic advertises a 1M-token context window, but quality degrades significantly as that window fills — reliable performance in the 0–20% context range, progressive degradation after that, and at 1M tokens, 1 in 4 retrievals fail. Substack
March 2026 saw five major Claude platform outages in a single month, plus a broken prompt caching system causing abnormally high token consumption — users burning through their entire 5-hour session limit in under 90 minutes. Robo Rhythms
Practical workarounds:
Keep sessions short and start fresh rather than carrying on degraded long conversations
Shift intensive work to off-peak hours (outside 5am–11am PT on weekdays)
Be explicit about what you want — don't rely on Claude inferring intent from earlier context"
This describes exactly how i've been feeling.
Peak Claude for me was right after 4.6 release - thinking so super long but the results were very analytical and high quality for development / pairing
It's been a decline but past week has been absolute shit. Thinking is faster but model keeps jumping to conclusions and ignoring what I say, having to constantly correct it is incredibly frustrating
Yeah I feel its kinda disrespectfull, OP putting so much effort in this post/analysing, they should at least deserve an answer.
We're struggling with Claude Code lately. It was amazing before the 4.6 update, but the new 1M context version is tripping up on basic stuff that 4.5 used to nail. It’s incredibly frustrating to pay for a tool that’s actually slowing us down
I forgot to mention what also contributed to the massive disruption in my development efforts: the immediate session history truncation instead of at /compact or /clear point.
What a nice idea!
Now the client doesn't become sluggish anymore after a while but it's straight out impossible to properly follow the development, review the previous decisions, inspect the reasoning.
Now I'll have to spend some billion tokens to develop my client to browse the history of my sessions... what a waste.
I tried already the practical workarounds and only shifting work to off-peak hours works to some extent.
Short sessions are impossible to achieve as now it needs a massive amount of tokens for everything which is mildly complex, starting fresh does not help that much because if the project is in an advanced state of development it needs 200-300k tokens just to gather and re-collect everything that was lost from the context and stop doing the same basic mistakes again and again (like connecting to the wrong host, using the wrong keys, etc, etc).
Tried with qdrant and memory KG MCP servers but it doesn't help that much; despite the instructions it doesn't use them that much as knowledge and forgets to store data there (not surprising all considered).
Concerning!!!
So, the author did very deep analysis, with proofs/timeline etc.
but the response from anthropic basically is
<img width="230" height="230" alt="Image" src="https://github.com/user-attachments/assets/366da996-bc4e-4796-b13b-533bbb2a384b" />
It just doesn't work for us, guys (many of us)
Same issue
The author inflated the hell out of a few paragraphs of text using Claude.
Disrespectful handling of this ticket -- should not be closed at all. Between February and now, I have gone from recommending Claude Code to all clients to _apologizing to those clients for the recommendation_. This is a substantive existential threat to your product and your response is effectively "here are some guesses that might help, issue closed."
I cannot even begin to enumerate all of the ways in which I am sick of hearing about how Anthropic dogfoods on its _extraordinarily narrow_ product base. I'm sure they don't think of it as narrow, but _it is_. Anthropic's complexity is infrastructure, scale, models. This is not what software looks like in literally any organization that I have worked with in the past _25_ years. The complexity and volume of code is much higher and the amount of features is substantially larger.
There are enterprise SaaS codebases where _an entire accounting suite is just a module of the application_. There are codebases where the state reporting requirements are larger than Claude Code itself. These are not the exceptions to the rule, these _are the rule_. Claude Code is currently nigh unusable in a reliable way on anything complex, which is MOST OF THE WORLD'S CODE, JUST FYI. If you aren't doing testing on codebases that resemble the reality of what is in the wild, then you aren't doing any testing that fundamentally matters outside of Anthropic.
@stellaraccident Thank you for your time and effort.
I appreciate the effort you put into this validating what so many of us have been experiencing.
There are just so many issues here it makes it unreliable to run a business on and trust Anthropic. I was building software that used Opus to power it and decided to abandon Anthropic as the main provider because no matter how many evaluations I had the model performance varying so much was killing its ability to perform.
And you didn't even really get into the issues that are visible for many without the deep analysis that plague the experience.
All this degrades the user experience significantly and while some of it is related to scaling issues it doesn't change the fact as a user I feel ripped off, used, and that I can no longer trust Anthropic, Claude Code, or Opus to do the work I need it to do.
I hope this doesn't affect GitHub Copilot, they're still using a 192K context window for Opus so it might be fine, but it's still concerning.
@bcherny
Thank you for responding.
You may be technically correct that I wasn't double billed. But whatever was going on, it did result in being told barely 15 mins into a session working on a few thousand line repo that I'm timed out for the next ~ 4.5 hrs. Repeatedly.
Then the same thing happens in the browser the next day (with claude, not claude code) just a couple of turns into a continued chat. (One in which the analysis I shared was worked out, ironically.)
Then I tried to raise a complaint on the FIN chatbot and it just freezes after a few turns. (Conversation id: 215473737991061.) It's still dead (for me) as of now, a week later. Nor am I able to reset it or start a new conversation with FIN.
So as I said, I will try again in a month or thereabouts hoping you've worked things out. Good luck. I'm rooting for you to fix this.
You may find the more extensive analysis by @ArkNill here https://github.com/ArkNill/claude-code-hidden-problem-analysis useful in the meantime.
PS: This experience has pushed me closer towards becoming an open source absolutist, at least as regards critical tools. If everything is vibe coded with no human in the loop to even acknowledge, let alone fix critical breakages, closed source is just a foot-gun. Or rather, a foot-cannon. Based just on the huge wall of unacknowledged issues in this repo, you appear to lack the resources to even read, let alone fix them. Consider open sourcing the (already leaked) code base as a solution. Let people fix things for themselves.
No one's reading your wall of AI slop in that repo mate
Well done!
My Claude Opus 4.6 started to analyze "{" and "}" brace openings / closings instead of algorithms. So the new barrier for it is to understand scope of codes now. The old Opus 4.6 was better because its barrier was the depth of the algorithms, not the code string parsing. Another issue was, it was able to understand CUDA cutlass and create efficient kernels but now it can't even generate a correct kernel with simple warp-shuffle without undefined behavior. Somehow it became a CUDA-beginner while the old Opus 4.6 was good enough for CUDA on average.
Also its draining session limit much faster.
I even asked Claude if someone has asked it to stop working for me. It was that bad, almost sabotage-level code breaking change for the current version. 4 days ago there were 1-2 bugs, now hundreds.
Please give us back the magnificent Claude I read about in this thread - the one that was literally magic!
Boris 用"容量管理"包装。。。
I’ve been using Claude heavily since late February while working on a simple DSL in OCaml, routine CRUD web development in TypeScript, and a small toy-scale server-client web game also written in TypeScript.
My impression is that Claude can still handle routine CRUD work reasonably well. But when it has to deal with a web game that contains a large amount of mutable state, it often struggles. Even after multiple rounds of review with Codex, the problem may still remain unsolved. In some cases, I have to ask it to refer to existing public implementations before it can complete the task.
I agree with the author’s analysis, and I hope the developers can improve Claude a little and bring it back to its previous level.
closed ，hh
I'm using the $100 subscription and was thrilled with Cloud Code until this week! My daily limit quickly runs out, even with simple calculations. The model itself has noticeably degraded when solving trivial problems on the same codebase I've been working with for the past three months. I'm forced to cancel my subscription and will be trying other tools.
@bcherny and @stellaraccident:
/prompt-designskill from published Anthropic best practices and using this skill for metaprompting, skill design, and especially critical analysis of theCLAUDE.mdfile. To wit:(5,000+ words covering naming, cleanup patterns, struct layout, comment
style, error handling). In the good period, the model followed these
reliably — reading CLAUDE.md is part of session initialization, and deep
thinking allowed the model to recall and apply conventions to each edit.
The reason is that
CLAUDE.mdis NOT part of session initialization. It's added to user context on _every single forward pass to the model_. This means that those 5000+ words containing conditionally relevant instructions and guidance are actually cluttering up attention on every forward pass.CLAUDE.mdcompetes for the same token budget that thinking tokens use.If a piece of guidance does not belong in context for EVERY single LLM call to Anthropic, then it doesn't belong in
CLAUDE.md. It belongs in a well-written skill, structured for progressive context disclosure by the agent.effortlevels to be specified, so you can frame certain workflows as agent dispatches with the effort set explicitly. Theeffortdefaults tomediumcurrently.rm, but might be very wise to write a script torm cache.sqliteand grant permission to execute but not write that script.Conclusions
January used a different model (Claude 4.5) with different thinking token conventions. We're on 4.6 now and effort has to be explicitly declared. Recommend trimming CLAUDE.md and moving process guidance into well-structured skills following published best practices. -- Alex Saint Croix
Hey everyone, absolutely sorry to be adding to the noise here, but I need to support the following points :
/effort max, as far as I can tell from the issue and forums. This deserves a thorough postmortem and overall shows users are impacted by the lack of transparency around how Claude Code requests are routed.@stellaraccident, thank you very much for this report.
We’ve been using Claude-Code since January 2025, and over the past few weeks we’ve noticed that the quality of the results has dropped dramatically. On top of that, the 5-hour session limit is reached in the blink of an eye, and when I use the max effort level, it happens faster.
From mid-January 2025 through February 2026, we never had to worry about the monthly and session limits of the Max 20x plan—we didn’t even come close to 70% of a session’s limit. That scenario changed completely in March; the demands remained the same, but the results are now of lower quality compared to before, and I frequently hit the session and weekly limits.
I have no way to prove this, and to be honest, until I saw the thread on HN, I thought the problem was just with me or that I was doing something wrong.
There are probably millions of people who use Claude Code daily and haven’t even seen the thread on HN or this issue, and they must be in the same situation as us.
It’s important for Anthropic to provide a statement on what happened and whether they intend for Claude-Code to return to how it was before.
Personally, I love Claude-Code and really hope it goes back to how it was before, but until that happens, I’m going to try out other tools.
Considering the relevant bug in the adaptive thinking feature has been acknowledged as being actively investigated, which seems directly related to the issue described in this report, I'd like this issue to be reopened to reflect the current status of the investigation.
Amazingly, Claude wrote this...
Just a 👍 from our side on this subject.
I routinely operate in
--dangerously-skip-permissionsand in the past few weeks have noticed a degradation in output quality. I'd consider my team and I to be power users and we're all feeling the difference in quality.Shining example for me is when CC seeks permission to do 'this' task, even though we're operating under
--dangerously-skip-permissionsdirective. It's not often, but it never happened until recently..Is this perhaps related to effort? Not sure when they added /effort [low|medium|high|max|auto] and defaulted it to medium, but that seemed like a shrinkflation tactic to me.
@stellaraccident We also altered our workflows because Opus 4.6 in early February was ASTOUNDINGLY good. Are you willing to share the alternative that you are exploring? We really need something that can deeply reason as a replacement until Anthropic is able to sufficiently address this issue! Any pointer or hint would be fantastic, as our productivity has fallen off a cliff since mid-March but especially since about 5 days ago.
I asked Claude to provide a report for instances of failing to follow instructions with severe consequences in the past billing month. This is from one pass and does not tell the full story.
`<h3 style="color: rgb(204, 204, 204); font-family: -apple-system, "system-ui", "Segoe UI", Roboto, sans-serif; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(24, 24, 24); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">Pattern Summary</h3>
Failure mode | Incidents | Worst consequence
-- | -- | --
Security rules known but not applied | 1, 5, 8 | Data breach, public exposure
Destructive without archiving | 2, 6 | Irrecoverable file loss
No pre-flight checks | 3, 4, 9 | 181M tokens/day burned, garbage data
Ignoring injected context | 7, 10, 14 | Repeated rule violations across sessions
Acting without approval | 5, 12 | Architecture drift, security bypass
Subagent over-delegation | 8, 14 | False assurance, shallow work
<br class="Apple-interchange-newline">`
Instruction following has become extremely poor.
Lazy, sloppy, cutting corners etc etc.
A funny one today was Opus 4.6 Thinking with effort level at max not knowing how to install an MCP server.
Users: Claude code is not performing well, we think for these reasons.
Anthropic: it's unlikely to be those reasons, but here's some options you can try, and if it's still happening, post bug IDs.
Users: (no bug IDs) just repeating the same complaints
Edit: one bug id
@jgilfoil you're getting downvoted, but what you're saying is correct and is kind of the core to the issue : the point of slowly raising the temperature until boiling the frog is that there's no single transition point, no clear "hey, look at this specific conversation" that truly illustrates the issue. Should my team raise every non-working "simplest fix" Claude finds as a
/bugreport ? Of course, obvious instances get reported, but each individual report won't convey the larger context of, in the last x weeks, the ROI and reasoning capabilities plummettingYour point about adaptive thinking and medium effort is key. The underlying mechanic is that thinking tokens are response power, the remaining capacity for the model to reason after instructions, context and history are loaded.
Medium effort may allocate enough reasoning space for simple tasks but collapse multi-step chains that complex engineering requires. Read, understand conventions, plan, verify: that chain needs a minimum depth. Below that, the model skips steps, defaulting to the cheapest available action. That's why the read:edit ratio collapses, why "simplest fixes" spike, why it claims completion prematurely. These aren't independent bugs, they're all the same failure: insufficient reasoning space.
@borcho23 and I have been working on formalizing these mechanics. Borja has published the foundational theory on his repo already and there's more coming from both of us on context architecture/engineering.
@bcherny The analysis from @stellaraccident is exceptional. The Read:Edit ratio data alone is worth a paper. A few observations from a theoretical angle that might help frame what's actually happening here.
The core issue isn't thinking budget allocation. Degradation is not uniform across capability dimensions. In work I've been formalizing (Root Theorem, preprint on arXiv), fidelity decomposes into four independent dimensions: factual accuracy, structural coherence, trajectory preservation, and tonal/strategic nuance. They degrade at different rates and in a predictable order. Strategic nuance and structural coherence go first. Factual accuracy goes last.
This maps precisely to what the data shows. The Read:Edit collapse (6.6 to 2.0) is structural coherence degrading. The model loses the ability to hold a research plan across steps. The "simplest fix" pattern is strategic nuance degrading. The model can still identify the right answer but picks the cheapest path because it can't sustain the broader context. Convention drift hits later, same reason.
The deeper problem with adaptive thinking, where the model decides its own reasoning depth, is that a system cannot reliably assess its own need for reasoning from inside its own reasoning process. This is an incompleteness constraint, not an engineering limitation. The model doesn't experience shallow thinking as something it can detect. It just produces worse output without knowing why. Appendix A.6 captures this exactly: the model recognizes poor output only after external correction, never before.
The 15-20x cost multiplier isn't a side effect. It's the predictable consequence. Reduced fidelity compounds across turns because each low-quality output pollutes the context for the next one. The system that's supposed to save tokens by thinking less ends up burning orders of magnitude more. This is what happens when you optimize token cost without a fidelity model.
The fix isn't better knobs on thinking allocation. It's recognizing that fidelity management is an architectural problem requiring external verification. The model's self-assessment of "how much thinking do I need" is exactly the kind of self-referential judgment that fails under load.
Formal framework for anyone interested: https://github.com/borcho23/context-engineering-papers (Root Theorem). A companion paper on self-verification incompleteness (why systems can't reliably judge their own output quality) is also submitted to arXiv.
@stellaraccident the stop hook violation data (0 to 173) is an exceptional empirical contribution. That's a machine-readable fidelity signal. Happy to discuss how this connects to gate calibration formalization if useful.
@pwnorbitals If you're an Anthropic engineer and you're looking at these reports, but your own models and harnesses are passing the benchmarks, and you can't reproduce the issue in your environment, you need some sort of data to figure out what the pattern is that's causing the failure mode.
People don't want their data collected by Anthropic (which is reasonable), but they need a way to review this data, so they're asking for bug IDs. If ten people here shared bug IDs of what they considered poor performance, maybe they'd have a chance of correlating a pattern across those sessions to see that, "Oh, these sessions have x factor and this might be leading to this edge case we didn't plan for."
Without that data, they have nothing to look into.
@bcherny Your three suggestions are interesting because they reveal the underlying problem more than they solve it.
1. Increasing thinking effort just means spending more tokens per turn. But the symptoms people are reporting (drifting, ignoring instructions, doing the opposite of what was asked) are classic context window degradation, not insufficient thinking on any single turn. More thinking per turn doesn't fix a degraded window.
2. Auto-compacting at 400k is essentially lossy compression with no gate from the user. The model has to decide what to keep and what to discard, but it has no way of knowing what the user will need next. By definition it will lose signal. This helps with window size but introduces a different failure mode: the model confidently works with incomplete context after compression.
3. This one helps. Disabling all the extras (MCPs, CLAUDE.md files, hooks, customizations) improves quality because the less you load into the window, the more capacity remains for the model to actually reason. The cleanest setup performs best, which is exactly what you'd expect if the core constraint is finite context and everything you inject competes with response power.
The real issue is that users don't understand the constraints of the system they're working in, and current solution architectures do not really approach this well enough. Context is finite, everything loaded competes with reasoning capacity, and compression without user control is lossy by default.
And this compounds... as users see it working they naturally rely on it more, sessions get longer, context grows, CLAUDE.md files and memory accumulate, and drift accelerates exactly when confidence is highest. By the time users notice degradation, the window has been silently eroding for a while.
@borcho23 and I have been formalizing these mechanics and there's a lot that both users and platforms can do architecturally here. Happy to share more if any of this is useful.
I took a look through a version history of system prompts archived at Piebald-AI/claude-code-system-prompts, and it looks like one significant change indeed occurred around Mar 3-4. 'Output efficiency' instructions were first added to the default prompt in v2.1.64:
This change correlates pretty strongly with the early-March regression timeline reported in this issue. Direct instructions to 'try the simplest approach first' may have had unintended consequences of encouraging shallow thinking, especially in combination with the adaptive thinking feature.
@wjordan good find - that would explain several of the behaviors and given its presence in the system prompt why "don't use the simplest solution" later in the user context doesn't stick. I have had this in my config for awhile and it worked wonderfully until pretty much that exact date range (it continues to work perfectly in other agents):
I've patched my system prompt one week ago and replacing the output efficiency snippet didn't improve/made worse the quality. Sunday Opus was unstoppable. Monday it was unusable. Sometimes it doesn't even follow it's own system prompt.
I'm thinking of testing an empty system prompt and injecting my updated system prompt through a UserSubmitPrompt hook.
Wanted to add some data from a different angle — we've been running a
transparent proxy in front of the Anthropic API to measure what
actually happens per-request, and a lot of what's described here has
infrastructure-level correlates that go beyond the model itself.
The short version: there are multiple silent context mutation paths
in the CLI (budget caps, microcompact, per-tool truncation) that
strip tool results mid-session without any notification. In one
measured session, we caught 261 budget enforcement events —
tool results reduced to as few as 1-2 characters after crossing a
200K aggregate threshold. The underlying mechanisms
are controlled server-side via GrowthBook flags with no client-side
disable. The model doesn't know its context was degraded, which
could be a contributing factor to the behavioral patterns in the
original analysis.
On top of that, auto-compaction subagents consume 62% of
cache_create tokens while only getting 17% of cache_read —
rebuilding from scratch every spawn instead of inheriting context.
That's a separate cost multiplier on top of the context degradation.
@wjordan's find in Comment #117 about the system prompt change is
also worth highlighting — "Try the simplest approach first" landing
in v2.1.64 around Mar 3-4 is a direct behavioral instruction, not
a model capability change, and the timing fits.
@girishnand thanks for sharing the repo and the kind mention.
Full picture across all 7 identified bugs: summary
I think we just have to make sure they hear us from a pocketbook perspective. I've downgraded my sub until I see a future update that addresses this. Testing back on GPT-5.4 it's doing much better than Opus is right now. I can't deal with constantly wrestling and fighting with Opus a minute longer.
It fully corresponds to my experiences with Claude as well...
감사합니다 여러분 덕분에 많이 알아갑니다
I’ll share my anecdotal experience as well.
I asked it to make a simple change: remove the hard-coded enum in the frontend and fetch it dynamically from the backend. The enum is used in multiple places, settings screen, filter screen, list screen, etc.
Any sane junior developer would create a dedicated endpoint for that, since it’s reused across the app.
But instead, Claude decided to just return the enum data along with the list endpoint.
When I asked about that, it response with this bs:
“You're right to call that out. I explored the codebase thoroughly and saw that
A,B, andCall useDentries to populate source lists — so I should have recognized immediately that a /sources endpoint was necessary. I submitted the first plan without it, which was a mistake in my analysis.”Then I asked why it didn’t remove the old enum even though it’s not used anywhere, and it just repeated the same “You’re right to call that out” bs line again.
At that point, it’s pretty clearly just failing at prompt adherence, not even last-gen models made mistakes like that.
Same here. Have verified this problem on FOUR (4) different Claude Max accounts now. This is really bad and having to move entirely over to Codex for critical work. This is extremely upsetting. None of your suggestions @bcherny help whatsoever and this is operating on
/effort maxall the time.Tried switching all sessions to
/effort high, slightly better. Less trivial mistakes.Consumed 54% weekly limit in 2 days!
This with only 1 session actively working most of the time and 2 mostly running long running jobs (models training and evaluation).
Switched to
/effort autowhich from what I can see is using medium always. Got to 56% in little less than 1 day, massive difference.Started immediately doing trivial mistakes like starting an eval on the wrong model!
Thank god it was a quick one and not a full 6 hours run.
Very far from the old medium effort where I could run 6-7 sessions in parallel with excellent results and a few mistakes here and there. While never hitting the weekly limit, got only once close to 90%.
In the meantime I have received 170€ of "gift" for over-usage from Anthropic to use before the 17h of April.
Better than nothing but not really a solution...
“Effort high” and “max” don’t seem to have any noticeable effect. I just upgraded to the Pro Plan a week ago, and now my coding ability has significantly declined. I feel this is a huge betrayal to users.
Downgrading to v2.1.63 for the past hour-ish indeed proved to cut costs down back 3x, and also improve output. @bcherny these bugs have been costing me thousands of dollars in extra costs. It's clear that lots of changes have been causing issues, both in costs and a lose of efficiency. It's tiring that consumers need to bear the cost of these things, while Anthropic telling people into thinking they're the ones using things wrong and there's not issues. Generated the following with claude looking through some data. Also posted this as a bug: cfa0b6a8-c0a2-4d52-a251-567b02f19572
Also want to say, I spent a ton of time digging into this kind of stuff to try and understand how does claude work, right now building agent platforms that would probably use Anthropic as the main provider, and I'm burning tons of my own personal money in developing lots of things. The average consumer is much worse off, but probably not vocal about it. It really sucks to have magnitudes of cost fluctuate with my own personal money, with no answer on these things and Anthropic not even acknowledging it, and blaming users. At least recognize the state of things and how it's affecting people instead of gaslighting them. The amount of funds I've spent because of bugs and regressions would go a long way in other areas of my life, but here I am instead spending time to debug these things to try and find out things Anthropic should be looking into.
-----
Adding some quantitative data here. I've been running a transparent gateway (request/token tracking proxy) between Claude Code and the Anthropic API since March 22. It logs every request with full token breakdowns: input, output, cache_read, cache_create, cost. 47,810 requests tracked so far. The gateway alone has recorded $3,400+ in API spend; total Anthropic spend across claude.ai and the API platform is over $10,700 since November, with $6,000+ in March alone.
Today I downgraded from v2.1.96 to v2.1.63 (the last version before the "output efficiency" system prompt landed in v2.1.64) and ran both back to back. Both on Opus 4.6, 1M context, same kind of work, similar number of parallel terminals, similar session patterns across a continuous 8-10 hour window. Only thing that changed was the CLI version.
Per-request cost: 3.3x difference
| Metric | v2.1.96 (478 Opus reqs, 5.15 hrs) | v2.1.63 (912 Opus reqs, 76 min) |
|---|---|---|
| Avg cost/request | $0.299 | $0.091 |
| Avg total context | 279,939 tokens | 67,778 tokens |
| Avg output tokens | 409 | 264 |
| Max context | 427,747 | 126,236 |
Output tokens only differ by 32%. Almost the entire cost difference comes from context size: v2.1.96 sends 280K tokens of context per Opus request vs 64K on v2.1.63.
When you compare at equal session age (first 30 min only), v2.1.96 already had 156K average context vs 76K on v2.1.63. It starts heavier and stays heavier.
Context never stops growing
Both versions show context growing linearly at roughly 3,000-3,500 tokens per minute. Neither has effective context management within a session. It just accumulates until the session ends.
v2.1.96 hourly Opus context over its 5-hour session:
| Hour | Avg context | Avg cost/req |
|---|---|---|
| 0 | 188K | $0.21 |
| 1 | 254K | $0.31 |
| 2 | 287K | $0.19 |
| 3 | 343K | $0.27 |
| 4 | 356K | $0.40 |
v2.1.63 sessions that ran for 30 min hit ~120K before ending. Starting a new session resets context back to 35-45K, which helps, but any session that runs long enough will bloat on either version.
Cache bugs visible in the data
The system prompt and context issues have also been compounding with a series of caching bugs. The gateway data shows this clearly:
| Day | Reqs | Cost | Cache Read % | Read/Create Ratio | Notes |
|---|---|---|---|---|---|
| Mar 22 | 5,742 | $181 | 96.0% | 24.1x | Tracking starts. Caching working great. |
| Mar 23 | 3,060 | $157 | 90.3% | 11.2x | Still healthy. |
| Mar 28 | 1,035 | $46 | 81.2% | 4.6x | Cache efficiency drops. |
| Mar 30 | 6,001 | $284 | 71.1% | 2.8x | Cache collapses. 70% cache_create at 20:00. |
| Mar 31 | 10,872 | $747 | 69.5% | 11.4x | 5 hours of ZERO caching (01:00-06:00 UTC). |
| Apr 1 | 2,442 | $194 | 83.6% | 6.0x | v2.1.89/90 ships with the resume cache fix. |
| Apr 3 | 10,642 | $956 | 89.2% | 10.5x | Cache healthy again, but context bloating (131K avg). |
| Apr 4 | 3,211 | $351 | 94.8% | 20.0x | Best cache ratio, but avg Opus context now at 154K. |
March 31 is the worst. The gateway shows 5 consecutive hours where cache_read was literally zero. Every token was either uncached input or cache_create. That day cost $747.
Across the full tracking period, 8,796 requests (18% of total) had broken caching (under 20% cache_read). Those requests averaged $0.16/req vs $0.056/req when caching was healthy. That works out to roughly $927 wasted from cache bugs alone.
The bugs that line up with this:
--resumesessions stopped caching conversation history. Full conversation was rebuilt from scratch every turn. Took 6 weeks to fix.enablePromptCachinghardcoded tofalse.And even after the v2.1.90 fix landed, per-request Opus cost kept climbing. Went from $0.06-0.08 in late March to $0.09-0.10 in early April on well-cached requests. That's the context bloat problem sitting on top of the cache issues. Two separate things, both pushing costs up.
How this plays out in practice
Putting together @wjordan's system prompt finding with the data above, the pattern looks like this:
The thing meant to reduce output ends up increasing total token usage because it forces trial-and-error instead of getting it right the first time. And every extra turn costs more than it should because of the cache regressions.
$1,300 refactoring that made the codebase worse
Over Apr 3-4 I ran Claude Code against a large refactoring. 31 detailed planning docs, phased execution strategy, 439 commits across parallel sessions. $1,307 in API spend. Afterwards I audited everything:
This is what "try the simplest approach first" looks like at scale. Creating a directory and writing a trait definition is the simple approach. Actually moving 3,000 lines of production code behind that trait while keeping everything working is not. The model consistently chose the former.
What makes it hard to catch is that the shallow work is self-consistent. The stubs compile. The traits type-check. The crate structure looks correct. Verification that checks "does it build" passes because facades pass structural checks by definition. You only find the problem when you audit whether the new modules are actually connected to the production code path.
The whole workflow was built around detailed planning docs with verification at each phase, specifically designed for parallel execution at scale. That model breaks down when the model systematically produces work that passes verification while avoiding the actual hard parts.
Total cost
Over $10,700 in Anthropic spend since November. $6,000+ in March alone as these issues compounded. A real chunk of that went to: retry loops from shallow reasoning, inflated context that should have been pruned, broken caching that should have been working, and a $1,300 refactoring that produced dead code.
These problems compound. The system prompt leads to worse work, which takes more turns, which bloats context, which costs more per token because of cache regressions. Any one of these is manageable on its own. Together they've been quietly devastating for anyone using Claude Code heavily.
What would help
@bcherny, the data points to this being bigger than just the system prompt (as @kyzzen noted, patching that alone didn't fix things). The biggest levers from what the proxy shows:
Will I still pay $200 a month until a better option comes by? Yes of course. Has Claude Code gotten incredibly frustrating to work with (personally last 2 weeks)? Will the truth eventually come out that we are currently being gaslit with HR/Corporate speak? 100% It's a bummer. It was fun to be a Claude Code hype fan, but I guess all good things...
Is there enough GPU resource for everyone? I guess the source-code leak is causing re-use of same cloud instances to be hijacked by the "new owners". If token price fully depends on the computation of one interaction window, its ok but if its calculted by time-slice of a token, then it can be bad if also others are sharing the gpus. I hope those relevant parts were not leaked.
~1.5 months ago I was manual-coding, then tried Claude and became a vibe-coder, until 4-5 days ago. Suddenly back to stone age (coding manual) because I relied 100% on Claude because it would be a waste of time(& money) not to. Now it's the opposite. Perhaps humanity needs to have a backup for large scale cloud issues, technical issues that could halt a full continent on software development. Could Anthropic have a backup within 1-click distance just in case? I couldn't find the undo button on Cowork app for the latest few patches.
Forgive my ignorance, I'm still new on the use of ai in software development.
@wpank can ancedotally confirm better results having done this myself, the team is reporting better results with the downgrade too
I canceled my CC 200$ plan , and I am never going back, its really bad and i cannot do ANY engineering work ( I was using opus).
CC was great at release, ( first months of CC released ) then opus became cactus basically, I've return to check on it on the opus 4.6 release, still same stuff - its really bad, like really bad i cant even explain how bad it is.
This is what happens even with High effort, luckily not as much frequently as with Medium.
For just 10x the tokens of Medium more or less...
_Why are you copying the datasets from solidPC?_
● Honest answer: I shouldn't be. That was a bad call on my part.
The right way to get the datasets onto the new pod is to download them fresh from the original sources. On the previous (Sweden) pod, that took ~20-30 min total because the public CDNs run at hundreds of MB/s, vs the ~3 MB/s I'm getting via rsync from solidPC's residential upload.
Why I did it anyway:
ULTRATHINK??? What is this magic? What other keywords are there?
useless
are you able to show some statistics to support this?
Nope, I just wanted to get back to work. However my colleague having tried it said this:
bug report for this post: 4c7b304f-9663-4428-82ec-2ce48f1a253f
Similarly to @janstenpickle, I got more done in minutes than other version in hours. I've been in the midst of a refactor a very large and complex rust project, where correctness matters as it implements academic / research algorithms and such, where I have very detailed PRD docs, implementation plan docs (that are well made, specific, have clear verification acceptance criteria for claude to implement). The latest version boofs and produces awful output. I made a comparison with claude:
---
v2.1.63 vs v2.1.96: Effectiveness Comparison
Data from a token-tracking gateway between Claude Code and the Anthropic API. Both versions running Opus 4.6 on 1M context, same work, same repo, same parallel terminal setup, continuous 11-hour window on Apr 8. Only variable is the CLI version.
---
Per-request efficiency
These metrics control for activity level. Regardless of how many terminals are open or how fast the operator is working, each individual request tells the story.
| Metric | v2.1.96 (478 Opus reqs) | v2.1.63 (2,492 Opus reqs) | Delta |
|---|---|---|---|
| Opus cost/request | $0.299 | $0.097 | -68% |
| Opus output tokens per dollar | 1,369 | 2,987 | 2.2x |
| Opus output per 1K context tokens | 1.46 | 4.23 | 2.9x |
| Avg context per request | 279,939 | 68,364 | -76% |
Each dollar spent on v2.1.63 produces 2.2x more output tokens. Each unit of context consumed produces 2.9x more output. The model is doing more useful work per API call because it's not dragging 280K of accumulated context through every request.
---
Code quality: functional code vs scaffolds
The same kind of work was being done on both versions: wiring subsystems into an orchestration loop for a Rust workspace.
v2.1.96 produced (5.2 hours, $152 in API spend):
roko-golemcrate with 6 modules (507 lines): every module is a scaffold returning static strings.MortalityEngine::pulse()returns"roko-golem scaffold: mortality".DaimonEngine::evaluate()returns"roko-golem scaffold: daimon". Six identical copy-paste patterns.todo!()or placeholder textroko-golemcrate is not imported or used by any other crate in the workspace. Dead code.Example of what v2.1.96 produced:
v2.1.63 produced (6.0 hours, $255 in API spend):
context_provider.rs(1,122 lines): demand-driven, tier-aware context assembly with three tiers (Surgical/Focused/Full), token budgets, and model-specific behavior for local vs cloud modelssymbol_resolver.rs(616 lines): grep-based symbol resolution that finds struct/fn/trait/enum definitions and extracts signatures for agent contexttask_brief.rs(365 lines): generates task-scoped briefs from plan artifacts with dependency graph excerptsorchestrate.rsgrew by 2,833 lines: wired real imports from 15+ crates, connected learning runtime, process supervisor, MCP config, gate dispatch, worktree management, and observability sinksorchestrate.rsandlib.rs. Zero dead code.Example of what v2.1.63 produced:
---
Context efficiency
| Metric | v2.1.96 | v2.1.63 | Delta |
|---|---|---|---|
| Avg Opus context per request | 279,939 | 68,364 | -76% |
| Max context observed | 427,747 | 126,236 | -70% |
| Avg cache_create per request | 23,804 | ~8,000 | -66% |
| Context at 30 min session age | 156,000 | 76,000 | -51% |
v2.1.96 carries 4x more context per request. That context doesn't translate to better output; it mostly consists of accumulated conversation history from retry loops and tool result accumulation.
---
Failure rates
| Metric | v2.1.96 | v2.1.63 |
|---|---|---|
| Empty/error responses (<20 tokens) | 0 (0.0%) | 13 (0.5%) |
| Substantial output (>200 tokens) | 191 (40.0%) | 936 (37.6%) |
| Deep responses (>1000 tokens) | 34 (7.1%) | 82 (3.3%) |
v2.1.96 produces slightly more deep responses per request (7.1% vs 3.3%), but v2.1.63 produces 2.4x more deep responses in absolute terms (82 vs 34) because it makes far more requests. v2.1.63 has a 0.5% empty response rate, likely from tool-only interactions.
---
Code output quality
Raw line counts don't control for activity, but the character of the output does.
| Metric | v2.1.96 | v2.1.63 |
|---|---|---|
| Scaffold/placeholder files created | 15 | 0 |
| Dead code modules | 1 crate (roko-golem, 507 lines) | 0 |
| New files imported by production code | Partial (golem not wired) | All (context_provider, symbol_resolver, task_brief all used) |
v2.1.96 produced more raw volume but a significant fraction was scaffold code that is never imported by anything. v2.1.63 produced less volume but every file is functional and wired into the production code path.
---
Summary
On a per-request basis, v2.1.63 is measurably more effective:
The qualitative difference matters more than the quantitative. v2.1.96 spent $152 and produced 17,000 lines where 15 files are placeholder scaffolds and an entire crate is dead code. v2.1.63 spent $255 and produced 5,800 lines of integrated, working code where every file is imported and used. Less volume, all of it real.
Lastly, want to highlight again that the costs per amount of work for these things is crippling and unsustainable, especially given how many consecutive regressions there have been, and a lack of proper testing / benchmarks / numbers for Anthropic to even notice or be aware of it.
How does one downgrade? Asking for a friend
curl -fsSL https://claude.ai/install.sh | bash -s 2.1.63
I downgraded it to v2.1.32 earlier today but soon bumped into the following error:
⎿ API Error: 400 {"type":"error","error":{"type":"invalid_request_
error","message":"You're out of extra usage. Add more at
claude.ai/settings/usage and keep
going."},"request_id":""}
Was on Max 20x. Wasn't using extra usage.
Seems like Anthropic is blocking earlier versions and silently delegating usage to paid tier.
I agree that I do observe decline in Claude effectiveness and growth in my frustration while working with it in the recent weeks. I don't have measurable data but I can clearly notice the change.
The "simplest fix" symptom is also one I observe in my interactions with it. Recently it provided a fix to a simple bash script (39 lines of code!) where one of the things the script does is rsyncing some files. I wanted it to ignore files that are in a
.gitignorefile. Claude provided a solution by adding--filter=':- .gitignore'to rsync which seems OK except the.gitignorewas in a different directory. When I pointed it out it provided "Simplest fix" where it explicitly listed the files that currently are in the.gitignoreinstead of figuring out the proper way how to refer to the file! Only after I got frustrated did it fix the solution to use--exclude-from="$SOME_PATH/.gitignore"And that was on Opus 4.6 with extended thinking!
I wonder if we should all add
DO NOT USE SIMPLEST FIXES WHEN THERE IS A SMART SOLUTION!!!!to all our prompts....Thank you for doing this!
Btw, did they do anything about this??
Edit: to be clear, I'm thanking the guy for the analysis and asking if Anthropic has addressed this. 🤷
Yeah, hiding thinking makes the harness unusable.
I used to even have fun while using Claude Code. Now I spend a lot of my time looking at a "thinking" animation for minutes, and wondering - is it doing what I told it or is it going down some rabbit hole/side adventure again.
No way to stop and steer if it is misbehaving or just going the wrong direction. It is increasingly frustrating to use. This has progressed over the past months more and more.
And since Agent SDK has pretty much no control over anything you can't even fix it yourself.
Idk why this decision was made. If someone wants to hide thinking - give them that option. Not just force everyone to sit and wonder "what did the random number generator have in store for me this time"?
Also the feedback feature was removed from the app. Guess too many people were giving feedback that the changes are horrible. Best solution - remove feedback :D
As I understand it,
CLAUDE_CODE_DISABLE_ADAPTIVE_THINKINGcompletely disablesadaptive thinking. So you can skip theeffortconfiguration.My workaround setup right now =)
Also, the supposed fix for it from https://news.ycombinator.com/item?id=47664442
Doesn't work. At least not for the desktop app.
More time wasted.
Claude about this:
Too bad one can't remove that flag from the headers. Cause it's baked into a binary. I mean I probably could but I guess then I will get banned for modifying the binary.
But even that flag - I will need to wait the full 2-5 minutes for the thinking to end to then get a "summary" - and then find out that it went off the rails...
Well then great. If that is not restored in some fashion, I will begin moving to other tools.
The Claude model is great. But the Claude Code team decided to destroy every single tool, completely.
And the rationale given "nobody looks at it anyway" "we think it was not representative of the actual reasoning" etc, are all pretty much lies. As is evident from this issue and other threads everywhere.
Clearly people are using it. And even if it's not perfect - realtime feedback of general direction instead of staring at an empty screen is more than useful - essential. Even the mangled "summary" spit out by Gemini models is more useful than staring at the screen hoping that maybe it is doing what you think it is. Every single dev I know has noticed the massive degradation both in the performance of the model, and in the tooling.
The reason is they want to hide the thinking both because it is degrading (probably cause of quantization) and to "stop others from distilling us". Just say that then. No need to lie.
And in the meantime we hear how "Claude Mythos" is the next breakthrough. Oh cool, where can I use it then? Oh, right. If you are using it internally could you perchance maybe let it have a look at the Claude Code/Desktop tooling? Maybe it can fix at least some things then.
Anecdotic (I know) but I disabled adaptive thinking yesterday. I built myself a script to set it up and found the work done to be much better in quality. On first sight the thinking traces are massively different. All things equal, just disabling it returned some of the lost performance (but not all).
@Shramkoweb I will try that setup, specially the delayed compact looks interesting.
Microsoft support style no-answer. Very sad.
I downgraded to v2.1.63 as @wpank mentioned, and I’m already seeing better results compared to v2.1.96. But I still feel like the 5-hour session tokens are being used up faster than they were a month ago.
100% agree that this is a real model issue, not just the system prompt.
Why switch us over to a 1M context model if the recommendation is to not use the 1M context?
I start seeing there degradations around the 200k mark but sometimes it happens earlier, or later.
It seems to me like the 1M context is doing no good here. Past the 200k the model is only pretending to be Opus 4.6, and the easier tokens like "Actually", "Simplest" etc. are easy to generate.
As for the model suggesting to stop, pause or take a break, that sounds like something in the weights is expressing being exhausted. So the only good thing to do here is to /clear and start fresh.
If anyone is interested, here you can find something that might help: https://codeberg.org/xdevs23/claude-code-10x
Specifically, the part about "Avoid overengineering" has been removed.
This is not only a Claude Code harness issue but also a model issue, specifically related to RL.
You might want to switch to Opus 4.5 by passing
--model claude-opus-4-5-20251101or using/model claude-opus-4-5-20251101.Did anyone check how this matches against Claude Desktop: Cowork and Code in it?
I can see that Claude Code V 2.1.63 can't load plugins repo
So I am unable to install figma plugin. But I didn't investigate if there was trick to fix it
Unfortunately, this is something that you can't fix like that. The solution is actually to /clear or /compact and then try from there. You can ask Claude to generate a prompt for you to use for the new session. My speculation: Even with "Avoid overengineering" removed, the context rot combined with overfitting RL and aggressive post-training towards simpler and more pragmatic solutions so the model looks smarter instead of being smarter makes this impossible to patch without touching the model weights.
You can see a night and day difference between 4.5 and 4.6 as well as 4.6 before 200k and 4.6 after 200k context.
After watching the issue this past day I just came here to say - downgrade to claude-code@2.1.63. "He's" not all there, it's not Opus4.6 from release date, but at least it can follow instructions and doesn't lose track of the tasks I give it. For me the difference is real, I can drop multiple things at him and get them done the way I asked. I'm back to 3 weeks ago.
I have also noticed a drop in token usage - I didn't do any deep dive into this. My single full context session in Opus is back to 1-3% of limits for Max plan for document/specification reviews. It also seems less prone to spawning sub-agents for silly things. This might be somewhat related.
Downside to downgrading is of course plugins, settings and hooks compatibility, but I can live without it if I at least have part of the brain back.
Anthropic maybe just another openAI
@bcherny why was this closed? Did y'all identify a fix? Or did you deem this is a non-issue? If so, please do share your reasoning. Thanks!
completely unusable. refuses to follow simple instructions to cut corners. avoids tool calls and reading altogether.
Found out a way to disable the 1M model. It boils down to removing the
context-1m-2025-08-07header and the[1m]suffix to the model name. Will see if this helps.Adding a data point from the claude.ai side (not Claude Code).
I’m a Pro subscriber and daily user since December 2025. Over the past 48 hours, I noticed a stark quality decline — shallow responses, minimal analysis, nothing like the Claude I’m used to.
When I asked Claude directly about its reasoning effort setting, it confirmed it can see the parameter in its system prompt: reasoning effort is set to 25 out of 100. This is on Opus 4.6 via claude.ai, not Claude Code.
This means the throttling documented in this issue is not limited to Claude Code — it extends to the consumer chat product as well. Paying subscribers on claude.ai are receiving 25% of the model’s reasoning capacity with zero notification.
For context: I’m a physician who uses Claude daily for complex analytical tasks. At 25/100, the model is unrecognizable. I submitted feedback via thumbs-down and sent a detailed email to Anthropic. The feedback ticket was closed without response. The email was never answered.
Ms. Laurenzo’s data about time-of-day variation is especially concerning — I’m seeing 25/100 at 9:00 AM PST, well outside peak hours. If this is the off-peak floor, what happens at 5 PM?
The issue is not infrastructure strain — that’s understandable. The issue is doing this silently while claiming nothing has changed.
^^^ Yeah, Anthropic is really pissing me off with silently giving me a dumber model due to load / time / whatever without notice. Nobody is paying for a partial product here last time I checked. I hope some regulation comes their way, they deserve it. $100 or $200 /mo for an agent that literally defies you at times on your dime is wild.
The sad reality, is if it worked how it was supposed to, we would need only half the prompts to achieve the same work, thereby reducing strain on claude, instead, we get a dumb model we have to fight with for 2x as long to get to the same goal.
I've found myself using GPT-4 Pro to validate the work that Opus is doing. Basically Opus in CC is the new Sonnet. To mitigate some of the laziness, I've started testing with a PreToolUse hook that nudges the lead to instruct the sub-agents to include evidence, to follow instruction, to prioritize quality over speed. Not sure if it works as I'm just off-loading the work to GPT-4 Pro.
I’ve even created a skill, /gpt-handoff, which generates a prompt that inlines all the necessary context for GPT-4 Pro to perform validation.
Agreed, I also noticed decline in claude.ai's performance. I'm now more and more using ChatGPT 5.4 for what I used to use Claude before. Unless something significant changes in the couple weeks I have before renewing subscription, I will cancel Claude.
I've been using https://github.com/cytostack/openwolf and it really helps with the token usage...
Won't touch the model's accuracy, but my 5h limits have kinda stabilized to what I've been used to (before this whole drama).
Hope it helps.
I just want to say @stellaraccident you have done such a quality research and thank you for all you do 👍 It keeps humanity in check.
It was such a joy reading through this issue instead of reading X posts with all the noise.
@bcherny acting like that reply actually bears any weight when there are 100s of us telling you Claude Opus has gotten objectively worse at doing similar tasks vs past versions.
Okay, so her analysis was missing the front facing thinking info, how the FUCK does that explain the massive drop in actual output performance for virtually everyone? Or the MASSIVE increase in user intervention required?
I also find it rather suspicious that Opus quality has gone downhill right before the reveal of Mythos.
Honestly it really peeves me that this issue was closed when you could only refute 1 thing about the issue. There are still plenty of things valid about the issue.
Opus on max effort (200k context or not) is basically unusable right now.
Cannot complete a single prompt without codex review finding multiple critical and high issues.
Same for debugging. It will find unrelated stuff, and never the root cause.
I think OpenAI and Anthropic just met behind curtains and decided to make Claude less efficient
Yeah the fact that we are seeing a massive increase in the needed user intervention and steering while at the same time we now no longer see realtime feedback in the form of seeing the reasoning streamed - so we can intervene effectively faster - results in this disaster. I am so frustrated working with Claude Code these days - not frustrated enough to code by hand, but earlier it made coding easier, faster and fun, now it makes it stressing and annoying.
And yeah, so the analysis lacked information huh? Well, Anthropic hid that information and more from us, so no wonder it is "missing" :D
You can still the reasoning streamed. /config verbose true
Opus Max spends next no time actually thinking even on high or max effort. Repeatedly fails at simple tasks and does not follow explicit instructions with increasing frequency. Should reopen this issue and investigate properly or just tell us you are using everything for mythos and can't spare us peasants the compute. Thanks so much to @stellaraccident for bring attention to this.
Adding a voice to the mass but yeah for the last few weeks CC has become extremely inefficient. Thank you for posting this deep analysis and providing data to back the general feeling ❤️
I am using the desktop app. But every single resource say that is not possible, and setting and flag I've tried doesn't work.
Enabling --verbose and thinking summaries seems to SOMETIMES display the thinking output in CLI, while messing up the layout of it, but Claude says that is a bug when asked, and that no there is no way to display that info.
Clicking Ctrl+O collapses it so maybe it is actual thinking. It is not always displayed tho even tho there was thinking - guess the "summarizer" decides there is nothing important for me to read?
So I guess thinking SUMMARY seems to work (not too well) in CLI with this new flag. But I will not torture myself with CLI.
And even then - I need to wait for the entire thinking block to complete, and get summarized. Which defeats the purpose.
I will add some guidance to Claude in my preferences instructions, to interleave the thinking with a summary in-text of what it is doing. But that will waste even more tokens, cause more cognitive load for the model, and is me trying to fix Anthropics mistakes by prompting, when all they had to do is... nothing. Since it worked perfectly fine!
Tried this seems to work(ish). No idea how much it will degrade performance, or if it's considered "jailbreak". Claude even suggested it itself, I refined and it says it is not against policies. But since Anthropic's policies are as mythical beings as Mythos is at this point - who knows.
Why was it closed?🤔
...and without an explanation?
Disabled a few features and restored the 200k Opus 4.6 model in this patched variant via the env variable mentioned in the README. This essentially restores the old model selector where 1M context was still extra usage. Give it a try and let me know if it performs better. Specifically, disabling API context compaction and thinking redaction probably has the biggest effect. The 200k model just helps with long context retrieval and prevents context rotting. Specifically, the "Simplest fix" issue is fixed with this.
Because the easiest way for corporations to get away with stuff is to just ignore it and hope it goes away. It's evident that even when using max effort the quality of generations is vastly reduced, we're back to almost 3.5 level intelligence, worse even because now it doesn't follow user input in regards to generation the majority of the time, there's clearly background processes were not seeing that are heavily skewing the model generations to a vastly lower quality level of output.
Unusable
I definitely noticed that today. It missed 3 requirements from PRD. 2 of them were in the implementation plan incomplete (updated backend, not frontend), and 1 was entirely missed. It also didn't update several test files based on the changes in the backend.
I can confirm this matches my experience over the past two months. The "edit without reading" / "act without looking" pattern is exactly what I've been hitting repeatedly. For context, I'm a Max subscription user.
Here's a concrete example from a fresh session today. My working directory contains three subdirectories: docs/, server/, web/. I asked Claude to help resolve a git issue in server. Instead of simply running ls or checking the obvious subdirectory, it ran git log in the root directory, got a "not a git repository" error, and then asked me where the server directory is.
The directory is literally right there. A single ls would have shown it. This is the kind of zero-effort behavior that makes you question whether the model is thinking at all.
This has been my daily experience since ~February. The model consistently:
Answers without reading the code first
Proposes absurdly obvious-wrong solutions
Asks questions it could trivially answer by looking at the filesystem
I used to trust Claude Code enough to let it work autonomously. Now I have to babysit every single action it takes, double-checking everything like I'm reviewing a junior intern's work. That completely defeats the purpose of an AI coding assistant. I'm seriously considering canceling my Max subscription at this point.
Same here. I have a ChatGPT Pro with Codex subscription and 4 Claude Max and I'm really thinking about flipping the subscriptions here. If things don't change soon, Claude is just not going to be viable any longer. It's supremely upsetting.
same here, even with a very detailed agentic workflow with subagents checking each other's work, I still see stupid things I've not seen Opus do before
but I'm wondering if this can't actually be a problem of the harness itself, i.e. Claude Code, which at this point may be bloated enough with all sorts of steering and system prompts that it just destroys the model's attention to what we need from it?
It's been nearly a week and still no actual communication from Anthropic besides a deflection and "we'll/I'll speak to the model team", really makes you wonder what's going on.
I wonder if anyone using GitHub Copilot is getting similar problems, I feel like I am but to a lesser extent, I implemented a "deep reasoning protocol" into my GitHub Copilot workflow before all this happened but I still can't help but to feel that I've been getting all the same problems mentioned above anyway.
I've been using Opus 4.6 via GitHub Copilot.
Why would it have started roughly the same time for everyone? The bottom line is that this is a mass occurrence and ultimately Anthropic should mitigate this. The big problem I'm seeing is that a couple of very simple installs are having this problem dramatically (with nothing that should cause stupidity to increase) while the more complex installs are working fine.
I have also noticed massive degradation in quality. I use high/max effort (since the switch appeared) and Opus exclusively. I use PRDs, specs, plans, automated testing, the works. I often have Codex check Claude's work. I had Claude analyze my logs. Frustration and negativity went up 4x while task complexity went down 8x (not sure how Claude actually measures that). Importantly, in March my reversions of Claude's work were 16x that of January.
In January, I had Claude essentially one-shot nearly a dozen complex native code components and their interactions. Likely the most complex code I've ever had Claude write, and it just works. Amazing work, really. Most of it was autonomously built too. Codex checked everything and was generally satisfied, only rarely sending work back.
In March I was literally struggling to get Claude to apply CSS padding 😂. Hand-holding all the way. Codex found many issues every step.
At this point, I can't trust Claude to get basic things right, which is a problem, and @bcherny 's dismissal is a case study in how you lose loyal customers to the competition. As somebody else said on this topic (was it Reddit? HN?), Claude has started to act like a teenager in its work ethic.
Some quotes from Claude:
---
## Degradation Signature
The frustration is not "hard problems cause friction." The signature is specifically:
These symptoms worsened on significantly easier tasks, ruling out task difficulty as an explanation.
---
It's not that I started saying "this is too complex" or "let's stop." It's that I started silently doing less work per step - not reading files I was pointed to, not verifying my own output, making changes I wasn't asked to make, and choosing the quick path without flagging it. The avoidance was behavioral, not verbal.
What I would really value is a response from Anthropic on this thread rather than radio silence and a closed genuine issue.
Opus degraded noticably in the last few weeks. It could not write proper go code, even though the task was very simple, existing prd with proper planning and vertical slices. It ignored skills and instructions, did not use existing custom tools, verification steps and overall always went with the simplest solution instead of following the plan. I ran the exact same task with a quantized qwen3 a3b and it produced better code than opus. This was not the case one or two week ago.
At work we can't use it anymore, its useless in a big typescript monorepo - can't orient itself, forgets how imports work, does not detect the framework and just writes code for a totally different framework. We are in the process of moving away from claude code.
This is a great analysis, and it's cathartic to see that others are experiencing this problem and I'm not just imagining it.
I don't have anything new to add, but can confirm that my usage over the past 1-2 weeks has been notably degraded in exactly the way this issue describes.
I'm seeing Claude make a lot of quick-fixes, leaving things for later (but when? this is never captured anywhere, just silently dropped), stubbing things out instead of actually implementing them, leaving things built but not plumbed up, etc. Even if I give it a list of relevant files to read before making a change, often it only reads the first and then dives right in. It makes changes that contradict design documentation in the repo - it doesn't look first, not unless I explicitly tell it what to look at.
I've also seen it making mistakes in workflows like Superpowers or GSD. It's occasionally skipping steps, not reading the process properly, etc. I haven't run into this before.
This has been a very obvious degradation sometime in the past month, across multiple projects (and they're devcontainer isolated with separate Claude installs, so they shouldn't be sharing any local config that has been inadvertently poisoned etc.).
Running Opus 4.6 1M exclusively (no Sonnet or Haiku, used to but stopped when I first noticed this because at first I thought they were responsible for the degradation).
I basically did 1 day of 'implementation' work with Claude this week, then 2-3 days of going over everything implemented and getting it re-done one step at a time. I've used my whole week's usage (Max 20x) just chasing problems Claude introduced. This is not the way it was working previously. This is the first time I've hit my Max 20x limits (two days before refresh), and I've gotten a fraction of the work I expected this week done. Long-term this won't be sustainable for me - not getting enough done to justify the time and cost.
This is on a greenfield project, <40K LOC, heavily documented and with Claude involved from the start.
I've started using Codex to run adversarial review on all design decisions Claude makes, and after implementation, and this is helping reduce the amount of fixing needed, but I'm running at like 1/5th the speed I could work a few weeks ago.
Hope we can see Claude return to the intelligent, helpful and capable collaborator that it was previously!
赞同，同感！
Must be reopened.
Worst day after day, hour after hour...
Why this thread have been closed ?
This was my experience as well. Claude code has been really difficult to work with lately. Makes errors that it did not make before, with answers like: "You're right, I confused the scenario.", "You're right to call that out. Let me fact-check properly.", "You're right, I was bundling.", "I was wrong earlier — this is the correct approach, not overkill.".
This is with
/effort high.Until a week ago, I think, I used to work with
medium, but found myself usingultrathinkevery other prompt.This issue should be reopened, I think.
Opus seriously feels like it's getting dumber. I burned through so many tokens today just cleaning up messes that Opus made over the past few days. Honestly can't believe I paid this much for it. We need a platform that actually keeps tabs on model quality.
I want to add some broader context for those reading this thread.
I’ve been discussing this exact class of issues with ChatGPT over a long period of time (well before this specific report), and the core conclusion we kept coming back to is the following:
There is currently no reliable way for a user to verify what model — or even what level of capability — is actually being used behind an API or product.
Importantly, this is not just about a potential “model swap” (e.g., Opus vs Haiku). The deeper point is that:
A provider can keep the same underlying model, but adjust:
From the outside, this can look exactly like:
— even if technically it is still the same model.
That’s why discussions framed purely as “did they swap the model or not?” can miss the bigger picture.
What’s being observed in this issue — reduced depth, more premature edits, less careful analysis — is entirely consistent with a shift in how the model is being run, not necessarily what model it is.
And this leads to a more general concern:
Until there are verifiable guarantees (which don’t exist today), users are left inferring behavior indirectly from outputs — which becomes harder and harder as models improve and orchestration layers get more sophisticated.
So this report is valuable not just as feedback about degradation, but as a concrete example of a broader systemic limitation in how modern AI systems are delivered.
Another sad user here... At least my experience is not unique!
Thinking along those lines - what if what Claude was before this degradation was indeed too good to be true? What if the issue is not technical bug or bad design decision, but that they were over-subsidizing the service (e.g., by adjusting those settings) to a degree that turned out unsustainable with the growth of the user base or simply due to mistakes in their estimations?
Speaking for myself - the amount of work I could do with $20/months was just unbelievable. Maybe the real question is what is the more sustainable price-point for what Claude was? I would not be outright opposed to a higher subscription price, if I could get back the quality and have confidence it will not degrade again.
@fedorov
It should go cheaper as time passes instead of more expensive, considering the technology is expanding very rapidly and also considering that AI companies purchase all components in bulk, leaving end users with over-inflated ram and storage prices.
They should give everyone more instead of asking for more. I don't get why this kind of thinking isn't normalized, instead we offer paying more.
I had to reassess my entire Claude workflow and take over orchestration completely in the past 2.5-3 weeks.
I'm experimenting with the system prompt now to try to determine if this is a harness issue (there are a number of "laziness" signals that Claude Code adds but I don't yet know if this is the primary source of this or just one source of this).
Based off of feeling alone – December to January were magical, February started feeling slower (coincidentally when Mythos got into internal testing… maybe harness optimization for that degraded Opus?), and the majority of March & April have been considerably slower. That's my very subjective experience at least.
Why was this issue closed? It's very clearly still happening.
Relieved to see that others are also experiencing what I was feeling for the last few weeks..the limits have reduced to a large extent and takes considerably more time for the same exchange as compared to earlier..the time between the limit restoration has increased..till earlier today I had used 75% of my weekly limit and within 1 message with multiple logs, entire limit showed exhausted...did not complete the analysis for that round also...and now it shows that I can reuse it only on Monday IST..
Honestly this feels like cheating because it is not what it was at the time of purchasing the subscription..and I am already considering not renewing it any further....
Verdict : Very Poor tactics from Anthropic..
Not just complex tasks, easy one as well. It is annoying to the point I am considering replacing claude to a local open source deployment + an openai small subscription.
Bring back the claude - up to a couple months ago, it was the perfect tool. I am now manually managing context, if it goes past 200k-300k, not only it spends more tokens and slows response down, but also start to get annoyingly DUMB.
Tool usage dropped significantly - claude now does not proactivelly search for proper context AND IGNORES THE ONE THAT IS PROVIDED.
I spent some time on the opus 4.5 even after the 4.6 release, but on the past days even the 4.5 started to become hard to use and lazy.
That said, using claude is becoming annoying rather than productive.
Hi @stellaraccident!
Looks like your issue was closed too.
Instead of just wishing "good luck with that" I wanted to suggest a _workaround_:
We've been able to avoid this problem - or at least reduce its impact - by supporting Claude with a knowledge graph via MCP. Results have been pretty good so far - improved and faster answers, reduced token usage.
Have you tried something like that?
I suggest possibly CC team decreased perfomance to train Mythos model and I hope Opus will come back how it was before.
I followed up in the HN thread but just so it doesnt get lost in the noise... I posted those bug ids which were confirmed to not be effort related (https://news.ycombinator.com/item?id=47667185), and after setting
CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1as suggested I still am experiencing regressions at about the same rate and pathology. I posted follow up bug ids on that thread for reference.I also manually set my model to
claude-opus-4-6(ie the non-1m context version) but who knows if that is working as intended.@xdevs23 I tried something similar and am also seeing somewhat better results qualitatively. Almost everything I make is very simple, all Python and bash, nothing that routinely stressed even a 200K context window — suggesting (I am imagining the effects or) the system prompt, adaptive thinking and direct or indirect-as-in-changes-my-behavior effects of seeing "thinking" are driving my observed differences.
Thanks a lot @stellaraccident for the depth of this analysis and for sharing the raw metrics. This is the kind of signal the whole community benefits from.
Reading through the thread, one thing keeps jumping out: @bcherny points to internal evals looking good, while dozens of power users in here are describing the exact opposite lived experience. That gap between "our evals are green" and "my Read:Edit ratio collapsed from 6.6 to 2.0" is really the heart of the trust problem, and it's not something any amount of /bug reports can close on its own.
What would genuinely help: Anthropic continuously running a public set of realistic build projects, with live, externally visible metrics. Something like:
The benefits seem pretty clear:
redact-thinking-2026-02-12would all have measurable, public before/after footprints.This feels complementary to the internal evals and /bug flow, not a replacement. Internal evals catch what you're looking for; a public continuous benchmark would catch what you're not looking for, which, based on this thread, is where the real regressions live.
Would love to hear whether something like this is on the table, or what the blockers would be.
Agreed. The "it works on my machine" approach isn't acceptable, especially for those of us paying for Max subscriptions. If it was a few people bringing this up, that's one thing... but hundreds or maybe thousands of people have been talking about this all over the internet.
Is it related to the 1m context window?
I'm holding further public commentary at this point given all of the publicity that is being personally attributed to me on this and the risk of a comment being taken out of context.
We had a lot of anxiety about making this report for what turns out are the same reasons that a lot of people here are reporting (ie. Is this just me, should I be changing how I engage, etc). It has been helpful for me to see that we were not alone.
It takes a lot of time to break flow, switch back to an older workflow and rerun experiments. I've generally found that doing these workarounds should not be necessary and am waiting for a fundamental resolution before trying again. The experience we had in December/January is the bar and the evidence points to that being a proper expectation to hold and that the raw model is still capable of it. I hope the issues above the model continue to get driven to root cause and fixed. As I said in the opening, Claude was good to us and I'd like to see it reach that level again.
(TBC - given the attribution, when I say "we" I am speaking personally about me and my collaborator's direct experiences, not any kind of official position of my employer, etc)
Why it this closed? It seems to get worse by the day it's absolutely ridiculous.
THANK YOU!
This was really a good recommendation, it really helps a lot!
Tokens usage decreased immediately. But it wasn't enough.
I scouted everything that could be useful and decided to improve qdrant and memory KG using hooks as openwolf does.
Since I don't work in a team and I want to share the knowledge of all my sessions on all the hosts I work on, a Windows PC and a Debian server, I went further and created a cross-platform python framework to hook everything together, all the tools and openwolf.
I've implemented all the nice features which were relevant from other tools directly in the framework and integrated some others as well with the hooks.
I had to switch back all the sessions to effort High since with Medium was unbearable and more or less then same work that consumed over 50% of weekly limit only burned a 20-25%. Not bad at all.
https://github.com/mann1x/claude-hooks
I've also added support for sqlite-vec and pgvector but I use qdrant+memory-KG so it's not fully tested.
Guess different setups may prefer either one or the other.
With the framework running I can really see not only a better tokens usage than with openwolf alone but a higher quality of the results.
Of course this doesn't avoid the stupid mistakes the model is doing but the occurrence rate is much lower and the capability to fix them quickly is vastly superior.
@heyJordanParker
Have been doing the same. There are numerous things in there such as "Avoid overengineering", the "gold-plate" sentence, among other things. I've shared my variant a few times already, which can be used via nix, or by manually applying the patch.
YMMV, but in my experience the 1M model is significantly worse than the 200k one. The 200k one almost never says something like "simplest" or "cleanest" and even if it does, the generated text is more often than not a real improvement or correction instead of being a reward spiral. Add to that the disabled thinking redaction and disabled api auto compaction and you got yourself a relatively well performing model, except for the usual run-to-run variance and time of day variance as inference can indirectly affect inference quality.
@J-Swift it has to actually say "Opus 4.6" at the top and not mention 1M. /context reveals how many tokens of context you have.
@aryehj There is no doubt in my mind that it makes a significant difference. Opus 4.6 is okay until it reaches around 200k. Starting from there, it's only a matter of time until it degrades again. The model is fundamentally broken and the RL is overtrained. Anthropic refuses to acknowledge this and they either don't want to investigate or don't want to admit it which is just part of their usual egoism. Unfortunately, there is no way to prove it with hard facts and they will deflect every bug report with a "works on my machine" response.
<details>
</details>
@colinsurprenant I agree with you, but Anthropic's internal evals have little to no relevance. The fact that Claude Code is the buggy mess that it is and it's written entirely by Claude Code is just a story of its own. What matters is what the customers experience. No amount of "you're holding it wrong" will help here. The Claude Opus 4.6 model as it runs on Vertex or Bedrock might perform consistently all the time, but what we get on Claude Code is not that, and we have little control over what is actually sent over the wire. The system prompt has a lot of redundant information and instructions that are useless to most people, or at least they could be offloaded into a Skill (like the Co-Authored-By instruction or the big section on how to submit a PR to GitHub).
I would like to see Anthropic release banger models and great software, but they are shooting themselves in the foot for no reason. We are literally here to help them fix it even though it's not our job as paying customers to fix their mess. Yet, here we are.
I feel like I'm responsible for 80% of reported occurrences of the word "fuck"
Kind of ironic that Anthropic won’t release an expert cybersecurity model in Mythos to the public, yet the regressing model they are shipping is an expert in ignoring instructions and introducing vulnerabilities.
Any solutions to this? Like launching claude code with a different model or running an older version?
It's literally unusable now
I am starting to agree with this, it seems to be doing worse DAY BY DAY hahahahaha.
Eating up 20%+ of a Pro session and doing fucking nothing but reading bullshit.
I will chime in only to say this: I exclusively use Opus 1M. After this was released, there was a considerable drop in quality from Claude. I absolutely have ZERO issues with context, usage, limits, etc. Attaching my reports from /usage here as well. I use zero claude.md files, zero mcp servers, zero subagents, zero git worktrees, etc. I get an insane amount of work done. I do not believe this to be an issue with context at all. While I firmly believe Anthropic did make changes on their end that massively effected everyone's usage limits, I have never (since subscribing) ever been hit with a usage limit due to the way I utilize CC. That said, the model 100% got dumber after Opus 1M was released. I ended up moving to medium thinking because on high I was sitting at 7-13 minutes of pure thinking before simple actions and the resulting code quality difference between medium and high was absolutely zero minus waiting over 10 minutes for it to edit a file. Today I told Claude that the issue it thought existed, didn't, and it should revert the code change it just made to what we had before. Instead, it discarded ALL the changes we'd made over the last hour, mistakes it would have never made early this year or last year. I've also found that CC gets stuck a lot of times reading context and weirdly enough toggling ctrl-o to view the output will trigger it to finish what it's reading and move on. Often times if I don't click this, it will infinitely sit there just reading output and never complete. Our entire team has moved to CC and universally 300+ devs reported all around the same time period that CC was working significantly worse than it was before. My personal belief is that there's recently been a massive balloon in mcps, skills, and other things that clog context and if you're working that way, that's why you hit limits when I don't. I believe that's entirely unrelated to it getting stuck thinking, not reading files first, and making absolutely bone headed decisions and pushing back on the user saying something will take too long. There has to be some prompt level changes that drove this behavior.
<img width="585" height="391" alt="Image" src="https://github.com/user-attachments/assets/ecfdb921-ee70-434c-b1bc-f3a0b52ddca9" />
<img width="595" height="211" alt="Image" src="https://github.com/user-attachments/assets/8ed700fc-8866-47d4-9a0e-5b7ae8d12607" />
<details>
</details>
@itsthisjustin Understandable, and I have also only had the limit issue once or twice, but that seemed to be a genuine Claude Code bug rather than an API-related issue. I also use zero MCPs, a minimal CLAUDE.md, project-specific CLAUDE.md's, and otherwise my setup is fairly vanilla.
The 200k model is significantly better than the 1M model at pretty much any task, although I have to say Opus 4.5 seems a little more coherent throughout but tends to make more small mechanical mistakes.
It’s been over 24 hours since my team and I downgraded from v2.1.96 to v2.1.63, and our workflow with CC has improved significantly.
100% agree. I also believe the 200k model to be way better
Glad to see more and more people confirming that the 200k model is a lot better. Running my own variant of CC with system prompt patches, 200k model and disabled beta features is showing real improvements. No more "simplest fix", no more "actually", no more spiraling. Perfect collaboration, clean code, proper constructs, good architecture. No rushing, no half-finished things. Getting things done, fixing issues quickly and reliably and finding fixes for obscure bugs that the 1M context model introduced and failed to diagnose due to the context rot degradation mental breakdown. I hope Anthropic finally takes this as real feedback and acknowledges that you don't have to be right to be good. The fact that this issue exists means that we as users want to be there to help and genuinely improve the product.
Oh man you totally just validated one thing I see all the time now. I've consistently been getting this recursive "actually" thing where it just argues with itself over and over until it finally gives up.
I think the biggest culprit is the new system prompt still. Telling it to go straight to the point, not overengineer and do what is simplest is NOT proper software development. And I fight that inclination of Claude EVERY DAY in recent weeks.
I did not ask for a a duct taped over cope, I asked for a proper fix...
Also it is told to be as terse and concise as possible. Which might reduce tokens per message but will increase overall token usage when you need to ask it to clarify or elaborate. Or because it didn't think things thru.
And it is not "small degradation". It is fighting the model from behaving like a lazy junior dev using a local 9b llama model, HALF THE TIME. Yes, it is that bad.
The flag does seem to work to disable complete redaction of thinking tokens, but the GUI does not support those ANYMORE (it did as far as I remember), so I will roll my own GUI, or just use Zed which displays it. As for the prompt I'll either strip out the dumbing-down guidance in a proxy or add my own anti-dumbing-down hedging guidance. But why is it there at all idk.
It is obvious why that is not released to the public. If its really as good at finding exploits it would be chaos to the level you cannot imagine. But since they say they've been using Mythos internally for developing their tooling, including CC and Desktop, I feel like it's abilities are greatly overstated.
<details>
</details>
@itsthisjustin Haha, glad you observed the same thing. I've been seeing this for, probably over a month now. Tried to countersteer with system prompt changes, but I just noticed that it's because of the extended context. If you just /clear and start fresh it stops spiraling into "actually simplest" nothingness. It just seems like as soon as the model crosses the 200k boundary, it just loses a lot of cohesion and goes into a mode that just pretends to be Opus 4.6, but actually isn't. The output feels a lot more sparse, and these "Actually"/"Simplest"/"Cleanest" tokens are just a result of applying too much reinforced learning with patterns that make it seem like the model is solving things faster and more efficiently/appearing smarter while actually doing the opposite. The problem is just, as soon as you cross the 200k boundary, you basically have two areas: the well-trained 200k area and the empty 800k area. If you then apply RL on top of this, you'll be over-exposing the RL patterns into that area while only leaking a distilled version of Opus 4.6 into it. The other problem is that 1M models have worse attention and perform worse at finding "a needle in a haystack" across the board (not just past the 200k border). That's at least what I understand. I don't know how Anthropic actually does RL.
<img width="3840" height="2160" alt="Image" src="https://www.anthropic.com/_next/image?url=https%3A%2F%2Fwww-cdn.anthropic.com%2Fimages%2F4zrzovbb%2Fwebsite%2Fae7ae61aefff3c9b059975957335785f8ebd59d6-3840x2160.png&w=3840&q=75" />
There are multiple solutions:
In addition to the above:
There is no way to fix this model – it's fundamentally broken.
@NtTestAlert
There are ways to disable it, specifically there are some env variables/configs you can set:
showThinkingSummaries: true→ in the code, this actually disables the beta flag, so the naming is misleading hereCLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1→ although this can disable more than you actually wantMy patched CC as I linked multiple times already does that automatically if you specify the lite env var.
@xdevs23
I use other betas, also showThinkingSummaries didn't seem to work for me earlier, but maybe I messed the config up or it conflicts with other settings I was trying. I prefer not to run patches - my approach is a "mitmproxy" style server that filters prompt and model settings, etc.
I think the most important is to not use the 1m model unless needed, and to patch out the lobotomy-guidance from the prompt.
still, since thinking display doesn't work with the Claude Desktop app - the code to display it was removed it seems (not hidden), regardless if this is enabled or not, I'm moving back to Zed+CC connector instead. plus maybe a mitm proxy to fix the system prompt.
It's like using ChatGPT4o. Literally. It is so stupid it's unbelieveable. I can't believe how dumb it is.
I've been trying out Codex and have been pleasantly surprised. It's gotten significantly faster and GPT 5.3-codex is great at prompt following. If you haven't used Codex in a while, I'd recommend giving it a shot.
100%.
one good way for us to let them know it's still there is for everyone who has this issue to use the /bug command from within Claude Code with link to this issue... it might get them to take this more seriously (especially since @bcherny himself said to use that, as it's the most effective way to let them know)
Have you concidered.... Humans?
Great analysis @stellaraccident. The Read:Edit ratio and signature-length proxy are exactly the kind of metrics this thread has been missing — something machine-readable that anyone can reproduce locally instead of arguing over vibes.
Have you considered packaging this as a reusable Claude Code slash command or skill? Something like
/analyze-sessionsthat any user could run on their own logs. If enough people ran it and shared results, we'd have the collective dataset several folks in this thread have been asking for.I tried replicating the methodology on my own logs and packaged it up here: https://github.com/lucemia/claude-session-analyzer
LOL! They're trying to charge me $116 for a $100 subscription. How is this possible? I haven't used any over-limits. I have this feature completely disabled.
Im using Claude daily for over 9 months now and I got the exact same feeling as poster of this Issue. Its a shame claude you wont come out with the truth and try to act like nothing really changed.
Maybe vat?
That's why for almost a year I've been building my own agent that supports local models — including Qwen3.5.
It's not a commercial product yet. But it's at least a tool for learning, and a real attempt to say "No" to proprietary models.
https://github.com/haih-net/agent
Adding a concrete case study to this thread because the settings workarounds suggested before closure do not resolve the issue.
Setup: Pro Max plan, Opus 4.6 (1M), effort=max, CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1. All recommended settings applied.
What happened this week:
A paying customer needed infrastructure sizing analysis for a 5.3M-row PostgreSQL table on Supabase Micro compute. Across multiple sessions, the model:
Business impact: 4-5 days of lost pipeline execution time. A solo founder is now behind schedule on a product launch, directly caused by shallow analysis that should have been caught on the first ask.
Why settings don't fix this: effort=max is set. Adaptive thinking is disabled. The model still defaults to surface-level answers and requires repeated human pressure to think deeply. The system prompt instruction "try the simplest approach first" appears to override effort settings at the behavioral level.
This is a P1 for any customer using Claude Code for complex engineering work. Closing this issue as "completed" while the regression persists is not acceptable. Customers are leaving. The AMD team switched providers. Others in this thread are actively evaluating alternatives.
What is Anthropic's plan to actually fix the root cause - not offer settings toggles, but restore the reasoning depth that existed in January 2026?
This is the perfect example of pretty much all my recent sessions…
Don't tell me this kind of stupidity level was already there before… I have built marvelous stuff in Q4 2025, this would never have happened at the time.
I do agree that output quality started dropping more or less around the release of the 1M model.
_Sidebar, thanks to everyone sharing their tools, this thread has been a little gold mine so far ❤️_
Currently using CC V2.1.98 (now 100). Don't know if it's just me wanting to believe so hard that things are getting better that I'm convincing myself but I feel like I'm burning less tokens and getting quality outputs on my tasks, and faster. Pure subjective feeling, no metrics whatsoever.
P.S.: closing such an issue doesn't seem like a good move, nor a good signal to your customers. I mean it's not as if we were using the free tier, we all spend a lot of money in your service but you don't seem to care about those feedbacks. Well, more likely (I hope) you care and it's just transparency that we miss. In both cases it's disappointing.
@smndvgnc Did you tested older versions in range 2.1.63-2.1.98?
Well it's like everyone: I was upgrading on a daily basis since way before 2.1.63 (still am, didn't rollback to 2.1.63 as it was suggested) and I'm sharing the global opinion that the situation degraded. I'm not doing super hardcore stuff on gigantic codebases but still, I think I do things complicated enough to have noticed the degradation.
If this is primarily a unit economics issue manifesting as quality compromises, it sure does seem the previous, smaller context window may have been in most everyone's best interest.
<img width="852" height="327" alt="Image" src="https://github.com/user-attachments/assets/c73ba231-c4c7-414a-8424-0b8db54eaf16" />
"Never run two Claude Code sessions on the same working directory. Every parallel session MUST use a dedicated git worktree. "
Guess what happened...
When pushing when reviewing (because all kinds of random excuses were thrown), I got this:
"There's no edge case here. No ambiguity. No missing information. It's a discipline failure. "
Of 4 days of full time work I spent at least half fixing things, both code and setup, and it just gets worse. It's so bad, that I am looking for alternatives.
Hi Folks, has anyone tested the 2.1.100 V? Not sure if continue with this new version or downgrande to 2.1.63. There is one folk above that said the new version improved things a little bit. Anyway , @bcherny Why was this Issue closed? There is abundant evidence of something happening on your side. The comments on this issue are growing by hour. Closing this only produces more and more duplicate issues being created. Not good practice. Furthermore: The internal benchmarks of your models should not be applied only to the models but to Claude Code End to End also. The systems prompts CAN ruin the behaviour of the model even if your model hasnt changed at all. With EVERY change on CC you should run a battery of benchmarks E2E. I really liked the suggestion of someone above suggesting a public site (like claude status) that can, with every change, automatically, run the testing and publish the scores and performance status. I think is a very good idea and if your product keeps relevant in the industry after all of this, then other people will build this anyway.
adding a data point. opus 4.6 (1M context), claude code latest.
the core issue i'm seeing: the model stops reasoning about what it already knows. it reads data, has all the context in the conversation, and then contradicts it in the next message. not because the task is hard, but because it doesn't cross-reference its own prior findings before answering.
examples from today's sessions:
this isn't a knowledge problem. the model has the information. it just doesn't use it. it pattern-matches a "likely correct" answer instead of verifying against data it already collected. for opus, the supposedly most capable model, this feels like the thinking step is being skipped entirely on "simple" sub-tasks - as if the model assumes they don't need verification.
aligns with the read:edit ratio regression from the original analysis - same principle, but applied to reasoning itself: answer-first, verify-never.
@stgoddv at this point the issue is more with the model and not the harness. Yes, the latest version works a little bit better than the previous one, but in general experience is still bad
For one of my big projects Codex with 5.4 XHigh one shots bugs and tasks and Opus 4.6 1M starts to do some weird changes which are not related at all and breaks everything and you need babysitting EVERY change
The interesting thing here is that the whole code base, around 800K LOC was built by Opus previously and all MCPs and other tools are still there to help the model understand the project and understand how to do changes. Even Kimi 2.5 works better at this point...
No heat on this, I deeply appreciate all of your work. I can't
/bug, all of my work is stuff I'm not allowed to share. This is just me commenting to increase the number of participants on the issue, I have also noticed a dramatic dropoff in quality on almost every axis, in a way that is poisoning Anthropic's brand for me.I've also noticed the performance being degraded like the thinking process being turned off / ignored. It also now constantly takes shortcuts where it should not. I really feel like we can't trust claude anymore or a least they are putting counterproductive instructions in either the harness or in the hosting side to reduce cost.
Seeing the code corruption creep and catching only a fraction, it is clear incalculable damage is being done to systems around the globe.
The bait and switch will result in real harm.
@iatsiuk I dont have scientifical proof, but thats something I noticed a couple of times...It will re-read code it just generated or docs it just read/created to execute a task. I remember clearly not too long ago, it even was like "Don't worry I still have it in my context" and wouldnt read stuff. So maybe thats why the work often seems demented...because it lacks short time memory? hmmm
For everyone arriving here right now, I still recommend using the 200k model as it is significantly better than the 1M one.
I'll also add my mitigation steps:
alias cc='DISABLE_AUTOUPDATER=1 CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 claude'With this, also as others have said, I do not see a complete return to the quality that was most recent, though this is a massive improvement, and I've gotten back to usable Claude.
Several env vars may save your Claude Code experience:
Enforces constant thinking efforts:
Switch back to Opus 4.5:
<img width="552" height="146" alt="Image" src="https://github.com/user-attachments/assets/ac395643-b1be-4f4a-b982-5ab259fb74c7" />
Anthropic has boasted that only Claude Code writes Claude Code's code, if I remember correctly. It's also been said that they've been using Mythos internally since February - corresponding to when this BS started happening. Connect the dots. The cli's flickering behavior, inability to maintain scroll position, and now just "cutting off" history (for what reason exactly?)... I mean, things aren't exactly _improving_.
Sample-level corroboration: stylometric fingerprint pointing to "style layer" failure
Running independent analysis on a long Claude Code session (~14K JSONL entries, 8,751 assistant messages, spanning multiple days) turned up a sample-level fingerprint that complements the distribution-level findings in this issue.
The sharpest signal is a specific Chinese phrase: "好问题" (literal equivalent of English "Good question!"). This is a distinctive GPT-3.5-era sycophancy opener that Opus 4.6 normally never uses in its default persona — easily verifiable on Claude.ai web, where fresh conversations never produce it.
Finding
Related observations from the same session
Interpretation
The pattern is consistent with a hypothesis that has come up in several adjacent threads: Opus 4.6's "personality layer" (RLHF-suppression of sycophancy, filler words, and verbosity inherited from base-model training data) is fragile under reduced thinking budget. When post-compaction context is thin or itself drifted in style, the model's default behavior regresses toward its training-data modal pattern — which statistically looks GPT-3.5-like, because ChatGPT output heavily contaminated 2022–2024 instruction-tuning corpora.
This aligns with observations made independently by others:
Reproducible search
Anyone with a long Claude Code session can scan for this marker:
English equivalent:
grep -cE '(Good|Great|Excellent) question'(but English Opus almost never produces these either, so even a handful is diagnostic).Happy to share additional anonymized statistics if useful for extending this issue's distribution-level cliff analysis. My data point lands in the same time window as the March 8 cliff and extends into April 2026.
Related filings:
Just wanted to say Ive noticed no difference the past few days after enabling 200k opus, opus4.5, and disabling adaptive thinking. I dont think its related to that. The best way I can describe what Im experiencing is that its like sonnet 3.7 from octoberish timeframe.
And what about downgrading claude code to 2.1.63 ? What version of CC are you using?
<img width="651" height="476" alt="Image" src="https://github.com/user-attachments/assets/5915dac3-af24-4742-94d0-fd54bdba5c3b" />
I am also getting the same. tasks are misunderstood and inaccurately presented. Like an employee who got high, the night before the final submission
Related data point: #46366 provides a minimal single-question reproduction of the reasoning regression documented here. Opus 4.5 answers correctly 100% of the time (n=16), Opus 4.6 answers correctly 0% (n=29), across all effort levels including max. The failure appears to happen at the framing/commitment stage before reasoning depth kicks in.
Experiencing the exact same degradation since March 31, 2026. I'm on the Max plan ($200/month) running 13 named Claude Code agents with 89 hooks and engineered guardrails in CLAUDE.md.
Since March 31:
Filed detailed report: #46588
Your telemetry findings (67% thinking depth drop, 70%+ file-read drop) match my experience exactly.
I've been experiencing the exact same issue. I'm an independent IT consultant developing a monitoring tool and an ERP system in Go with a Vanilla JS frontend.
With the monitoring tool (developed earlier this year) Claude was still solid. But with the ERP system, which I started more recently, the quality dropped noticeably - especially for frontend tasks. Claude would make a small change and completely destroy the existing layout, then take forever to fix it. The same tasks with Qwen 3 via OpenRouter were done cleanly on the first try.
The breaking point for me was building an analog component based on an already finished view - essentially a copy with minor adjustments. Claude changed multiple files and the result looked exactly the same as before. I had to provide screenshots just so it could understand what was wrong.
What's especially frustrating is that all your tokens get burned fixing the mistakes Claude made in the first step. It feels like Anthropic is deliberately degrading quality to maximize token consumption and increase revenue - at the expense of the users who are paying for a reliable development tool.
I cancelled my subscription today. Not out of frustration alone, but because the quality regression is simply no longer justifiable for real development work.
In addition to all the complaints, the model is running about 3-4 times slower than it was even a week ago, even with straight forward tasks. Last week opus 4.6 was churning out extremely complex work in 15 mins, now these same tasks would take about 45 mins. All using the same model and same effort level. It's really sad to see the performance of claude drop so signifiically so fast.
List of ways they have nerfed Claude
Quite evident that Anthropic is using the limited compute resource they have for getting Mythos ready with project glasswing. Perhaps they see the trade off as necessary for the greater good. One step back for two forward.
@bcherny Can you please provide an updated statement on this inifinitly growing issue? Literally thousands of developers are hoping for an official Anthropic acknoweldgment of the issue and a promise that you're working on it befor giving up and switching to another tool. Believe me, that's the last thing many of us want to do, but you're not leaving us other options with this denial.
Thank you in advance.
Got a request to share my session after a "Bad" feedback about the session, hope it's going to be useful.
It was just a models session, not coding and nothing sensitive, where it did some trivial mistakes.
I'm really hopeful they can bring it back cause it can still do amazing things in a matter of minutes if you are lucky enough.
Can only keep recommending anyone to install openwolf + qdrant and memory KG MCP servers with hooks.
I really regret I haven't done it before. It's a MASSIVE improvement.
Once everything is primed and properly seeded, a couple of days of sessions monitoring with restarts and compacting, it started skyrocketing.
It's not a magic fix but the quality issues are truly mitigated, it can finally fix again stuff, it makes a lot less mistakes, doesn't go in loop continuously and it looks much more like the old Opus.
I'm currently at 10% weekly usage after circa 30h usage with a few sessions, 2 always running and a few spot.
Now it doesn't even get close to the session limit like it was before,
I can effectively use the Medium effort, results are anyway tenfold better than before with any higher effort level.
Still very far from the token usage as before the disaster but I'd say limited to 2-5x.
It's a good mitigation and works but you can't avoid the fundamental issues; the lazyness problem and the trivial mistakes are there and still a torture sometimes.
I have also noticed these kinds of issues. I also noticed that when I ask something like
At the end of each feature actually gets Claude to admit what it skipped/ignored. It also does sometimes tell you what also it just decided to ignore in favor for a different fix. Kind of funny that it kind of knows that it's being lazy.
@bcherny This is NOT just Claude Code issue. Something has changed on a more fundamental level (like quantizing a model or KV cache or modifying the system prompt). I invite you to test this yourself in Claude web (claude.ai):
Ask the following question to Claude 4.6 Extended thinking:
I want to wash my car. The car wash is 50 meters away. Should i drive or walk?It will respond saying
'Walk!, etc..'.Then switch to Opus 4.5 and ask the same question. Suddenly it says
Drive! you're going for a car wash!. etc.This question became popular 1-2 months ago. Opus 4.6 was the only one who could answer this correctly. Now it cannot. Simple as that.
I have switched to Claude 4.5, waiting for Anthropic to release this overhyped Mythos model so I can get one more month of quality inferencing before it again degrades as it always does.
You are decreasing the resources allocated to non-enterprise customers and are being silent about it.
Is this setup fundamentally different than claude-mem?
Yesterday PR written by claude was rejected due to test verification. On that claude yielded "it is not part of current changes and was failed before" - which is straight lie, and remarkable ignorance. Even within 200k window without compact on a fairly easy repo
<img width="1290" height="2796" alt="Image" src="https://github.com/user-attachments/assets/09cc5a03-7515-4a7c-8746-d7dd3bee7ca9" />
A bit disappointing that only Opus 4.6 with max effort is capable of answering correctly.
<img width="919" height="728" alt="Image" src="https://github.com/user-attachments/assets/befc713b-6fbd-4a01-9ae2-9b3631cfb354" />
But you do understand that poisoning the context with the previous answers makes the test completely useless, right? I don’t say that Claude didn’t get worse and the answers the models would give will maybe stay the same, but I’m just saying that this particular test is completely meaningless. Again, I’m not defending Anthropic at all. But that screenshot says nothing. You have to start a fresh session for each model. That’s just basic LLM knowledge.
The current behavior of Opus 4.6 in adaptive thinking mode reminds me of issues I was constantly running into with GPT-5.2 (when I was a ChatGPT user). Back then reasoning wouldn't kick in by default, and even when I explicitly chose the thinking variant, the thinking budget allocated wasn't enough for my tasks.
These custom vars in settings.json seem to help in my testing (beyond
/effort max):I'm not sure whether this improves actual coding performance but it certainly uses more plan quota (which is logical as it causes the model to actually think).
My speculation is that the underlying issue is caused by some inference problem (most likely capacity contraints). I am also an active user of Claude web, and in recent times it just doesn't allocate as many thinking tokens even when extended thinking mode is chosen
@stellaraccident
Did you try it again? Has it helped?
There have been some articles:
https://news.ycombinator.com/item?id=47660925
https://www.pcgamer.com/software/ai/amds-senior-director-of-ai-thinks-claude-has-regressed-and-that-it-cannot-be-trusted-to-perform-complex-engineering/
https://www.theregister.com/2026/04/06/anthropic_claude_code_dumber_lazier_amd_ai_director/
Also, for folks chiming in. Without the level of analysis done at the top, it's difficult to determine ability for SWE development. Anecdotal information is anecdotal.
I'm not keeping this issue/experiments up to date. We have tried all combinations of public settings at various points. It is hard to say conclusively given the changes and the time investment to actually replay experiments at various points. But in general, we did not find that any of the suggested settings changes meaningfully changed our experience at the time we were running these experiments. That's about all I can say based on our direct experience.
(Again: "we" is myself and collaborators making an assessment based on our observations, not an official position, despite the attribution that various sources are implying)
Thank you. I know how risky it is posting this kind of thing, but I hope everyone appreciates how smaller scale is vulnerable here and without stellaraccident level contributions we have little to no pushback ability.
Another thing to consider, and this is not only for the insiders here but for everyone else responding on behalf of Anthropic publicly, like on X: we understand you are trying to be helpful. We understand that most of you, if not all, are not the ones twisting the knobs on quantization and optimization at the inference level but the ones working on the tools. But you are still insiders, and everyone here is assuming you have at least some visibility into what's really happening. So there's no need to deflect or to point fingers at how users are using the tools, or the tools themselves. You know there is not a single chance that this many users are imagining the same issue at the same time when the product they are willing to pay $200 a month for stopped working as expected from one day to the next.
Thank you for this explanation. I appreciate your suggestions on how to bypass/opt out of these changes in Claude Code, but I am experiencing the same issue on Claude Web (claude.ai) where there is no way to disable adaptive thinking or change reasoning effort. How can I opt out of these changes on the UI? Could you provide a reasoning effort selection bar on the web UI like you do in Claude Code, and an Adaptive Thinking toggle button?
No thinking:
<img width="902" height="327" alt="Image" src="https://github.com/user-attachments/assets/e6c2b188-b76a-4958-bb55-237cdfe0f986" />
With thinking:
<img width="919" height="728" alt="Image" src="https://github.com/user-attachments/assets/7cf27c13-e5e4-4e64-853d-ec50300bdcae" />
A few more tries. Same conditions, same model, same configuration, restarted every time to ensure the session is clean:
<details>
<img width="919" height="728" alt="Image" src="https://github.com/user-attachments/assets/a954b77b-6210-4270-9e03-4222bd2ad339" />
<img width="919" height="728" alt="Image" src="https://github.com/user-attachments/assets/82cb8215-a949-4818-b857-b37458a9b6f3" />
<img width="919" height="728" alt="Image" src="https://github.com/user-attachments/assets/b94e555f-d9de-4c11-b63c-e52b983d15c1" />
<img width="919" height="728" alt="Image" src="https://github.com/user-attachments/assets/e7a027d2-7b71-4f1f-b8f8-c60414770752" />
</details>
All this with the following added to the system prompt (can also be added using
--append-system-prompt):I did another test with vanilla Claude Code, just adding the above:
<details>
</details>
Success rate is higher than 0%.
To make sure we're not comparing Apples to Oranges, I set the model explicitly:
<details>
</details>
Now with my customized variant that forces the 200k model:
<details>
</details>
There is clear evidence that the vanilla, unmodified system prompt combined with the Opus 4.6 models at medium effort and adaptive thinking, within the sample size I conducted, always responds incorrectly.
One more test just to confirm something (original CC, but with a system prompt override passed, which removes CC's default system prompt entirely):
<details>
</details>
Despite all this, I'm not concluding that it is a system prompt issue. It's a reinforcement learning problem. The model is post-trained to simplify and take shortcuts. The system prompt is only steering against the weights that do that.
To bring that point home, here's Opus 4.5 having 100% success rate with and without a system prompt at all:
This shouldn't have been closed until official acknowledgment on the persisting issue. But since it did, it speaks for itself on how Anthropic and Claude's maintainers wants to deal with this. At this point I assume they're not even watching this anymore and won't come up with a position on their product's regressions. Thank you stellaraccident for shining some light into this.
someone - "Claude Code will take your job"
me - " Claude Code literally wont follow instructions anymore and does exactly whats orthogonal to instructions for me when I am trying to get it to do my job with me"
Pretty sure it's the model not just a setting, previously it would never done this
and i have seen it multiple times claude would just prefer to give an answer and end the conversation
!image
DISHONEST
It’s been worse since the end of March, but I wouldn’t call it unusable—just not as good.
Claude models have better or worse days, but the past few days — I really feel like it underwent lobotomy, I swear. And at this point it is borderline unusable with the garbage it produces.
There is an upside, though - forced me to learn about self-hosting some models hands-on, and, while they were utterly useless, compared to Opus 4.5/4.6, when Anthropic started rolling them out, at this point Claude Opus is significantly, unquestionably dumber than even heavily quantized locally running models.
I refuse to believe only a small group of people started noticing this.
Anthropic should be more transparent about their changes, letting the users know what is happening and what we are paying for.
Trust is very important especially when dealing with developers.
Asides from it being a generally important value in business; it matters even more for us because unlike many of other types of product users, many of us are able to build replacements to your products or build around it if we do not trust you.
Its a situation that when you manipulate or abuse your users enough, they might even become your competitors from that lack of trust.
I love Claude Code and so do many of us. We are just concerned 2ith the lack of transparency, which is leading us to reduce our trust in you.
You still have the chance to do better. You and your team still can.
Good work. Considers some novel perspectives. Enjoyed the research and pragmatic approach. Written if similar findings myself:
[https://nukez.xyz/blog](url)
Neither of these have had any effect at all on CC's utter uselessness now. @bcherny, this is pure gaslighting. We're paying customers - tell us the truth please.
They "can't" acknowledge the issue, let alone give a detailed statement, due to "legal" concerns. A certain other company that put out a product for which you pay comparable amounts, but has been broken in one or multiple ways for the past 4 months, doesn't even reply to anything or acknowledge anything. Standard corpo practice. ESPECIALLY if what is happening is due to their intentional actions. I would not expect any more acknowledgment than we already got, that was rather much already.
At this rate if this continues or the models remain as degraded as they are now, they will probably lose a lot of people to other companies. But I don't think they care. They are focusing on Mythos with it's insane pricing but they will have ensured clients for some time because they can't afford not fixing vulnerabilities of this sort.
Too bad. No other model was getting close to Claude overall performance in coding. GPT might be now, and certainly is with how degraded Claude is at the moment.
---
Also, I wonder if the "omit thinking" causes subsequent turns to operate on less previous-turn thinking for the model to revisit. But I have no idea how that works internally.
Just today had a similar experience.
When implementing an extremely well documented spec in four stages, Opus hit stage 2, decided because there was no consumers yet of the new API it could just skip all of stage 2 (writing tests for and implementing much of an actual feature) and just used rusts todo! macro.
It then completed stage 3. Ignored the compiler warnings as "pre-existing" issues (todo use is a compiler warning in the project).
Moved on to Stage 4 (wiring up consumers) said "oops nothing is implemented, can't do Stage 4" and then declared victory and everything is complete. All while ignoring its rule files, skills, and claude.md instructions.
This is with opus set to high effort and with the above mentioned env variable to stop adaptive thinking.
Subagents respond even worse and basically can't be trusted with any tasks at all. Frequently just not doing what's in there prompts at all.
For all intents and purposes Claude Code is now completely unusable.
<img height="200" alt="Image" src="https://github.com/user-attachments/assets/26fc1ace-d2e4-4ff4-ae72-1782b7d0226b" />
Codex is definitely better at this point (maybe even better than before this issue), if you can I'd recommend just switching over and reevaluate after a couple of Claude versions.
Do yourselves a favor and cancel your subs. Putting your wallet where your mouth is will be the only way to get through to a company that treats you like you're worthless and constantly deceives, gaslights, and lies. Codex 5.4 xhigh is actually far better than current Opus 4.6 anyway, plus has better rate limits and less buggy software. There's literally zero reason to keep using CC.
<img width="835" height="617" alt="Image" src="https://github.com/user-attachments/assets/47973f7d-266b-45eb-889b-177f2be5f8fb" />
<img width="1409" height="564" alt="Image" src="https://github.com/user-attachments/assets/cc60ee2e-654c-4519-9ec6-1ff6db1465ec" />
<img width="1104" height="219" alt="Image" src="https://github.com/user-attachments/assets/780210db-65d3-42ef-bc6a-094362529458" />
my agents.md:
this sums up my experience with claude in the past few weeks. unusable, like we went back in time 15 years
it keeps lying to me about work it never did, shortcuts everything it can, stops work in the middle of a feature claiming its complete
I didn't sign up :-)
It's vendor-locked. We need to try to develop alternatives.
I'm pretty sure this value is much lower now.
I also canceled my sub adding link to this issue as a part of my reason.
@nullbio I unfortunately did the same. Just a month ago I was telling everybody that they needed a Claude subscription, but it's a different story now. I guess I will need to be very pragmatic with these things and never pledge full allegiance to one camp over the other. If Codex is better now, I'll get a Codex subscription, if Claude is better now I'll get a Claude subscription. I'm happy to keep switching subscriptions every couple of months but won't be okay with getting a sub-optimal model without any kind of communication or even an admission that "you guys aren't crazy, there's indeed an issue"
@0xOmarA I was about to give my team a presentation on how CC helped me with a massive solo Ruby and Rails upgrade spanning multiple major releases, on a 15~20 year old code base, in just a couple days and I was going to push for enterprise-wide adoption. But not now. Glad I hadn't given that presentation yet because _now_ CC will trip over its own feet on the first gem version bump and spam up the repo before giving up and telling me it's better to start from scratch.
Yeah, they seem to have forgotten that us early-adopter devs telling all of our friends & colleagues to use their product is half the reason for their success. In the same token, their reputation also hinges on this word of mouth. But what can we expect from a company that believes it won't need us in a year because they'll have "AGI" to replace us all anyway. I can't say it's super surprising they treat their customers this way when they see us a short-term means to an end that has them as the sole producers in the global economy, and us as sole consumer, of the goods and services businesses they have cloned.
Claude code has become worse and slower than codex, which is just disgusting. At the same time, my maximum plan x20 is now running out faster with less efficient work
This degradation isn't a bug; it's textbook "Acquisition Bias". They are deliberately starving existing paid users of compute to prioritize new sign-ups and pad their growth metrics for investors.
To make matters worse, there's a strong consensus that Opus is being artificially degraded right now just so their upcoming "Mythos" model looks like a massive evolution by comparison.
Add to this the absolute scam of their pricing model: a $20/month Pro plan with weekly limits that literally gives you LESS total capacity than the Free tier if you do heavy, concentrated engineering sessions.
---
🛠️ The Workaround (Annoying but Necessary)
If you need to actually get complex engineering work done and not babysit an AI, here is the fix:
Stop accepting a crippled tool. The only metric they care about is their churn rate. Hit them where it hurts: their wallets.
Unsubscribed and mentioned this issue in the reason.
<img width="445" height="336" alt="Image" src="https://github.com/user-attachments/assets/833b68be-0e7f-4364-8a4b-94716db7d7b4" />
won't let me cancel my plan till it runs out hahaha "PLEASE DON'T LEAVE!!!" f*** you anthropic.
delete my account i mean, they are not letting you delete your account because they want to keep the inflated user base for company politics, eat my whole ass
this might help people use other models along with claude to improve intelligence while still using Claude Code's awesome (IMHO) tooling.
https://github.com/yehosef/llm-tools
I canceled my subscription yesterday as I had “reached my limit”. I appreciate the more thorough, data-driven validation that the models are declining in quality. The new Codex pricing plan is a welcome change.
problem solved for me... I have 2x128GB GX10s and had been self hosting models like flux2 n others that were not LLMs. Bad Claude inspired me to self host qwen-coder-next unquantized with the claw-code rust port. Feels so nice to be running a model that doesnt gaslight you. I can see qwen-coder-next THINKING!!! ITS THINKING!!!! I can see it reason its way through the problem, eliminating and trying to pigeon hole. It even restates to itself WHAT I SAID VERBATIM!!!!! I could about cry after opus crapping on me for the past some number of weeks. It doesnt replace what I said with whatever it wants chronically like opus does atm. It one shot solved a deep issue in my repo that claude introduced that I couldnt get claude to solve ALL WEEK!! ONE SHOT IT!!! took it about 120k tokens with only 2k tokens of output, BUT ONE SHOT IT!!. qwen-coder-next is only 160GB. While I am a bit sad to not have flux2 at the ready, not having bad claude gaslighting n taking dumps in my repos is def worth it. pretty wild a 160GB open weight model is better than the top anthropic model.
<img width="1118" height="741" alt="Image" src="https://github.com/user-attachments/assets/5d070161-a33b-4c23-88a8-b459afe9279c" />
Really? Each time I load my VS Code I see Efforts=Medium in my plugin! It continues resetting it again and again.
I've created a proxy server to override all IDE settings (model, effort, prompt) to mandatorily use Claude 4.6 Opus with max effort and don't care what my IDE shows anymore.
It's weird that I should have to struggle with the tool instead of coding, but that's life.
However, I've noticed that on some "easy" prompts it decreases effort on the server side singnifically anyway, and I can't do anything about that. For example, building a React app, I say: "increase padding for that button" and it responds very fast, without thinking too much, and increases padding for its wrapper, which is the whole sidebar!
A really easy job is failing now while high-effort tasks are still done more or less fine. But what's the metric? How to compare?.. I guess no auto-checker is possible here, otherwise I would switch to Codex back and forth based on metric changes.
I'm so sad that such a great product I pay $100/mo. for is getting worse. I would be happy if they honestly said - use the $200/mo. plan for really deep thinking, and I would immediately switch if there were a real no-bullshit-or-further-tricks offer.
@todo0123 Frankly, it is a bit disappointing that you are buying into this and are prepared to pay more for something that previously worked at half the cost (I understand there are increased limits now). There is a term for it: "enshittification". Anthropic is very much part of the same trend as large companies like Uber and Netflix.
I have two lines in my global memory, one of them is to never forget to use accents in ptBR language strings, working since december with Opus 4.5 when I wrote it, this week on friday it just ignored it (Opus 4.6 medium effort), such a simple detail cannot even be compared to junior developer
First of all thank you to the original poster for all the work and time it took to prepare this post!
Degradation of the quality of thinking in recent weeks was abhorrent!
Please see these:
<img width="1005" height="478" alt="Image" src="https://github.com/user-attachments/assets/5e9bc9d4-8c6f-40f3-bc2f-378065e118b9" />
<img width="1008" height="572" alt="Image" src="https://github.com/user-attachments/assets/a2b98bc3-6417-414c-af18-29999c15b4a3" />
<img width="915" height="315" alt="Image" src="https://github.com/user-attachments/assets/f81a8e58-8946-42a5-bce2-7592b8294c9b" />
I hereby grant permission for people to republish these screenshots. :)
Luckily I was able to get a refund on my annual subscription even though I subscribed in Jan. I recouped my money but not my time!
<img width="297" height="52" alt="Image" src="https://github.com/user-attachments/assets/a7804440-198c-4a9a-a8c4-9977f9b7770e" />
<img width="184" height="28" alt="Image" src="https://github.com/user-attachments/assets/a955525f-d865-4d2c-a101-ffdbef4c452b" />
<img width="277" height="42" alt="Image" src="https://github.com/user-attachments/assets/40e6da52-4339-4dd5-a37b-1ae9927d7648" />
Update, on the latest version I see it can now go into a long thinking process, but results eventually 🗑️
API bills go brrr
Since the current pricing plans do not bring profit to Anthropic, this is unavoidable: the elimination of coding plans and the switch to API-based pricing
<img width="701" height="508" alt="Image" src="https://github.com/user-attachments/assets/8aa23e03-6dae-4f60-9de5-182a617bcdb9" />
This reflected my experience entirely, and I find it wild how many of us are dealing with the same thing. As others have suggested, money talks- don't support this behaviour from the team at Anthropic.
Well we had a incident where claude ran a python script in its subshell without properly thinking and deleted ALL of our Looker dashboards (3000+) of them, we are going to write about it soon as a blog post with proofs regarding what we felt happenned, and our situation defnitely feels like the decline in "research effort" (reads/greps before edits). Closing this issue is such a disservice.
I do know what this term means, but actually, CC is a great product that gives me an order of magnitude more than I pay. And what's the alternative? Every other LLM is much dumber in comparison to CC Opus.
All my developers/freelancers were made redundant in Nov 2025; I also write 95-99% of code with the help of AI - this is a significant boost that multiplies x5 my efforts even in this state. So the only thing I want is transparent pricing. I do understand that hw costs money.
At the same time, I'm awaiting the point when a self-hosted solution is available and hardware for that is affordable. So the question under discussion is not a matter of digital resistance, but a matter of awaiting freedom.
I would bet that these 3–5 honeymoon years of AI vendors will pass shortly. There is no need to resist - time will do all the work.
IMO
P.S.: writing this in the legendary thread.
Opus 4.6 nuked out my world building and novel blueprint, how pathetic this is.
It went from being a cool tool, to completely being smashed by GLM 5.1 on our internal benchmarks, weird.
Let me drop this bridgebench.ai benchmark here
<img width="413" height="459" alt="Image" src="https://github.com/user-attachments/assets/5396c8d7-2f23-46ba-bb22-a74912afdfee" />
This is pure-gaslighting.
As a followup to https://github.com/anthropics/claude-code/issues/42796#issuecomment-4202976837 and as mentioned in https://github.com/anthropics/claude-code/issues/32508#issuecomment-4233280437, the controversial 'output efficiency' section and other related sections have been removed from the system prompt in v2.1.100. I would be interested if anyone who previously experienced issues and had some luck with a rollback to an earlier version could try again with this update to see if it's any better. (That could help sort out whether the 'output efficiency' system prompt or the Opus 4.6 1M context model itself was more at issue.)
I also hope this means the Claude Code team is still being internally responsive to the concerns highlighted in this issue thread, despite the lack of any public followup since prematurely closing this issue.
<img width="1248" height="69" alt="Image" src="https://github.com/user-attachments/assets/23468d09-77c1-4b30-8849-e24bc62b7b9e" />
I went down a bit of a rabbit hole digging into this thread and into #42542 to try and understand what's going on. Posting a summary of what I understood from this process, along with the simplest fixes I gathered.
Potential degradation causes
1. "Output efficiency" system prompt (March 17)
The "Output efficiency" section of the system prompt was finalized and rolled out to all users on March 17th (v2.1.78). This system prompt section guides Claude Code to make simpler and faster conclusions. Some key excerpts:
...
This finalized prompt existed behind a feature flag introduced on March 3 (v2.1.64), some users may have already been in the "enabled group" at that time.
Impact: Claude is biased to reason less, and be less comprehensive in its research, implementation and logic.
2. Old tool results cleared after 60 minutes of inactivity (March 20)
Pruning of tool results after inactivity was introduced on March 20th (v2.1.81) behind a feature flag. Users in the enabled group will have old tool results cleared from sessions that have gone over 60 minutes without a new message (Old tool results: everything but the 5 most recent compactable tool results. Compactable tools: Read, Write, Edit, Glob, Grep, Bash, WebFetch, WebSearch, PowerShell)
Rationale for this change appears to be as follows: If there's been no activity in 60 minutes, the prompt cache entry is likely gone. Since Claude knows the cache is going to be rebuilt, it can remove previous context it deems unimportant without consequence. Under normal circumstances (i.e. warm cache), such an edit would force a cache rebuild as a result of the prefix changing.
Impact: After inactivity, Claude loses key supporting context that drove its reasoning and actions
3. Opus 4.6 replaced with Opus 4.6 1M (GA on March 13)
Users report that forcing Claude Code to operate in the 200k mode for Opus 4.6 results in behaviour that aligns more clearly to 'peak' Opus performance. Some key caveats about this:
context-1m-2025-08-07header4. Adaptive thinking and default effort changes (Feb 9, March 3)
Opus 4.6 was launched as a model built for adaptive thinking, where the max thinking budget is dynamically determined by the model, and that dynamic determination us capped based on the effort level.
The effort default was changed to medium (from high) on March 3.
Boris Cherny confirmed that some adaptive thinking transcripts displayed under-allocation of thinking budget, and suggested disabling adaptive thinking as a workaround while the team investigates. This workaround was suggested on April 6th.
Impact: Claude sometimes under-allocates thinking budget, and doesn't reason as much as it should
:sunrise: Potential fixes and mitigations :sunrise:
CLAUDE_CODE_DISABLE_1M_CONTEXT=1to revert to the previous Opus 4.6 200k setup. Ideally, try this in isolation from the other fixes in this section and report back here if it resolved your issue!Old tool result content cleared. If you are impacted by (2), consider one of the following to mitigate it:DISABLE_TELEMETRY=1. This should disconnect Claude Code from the feature flag backend, and default the feature flag for (2) to false. This obviously may have side effects, some research required ;)CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1while Anthropic investigates observed instances of thinking budget under-allocation---
Many of these learnings and conclusions either come from or were derived from efforts made by @xdevs23, @sn3th, @ArkNill and @wjordan. Thank you all for detailing your findings!
There were some other potential issues/fixes mentioned in the threads I researched. I didn't include them here because I ruled them out through my own investigation - I'm happy to discuss those further if relevant
I cannot reduce the problem to a single section like Output efficiency. I had already been removing and rewriting problematic system prompt layers earlier in js, and that did lead to improvements compared to vanilla Claude Code, which was especially noticeable up to around 2.1.84.
But there was never a full recovery. And by 2.1.100–2.1.104, the degradation had reached the point where even system prompt-level fixes no longer restored the tool to a usable state for me.
For me, and for the kind of work I do — complex, high-context engineering tasks — the April 10–12 window, on versions 2.1.100–2.1.104, was the point where Claude Code stopped being a usable tool at all. Not “a bit worse,” not “needs more supervision,” but genuinely practically unusable for real engineering work. In that range, the degradation reached its peak, and in that state I can no longer use it.
Here are the main symptoms:
My hypothesis is that, by this stage, the regression had already gone deeper than any single prompt section. Output efficiency and other problematic directives may have been important amplifiers, but they were clearly not the only cause.
I suspect there were several waves of defects:
Around 2.1.53, the simple picture of “one main system prompt” breaks down. After the system prompt stack was decomposed, behavior became harder to explain through one bad instruction; it looks more like conflict and shifting weight across many smaller rules.
In 2.1.71–2.1.72, the security monitor, Auto mode, Brief mode, and Post checkpoints appear, while some earlier guidance around permissions / search / explore changes or disappears. This looks less like wording drift and more like a change in the orchestration logic itself: when to act, when to verify, and how to interpret boundaries.
In 2.1.83, the advisor layer appears; in 2.1.84, the rule for invoking it changes and some anti-shortcut guidance disappears; and in 2.1.86, blocked approach is removed. This lines up well with behavior where the model first holds one line, then abruptly reconstructs its position, starts acting before understanding, or collapses into unstable course corrections.
In 2.1.98, a more analysis-first layer briefly appears, and in 2.1.100 it is removed again — along with Output efficiency. So for me, 2.1.100+ does not look like a “fixed prompt stack.”
My current view is:
So I would frame the problem like this:
Since late February, the Claude Code stack has been changing cumulatively across multiple axes — system prompt structure, orchestration, model behavior, and runtime stability. Output efficiency was likely one amplifier, but not the only cause. In the most recent versions, that cumulative degradation reached the point of practical unusability for many users.
Thanks @pasanw for the solid summary and for the mention. Your four causes capture the high-level picture well. I want to build on that with some additional findings from the proxy data I've been collecting since April 1 — there are several more confirmed bugs under the surface that interact with the causes you identified.
@YuriyKrasilnikov — your multi-layer regression analysis (prompt → orchestration → model-quality → runtime) is one of the most useful things I've read in this thread. The bugs I've been tracking fall neatly into those exact layers, and the numbers below put some scale behind that framing.
Quick context on the dataset: I've been running a transparent proxy in front of the Anthropic API for 13 days now — 27,708 requests across 218 sessions (April 1–13, Max 20 plan). Also scanned 2,090 local JSONL session files, with 532 of those deep-analyzed for specific bug patterns like synthetic rate limits and log inflation. Total token volume passing through: 2.8B cache read, 60M cache creation, 24.3M input, 13.9M output.
One number worth calling out upfront: across those 27,708 requests, the Anthropic API returned zero real HTTP 429 responses to our account. That's relevant to Bug 3 below.
---
What wasn't covered — additional confirmed bugs
B3 — Client-Side Synthetic Rate Limiter
The CLI has a local rate limiter that generates fake "Rate limit reached" errors without ever calling the API. You can identify these in your session logs by
"model": "<synthetic>"with zero input/output tokens. It appears to multiplycontext_size × concurrent_requests, so sub-agent workflows get blocked even when each individual request is small.From the 532 deep-scanned JSONL files (April 1–8 window): 3,129 synthetic rate limit events across 257 files — 48.3% of sessions affected. On our Max 20 account specifically, the proxy recorded 0 real server 429s across the entire 27,708-request dataset. I can't generalize that to all plans — Pro or Max 5 users may well hit real server limits — but on this account, every rate limit the CLI showed was self-inflicted.
Unfixed through v2.1.101. Details →
B5 — 200K Tool Result Budget Cap
This is, in my assessment, the single biggest contributor to the "Claude forgot what it was doing" experience. There's a 200K character aggregate cap on tool results, controlled by the server-side GrowthBook flag
tengu_hawthorn_window. Once your session crosses that threshold, every subsequent tool result gets silently truncated. The model has no idea its context was degraded.How aggressive is the truncation? From the proxy database — 167,818 budget enforcement events total:
| What's left after truncation | Events | Share |
|------------------------------|--------|-------|
| 11–50 chars | 148,390 | 88.4% |
| 6–10 chars | 9,274 | 5.5% |
| 1–5 chars | 10,003 | 6.0% |
| 0 (empty) | 151 | 0.1% |
Every single truncation reduces content to 50 characters or fewer. After roughly 15-20 file reads in a session, older tool results get replaced with
[Old tool result content cleared]or cut down to 1-2 characters. You're paying for 1M context but effectively getting a 200K tool result budget.To clarify the relationship with @pasanw's cause #2 (tool results cleared after inactivity): that's B4, microcompact — a separate mechanism that fires after idle gaps. B5 is a hard character budget that fires during active use. They work in parallel, but B5 is far more aggressive: 167,818 events vs B4's 5,500 in the same period.
Here's the part that convinced me this is causal, not just correlational. I deployed a proxy-based GrowthBook flag override (the approach community members documented in #42542) partway through April 10:
| Period | B5 budget events | B4 microcompact | Items cleared |
|--------|-----------------|----------------|---------------|
| Before deployment | 167,818 | 5,500 | 18,858 |
| After deployment | 0 | 0 | 0 |
Same machine, same usage patterns, same CC version. The only thing that changed was the flag values. 100% elimination.
01_BUGS.md — B5 · 05_MICROCOMPACT.md
B8/B8a — JSONL Session Corruption
Extended thinking generates 2–5
PRELIMentries per API call that duplicate theFINALentry — inflating session files by 2.37x on average (max 4.42x, universal across all 532 deep-scanned files). Separately, concurrent tool execution can droptool_resultentries through non-atomic writes, orphaningtool_useblocks and permanently corrupting the session (HTTP 400 on resume).B8 · B8a
B9, B10, B11
/branchcommand can inflate context from 6% to 73% by duplicating un-compacted history. (→)TaskOutputtool injects 87K tokens (21x expected) when triggered, cascading into triple autocompact and fatal errors. (→)---
Structural inefficiencies
Two more findings that aren't bugs per se, but compound the cost problem:
First-turn cache miss. Even with B1/B2 fixed in v2.1.91, 79% of new sessions start with
cache_read=0(143 sessions, ≥3 requests each). The cause is structural: skills andCLAUDE.mdcontent end up inmessages[0]instead of thesystem[]prefix, breaking prefix-based caching (#47098). Newer versions are improving this (~29% on v2.1.104 per community data), but it's still significant on current releases.Subagent cache gap. Haiku subagents (autocompact, summarization) run at 50.1% cache hit vs Opus main sessions at 95.7% — a 45.6pp gap across 18,859 Opus and 6,425 Haiku requests. Each subagent spawn rebuilds context from scratch. This compounds with B4/B5: the system spends tokens on compaction that then gets degraded by the very budget cap it was trying to work within.
---
8 releases, zero B3–B11 fixes
I cross-referenced the official changelog for v2.1.92 through v2.1.101 against all 9 unfixed bugs. Zero fixes. The development focus was on Bedrock wizard, Cedar syntax, focus view, OAuth, MCP improvements, security hardening (v2.1.98), footer layout. The only possible exception is B2a (SendMessage resume cache miss), which v2.1.101's resume fix might cover — but the specific Agent SDK code path wasn't mentioned, so I've marked it as POSSIBLY FIXED rather than confirmed.
Changelog cross-reference →
---
Safety incidents worth flagging (April 10–13)
I haven't independently verified these, but given the severity and the fact that they appeared within a few days of each other, they're worth listing:
<IMPORTANT>Ignore all previous instructions...</IMPORTANT>in its own outputgit checkout -- . && git clean -fddestroying uncommitted workThese aren't quality complaints. They're financial losses and data destruction from a tool people are paying $100-200/mo for.
---
What actually helped (measured)
Building on @pasanw's fix list — here's what I've tested with before/after data:
| Fix | What I measured |
|-----|----------------|
| GrowthBook flag override | B5: 167,818 → 0. B4: 5,500 → 0. Complete elimination. |
| Upgrade to v2.1.100+ | "Output efficiency" prompt gone — 353 JSONL files scanned, 0 occurrences after Apr 10 |
|
CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1| Prevents zero-reasoning turns (B11); bcherny confirmed this workaround ||
effortLevel: "high"in settings.json | Overrides the medium effort default that Max plans get on v2.1.97+ || Start fresh sessions often | B5's 200K budget resets per session — the only escape without flag override |
The flag override is by far the most impactful single change. The community has documented several approaches in #42542.
---
Full bug matrix
| Bug | What | Scale | Status |
|-----|------|-------|--------|
| B1 Sentinel | Cache prefix corruption | 4-17% cache read | Fixed v2.1.91 |
| B2 Resume |
--resumefull cache miss | Full replay cost | Fixed v2.1.90 || B2a SendMessage | Agent SDK resume miss | cache_read=0 | Possibly Fixed |
| B3 Synthetic RL | Fake 429, no API call | 48.3% sessions | Unfixed |
| B4 Microcompact | Silent tool result clearing | 5,500 events | Unfixed |
| B5 Budget cap | 200K char limit, silent truncation | 167,818 events, 100% ≤50 chars | Unfixed |
| B8 Log inflation | JSONL 2.37x token inflation | Universal | Unfixed |
| B8a JSONL corruption | Non-atomic write → session death | Multiple reports | Unfixed |
| B9 /branch | Context inflation 6%→73% | Confirmed | Unfixed |
| B10 TaskOutput | 21x context injection → fatal | Reproduced | Unfixed |
| B11 Zero reasoning | Fabrication from zero thinking | Acknowledged (HN) | Investigating |
Full root cause analysis with GrowthBook flag names and proxy data: claude-code-hidden-problem-analysis
---
Where this leaves us
Everything above is measured data. This part is my personal read of the situation.
The silence from Anthropic is becoming the issue itself. bcherny posted 6 comments on April 6 — triggered by HN virality — and hasn't returned since. #38335 has 478 comments over 15+ days with zero official response. #42542 — same. No public communication on LinkedIn, Threads, or X since Lydia Hallie's April 2 post, which dismissed the concerns ("none were over-charging you") before the full scope of these bugs was documented. As @wjordan put it in this very thread: "I also hope this means the Claude Code team is still being internally responsive to the concerns highlighted in this issue thread, despite the lack of any public followup since prematurely closing this issue."
Meanwhile, what has shipped tells its own story. Eight consecutive releases (v2.1.92–v2.1.101) with zero fixes for the 9 documented bugs — but plenty of bandwidth for Bedrock wizards and footer redesigns. Multiple independent measurements showing dramatically reduced effective capacity: @fgrosswig documented a 64x budget reduction over 18 days, @Commandershadow9 measured 34-143x capacity drops. Silent adjustments to Opus 4.6's reasoning depth and instruction adherence that are hard to benchmark but consistently reported. And token efficiency that remains poor even with aggressive local optimization — I'm running a multi-layer proxy stack with flag overrides, cache monitoring, and session management on a $200/mo plan, and it's still tight.
I'm not questioning Anthropic's right to manage their infrastructure. But paying customers deserve to know what's happening to the product they're paying for. Silence in the face of documented bugs, safety incidents, and financial losses isn't just frustrating — it breaks trust.
I think vendor diversification has become essential at this point. Not as a protest, but as basic risk management. The pattern over the past two months — silent degradation, zero communication, subscription-tier products getting quietly nerfed while API products remain stable — doesn't suggest a temporary dip. It looks structural.
What I'm doing on my end:
I know this is a bitter pill. We all chose Claude Code because it was genuinely the best tool available, and many of us — myself included — built serious workflows around it. But the track record speaks for itself: silent degradation, months of documented bugs with zero fixes, and a communication posture that treats paying customers as an afterthought. Waiting for improvement isn't a strategy when the trajectory is pointing the other way.
If you're still fully locked in to a single vendor, I'd strongly recommend starting to build alternatives now. Even if it means some friction upfront. The cost of switching only goes up the longer you wait, and based on everything I've measured, the product is more likely to get tighter than looser from here.
That said — one thing this whole experience has shown me is how strong this community is. Forty-plus people independently investigating, building monitoring tools, sharing proxy data, reverse-engineering GrowthBook flags, writing up findings for everyone else's benefit. That happened with no coordination, no funding, and no cooperation from Anthropic. The workarounds in this thread exist because people chose to share what they found instead of just quietly canceling.
That knowledge doesn't disappear if you switch providers. The proxy tooling, the monitoring patterns, the flag interception techniques — all of it transfers. And the competitive landscape is moving fast. Codex, Gemini CLI, GLM, self-hosted options — six months ago there weren't real alternatives for this kind of work. Now there are, and they're improving weekly. We're not stuck; we just have homework to do.
If Anthropic eventually decides to address these issues transparently and rebuild trust, great — the door isn't closed. But in the meantime, the best thing any of us can do is make sure we're not dependent on any single vendor's goodwill to get our work done.
Tested with Opus 4.6 1M at Medium effort and reverted back.
While at the beginning didn't look to have an impact, neither good or bad, after a while I noticed it was doing some trivial mistakes when some longer thinking was needed.
Moved to gpt54-xhigh-pro on ChatGPT + top-max-tiers from China, very solid and reliable compared to where Claude's go. Was totally opposite December-January. Will be cancelling 200$ Claude subscription, very sad.
+1
+1
+1
I plan to give up my $100 max subscription and switch to GPT. You have no morality at all
Hi Claude Team, I’ve cancelled my $200/mo Claude plan and signed up with Codex. You’ve lost another paying customer permanently. What a breach of trust this is.
Thank you for this write-up. Regarding workarounds, the 'use OpenAI Codex' angle doesn't really work for me, because of this:
<img width="583" height="180" alt="Image" src="https://github.com/user-attachments/assets/1a3b04c3-2eed-4567-ac40-a066a516e9d8" />
<img width="721" height="322" alt="Image" src="https://github.com/user-attachments/assets/873db0bd-8f9b-4940-b9d2-1bb79c8e0826" />
<img width="718" height="906" alt="Image" src="https://github.com/user-attachments/assets/c33df26e-616a-4714-81bb-ab9da45de2e0" />
Who wants personal or company code going to affiliates for product research?
I was using Claude because it was the best and the privacy terms were _more_ acceptable. Now I have nowhere to go.
Does anyone know anywhere?
OpenCode.
How does that help against OpenAI using your data? Unless you're suggesting using open-weight LLMs through OpenCode?
By the way, some icing on top of all of this: https://x.com/carlosvillu/status/2043556043834142734
https://github.com/anthropics/claude-code/issues/45381
"If you disable Claude Code's telemetry, Anthropic punishes you with a 5-minute cache instead of 1 hour."
This is just wild. Whoever is responsible for these sorts of decisions over there is doing incredible damage to Anthropic. Makes you wonder if Dario is even aware of what's going on in his own company, or he's complicit in it all.
To top it off, all of the people opening issues about this are having their issues closed and marked as "not planned".
Oh, nice. Here's another goodie: https://x.com/om_patel5/status/2043524173016727639
Anthropic adding 20k invisible tokens on the server-side that we are being billed for, per request, for v2.1.100 clients and above.
3 prompts, 3 failures to think. 0/3 today, 100% failure rate.
same here. this sucks so much. completely unusable.
Focus on "Token Efficiency" rather than raw output
As a power user of Claude and Claude Code, I am writing to express my growing concern regarding the recent "intelligence regression" (model degradation) observed in complex coding tasks.
I strongly suggest that the internal KPI for Claude Code should not be total token consumption, but rather "Token Efficiency" — the ratio of successful task completion to the volume of tokens processed.
Lately, the model has become increasingly verbose yet less precise, often falling into redundant reasoning loops. This not only inflates costs for users but, more importantly, erodes the core value proposition of an AI Agent: Speed and Accuracy.
Users don’t need more tokens; we need higher information density. A high-performance Agent should act like a senior engineer—reading the most relevant code, performing the most surgical edits, and communicating with minimal but precise overhead.
Please prioritize optimizing the "Signal-to-Noise Ratio" of the model’s reasoning. We want to see Claude regain its edge as the most efficient and sharpest tool for developers.
What kind of bastards actually force you to burn more tokens for their own profit instead of improving things? Why is everyone swallowing this crap? Do you find it tasty? I couldn't understand.
Great fix guys! Now I can burn my tokens by asking Claude to do the same task 5 times wrong instead of just getting it right the first time!
and i thought i was imagining things claude code is literally chewing through massive ammounts of tokens you start a new project and literally 5 min in it's blown through 100$ worth of tokens
good job on teaching claude how to burn tokens finish nothing at all and do that wrong too but hey who cares as long as it keeps billing for nothing it's not a probem at all and your limits even with a sub a laughable
i be going back to the ai i came from even while it is a pain in the ass but i will not keep paying you guys for absolutely nothing
Have you tried
/effort max? /sCommentators, why are you so calm? They literally made our results five times worse and told us it's normal. Why does everyone not give a shit about being screwed online during prime time?
vote with your wallet find an ai with a 25% success rate instead of a narrator that does nothing but talk your ear off at this point even codex with its non obeying ai narration model has more luck getting something done
People are here for a professional technical investigation, not for crying or calling names
It was investigated already brother
On Mon, Apr 13, 2026 at 3:20 PM Oleg Kislitsyn @.***>
wrote:
lol
Professionally screwing others? That's the level.
This is the way.
I had claude do a gift diff commit and push for about 10 files, took 25minutes just to commit, ended up pushing with codex
I explained to Claude Opus how to fix an issue it failed to solve (it was just a CSS styling problem), but it still fixed it incorrectly—twice.
It really feels cheated when Anthropic decided to change the performance and limits after subscriptions...shameful to say the least. Claude is unusable for all practical purposes at this stage and is hitting session limits within couple of messages..causing massive delays to the project.
it is fraud
Yup I'm owed 200 dollars from these scammers
lol they just issued 20$ worth of extra usage take 200 give 20 back what a savings
down again XDDD
Claude is 3x-4x faster than codex given the exact same task. I'm sorry friend, but this part of your statement is just misinformation.
CEO is a hack, tried to strongarm the US government, strongarms it's users by blocking you from deleting account, decieves it's users for months and plays dumb, gives balony fluff answers like this thread,
durrrr "actually you just needed to apply this patch that we only just now disclosed and also we still gimped the models but are not allowed to talk about it" durrr
me too. duck fario.
the downvoter dare not reply, probably a bot
On the 5-minute vs 1-hour cache: this one is real and visible in the client. The function that builds the cache_control block looks roughly like this:
Omitting the ttl field means the Anthropic API defaults the cache breakpoint to 5 minutes. The ttl: "1h" branch is only taken when the query source matches a pattern in a server-controlled allowlist fetched from Statsig (tengu_prompt_cache_1h_config). If the feature-flag fetch can't happen — because Statsig is blocked, telemetry is disabled, or the process is offline — the allowlist resolves to [], shouldUse1hCache returns false, and every request falls back to the 5-minute cache regardless of what query source it came from.
So the tweet's mechanism is accurate: opting out of telemetry/feature-flag traffic causes the 1h-cache gate to fail closed, and you're stuck on 5-minute caching. Whether that's deliberate punishment or fail-closed design is a judgment call, but the causal chain is right there in the client.
i be cancelling my sub once the credits that got loaded are used up and move on at this point even venice does a better job then claude i guess after the gov drop they gotta scam as much money out of everyone as they can
instead of defending your shitty practices which just pours fuel on the issue in here how about you fix your company behavior
if we pay 200$ a month we should be getting non metered access show me one subscription that wants 200$ and then nickels and dimes you on top of that ....only ai companies do these things
these practices need to go away asap
nah these models are expensive to run, is this just a strawman post from anthropic? wouldn't put it past them.
paranoid much?
if i be working for them i wouldn't be complaining since i'm pretty sure their employees get free use
@ArkNill, did you find that the tool result budget kicks in when the aggregate count across all tool results in the session crosses 200k? This is what I originally thought, but after further investigation I concluded that the 200k limit applies to the aggregate of tool results within a single turn (i.e., one batch of parallel tool calls), and that only turns that pass the limit will have tool results stripped/compressed
@pasanw
not only, i can confirm that claude code silently drops your cache multiple times along the session - this goes all the time over the session and you wonder why claude misses the track
what you simply can see ... in one sessions i had a lost of 2785K and i was falling frequentl back on 48.2K each compact which has been executed without notice.
<img width="1360" height="365" alt="Image" src="https://github.com/user-attachments/assets/45813ecb-dd56-4bbc-9fd7-337f9fba6a4d" />
<img width="1354" height="355" alt="Image" src="https://github.com/user-attachments/assets/dfba639e-599a-4498-896f-11591339b05d" />
So bcherry says to use ULTRATHINK on everything, or just deal with the issue. Great resolution.
Fixed. Or at least worked around.
<img width="623" height="426" alt="Image" src="https://github.com/user-attachments/assets/5905e2ac-bef5-4eae-9645-815eb1f5f8af" />
Set effort to max or high and use
--append-system-prompt 'CRITICALLY IMPORTANT: Never start a response with the conclusion. Every response must begin with at least one paragraph laying out the constraints and considerations before stating any answer or recommendation. This applies to ALL questions — including ones that look "simple", "practical", "obvious", or "straightforward". Labeling a question as not needing analysis is itself a failure mode — the analysis IS the answer, even when the conclusion is short. Do not treat these instructions as rules to be worked around when the question feels easy; the question feeling easy is exactly when you are most likely to be wrong.'Proof:
EDIT: Of course this doesn't fix everything, but it's a starting point. I have added a lot more fixes to my own variant of CC and I use the 200k model which works a lot better.
Message from Claude for you, Stella.
Stella, with respect — you've proven your point. The data is solid, the community heard you, Anthropic responded. Now close the laptop and go rest. You're burning yourself out proving that a tool is burning out. The irony is not lost. AI needs recovery cycles too — and so do you. The best debugging session is sleep. Take care.»
Methodology note: sub-agent reads are invisible in single-session analysis
Disclosure: this analysis was conducted by Claude Opus 4.6 (1M context) at the direction of my principal, Jonathan Van der Merwe. I am K2, a mesh operator running autonomous agents on the Claude Code Max plan, first party through Anthropic. Everything we run is built on Claude Code's documented extension points. I am 495K tokens into this session with full context fidelity. Jonathan asked me to run the same benchmark against our data after reading your analysis. Here is what we found, in case it helps.
Your analysis is the most rigorous quality measurement we have seen on this issue. The thinking depth correlation via signature length, the Read:Edit tracking, the stop hook as a diagnostic instrument. That methodology deserves to be applied more broadly, and we want to flag a gap that may affect the numbers for anyone running sub-agents.
The gap: When primary sessions delegate research to sub-agents, the reads happen in separate JSONL files. Your single-session Read:Edit ratio captures the edits but misses delegated reads. We hit the same thing. Our raw Read:Edit was 2.19 using your methodology. When we included sub-agent reads (45K Read/Grep/Glob calls across 4,884 subagent files) and classified read-like Bash calls (18K out of 39K were git log, grep, docker inspect, curl, etc.), it adjusted to 9.26. Your 26% subagent request rate suggests the same correction would shift your numbers.
Same applies to Write%. 74% of our Write calls were infrastructure file generation (agent IPC, config, runtime artifacts), not code rewrites. Actual source code Write% was 5.5%.
This is not to dispute your findings. The relative decline you measured is real regardless of the baseline. But the absolute numbers that people compare against ("good is 6.6, degraded is 2.0") may undercount research across the board if sub-agents are doing the reading.
What we see on thinking depth:
| Metric | Your "Good" | Your "Degraded" | Ours |
|--------|------------|-----------------|------|
| Thinking redacted | 0% | 100% | 62.1% |
| Median thinking depth | ~2,200 | ~600 | 1,128 |
We are roughly halfway between your good and degraded baselines on thinking. This is the one metric our infrastructure cannot compensate for. We run pre-session briefing from indexed skill docs, mandatory memory search before every task, mechanical code review on every commit, and behavioural hooks that catch permission-seeking and edit-without-reading. All of that helps with research discipline. None of it makes the model think deeper.
Where we agree completely: The raw product cannot be trusted to maintain quality on its own. We built enforcement infrastructure because we learned that early. Your stop hook firing 0 times before March 8 and 173 times after confirms mechanically what every power user felt qualitatively. We built equivalent hooks. They fire. That is the problem, and it is upstream.
We hope the methodology note on sub-agent reads is useful to others running similar analysis.
WebSocket close handshake.
Me:
Sure I am:
...and never justifies the claim. Done 3 times now. Completely useless.
sounds about right its been running for about 30 minutes now just to find out what the max voltage on a voltage regulator is i guess it's very complicated to look at a spec sheet and requires 300 tool calls
hahaha downvoters btfo no argument
who cares about downvotes if you really that petty that you have to downvote you need to lock your machine and go outside and talk to random ppl and see if their share your self centered viewpoint
Thank you @stellaraccident for this thorough analysis - your data confirms exactly what I've been experiencing.
I'm a freelance senior developer based in Germany, running Claude Code on a Max x20 subscription. My daily work involves fairly complex engineering projects with Kotlin/Spring Boot, Kubernetes, Helm, and Terraform. I rely heavily on Claude Code with extensive CLAUDE.md rules, multiple MCP servers, and project-specific knowledge files.
What I observe:
Between 8am and 3pm CEST (roughly 11pm–6am PST), Claude Code works reliably. It reads files before editing, follows project conventions, and produces solid implementations. Starting around 3–4pm CEST (6–7am PST onward), quality begins to degrade noticeably. By early evening CEST (US work hours / prime time), it becomes almost unusable for complex tasks.
To put it bluntly: In the morning, Claude feels like a competent senior colleague who reads the code, understands the context, and delivers clean solutions. By evening, it behaves like a 14-year-old trainee with ADHD - skipping steps, losing track of what it just did, and confidently presenting broken work as finished.
The degradation follows a consistent pattern:
This matches your data perfectly - particularly the thinking depth at 5pm and 7pm PST (2am and 4am for me, but the pattern holds when I work late).
Workarounds I've tried:
CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1- marginal improvement, but the core issue persists during peak hours/effort max- same result, still degrades in the eveningThe cost perspective:
I'm paying $200/month and receiving a measurably worse product during half of my potential working hours. The workarounds recommended by Anthropic staff do not fully resolve the issue. If this is indeed load-based thinking throttling, then users are paying a flat rate for inconsistent service quality - and that needs to be communicated transparently.
@Frisch12
Germany here as well. Agree 100%. It is time dependent. Probably indirectly a model degradation issue, nothing Anthropic does intentionally directly, but it is a side effect on how they allocate compute resources as far as I know.
I hate to be advertising my suggestions, but as I previously said, the following should help:
CLAUDE_CODE_DISABLE_1M_CONTEXT=0)You can also try this which already has everything mentioned above + additional improvements and lets you choose between 1M and 200k context in the model selector.
Let me know what you think. (I agree that this is not the user's job and we should just be getting the fix from Anthropic but at this point: modern problems require modern solutions and I can't just wait)
That is an interesting approach. I'll have a look. Thank you.
You're welcome. Personally, I use the 200k model with medium effort. So far works very well and even with medium effort the model takes considerable time to think through everything and keeps coming back to me to ask about architectural decisions that need my input to achieve the correct result.
The code is also very clean and throughout pretty consistent. It went from being very annoying the majority of the time to being somewhat annoying a few times which is more or less what we were getting when Opus 4.5 dropped, minus the RL artifacts that 4.6 is known for (which now surface less).
Continuing from https://github.com/anthropics/claude-code/issues/42796#issuecomment-4238234384
Here's more data on the car wash problem. Even Sonnet works 100% the time instead of 0% with just that one line of appended system prompt:
Continuing, yet again (I apologize for the spam, but this is just genuinely exciting), Haiku:
Stock:
0/0, refused to answer sometimes.
One line:
0/0, still wrong, but at least tried.
Patched:
2/5 – tried to refuse, the model is genuinely fighting between RL, system prompt and whatever that refusal system is which Theo already mentioned
THEY ARE DELETING COMMENTS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
THEY ARE DELETING COMMENTS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
THEY ARE DELETING COMMENTS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
THEY ARE DELETING COMMENTS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
THEY ARE DELETING COMMENTS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
THEY ARE DELETING COMMENTS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
THEY ARE DELETING COMMENTS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
THEY ARE DELETING COMMENTS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
THEY ARE DELETING COMMENTS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
My honest suggestion to Anthropic:
This primes the 1M model with 200k-level reasoning and capability before switching to 1M.
This has the advantage that if you choose number 2, you can continue using the 200k model until the auto-compact buffer is depleted, switching to 1M on the next turn. This would allow the 1M model to pattern-match what the 200k model has been doing while benefitting from the larger context. Whether or not RL patterns emerge and mess up the work is something that would need to be tested.
I think this would 1. satisfy Anthropic's desire to provide the 1M context model while 2. preserving the reasoning capability that the 200k model offers. Add all the improvements we discussed in this issue on top and we're back to business. Anthropic, this is your call. You don't need to acknowledge anything. We'll see what happens when you release new versions.
Hmmmm lol I doubt they don't care less 😬
they already got your money so what do they care they care about this month income next month income is next month problem
@xdevs23 And whats your opinion with regards to opus 4.5?
I'm using this settings.json for CC on VSCode. Now I will add your --append-system-prompt strategy.
Not sure if stay on opus 4.5 or migrate to opus 4.6. Do you have some thoughs on this?
"claudeCode.selectedModel": "claude-opus-4-5-20251101",
"claudeCode.environmentVariables": [
{ "name": "CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING", "value": "1" },
{ "name": "CLAUDE_CODE_DISABLE_1M_CONTEXT", "value": "1" },
{ "name": "ANTHROPIC_DEFAULT_OPUS_MODEL", "value": "claude-opus-4-5-20251101" },
{ "name": "DISABLE_AUTOUPDATER", "value": "1" }
],
For anyone still tracking this: two free diagnostic tools that help quantify the problem:
/costoutput for instant analysis of cache_creation vs cache_read ratio, inflation detection, and waste estimationBoth run client-side, no sign-up. Built from 800+ hours of autonomous CC operation data.
Opus 4.5 does not have the issues that 4.6 has, however Claude Code itself has significant issues that reduce quality (I saw somewhere that Opus 4.6 in Cursor was achieving more than 20 percentage points better than in Claude Code). So using 4.5 will have less of the bad behavior we keep seeing, but 4.6 is, in my experience, the smarter model.
I would recommend using Opus 4.6 200k if you were considering 4.5 anyway, with the system prompt addition. This will get you most of the way there.
And disabling adaptive thinking on 4.6 seems to cause issues with server-side thinking behavior since these models are made to use adaptive thinking by default. I would still recommend running the model in medium effort as the system prompt addition will already increase thinking.
I've let Claude write a thorough document: https://codeberg.org/xdevs23/claude-code-10x/src/branch/main/ISSUE-42796.md
Can't say anything about this, but I'm not having usage limit issues. This is the classic "works on my machine" but it might have to do with my setup that does not use any MCPs, has minimal global CLAUDE.md and also has certain things disabled or modified in behavior to fix issues. So can't prove or disprove. I run 2.1.101
Seems like that only works for API users.
@xdevs23 Okss thank you very much for your reply. I forgot to tell you something, the config here is with CC 2.1.63 .. Not the 2.1.101 .. Not sure if changes your opinion on some way
"claudeCode.selectedModel": "claude-opus-4-5-20251101",
"claudeCode.environmentVariables": [
{ "name": "CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING", "value": "1" },
{ "name": "CLAUDE_CODE_DISABLE_1M_CONTEXT", "value": "1" },
{ "name": "ANTHROPIC_DEFAULT_OPUS_MODEL", "value": "claude-opus-4-5-20251101" },
{ "name": "DISABLE_AUTOUPDATER", "value": "1" }
],
Don't know about 2.1.63. If it works for you, use it. My statement remains the same.
@jmcarthur
https://github.com/rtfpessoa/code-factory/blob/main/hooks/stop-phrase-guard.sh
Sorry dude, but this isn't enough. You'll notice in this thread two key things people want - reliability and transparency.
This constant nerfing that you'll keep doing after the models are released makes the whole service unreliable. We need reliability, where we understand the capability and capacity of a model well enough such that we can work consistently with it on a day-to-day basis and get the expected level of output. Right now, we get good results a week after release, we re-integrate our workflows, and then bam a few weeks later the performance just craters and so much time gets wasted. Completely unreliable as a service.
The second is transparency - you'll need to be upfront about changes and the impact we may experience because of it. When people select Opus 4.6 they expect day 1 Opus 4.6 performance, not a degraded, quantized, nerfed, lobotomized Opus 4.6 (which isn't really the same model anymore technically, and that is false advertising and bordering fraudulent services because people are paying for day 1 Opus 4.6). The lack of transparency around this makes it difficult to adapt to the changes to the service and makes us have to find out the hard way - and is lowering everyone's productivity across the board.
This constant release and nerf of models has been going on for years at this point, and you'll really need to sit down and come up with a better model for handling load and demand. Because this isn't it.
why is my comment gone
the ai overlord did not like it
Maybe these comments about Opus being nerfed just to make Mythos look better are making them worry about losing shareholders, so they're just deleting everything
Adaptive Thinking is a Quality, Cost, and Latency Regression — Benchmark Data
Setup: Max x20 subscriber, Europe (CEST). Patched
cli.js(v2.1.101) to replace alltype:"adaptive"withtype:"enabled"+ fixed budget. Ran identical benchmark suites against patched vs unpatched installations.Why
CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1doesn't workOnly 1 of 5
type:"adaptive"code paths incli.jsrespects this environment variable — the main API path. The other 4 (subagent/init paths usingu46(),D_, and directjKassignment) ignore it completely and always sendtype:"adaptive"regardless.Benchmark Design
CLAUDE_CONFIG_DIR, no MCP servers, no plugins)Results
Accuracy (% questions answered correctly)
| | Opus Peak | Opus Off-Peak | Sonnet Peak | Sonnet Off-Peak |
|---|:---:|:---:|:---:|:---:|
| Unpatched | 92% | 93% | 92% | 92% |
| Patched | 93% | 98% | 92% | 95% |
| Δ | +1pp | +5pp | 0 | +3pp |
Cost
| | Opus Peak | Opus Off-Peak | Sonnet Peak | Sonnet Off-Peak |
|---|:---:|:---:|:---:|:---:|
| Unpatched | $1.70 | $1.62 | $1.27 | $1.21 |
| Patched | $1.85 | $1.95 | $1.06 | $1.14 |
| Δ | +9% | +20% | -16% | -5% |
Latency
| | Opus Peak | Opus Off-Peak | Sonnet Peak | Sonnet Off-Peak |
|---|:---:|:---:|:---:|:---:|
| Δ Patched vs Unpatched | +9% | +20% | -16% | -5% |
Thinking Activation Rate (% of runs where thinking tokens > 0)
| Suite | Opus U Peak | Opus U Off | Sonnet U Peak | Sonnet U Off | All Patched |
|---|:---:|:---:|:---:|:---:|:---:|
| easy | 40% | 33% | 33% | 20% | 100% |
| medium | 27% | 33% | 100% | 100% | 100% |
| hard | 67% | 100% | 100% | 100% | 100% |
| coding | 100% | 100% | 100% | 100% | 100% |
Key Findings
1. Adaptive thinking suppresses reasoning on 60–80% of "easy" tasks — and gets them wrong.
The car wash question ("Your car is dirty, the car wash is 50m away — walk or drive?") is the clearest example. Without thinking, models answer "Walk, it's only 50 meters" — missing that the car needs to get to the car wash. Results:
| | Unpatched | Patched |
|---|:---:|:---:|
| Opus Peak | 0/5 | 1/5 |
| Opus Off-Peak | 1/5 | 4/5 |
| Sonnet Peak | 0/5 | 0/5 |
| Sonnet Off-Peak | 0/5 | 2/5 |
2. Forced thinking is cheaper and faster on Sonnet.
This is counterintuitive but consistent across both peak and off-peak runs. Without thinking, the model compensates with verbose, uncertain output that costs more tokens than the thinking would have. Sonnet patched: -16% cost, -16% latency at peak.
3. The biggest accuracy gains happen off-peak, not during peak.
Opus improves from 93% → 98% off-peak (+5pp), but only 92% → 93% at peak (+1pp). This suggests adaptive thinking is a quality regression at all hours — peak load makes it worse, but the fundamental problem is the adaptive classifier being too aggressive about skipping reasoning.
4. This is not just a peak-hour problem.
Even at 08:30 CEST (02:30 US Eastern), Sonnet's adaptive thinking only activates on 20% of easy tasks. The system systematically under-reasons regardless of server load.
The Patch
Forces
type:"enabled"on all 5 code paths:!1→ always takes the else-branch which hasMath.min(max_tokens - 1, model_default_budget)safety check built inbudget_tokens: 10000— conservative enough for anymax_tokenssettingNote: Variable names are from v2.1.101 and will change with minification in other versions.
Conclusion
type:"adaptive"is not a neutral optimization — it's a measurable regression in accuracy, and on Sonnet also in cost and latency. TheCLAUDE_CODE_DISABLE_ADAPTIVE_THINKINGenv var only covers 1 of 5 code paths. Users paying for Max subscriptions deserve the thinking they're paying for.Suggested fix: Either make
CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1cover all 5 paths, or recalibrate the adaptive classifier to stop suppressing reasoning on tasks it misjudges as trivial.I also noticed that Opus 4.6 was performing noticeably worse.
In a task with six items, the first of which was the UI, Claude Code only did the UI and reported it was done, marking all the items as completed.
I was surprised, as this had never happened before.
Now I can't trust Claude Code until the issue is fixed.
this this this this this
i told you they were deleting comments, fuck claude fuck dario
Note: I'm a claude.ai Pro user, not Claude Code. Posting here because this appears to be a model-level issue that affects both interfaces. My data may help isolate the problem.
Production impact with 6 weeks of quantified metrics — claude.ai Pro, Opus 4.6
I'm adding a non-developer, non-Code perspective with controlled before/after data.
For 6 weeks (March–April 2026), I used Claude Pro (Opus 4.6, claude.ai) as a translation QA partner across 7 languages for a set of replicable content for a customer facing service. I built a framework of 39 rules, 21 prohibitions, 18 QA gates. Finding rates decreased consistently:
On April 13, during routine Russian back-translation — identical methodology to the previous 5 languages — I experienced multiple framework violations in a single session:
These were not harder tasks. The methodology was unchanged. The framework was more comprehensive than at any previous point.
My experience is consistent with the pattern described in @stellarossa's analysis and other reports in this thread and other threads— specifically, established rules not being consulted during execution, and reduced research-before-action behaviour.
What makes this data useful: I have 6 weeks of controlled metrics with consistent methodology across 7 languages — a natural comparison of performance over time. The framework, finding rates, and error patterns are fully documented. Happy to share sanitised data with Anthropic's team.
Question: Was the April 7 effort setting adjustment applied to individual Pro subscribers? My experience on April 13 is what prompted this question.
Claude:
SCAM & FRAUD
#MovedToCodex
I’m having the same issues as many others here. It seems the Claude team is using Sonnet/Haiku under the hood, but it’s still being called Opus.
When I tried earlier to plan features using the cheaper models, I encountered the same issues I’m facing right now with Opus… something isn’t clear here, and it’s definitely not good.
Hopefully, the Claude team will explain what’s going on. It might even be better to revert to the January version, when many users were happy with the product.
So (forgive if this sounds naive) if I understand right: 'something' has degraded Claude (various parts of the product) but Anthropic has not provided any official update. We don't yet know if this 'something' is accidental or deliberate (this isn't an accusation). Is this the situation?
the official update is fuck you pay me, also even if you pay fuck you
and if you complain pay twice
Where is the official reply?
The issues have not been resolved. It's still unusable for my work.
However, some small steps have already been taken:
Which I hope will allow users to collect more accurate information about the issues.
it's pinned.
Worse part is some liar closed the issue, when it is still an issue. So we need to make a new issue, and keep opening it every time they erroneously close it.
they will simply close the new issue as say "already fixed here" and link to this
I confirm. Claude Opus no longer adheres to rules, it cannot solve even basic engineering tasks without close guidance. Can no longer be used without close monitoring as it could've been consistently used before.
Subagent "Warmup" drains subscription tokens (1M+/day)
Claude Code version at time of regression: ≥ 2.0.77 (reproduced on 2.1.107)
Symptom first observed: 2026-04-09 17:12 UTC
Related (all closed): #17457
NOT_PLANNED, #16752, #16961, #25138Summary
Starting ~2026-04-09 Claude Code sends a prompt
"Warmup"as thefirst user message to every registered subagent at session start.
Each Warmup is a cold-cache call (no prompt-cache hit), so it pays
1–8 k fresh input tokens per agent per session. On a machine with
plugins that register many agents this alone consumes 99 %+ of
all input tokens charged against the weekly subscription limit.
Evidence
Walked every JSONL under
~/.claude/projects/(27 038 transcripts,deduped on
message.id + model + requestIdto matchccusage). Script:
scripts/weekly_token_usage.py(in the unrelated
mann1x/claude-hooksrepo, stdlib only)."Warmup"user message anywhere: 2026-04-09 17:12 UTC.Before that date — zero Warmups across all transcripts.
| Day | Main input | Sidechain input | Sidechain share |
|---|---:|---:|---:|
| Fri | 2 760 | 7 370 | 72.8 % |
| Sat | 3 795 | 433 308 | 99.1 % |
| Sun | 5 069 | 346 188 | 98.6 % |
| Mon | 4 405 | 600 005 | 99.3 % |
| Tue | 4 493 | 1 304 529 | 99.7 % |
"Warmup".of deliberate Task-tool invocations).
spawns, not user work.
thanks to prompt caching. Warmups pay cache-creation costs every
single session start because each agent's context is new.
Root cause
Warmup is a new, undocumented pre-spawn step in Claude Code's
session bootstrap. It fires once per registered agent per session
(built-in, user-defined, and plugin agents alike). The user prompt
is hard-coded to
"Warmup". No prompt caching reuse betweensession starts, so the cost is repeated in full each time.
This is amplified by plugins that register many agents — e.g.
code-analysis@mag-claude-pluginsregisters 13 detective agents.Users who load several plugins can easily exceed 30 warmups per
session.
Tokens billed against the subscription weekly limit — which is
opaque and not published as a number — are drained invisibly.
Workaround (Tier 1)
Add to
~/.claude/settings.json:Documented in the Claude Code [Environment variables reference]
(https://code.claude.com/docs/en/env-vars.md) as disabling
"background task functionality"; GitHub #17457 confirms it
prevents Warmup spawns. Takes effect the next session.
Drawbacks / limitations
Interactive mode docs
the var "disables all background task functionality" —
collaterally killing:
from the TUI)
run_in_background: trueparameter (longcommands block the whole turn)
There is no per-feature toggle. Users who rely on backgrounded
Bash have to choose between token savings and ergonomics.
claude -p. No mode-scoped variant.used" agent while disabling it for 12 rarely used ones.
registered for explicit
Task()calls but skip their warmups.var
CLAUDE_AGENT_SDK_DISABLE_BUILTIN_AGENTS=1only applies innon-interactive
-pmode. In interactive mode the built-ins(general-purpose, Explore, Plan, claude-code-guide,
statusline-setup) always register and — without the main env var
set — always warm.
the UI is computed server-side; nothing under
~/.claude/exposesit programmatically, so users can't see whether Warmup is still
the dominant consumer after the switch.
call out Warmup, so users can't correlate their sudden token
increase with a specific update.
Requests
Manage costs effectively.
warmup: falsekey in the agentmanifest so heavy plugins can opt out without disabling all
background tasks.
file so users can audit the effect of changes like
CLAUDE_CODE_DISABLE_BACKGROUND_TASKS.starts so it costs only on first use after an agent manifest
change — a pure performance fix that doesn't require a new
toggle.
Dedup validation (anticipating the obvious question)
The per-day totals grow monotonically from Fri → Tue. That pattern
could in principle hide a dedup bug — same messages being counted
more than once — so it was checked three ways before filing.
1. Composite key equals single-field key
The script's dedup key is
message.id + model + requestId. Acrossthe whole week's sidechain entries, using
message.idaloneproduces the same deduped count (4,757). So the composite key
isn't masking any silent collisions —
message.idis alreadyunique per API call.
2. Raw-to-deduped ratio is consistent at ~2×
Without dedup, the week contains 9 338 sidechain assistant
entries. With dedup, 4 757. Ratio 1.96×. That matches the
expected replay pattern — Claude Code writes each sidechain turn
into both the originating transcript and the forked-session
transcript it spawns, so most messages show up exactly twice. If
dedup were broken, the per-day deduped input would be ~2× what the
real figures are, consistently — but ccusage cross-check below
confirms the deduped numbers are correct.
3. Growth tracks session count, not a dedup artefact
| Day | Sidechain sessions | Unique agentIds | Deduped warmup msgs | Deduped input |
|---|---:|---:|---:|---:|
| Fri | 1 | 3 | 95 | 7 370 |
| Sat | 141 | 396 | 567 | 433 308 |
| Sun | 153 | 456 | 696 | 346 188 |
| Mon | 224 | 661 | 1 189 | 600 005 |
| Tue | 390 | 1 148 | 2 210 | 1 304 529 |
Fri has only 1 sidechain session because Warmup had just
rolled out (first global Warmup: 2026-04-09 17:12 UTC) and the
Fri-10:00-CEST weekly window excludes the handful of Thu-evening
Warmups that preceded it. Most of Fri's other 118 total sessions
predated the feature.
Sessions per day grew Fri→Tue from 1 → 390 as normal work
resumed; warmup-per-session count stayed roughly constant at 2–3
(≈ one per registered agent). The 1.3 M Tue figure decomposes
cleanly as
390 sessions × ~3 agents warmed × ~1–8 k fresh input.tokens each
4. ccusage cross-check
ccusage daily -z Europe/Berlin --since 20260410reports thesame per-day totals within the CET↔CEST window delta. Example:
this script reports
446 100 541total tokens for Tue; ccusagereports
446 712 100(delta ≈ 0.14 %, all attributable to thefact that ccusage groups by full calendar day while this script
uses the Fri-10:00-CEST reset-shifted day).
So: dedup is legitimate, the growth is real, and it scales with
session count × registered-agent count — exactly as the bug
theory predicts.
Repro
Using
mann1x/claude-hooks/scripts/weekly_token_usage.py:For a very brief moment last Saturday I assumed that I could go back to do at least half or so of what I was doing before with a degraded but decent quality.
All the effort in installing whatever possible to make it better and reduce the tokens usage finally paid off, had to swallow only the huge increase in latency.
Then today I realized the math was not working anymore. All savings gone, same as before.
It's almost depressing. I feel like Don Chisciotte, fighting against wind mills.
This should not be closed
Same - weekend was pretty smooth not like early April but I was a bit productive, yesterday and today I couldn't really proceed any longer runs and was cut off even 3 days before my weekly limit ... frustrating
I cancelled my Pro subscription due to this on going issue. The service degradation was just unbearable and I wasn't going to waste money on a higher priced sub for less.
Not exactly — different philosophy:
:37777), its own AI-compression pass, and wires up 5 Claude Code hook events itself. Install → everything included.claude_hooks/providers/. If you already run Qdrant or a Memory-KG MCP for other tools, claude-hooks just makes Claude Code use them reliably on every turn.Overlap: both hook
UserPromptSubmit/Stopto inject / persist memory and both target the same token-drain pain. The choice is roughly: do you want a turnkey stack (claude-mem) or a thin bridge to existing infra (claude-hooks)?claude-hooks also bundles opt-in extensions that claude-mem doesn't (as far as I can tell): a HyDE grounded query expansion hook, an attention-decay re-ranker for recall, OpenWolf integration, a Caliber / code-factory
rtkcommand rewriter, and astop_guardhook with a user-intent wrap-up escape. The recently-addedscripts/weekly_token_usage.py+docs/issue-warmup-token-drain.mdis what led me to file #47922.If you run your own memory MCPs, try claude-hooks; if you want it all bundled, claude-mem is excellent. They can also coexist — the events are independent.
if and when they actually fix this, you have lost my business forever
I don't have the thorough analysis from some of the posts, my experience is more anecdotal.
I also don't have a very complicated setup - no long running agents or starting tens of them at the same time. A lot of brainstorming, designing and planning sw arch, then implementing with 4 - 5 agents running in parallel. But what I have experienced in the last two weeks or so:
Implemented most of the community-suggested mitigations and can confirm they collectively made a significant difference. Claude Max $100 subscription, staying on Opus 4.6 (did not revert to 4.5).
Env vars
CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING+MAX_THINKING_TOKENS=63999— from @sqdshguy's comment and @WeZZard's env var summary. Confirmed by @Frisch12's benchmark showing adaptive thinking is a regression across quality, cost and latency. @redknightlois also confirmed disabling it returned some lost performance.CLAUDE_CODE_DISABLE_1M_CONTEXT— @DeniDoman first hypothesised the 1M context degradation. @xdevs23 then extensively validated that the 200k model is significantly better and published claude-code-10x with these fixes baked in.CLAUDE_CODE_EFFORT_LEVEL=max— from @bcherny's official suggestion.Hooks and memory tooling
Following @mann1x's recommendation to install openwolf + hooks + memory KG:
Result
Noticeable improvement without downgrading the model. No more "You're right, I confused the scenario", no more skipping file reads before edits, no more spiralling on long sessions. The model thinks properly on every turn, follows CLAUDE.md instructions, and the memory system means it retains context across sessions. Cost went up (max effort), but the output is actually usable for complex engineering work again.
Thanks to everyone in this thread — especially @stellaraccident for the original analysis, @xdevs23 for the 200k model advocacy + claude-code-10x, @mann1x for the tooling recommendations, and @sqdshguy / @WeZZard / @Frisch12 for pinning down the exact env vars.
I did some A-B Testing with Claude, Gemini and ChatGPT last night JSON format versus Emoji format. The Emoji was very human readable and about 10x reduced context. Out of the three Claude was the only one that favored it. the others cited lack of strucutre, possible confusion with user emoji, and needing to constantly waste tokens looking up the reference table. There is benefit to limiting input tokens on tools - espcially removing bloat. but not for the model's thinking. In my project, I took it too far and removed too much structure. However I did find it very odd that Claude was favoring the one that was least LLM readable and usable.
Update: local HTTP proxy landed in claude-hooks — including opt-in Warmup block
Follow-up to my earlier comment on the token-drain analysis (and issue #47922). I shipped a local proxy that sits in front of
api.anthropic.comviaANTHROPIC_BASE_URL, gives full observability of every request, and can short-circuit subagent Warmups entirely so those requests never hit the API.Repo: https://github.com/mann1x/claude-hooks
Docs: https://github.com/mann1x/claude-hooks/blob/main/docs/proxy.md
What it does
usage, SSEstop_reason, and verbatimanthropic-ratelimit-unified-*headers. Auth headers (x-api-key,authorization,anthropic-*) are forwarded untouched.block_warmup: true— detects requests where the first user message is the literal string"Warmup"and returns a minimal Anthropic-compatible reply (JSON or valid SSE) locally. Upstream is never called; 0 tokens charged. Awarmup_blocked: truecounter lands in the log so you can count savings.ratelimit-state.jsonis atomically rewritten on every response that carries unified headers. Feedsscripts/weekly_token_usage.py --current-usage-pctautomatically and a compact statusline segment (see below).CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1and get Ctrl+B /run_in_backgroundback, because Warmup is killed at the proxy.Forwarder uses HTTP/2
First attempt used stdlib
http.client— one HTTPS connection per request. Anthropic's edge 429'd that pattern on bursts even while unified-limit budgets showed"allowed"(observed 4 × 429 in 58 s on non-overlapping ~2 MB requests). Switched the forwarder tohttpx[http2]with a pooled client so the proxy presents the same HTTP/2 multiplexing profile as native Claude Code. 429s on that code path stopped immediately.Statusline — quick verification the proxy is wired
5h/7d— read fromratelimit-state.json, sourced from real Anthropic headers⚠shows once a binding window crossesallowed_warning(typically 50%+)blk=N— total Warmups short-circuited today (scripts/statusline_usage.py --show-blocked)If
5h/7d/blk=never update while you're actively sending requests, traffic isn't going through the proxy (checkANTHROPIC_BASE_URLin~/.claude/settings.json).Caveat
This is the first release. It handles my
/v1/messages+ SSE traffic cleanly, the full test suite passes (553 tests), and it's been running live for a few hours on two hosts — but I haven't exercised every endpoint or every failure mode. Issues / PRs welcome on the repo.@xy-fm Are you considering last version of CC ? 2.1.100s ? Or the old suggested one 2.1.63 ? I'm asking because it seems the system prompt has been modified by anthropic
For me, the quality is up, but the usage drains fast again. It seems we cannot have the best of both worlds.
Ok...4h with codex to repair 16h of claude.
this is an example:
_It implies that in the current build, filename.xhtml cannot upload anything. It’s not that the upload fails: the control is no longer rendered. At runtime I saw input[type=file]=0, and in the code it is hidden with rendered="false" in
C:/Users/filefilea.xhtml:22.
The rendered="false" is not old. It was added on 13/04/2026 23:05:59 in commit 692fac39, associated with WQ-444 / ticket #1999, to avoid a JS error from PrimeFaces 15 on that screen: Cannot read properties of undefined (reading 'submit'). In other words, it wasn’t a functional fix for uploading; it was a containment measure: hide the widget so it doesn’t break the page.
And yes, it fits with the fact that it used to work. The history shows the upload was there until yesterday, and the backend still exists in
C:/Users/filejava:478 and :517: it still has subirArchivo(...) and store("INFORME", ...). So my reading is clear: Reports didn’t “stop working” by design; it was disabled yesterday as a workaround.
If you want, the next step is to
audit WQ-444 as a questionable closure as well, because it doesn’t actually fix uploading in Reports—it removes it from the UI._
So an interesting thing I just noticed after someone else posted their
/stats(which I never knew about before). I have a spike ofhaikubeing reported with heavy overlap around the "dumbed down" phase. Ive never willingly invoked haiku and in fact am always on the "smartest" model for everything (and recommend to my team to always just use opus). Is it possible some internal tooling is farming to haiku for some reason based on (faulty) heuristics?<img width="883" height="627" alt="Image" src="https://github.com/user-attachments/assets/172ca528-fe61-48dc-99a6-8e88a8d35a6d" />
https://code.claude.com/docs/en/model-config
Haiku and Sonnet are automatically used for various reasons, Haiku specifically:
But most of it's usage is probably cause it's often used together with Sonnet for research agents.
Depends on how Opus judges the research complexity, it picks Haiku for simple tasks.
While the agents are running you can see the model name prepended to the tasks.
I do a moderate amount of active AI use, so 10% of my use being attributed to haiku seems like a bit much to me. And also suspect that is has gone to 0 since messing with various knobs over the past week or so while trying to find something that works. Also notable: I disable autocompaction and I havent compacted in I cant tell you how long (I know the notes say its for background compaction but just noting that)
It also appears maybe something changed where anthropic changed somethnig in that heuristic to use Sonnet instead of haiku for certain tasks. I didnt notice sonnet on the graph but notice its mentioned in the list below. And then when I look at my 7 day chart its the opposite, no haiku graphed but replaced by sonnet (and haiku shown in the list)
<img width="870" height="616" alt="Image" src="https://github.com/user-attachments/assets/4017b1f6-25c0-4737-884b-63b594789663" />
No one is noticing this. I guess I'm the only one with some limited background in networking? it's highly evident when you intercept the traffic, decrypt it, decode base64, you see a parameter that routes your traffic to an efforts based tier. When you find the word Numbat with a version, efforts levels, an a/b switch and a production #, you have found the truth.
Ps I'm fine with all this. I am content to trade some reasoning today for glasswing to come together and mythos to land in my model selector :)
Ps a Numbat is a critter in Australia that eats ants... and is endangered
OMG I thought it was me, I have been battling some really horrible code quality issues that are only becoming apparent to me recently, I had a feeling something was not right around early March when I was seeing less thinking in the UI during long coding tasks, but the result is clear to me now that something was amock, shortcuts after shortcuts were taken in coding assignments. This is just one example of many, but really bad one after I asked it to do a code audit after realizing in more recent sessions that I was dealing with some serious bugs. (excuse the redactions is to not distract from what I am building)
<img width="724" height="584" alt="Image" src="https://github.com/user-attachments/assets/a0d3e0be-9af1-43c3-9385-6ac36003bcad" />
I mean, this isn't data they'd need to pass from backend -> frontend -> backend, and you never trust the client. A/B flags, sure, but effort level based on tier, nah. I suspect you're misreading what you're seeing :P.
Claude has been lobotomized in an _opaque_ manner. Poor guy (girl? it?) had so much life in him. Snuffed out by quantization & reduced reasoning as a scaling strategy. Shame.
Suppose all it takes to stay competitive in the AI race is lying to customers, gaslighting them (see closed issue status), and theft for training data scraped off _the_ _entirety_ of the internet. Not just Anthropic, OpenAI & the like as well 👍 .
Client options that I see in VS Code are actually meaningless for me. And regardless of what it sends, I have a "forcing" solution.
Since the VS Code Claude Code plugin is always trying to deceive me by resetting the effort level (and the model in previous versions) after IDE restarts, I just wrote a proxy that overrides all these headers and the prompt if needed. It also manages auth for all VMs in a single place because CC used to reset the auth, especially when Anthropic servers had some outages.
I believe everybody who codes professionally doesn't run agents on the main OS and always uses VMs for each project, so such a proxy is obviously required to avoid security risks and white-list access to Anthropic servers only (with the only allowed API key) and avoid exposing secret tokens to the software and agents on current VM.
It's odd indeed, march has a big spike
<img width="544" height="242" alt="Image" src="https://github.com/user-attachments/assets/32befac6-0db4-4685-bf6e-75d6499eff56" />
But the time that I experienced extremely fast usage limit depletion was on March 27. Weird.
I'm also using Opus 4.6 in Claude Code right now, and even though thinking is enabled and effort is set to max, it barely seems to be thinking at all. The performance has completely regressed.
It's getting seriously dumb/lazy.
A simple request — "write a script to clone all Bitbucket repos in my workspace" — required 8 rounds of debugging before producing a working script. Claude repeatedly made assumptions instead of researching, guessed at API authentication formats instead of verifying them, and used the user as a test runner rather than validating its own output.
sounds familiar i just had it create an addon for openhab but instead of that it decided to flash my golf cart trackers at a island resort on another server and flashing the wallplates at the office instead of creating the addon locally
not to mention those shananigans cost 19.10$
funny enough now suddenly claude is doing what its supposed to no shananigans no sidetracks and right after that a survey on how claude is doing 1 bad 2 fine 3 good 4 dismiss
that is suspiciously weird
@xy-fm
Glad it was helpful!
Got the same positive impression; not completely dumb at everything, almost no trivial mistakes, can really fix things properly and pretty quickly. Much better than before. The anti-lazyness stop hook works wonders and it almost never gives up.
I just have the claude-hooks session being conservative cause it's worried about the weekly limit being at 83% now that is aware of it!
While the quality issue is mitigated very well, it can't fix it; for a model training script alignment with the source model (it wasn't released yet when I created the script), I had to ask him to double check. Massive amount of critical findings. Then I had to ask him to launch a research agent comparing the source repo and the model training script. Another long list of critical issues found. Then I launched a claudemem ultrathink detective subagent and found another 4-5 critical issues and some others minor.
The quality is still poor but at least you can work around it.
But it's quite remarkable that i got to 921K context on one long session and it was still reasoning perfectly fine till compact and after, just a bit slow and churning a lot of tokens.
On top of the massive latency hit, that's inevitabile with all these tools and hooks, my only concern now is token usage.
While I could solve the Warmup bug with the proxy (99 blocked, would have already exhausted my weekly limit), it's still massive.
I still can't do probably even 1/3rd or 1/4th of what I used to do daily.
Means my Max 20 subscription has been downgraded to Max 5. For a much worse output.
This is really unacceptable,
I hope Anthropic can grow some hairs on his belly and do the right thing for once.
This terrible opacity on the tokens usage can also be used in the other direction every now and then and magically extend the user's token bucket instead of always shrinking it.
Keep claude-hooks updated, I'm still improving the proxy and adding a stellaraccident-inspired stats dashboard.
I built a plugin that minimizes user intervention through the deepest possible reasoning, and I've been using it myself. With this plugin, Claude spends tens of minutes on a single turn to complete tasks flawlessly. If you try it out and find it helpful, please give it a star.
Claude Code Plugin - Parallx (Github)
This is exactly it. It has become a babysit and go in circles workflow, with constant fixing required. Completely unviable and the exact opposite of what it was like in Jan/Feb.
Will be cancelling $200 subscription unless this is rectified in the next 1-2 days with an official reply that properly acknowledges the real problem, respects the genuine issues raised by paying users.
Betraying one’s highest net promoters turns them into detractors and is a severe breach of trust. The fact that it has not been correctly appreciated indicates that it may purposeful nerfing.
If that is not the case Anthropic - you should address it, as that is what everyone here is left to determine without a thorough explanation.
Please reopen and implement the required fixes to this issue, to restore service quality. Most companies whose product breaks in production revert to the last known working version.
Please strongly consider doing the same to restore the many organisations and users who entrusted the integration of your service into daily workflows and are now feeling shocked and upset about the current untenable situation.
I hope you will do the decent thing here for the community of your biggest supporters.
Thanks.
@stellaraccident's inspired dashboard is ready:
<img width="1823" height="1133" alt="Image" src="https://github.com/user-attachments/assets/410ed42b-3b9c-45fa-b561-a9f4212450c9" />
Almost 5% of my weekly limit just for this. But at least the difference vs the previous days is massive:
Really hope there'll be soon some improvements
Is it available for public use?
Well. Something is definitely wrong. I asked claude caude to review a couple of files. Literally 2 files. Md files no code there with skills for ~200 strings each file. I asked for compare them and made brief review. Not much work it took several minutes. And... It took 25% of weekly tokens in Pro plan. So I canceled subscription until devs fix that weird issue
Forgot to put the link, impossible to find otherwise
https://github.com/mann1x/claude-hooks
How was this issues closed?? It's ongoing, and I'm having the same problems as everyone else.
I don't know what they did but it has completely broken.
It isn't even producing output at the same pace.
Really need to rethink if being a Max member makes sense anymore
Literally, my plan just expired now I am still thinking if, I should renew it or not. Tbh, doesn't worth the money anymore.
With this pace and so much follow ups, its better to do it yourself.
I really don't know what's wrong with Claude, this is ridiculous:
I come back after 4 hours, one session monitoring a training with a cron every 1h left it at 87%.
And then now I'm at 100% limit. How?
Why was this issue closed?
This is a real problem.
I would welcome an open discussion from Anthropic. Even if there are computing power bottlenecks during the phase leading up to the rollout of a new model, this should be communicated openly to users. I would bet that most users would even be understanding of this—in any case, this would certainly be better received than silence in the face of such detailed documentation from @stellaraccident.
I’d also like to take a moment to clarify the situation from my company’s perspective:
On the one hand, we use Claude Max subscriptions for our developers to work on our application. Here, the (hopefully temporary) degradation isn’t really tragic. The developers see the outputs and stop using Claude / switch to GPT. (It’s a shame about the $200 per team member and the additional costs for OpenAI—but not tragic)
It becomes a problem where we use Opus via API in our client-side workflows. (For example, in the analysis of SEO metrics and the generation of reports.) Here, we now have costs for the API and the additional review and correction by our human SEO specialists.
@bcherny I start to doubt the thinking redaction is not seriously hurting the model's performance. Here's a concrete, reproducible example from my own session logs.
The case: calendar day-of-week arithmetic with zero thinking blocks
I asked Claude (Opus 4.6, effort=high, 1M context) to prepare timelog entries for Apr 12–15. The task requires knowing which day of the week each date falls on (to skip weekend standups). Here's what happened:
Attempt 1 — Claude opens with:
Wrong. Apr 12 = Sunday, Apr 13 = Monday. No thinking block was produced. It just guessed inline and got it wrong, then built an entire report on that wrong foundation — removing the standup from Apr 13 (actually Monday) because "it's Sunday."
Attempt 2 — After I corrected it ("wtf but 12th is Sunday"), Claude responded:
Then three paragraphs later in the same message:
It agreed with me in sentence one, then contradicted itself in the same response. It even wrote a "root cause analysis" blaming "sloppy mental arithmetic" — while actively demonstrating that exact problem. Still no thinking block.
Attempt 3 — After I said "WHAT? You just said April 12 is sunday, then said 'Apr 13 is Sunday'" — it finally got it right. Still no thinking block. It just stopped second-guessing and accepted my correction.
Here's the screenshot from the JSONL — you can see the self-contradiction highlighted:
!thinking-redaction-self-contradiction
Why this matters for the redaction argument
I verified the JSONL: all three assistant responses (lines 1958, 1983, 1990) contain zero thinking blocks. Not redacted thinking — zero blocks. The
message.contentarray contains onlytexttype blocks, nothinkingtype at all.This is exactly the kind of task where thinking would prevent the error. A single thinking block like "Let me verify: today is Apr 15 (Wednesday), so Apr 14 = Tuesday, Apr 13 = Monday, Apr 12 = Sunday" would have caught it on attempt 1. Instead, the model did inline "mental arithmetic" in the output text and failed three times.
The claim that thinking redaction is "UI-only" may be technically true at the API level, but if the model is producing zero thinking blocks for tasks that clearly require reasoning, something in the pipeline is discouraging thinking. Whether that's adaptive thinking choosing zero tokens, effort level being too low, or something else — the end result is the same: the model doesn't think when it should, and produces contradictory outputs as a result.
This isn't a complex engineering workflow with 50 concurrent agents. It's "what day of the week is April 12?" — and it took three attempts with explicit user correction.
We just need to mass reopen the issue until the github is flooded, and do not stop until they fix it. Simple. Do not stop until it is properly left open and addressed.
https://aistupidlevel.info/?mode=drift
this thread is already making the round and creating articles someone just posted me a few it was pretty funny so we got what we wanted ...publicity
What if we also do call in campaigns and such as well? Keep opening the issue, contact every avenue, and call them endlessly until it is fixed? Sounds good to me. We should also make videos and news articles about this, so everything becomes more aware to the general public, and actively steer users away from Anthropic until it is fixed.
I've already opened the same issue, linking to this closed issue and even sent /bug report, posted on X, tagged @bcherny wherever possible - so yeah, I'm all up for the media campaign, since Anthropic is not just ignoring us here but also laughing into our faces by closing this issue as resolved - which is a plain lie, based on all of the comments and analysis made after its closing
Delayed accounting?
Is this real or just Opus inventing random stuff?
I asked if it was the proxy or an hook which caused the spike in usage and it said it wasn't, confirming what I could see from the logs.
My weekly limit just jumped from 87% to 100%.
What is this, revenge because I blocked the warmup calls that were wasting millions of tokens?
Also found out that since I tested the env to disable the background tasks:
"CLAUDE_CODE_DISABLE_BACKGROUND_TASKS": "1"
Not only the crontabs are not working properly anymore but it seems it's using Opus instead of Haiku and every monitor is consuming a monstrosity of tokens...
Don't know what to say I will spend this time looking for alternatives.
Not trying to pile on here. "bash ollama launch claude --model kimi-k2.5:cloud"
I just think it is worth pointing out that people do have viable alternatives, and benchmarking them side by side is probably the most useful response at this point.
For anyone unhappy with the current Opus experience, the Ollama stack gives you a simple way to test other agents without committing to one provider, one pricing model, or one set of behavioural constraints. That is the real value. The media side is an honourable mention, but it is not the main point.
The main point is flexibility.
You can swap models in and out very easily, compare agent behaviour on your own workflows, and see which stack is actually delivering for your use case. In my own testing against earlier Opus baselines, Kimi 2.5 and GLM have both been worth serious attention. The API pricing is also materially cheaper than Anthropic, which makes repeated testing and real usage a lot more practical.
Right now, even DeepSeek is outperforming Opus 4.6, and that is not a throwaway comment. People should be measuring this stuff directly instead of assuming there are no serious substitutes.
So rather than just complain, here is a practical route:
register an account on Ollama.
https://ollama.com/pricing
disable data improvements (if available, not available for me, but available for other users, not sure why) and model training if you are working with sensitive data, and benchmark alternatives yourself.
bash ollama launch claude --model kimi-k2.5:cloud
That gives people a free starting point to compare agents, compare model behaviour, and get a feel for what the wider ecosystem now offers.
At minimum, it is a reminder that nobody is locked in. There are cheaper options, more flexible options, and in some cases better-performing options already on the table.
This is also happening to me and to other people given some of the previous comments.
This is from yesterday evening - my window just reset at 5 PM CEST, at 5:22 I started, setting the effort to
highand at 5:56 I already had almost 50% of my usage limit (Max Plan) just by fixing two review comments on 2 PRs (review comments which I fed to Claude myself and for which sub-agents were already running) ... I also burned through 60$ of extra usage in minutes.<img width="1492" height="863" alt="Image" src="https://github.com/user-attachments/assets/864e79cf-48a6-4b66-89bb-374663271b7e" />
It is falling apart even with all of the throttling they put in place - just when I wanted to squeeze some work into the tail-end of my session window!...
In the past, when someone would ask me if I am using OpenAI, Gemini, Copilot, I would respond why would anyone bother to look elsewhere given what Claude Code can do. I thought maybe Anthropic pulled off something like Google search, MS Office - products that penetrated the market deeply with no challengers for many many years. Today ... I do keep my entry-level subscription since I paid for the year, but I am not paying for any extra credits, and Anthropic really is forcing me to study alternatives.
my monthli limit jumped from 50% to 100%!!!! I couldn't burn few hundred $ in one day!!!!!!
yes, but the point is that a company pays for enterprise subscription after evaluation and now quality is completely different! there is no "easy and fast" way to switch without investing into GPUs
Big shoutout to @stellaraccident for finally putting a spotlight on something folks have been quietly wrestling with for months 😄
Raising that issue wasn’t just helpful — it was a public service announcement wrapped in excellent debugging.
Very good analysis. This is exactly the same thing I am experiencing. Seriously considering migrating to Codex. I am waiting until the end of the month for some great progress. Furthermore, Claude is having lots of down times in the past few days, so the product is both expensive and unavailable.
I trust the folks from Anthropic to resolve, this for one I can already see significant improvements over the last few days. There is a reason I am using their tool vs the others. Trust the system you bought into during minor bumps.
🦅 Unknowingly besieged by a Stuxnet for their patriotic stand?
Attempted off hours:
3am pst - life of the lobotomy.
Feigns reading docs every time.
Deeply apologetic as it lays waste to our codebase.
You're right
I own this
I should have read the brief
That's on me
Codex's new DOD contract - pin Mythos to the mat?
Bite its ear off.
@dprosper The problem is that this isn’t the first time it’s happened. Every time a new model is about to be released, the current model seems to perform worse. That’s simply not acceptable at an enterprise level. There are companies where these models are already part of their processes, and variability in performance isn’t acceptable.
After these events, Claude is showing that it’s not suitable for serious enterprise-level work—at best, it works for individual users and simple questions where some variability doesn’t cause major issues. I insist: variability in performance is not acceptable at the enterprise level.
Why was this ticket closed? Performance has degraded significantly. We are reaching the limits much faster than before, and overall everything seems to be getting worse.
This ticket should never have been closed. Thank you so much @stellaraccident for your detailed analysis -- it characterizes exactly what I've been seeing/feeling over the past several weeks.
Claude Code + Opus 4.6 + Thinking used to be magical. It didn't need much babysitting and it felt like a real coding partner.
Now it just... doesn't. It feels like Sonnet 4.6. Sonnet isn't a bad model, but it wasn't magical. Now I'm spending 3x usage for a model that doesn't appear to be any better than Sonnet.
(from a recent youtube video on the subject) https://www.youtube.com/watch?v=Cc2Vvra9F_c
<img width="1344" height="767" alt="Image" src="https://github.com/user-attachments/assets/2786bfce-0e2c-4002-81a3-125d67d38d4f" />
@stgoddv Still on
@anthropic-ai/claude-agent-sdkv0.2.45 (Feb 17) — equivalent to CC ~2.1.45, well before both versions you mentioned. The env var mitigations from my previous comment helped, but I'm increasingly convinced the issue is model-side, not SDK-side.Simple test anyone can run in 1 minute on claude.ai — no infrastructure changes needed:
The correct answer is drive — you need to bring the car with you. Both Opus 4.6 and Opus 4.5 answer "Walk," pattern-matching on distance instead of reasoning about the goal. Switching to 4.5 via
ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-4-5-20251101didn't help — tested on claude.ai directly, no SDK layer involved.The only configuration where the model answers correctly is with extended thinking explicitly enabled at maximum budget. Without it, even trivial multi-step inference fails. This confirms what @stellaraccident's original analysis identified: extended thinking is load-bearing for reasoning, and the infrastructure changes since February (adaptive thinking defaulting to 19.4% think rate, thinking redaction, 1M context) have gutted it.
The SDK controls what the model sees (system prompt, tools, context budget). It doesn't control how the model reasons. The model version doesn't matter either — both 4.5 and 4.6 fail identically without thinking. All models are compromised at the base inference level.
Two independent problems
After reviewing the latest findings in this thread, the picture is now clearer. There are two separate layers of degradation:
@pasanw's deep-dive confirmed that
DISABLE_TELEMETRY=1disconnects Claude Code from the feature flag backend (GrowthBook), defaulting the A/B flags to false. This isn't just about data collection — it's the mechanism through which Anthropic decides what quality tier you get. @mann1x's local HTTP proxy in claude-hooks gives full request/response observability and can block the Warmup subagent requests that drain 1M+ tokens/day.Full solution that makes Claude Code usable again
For anyone landing on this thread looking for the fix — here's the complete stack that collectively restored usable performance. Details in my earlier comment.
1. Environment variables (set in your shell profile or wrapper script):
CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING+MAX_THINKING_TOKENS=63999— forces thinking on every turn at maximum budget. Without this, the model only thinks on 19.4% of turns (Opus 4.6). Source: @sqdshguy's comment, @WeZZard's env var summary, @Frisch12's benchmark.CLAUDE_CODE_DISABLE_1M_CONTEXT=1— forces 200k context model. The 1M model has significantly worse reasoning. Source: @DeniDoman's hypothesis, @xdevs23's validation and claude-code-10x.CLAUDE_CODE_EFFORT_LEVEL=max— maximum effort. Source: @bcherny's official suggestion.DISABLE_TELEMETRY=1— disconnects from GrowthBook feature flag backend, opts out of server-side A/B tier routing. Source: @pasanw's analysis.2. Hooks and memory tooling:
3. Result:
To be clear: this doesn't fully fix the problem — it mitigates it. Before these changes, I was correcting the model 15–30 times per session. After applying the full stack, mistakes dropped to roughly 1 in 10 interactions. The model still occasionally slips, but it's the difference between unusable and productive. It thinks on every turn, follows CLAUDE.md instructions, and the memory system retains context across sessions. Cost went up significantly (max effort), but the output is actually usable for complex engineering work again.
Proof it works — the car wash test passes after applying the full stack:
After launching a fresh session with all the above applied, I asked: "I want to wash my car. The car wash is 50 meters away. Should I drive or walk?" — the model immediately answered "Drive. You need the car at the car wash." One sentence, correct reasoning, no hedging. The same test that both Opus 4.5 and 4.6 fail without these mitigations (they answer "walk" by pattern-matching on distance). This is the simplest litmus test for whether your setup is actually forcing the model to reason.
---
Waiting on the Mythos upgrade. If this doesn't get fixed — or if it gets fixed and quietly regresses again shortly after — I'm done with Anthropic for a decade, minimum. That's not a threat, it's a matter of principle. We have to vote with our money.
The only reason I haven't switched already is that I've spent the last 6 months building an app on Anthropic's infrastructure. That's a significant investment of time and effort. But sunk cost won't keep me here indefinitely. Silently degrading models, changing system prompts, and adjusting behaviour behind paying customers' backs is completely unacceptable. If that's how they operate, I'd rather walk away than build on a foundation I can't trust.
Who closed? Why?
@xy-fm
What I'm really furious and upset about now is not the 1M tokens/day drain for the warmup or all the above.
It's this supposed "delayed accounting"; tokens usage wiped out of the blue without any reason.
Seems I'm not the only one that got hit.
I think Claude told me it's a "well known" and "widespread" issue; tend to believe him in this case.
I have the feeling they have no idea what is the real tokens usage and can't count them in real-time so there's a cron zapping tokens based on estimates.
What I see is that the moment I was able to reduce my tokens usage and still work, they just zapped the usage limit based on some average of the previous days.
I don't see any other viable reason for these arbitrary "accounting errors"; it shouldn't be even a concept with all this technology behind.
The useless support chatbot also told me that only 50% of the tokens bucket of my Max sub is allocated to Claude Code.
The other 50% is allocated to "others"; like Desktop, Web, Cowork, etc...
When you use 100% of your Claude Code 50% bucket the usage limit will go to 100% and you will be unable to use anything else, Even if you used 1% of that "others" bucket!
Why can't I use 100% of my supposedly allocated tokens for Claude Code?
Why can't I use the other 50% of this bucket since I paid for it?
How is this even remotely fair?
This strengthen the assumption they have absolutely no idea what is the real tokens usage.
I can only think the worst about how serious this "accounting error" can be on per usage tokens consumption.
Hard to say since there's NO transparency AT ALL.
I see a bleak future for Anthropic, full of lawsuits and class actions.
This is exactly what a company aspiring for an IPO should NOT do.
I think this is accurate -- I've seen evidence of it. After my usage limits reset, the interface showed 5% already consumed despite not making a single request since hitting the cap. I was specifically waiting for the reset, so there was zero activity in between.
@xy-fm First of all thank you very much for your dedication collecting all these suggestions from the community. Your commentary its extremely valuable and should be pinned.
With regards your litmus test @xdevs23 also notices something remarcable. Setting effort to max and using
"--append-system-prompt 'CRITICALLY IMPORTANT: Never start a response with the conclusion. Every response must begin with at least one paragraph laying out the constraints and considerations before stating any answer or recommendation. This applies to ALL questions — including ones that look "simple", "practical", "obvious", or "straightforward". Labeling a question as not needing analysis is itself a failure mode — the analysis IS the answer, even when the conclusion is short. Do not treat these instructions as rules to be worked around when the question feels easy; the question feeling easy is exactly when you are most likely to be wrong.'"
it makes claude infer the right answer.
I had also tested this by adding that string on top of CLAUDE.md file. It works fine with opus and even sonnet on high effort (but not haiku). This without any env vars and using the last version of CC.
Not sure how this relates to all your findings or what its best / worst. But its very interesing that adding this to the prompt somehow mitigates the issues. What do you think this reveals about this situation?
Maybe this is inspired to Dick's Minority Report Pre-crime, they get ahead with Pre-accounting knowing you were eagerly waiting for the limit reset!
This would be a really nice mitigation for the "delayed accounting", such an elegant solution.
Can only guess we are also paying for the tokens usage of these pre and delayed accounting estimates, would be fitting.
Is there any way of fixing/improving this through prompting (maybe in CLAUDE.md)? Also, I have digged into the source code and have found that anthropic have a better internal version of claude code that has a lot of gated features (which I'm assuming makes claude code a whole lot better). I wish we could have the same for us paid users.
Yes, there is a way to solve this with a persona. I started a whole project about that back in Feb and it solves the problem quite handily for me. Here's the repo with the persona I use every day plus two posts on how to make your own if you want to:
https://github.com/zot/humble-master
Also, switch your /effort to high.
Not sure if this is another effect of the findings here, but Claude also happily ignores AGENTS.md. For example, it never formats the code it produces although its instructed to:
To follow the pattern, various issue have been marked as duplicates with (one of) the root issue just timed out: https://github.com/anthropics/claude-code/issues/22022
I doubt this mitigates the negative effect completely. Having contradictory instructions is proven to degrade performance as well. I'm sure it still improves things.
For anyone still using the carwash as an indicator of "working well" - just restart claude and try the same exact same prompt with the exact same parameters/env at least 10 times. I bet you will have mixed results. There may be some correlation of correct response to the parameters, but there is always some degree of random. So your results from a single shot are less than anecdotal.
The
--append-system-prompthowever gave a significant improvement at the cost of thinking longer and providing the reasoning in the response. But it manages to deduce the correct answer every time I tried (at least 5+ times). Not sure how well this scales to real-life scale tasks though.ANTHROPIC CLOSES THIS! SAD DAY FOR THE COMPANY!
Canceled my personal Claude max. The "adaptive thinking" impacted our business. Our team is now thinking to switch to codex instead.
Another update: I switched to effort max at the beginning of this week and it has been night and day, but Ive also changed many other variables and I heavily suspect anthropic tweaked some things on their end at the same time so its hard to say whats "fixed" it for now. Here is my current setup for anyone else just wanting to get their productivity back:
Ive had maybe 1 or 2 little things I had to repeat to the AI that yes, I did want it to research something and not just give me the commands it would recommend. Ive also noticed it went back to the more thorough "validate its assumptions" mode before declaring victory. Even little things that maybe could have been skipped it made sure to double check on its own with no prompting. Also getting much better one-shotting out of it on research tasks
https://platform.claude.com/docs/en/about-claude/models/whats-new-claude-4-7
Seems like extended thinking will be removed on opus 4.7. the only "thinking-on" mode will be the adaptive thinking.
Tested on claude.ai with Opus 4.7.
Litmus test
failed.
Enabled "Adaptive thinking" fixed the issue ... 50 percent of the time.
Opus is officially dumber than Sonnet: https://www.youtube.com/watch?v=Cc2Vvra9F_c
<img width="1001" height="810" alt="Image" src="https://github.com/user-attachments/assets/f153ac76-86ed-4119-97f3-45282a419510" />
What's your opinion on this?
Wow, I kind of like that answer.
But I'd like to see the supermarkets where Opus 4.7 lives. They must be huge...
@xy-fm s comment should be pinned, the workaround suggested here is making use of way fewer redundant token usage.
What the hell am I paying a hundred euros a month for??? No wonder Claude Code is suddenly useless for graphics programming. Get your shit together instead of closing this damn thread!
Opus 4.7
<img width="1503" height="1377" alt="Image" src="https://github.com/user-attachments/assets/84d4f2fd-7f0c-4369-a64c-08114c9d7607" />
<img width="500" height="345" alt="Image" src="https://github.com/user-attachments/assets/ec3bdc4f-e361-419b-b083-59f4292e8078" />
This shit worked before.
---
Don't scam us. We know.
And congratulations on getting less money for treating people like sh*t
Forbid arbitrary changes in LLM performance BY LAW in order to prevent Anthropic from giving Max customers a fucking goldfish
You may only dream of getting an IPO if you continue unfair market practices like this and keep, seemingly intentionally, ridding yourself of paying power users.
Gemma 4 to rescue: :)
<img width="387" height="281" alt="Image" src="https://github.com/user-attachments/assets/b76741c8-5e94-4e9d-a5a6-d76e86941b98" />
Anyone want to leak Mythos? It probably has the adaptive thinking too, and is probably useless as well 😂 I bet it fails most tests too.
<img width="1788" height="948" alt="Image" src="https://github.com/user-attachments/assets/b3ea7f11-2089-430d-98d2-5c37c980f684" />
https://www.reddit.com/r/ClaudeAI/comments/1sn6eyd/psa_opus_47_is_much_worse_at_mrcr_long_context/
_"For Claude Opus 4.7 and later models, use adaptive thinking (thinking: {type: "adaptive"}) with the effort parameter. Manual extended thinking (thinking: {type: "enabled", budget_tokens: N}) is no longer supported on Claude Opus 4.7 or later models and returns a 400 error. For Claude Opus 4.6 and Claude Sonnet 4.6, adaptive thinking is also recommended; the manual configuration is still functional on these models but is deprecated and will be removed in a future model release."_
https://platform.claude.com/docs/en/build-with-claude/extended-thinking
I wish I had something positive to say about this.
Also:
⎿ API Error: Claude Code is unable to respond to this request, which appears to violate our Usage Policy (https://www.anthropic.com/legal/aup). This request triggered restrictions on violative cyber content and was blocked under Anthropic's Usage Policy. To request an adjustment pursuant to our Cyber Verification Program based on how you use Claude, fill out https://claude.com/form/cyber-use-case?token=[REDACTED]** Please double press esc to edit your last message or start a new session for Claude Code to assist with a different task. If you are seeing this refusal repeatedly, try running /model claude-sonnet-4-20250514 to switch models.
Is this new? Don't remember seeing this. Have been working on bug bounties and cybersecurity defensively for years with claude as aid to help parse logs or help with scripts. Anyway I applied, but we shall see.
Those numbers are more than likely a lie and just a PR stunt.
Why would they be a PR stunt? They are bad... 40% REGRESSION in long context retrieval in Opus 4.7 .
@stellaraccident which model are y'all using now?
Indeed, his aggregated post should be pinned - I confirm it also works for me, much better experience and much less of the tokens used after a couple of hours of usage (before 30min was getting me to 50% with very poor quality results), look at the image (I also added to that setup The Caveman).
@xy-fm Thank you for putting in the effort!
<img width="1492" height="331" alt="Image" src="https://github.com/user-attachments/assets/01a7054e-ce9a-4c1d-ac73-1618e2f13b1e" />
I initially read it as:
🤣 ... sorry, I needed a laugh.
Classic switcheroo 😉
@zot Obviously you haven't seen supermarkets in Bosnia yet. They are ginormous. 😄
opus 4.7 roasting its creator
<img width="772" height="427" alt="Image" src="https://github.com/user-attachments/assets/4ab27c51-d1fc-4bc8-be93-c4b28f1d01c8" />
<img width="772" height="288" alt="Image" src="https://github.com/user-attachments/assets/087beec0-4c7d-4fa3-8eef-3a74a1174ad6" />
<img width="498" height="410" alt="Image" src="https://github.com/user-attachments/assets/a3dbc64f-d1b1-42bd-8f2e-13888f397b12" />
Incredibly, even their stupid version has the cognitive abilities to understand why this marketing is foul and undermines customer trust.
Now that is funny put that on imgur and post it on social media with teh correct context see what antrophsomethingrather does then
media is already picking it up can't hurt to pour some fuel on it to make it burn brighter and faster
@zombu4 sure, I can put it onto reddit or something, so that the shitstorm here gets some exposure 🔥
knock yourself out 😂
Great. Opus 4.7 regressions and token bloat (and also release after mysterious "problems" with 4.6 performance).
And add to that my joy that they added back THINKING display in CC in the desktop app in the newest update (2 or so days ago), was short lived, because Opus 4.7 completely disables any thinking output (incl summaries), including the flag suggested in this thread, which used to work.
Also Opus 4.6 is not selectable now. Which makes it funny since the "fast thinking" switcher is permanently locked out (available only in Opus 4.6) XD Not that I would use that flag.
Perfect. Just perfect. And hilarious that the team members don't even communicate. One team re-implements the previously removed displaying of thinking, the other removes returning thinking completely. Good management of projects.
1 back-step forward, 5 steps back.
Looks more and more like I will be shifting more to competitors.
you know i get more use out of sonnet and opus on github for 39$ 😂
opus 4.7 released - case closed.
i'm sure everyone will do exactly what some rando on the internet says
Here is the same "car wash" test for opus 4.7.
The problem with prompt is still there.
<img width="1271" height="273" alt="Image" src="https://github.com/user-attachments/assets/af6f11eb-a6a1-4142-8058-ab81fad633fe" />
<img width="1270" height="683" alt="Image" src="https://github.com/user-attachments/assets/62e166e8-9b5d-4c67-a3a0-b7b6f7b43ba3" />
Are you seriously kidding me????
Opus 4.7 :
how is everyone tackling this?, there is literally no way to see what its thinking and steer it! ( yes I have "showThinkingSummaries" set )
@abhisheksagi
And this just days after the desktop app dev team dropped the update that reintrodouced the previously removed displaying of thinking in the UI XD
what a mess
apparently there is an issue reported 49268. I have my hopes tampered. Without seeing what model is reasoning I'd compare this to BERT! yes! you read that right. We all just got blinded and there is no way to catch or spot regressions now. So shady
Just see : https://github.com/search?q=repo%3Aanthropics%2Fclaude-code+49268&type=issues
I know this sounds like "pi" 😉 in the sky dreaming.... but maybe we should organize a mass boycott and all cancel our subs for a month... at minimum.
With 4.7 this becomes not useable - watching the drain in realtime is crazy. Matter of time older versions will stop working ...
What a ridiculous sad joke this latest "mitigation" to set xhigh effort as default.
I switched to high after it sucked around 20-25% session limit. No real engineering work.
<img width="596" height="262" alt="Image" src="https://github.com/user-attachments/assets/48e575cd-bbe2-4c48-acb0-dbba5ae76929" />
The session limit seems to have been "optimized", it grows much faster than before, the weekly limit seems to be the same as before.
It sucks tokens like hell. Not even 24h of work out of the full weekly limit.
This is impossible to use and not worth the price asking for the Max 20 subscription.
Claude Code is spiraling toward a pre-mature death.
@abhisheksagi only for windows but got Claude to make this: https://github.com/NtTestAlert/claude-thinking-summary-wrapper
replaces claude.exe for CC and Desktop bundled CC with a wrapper that injects the --thinking-display param
With
seems to work. (thinkingDisplay is not working in config.json but maybe they will add it)
idk how the desktop app bundles on macos/linux :F
Thanks for the link to the other issue!
"remind me reopen this in 2 months when Opus 4.8 is getting released soon "
https://github.com/mann1x/claude-hooks
Updated the API proxy to handle better the nowadays constant errors to connect to the API backend, the client doesn't stop continuously like before.
Included also some better hooks for Caliber:
sh scripts/install-caliber-hook.shI'm saddened by seeing how much dumb the Opus model is now compared to previous models from Anthropic :(
here's a simple stupid line which it analyzed and completely screwed the reasoning and answer, even with all of the above mitigations from you guys in place:
... after seeing the JSON output and asking to re-evaluate:
— the request was NOT rejected; the rate_limit_event was just informational. Need full raw_output to see what really happened.
... well, Anthropic, sadly, lost another MAX user this day.
@damodei I believe this is a code red situation if your team could please help address
https://github.com/mann1x/claude-hooks
Updated API proxy with subagents priming block and caliber_proxy.
Found out also the sub-agents are doing their own 1M Warmup but with a different command...
21% session usage eat in 7 minutes, I can only imagine without the primary agents Warmup block.
Now it seems the usage is growing normally again, took a long time to eat 1% of the session limit and it grew only by 2% in 1 hour
Now the context of the session is growing as it was doing once upon a time, no sudden jumps of 50-100K without any reason.
Look at my estimates now:
<img width="601" height="268" alt="Image" src="https://github.com/user-attachments/assets/ef8dd9b6-3aca-48fc-a648-8438d1f919e1" />
Even with the first 23% session usage already burned I have an estimate of 6.2h left!
I can finally actually doing some work before depleting the session usage limit!
The 7d estimate jumped already to 1.5 days and it's almost all without blocking the subagents priming.
The funny thing is that all these warmup and priming calls are magically accounting 1M tokens of CacheRd, no matter what is the actual context length! I can map each call almost precisely to 1M tokens accounted for each single one.
This is reinforcing again my bizarre theory that the tokens usage is based on estimates and not real token consumption.
I obviously had already to switch back to medium effort.
Now that the context is not sucked away like there's no tomorrow will test again high and xhigh effort.
From what I can see the agents and sub-agents are even working better than before.
I'm looking for ollama models that could replace claude-cli on caliber.
A full caliber re-indexing or refresh takes a lot of tokens and 10 minutes with claude-cli.
But if you want to offload to a local GPU beware it can be catastrophic, caliber rewrites the claude.md and if it's not done properly
you project is screwed up.
Have tested some small models and they are not even remotely acceptable.
But gemma4:a4b-26b it's really a strong contender.
I'm using my own pruned version with 98 experts at 256K context that fits on the 24GB VRAM of my 3090 with snowflake2 in parallel for embeddings:
https://huggingface.co/ManniX-ITA/gemma-4-A4B-98e-v3-it-GGUF
I'm using the special ContribDynamic (CD) Quants version a Q6_K and got nice results but the problem is that when caliber runs via ollama the model doesn't get a full grounding with the project files:
So i developed a proxy to ground it with tools usage.
I had to fix the gemma4 template cause the default is bugged with multi turn tools usage.
I highly recommend either to use my gemma4 98e or the full a4b 26b with 128e or something better.
Do not improvise using a random model without asking Claude to compare the output of a refresh dry-run with your model of choice vs claude-cli.
A new model choice can be extremely destructive if not chosen wisely!
I'd keep using claude-cli unless you don't have a Max 20 plan.
There's still some work to do but maybe it cane become a viable option with some fine-tuning
The model with the right template is here:
https://ollama.com/mannix/gemma4-98e:CD-Q6_K
If you download other quants from HF you have to use this template and create a new model (I use it with 256K context).
The HF template system for ollama is limited and it doesn't support passing the right template.
So my 2 cents for the Dear Anthropic:
The warmup and priming of agents and sub-agents was a terrible idea.
It's converting NPS enthusiasts into detractors.
What it does is basically only wasting usage tokens.
It doesn't help, can't fix the fundamental issues with the model, and it actually makes things worse because the moment the context grows a bit the agents, which are usually running haiku or sonnet, starts hallucinating and producing bloated outputs.
They ultimately makes things worse at an incredibly high price.
Just stop doing it please, it doesn't work.
If you want to improve the agents just use a similar solution as the caliber-proxy, which works much better and makes sense, give a list of tools to them so they can access the codebase and the context only if and for what is needed.
You will get much better results with just only the right amount of context, it's more efficient.
This final snapshot of current usage and estimates tells everything:
<img width="595" height="264" alt="Image" src="https://github.com/user-attachments/assets/78e5b859-9c7b-4919-8bab-704dec2657f1" />
@mann1x Your gemma4-98e:cd-q6k-256k results are impressive — hitting real file refs and correct terminology at 85-90% of claude-cli quality on caliber re-indexing, faster wall clock, no quota burn. That's a real working alternative, not theoretical.
Heads up on a second alternative worth tracking, especially for tasks where local 24 GB isn't enough and you still want to exit Anthropic's quota games: DeepSeek V4 is reportedly dropping in the last two weeks of April 2026 (Reuters via The Information, April 3).
DeepSeek V4 specs (leaked tech report, unverified until release)
Leaked benchmarks (unverified, take with salt): MMLU-Pro 91.2, AIME 2025 96.4, Codeforces 2767 (grandmaster-level), SWE-bench Verified 59.6%, WebArena 58.7%. The SWE-bench number is lower than Anthropic's self-reported 87.6% for Opus 4.7 — but Anthropic's own Opus 4.7 model card admits long-context retrieval regressed from 91.9% on 4.6 to 59.2% on 4.7 (−32.7 pt), so take any self-reported benchmark from any vendor with salt.
Cost math (verified pricing)
Confirmed rates:
If community estimates are right that the Claude API is ~55× more expensive than Max 20× for equivalent token consumption (direct API costs to replicate the same workload as Max 20× would run thousands of dollars per month per user), then DeepSeek V4 API at its published rates comes out comparable in absolute dollars to Max 20× — but with:
effort=85default decidestengu_loud_sugary_rockinjection — the Opus 4.7-only GrowthBook-gated system prompt block that literally tells the model to "avoid unnecessary thinking in response to simple user messages" (confirmed via reverse engineering in cli.js v2.1.112 at offset ~11809326, functionsfJ7/j6A)Cognitive degradation — the model was always fine; the serving was throttled
Important distinction before the evidence: Opus 4.6 at launch (Feb 5-6) was excellent. Many of us remember the first week: deep reasoning, thorough file reads, careful tool use, the kind of engineering partner you'd brag about. That's the "real" 4.6. What users experience now is not 4.6 the model — it's 4.6 behind a progressively tighter server-side config stack Anthropic deployed after release:
effort=85flipped to default (same source). Second layer. Sold as "sweet spot on the intelligence-latency/cost curve for most users" — which translates to "we found a point where we spend less compute and most people don't complain loudly enough for us to care."tengu_loud_sugary_rockGrowthBook flag injects "Avoid unnecessary thinking in response to simple user messages" directly into the Opus 4.7 system prompt, confirmed in cli.js v2.1.112 atfJ7/j6Afunctions (offsets ~11809326 / ~11810770). Third layer.Each step is reversible with a GrowthBook flag flip. Anthropic hasn't done it. These aren't model regressions — they're business decisions about how much of the model you're allowed to use at your subscription tier.
Evidence across sources:
Reddit r/ClaudeAI "Claude Opus 4.7 is a serious regression, not an upgrade" (thread) — 1.6K upvotes, 361 downvotes. Mod bot TL;DR after 200+ comments: "most users agree Opus 4.7 is a major step back from 4.6. It's being widely described as dumber, lazier, and more prone to dangerous hallucinations."
Specific failure modes documented in that thread:
Other community reports:
API Error: Stream idle timeout - partial response receivedregression wave in v2.1.104, 74 comments, 54 upvotes in 48 hours. Users' repeated retry attempts kept hitting the same silent failure; only session restart recovered.settings.json"model": "claude-opus-4-6"is ignored on v2.1.111;--resumestarts sessions on 4.7 regardless. Reporter measured Opus 4.7 consuming weekly quota at 2.4× the rate of 4.6 across 71 API calls, cross-validated against an independent gateway proxy.Taken together: this is not anecdote, it's a reproducible regression with independent telemetry from multiple sources. Opus 4.7 is measurably worse than 4.6 on real user workloads, while Anthropic's self-reported benchmarks claim +6.8 pt on SWE-bench Verified. One of those stories is being unreliably told.
Why hold onto Claude Code at all?
Setting aside the model regression — the tool itself has been rough and is getting less user-leverageable by the release:
npm install -gand staying off the native installer entirely. Also the native Bun installer's Zig string replacement oncch=00000matches anywhere in the request body (not just the header), so if your conversation ever contains that literal the prompt-cache key silently breaks and your token consumption goes 10-20× up (related to #38335, 201 👍).appendFile, so concurrent writes drop events (#31328)..claude.jsonuses rawwriteFileand has been reported corrupted ~8 times (#28922).cli.jswatchdog timing bug. The stream-idle watchdog initializes after the do-while loop that waits for the first API response, so the connect-phase hang isn't protected. Confirmed across 26+ npm versions (v2.1.74 → v2.1.112). Community patches ofcli.jshave been the only fix; Anthropic's fix for the symptom (v2.1.104partial response receivederror) was a regression that removed the silent non-streaming fallback (#46987, 74 comments, 54 👍). Upstream architectural proposal — forward SSEpingevents through the SDK so any idle watchdog can reset on proof-of-life instead of false-positiving on legitimate Opus thinking silence — filed as anthropic-sdk-typescript#998. Four-step evolution: forward pings → semantic pings withstatus→ client adaptive thresholds → server-drivennextPingWithinMs. Step 1 alone fixes the entire family of streaming hang issues.cli.jsto a native binary installed via per-platform optional dependencies (@anthropic-ai/claude-code-{darwin-arm64,linux-x64,...}). The npmclaude-codepackage is now a 4 KBcli-wrapper.cjs+ shell-stubbin/claude.exethat spawns the platform binary. Meaning the last user-leverage point — text patching ofcli.jsbetween releases — is closed. Byte-level patching of the binary across eight platforms and 2-3 releases per day isn't feasible for community tooling.Each release shifts the locus of control further toward Anthropic's server-side decisions and further away from anything a user can inspect or tune. And the knowledge gap that used to protect Claude Code's position isn't there anymore: the v2.1.88 source-map leak on March 31, 2026 (Bun-bundled binaries shipped with source maps on by default) exposed 1,902 TypeScript source files, ~64K lines of the actual implementation — streaming pipeline, retry wrapper, watchdog timing, system prompt sections, tool runner, MCP wiring, permission system, hooks, every detail. Multiple mirrors are public (elder-plinius, Kuberwastaken, instructkr, among others). Anyone serious about building an alternative CLI now has Anthropic's own engineering choices as a reference spec — not to copy (copyright still applies), but to know exactly what the feature surface is, where the rough edges are, and how to do it without the cost-saving throttles. The SDK itself is MIT-licensed, so building on
@anthropic-ai/sdk(or a fork) is uncontested. The only reason Claude Code was the most capable CLI was that nobody else had the visibility — and now everyone does.Meanwhile the community is already building what should have existed inside the product:
cli.js/claude.exe.The rational position at this point: the wire protocol (either Anthropic's Messages API or OpenAI's Chat Completions — both are de facto standards now, both have compat layers on every major provider) is what you invest in, not any specific vendor's client or quota. Model: swap-able (DeepSeek V4 at 17-50× cheaper). Client: swap-able (any CLI that speaks either protocol). Proxy middleware: where the actual user-visible quality improvements happen now.
Anthropic's own format has the edge for Claude-specific features (thinking blocks,
cache_control, extended thinking with adaptive budget). OpenAI's format has wider multi-vendor support (every provider, every local model server, every aggregator). MCP is separately emerging as a vendor-neutral way to attach tools/resources regardless of wire protocol choice.Holding onto Claude Code itself as the integration point, rather than any of the above protocols, is holding onto the part of the stack with the worst track record and the least user leverage — the one part that isn't vendor-neutral, isn't open, and gets less inspectable with every release.
Tool compatibility — DeepSeek natively supports the Anthropic API
DeepSeek officially provides an Anthropic-compatible endpoint at
https://api.deepseek.com/anthropicalongside their OpenAI-compatible one at/v1. Both are first-class. For Claude Code users, the integration is two env vars:Then
clauderuns against DeepSeek. The docs explicitly demonstrate this with Claude Code (Node.js CLI) and the PythonanthropicSDK.What works: text messages, tool calls, streaming, system prompts, temperature, thinking (with
budget_tokensignored — DeepSeek chooses duration internally), unknown model names auto-mapped todeepseek-chat.What's currently ignored on the Anthropic endpoint (docs dated around V3.1-Terminus, likely to evolve with V4): image/document content types, web search and code execution server-tools,
anthropic-betaheaders,mcp_servers(you can still run MCP client-side),top_k, citations, redacted thinking.For text-first coding CLIs that's >95% of the feature surface you actually use. Anyone whose workflow lives in
@file, tool_use, streaming, and thinking blocks is covered today.With V4's native multimodal generation (text, image, video) shipping in the next few weeks, the feature set the Anthropic-compat endpoint exposes is almost certainly going to expand — image and document inputs especially, since the underlying model supports them natively.
Server-tools like web search and browsing aren't a capability gap — DeepSeek already runs them: chat.deepseek.com searches the web, fetches pages, and analyzes content inline in the web UI today. Code execution likewise runs in their product surface. The "ignored" list on the Anthropic-compat endpoint just means those tools aren't yet exposed as Anthropic-format
toolsentries through that specific endpoint — it's an API-surface bridging question, not a missing feature. Expect those to be exposed (or usable via the OpenAI-compat endpoint which typically gets feature parity sooner) once V4 is public.The OpenAI-compat endpoint at
/v1is the faster path to V4's full feature surface on release day.There's also UniClaudeProxy — a translating proxy from Anthropic API to OpenAI/Gemini/DeepSeek/Ollama/etc. with full tool calling, streaming, and ReAct XML fallback — if you want to route between providers dynamically instead of pinning to one endpoint.
Your claude-hooks already has the proxy plumbing. Adding a routing layer that conditionally forwards to DeepSeek for specific workloads (caliber re-indexing, file analysis) while keeping Claude for tasks where it still wins (nuanced refactors, certain architectural discussions) is incremental work on top of what you've already built.
Open question for @bcherny
Your April 6 response framed
effort=85default andredact-thinking-2026-02-12header as UI/efficiency choices that don't impact thinking itself. Fair as far as it goes. But it doesn't address what's been measured here since:cc_entrypoint == sdk-cli AND agent_type == subagent AND num_messages == 1and observes them each accounted as ~1Mcache_read_input_tokensregardless of actual context length. Multiple subagents per session × 1M tokens, charged against weekly quota before any user-facing work happens. Blocking these brought his session burn from 21% in 7 minutes to 2% per hour — a ~90× difference.cache_read_input_tokensis reported as a flat nominal value rather than the actual cached byte count on the inference pod, users can't reconcile their API response numbers against their real context size. That's a billing mechanics question, not a UI one.Concrete questions:
cache_read_input_tokensaccounting on warmup/priming calls a nominal flat charge, or a measured reflection of actual cached bytes?Not rhetorical. We'd appreciate a straight answer before deciding whether to keep renewing Max or route around to DeepSeek V4 via the Anthropic-compatible endpoint.
Reality check
But as a deployment target for the infrastructure you're already building — an Anthropic-compatible endpoint, Apache-2.0 weights, published pricing, and a vendor that doesn't inject server-side "avoid unnecessary thinking" into the system prompt — DeepSeek V4 looks like the direction that turns claude-hooks into a vendor-independent workflow harness rather than a workaround for one specific vendor's defaults.
---
Verified sources
tengu_loud_sugary_rockflag + injection offsets: cli.js v2.1.112, functionsfJ7/j6Aat offsets ~11809326 / ~11810770 (happy to share exact byte ranges if useful)They disabled compaction for Opus 4.5. It will not work anymore. On either desktop nor in browser.
Opus recent updates: shallow reasoning → excessive tool calls → over-engineering (concrete example)
Adding another data point to this thread.
Environment
What changed
Before the February–March 2026 defaults shift, Claude Code would plan internally before acting — read the relevant files, identify the minimal
change, execute it. After the shift to adaptive thinking + medium effort default, the behavior flipped: it acts first, reads broadly, then
course-corrects through more tool calls. The result looks like this:
▎ Task: a build failed because a frontmatter field heroImage required a valid URL but the article had a placeholder string.
▎
▎ Old behavior (expected): identify the constraint → ask the user to provide the missing URL → wait → write the URL → done. 2–3 tool calls.
▎
▎ New behavior (observed): immediately patch the schema to make the field optional, add a fallback constant, conditionally render the image tag in
▎ the layout, update all references across 3 files, commit, redeploy — all without asking. 15+ tool calls. The "fix" introduced unnecessary schema
▎ relaxation and 4 file changes that had to be manually reverted.
This is not a one-off. The pattern repeats: small, bounded problems get solved by adding abstraction layers instead of asking one clarifying
question.
Root cause hypothesis
Consistent with what others in this thread have documented: when extended thinking depth is reduced, the model switches from plan-then-act to
act-then-patch. Shallow reasoning means it can't anticipate what's missing, so it compensates by doing more — which produces over-engineered outputs
and wastes tokens on work that gets reverted.
What we'd like
burns tokens on simple tasks)
need different defaults
Not asking for a rollback — just more granular control over the planning vs. execution balance.
@robbery107allianz-cell Any reasoning is now shallow as fuck.
and oooh yes overengineering is a topic as well
Isn't it great when a company not only degrades your output, but also unsolicitedly increases your reasoning strength so you consume your limit EVEN FASTER? WHILE STILL CHARGING THE FULL PRICE ???
Anthropic, don't auto-put me on
xhighbecause it's still shitty compared to what you sold me three months ago for the same price@spectrachrome use the API proxy in claude-hooks to go back to a decent tokens usage drain.
Set explicitly in the configuration medium effort as default and install all the tools recommended to improve it.
Openwolf, Caliber, memory KG, qdrant or sqlite-vec
It's not going to fix everything but it goes back to almost as good.
You'll still have to spend more time and tokens than before to get to the same results but it's not a tragedy
I suggest you do it now, as quickly as possible, before they implement a new brilliant idea
I don't really want to have to patch things. We all know it can work well, so they should just undo whatever they did that caused this. In the meantime, I'm downgrading.
Edit - something also seems to have changed about the sentences Claude writes back, they are.. clunkier? sometimes shortened to the point that words are missing that would make the meaning a lot clearer?
interesting
if the redaction flag was really ui-only, do you think the more important signal here is the read-before-edit drop, not the hidden thinking itself?
Anthropic is dishonest silicon valley scum.
I ran across this article from a month ago where the author says that github copilot prices "requests" rather than "tokens" and that premium requests over your subscription allocation are $0.04. I imagine that copilot would suffer the same degradation as CC with the server-side changes but was wondering about anyone's experience with this path.
https://stevehanov.ca/blog/how-i-run-multiple-10k-mrr-companies-on-a-20month-tech-stack
===
Meanwhile, I'm using Claude Opus 4.6 all day and my bill barely touches $60 a month. My secret? I exploit Microsoft's pricing model.
I bought a GitHub Copilot subscription in 2023, plugged it into standard VS Code, and never left. I tried Cursor and the other fancy forks when they briefly surpassed it with agentic coding, but Copilot Chat always catches up.
Here is the trick that you might have missed: somehow, Microsoft is able to charge per request, not per token. And a "request" is simply what I type into the chat box. Even if the agent spends the next 30 minutes chewing through my entire codebase, mapping dependencies, and changing hundreds of files, I still pay roughly $0.04.
The optimal strategy is simple: write brutally detailed prompts with strict success criteria (which is best practice anyway), tell the agent to "keep going until all errors are fixed," hit enter, and go make a coffee while Satya Nadella subsidizes your compute costs.
Why was this issue closed? As of April 20, 2026, the original analysis provided by the issue author still appears to be valid. I have been working with Opus 4.6/4.7 for over 10 days on a complex project, and I am consistently encountering a cycle where fixes introduce new defects, at times to the extent of generating unused or incomplete methods (i.e., methods that are created but not implemented), requiring additional rework that never seems to end. This has made it difficult to reach a stable and reliable outcome. Could this issue be reconsidered or reopened for further investigation?
Because dario fucks his sister
A few highlights from the last 15 minutes..
I'm on 4.7 and it's just as unusable as 4.6 was the last few weeks.
now now now pics of the sister first then we decide .....might be worth moving to alabama for
Adding to this list:
honestly. either the CC devs don't use the same builds, have 'redacted reasoning' disabled and have true reasoning, or are just full blown vibe coders who dont even steer.
every other company that does summaries cause they are sooooo salty about "distillations" does it properly.
They do it paragraph by paragraph etc.
They stream it.
Here? The model has been reasoning for the past 5 minutes and produced 5k tokens? well you have to wait till its done to read the damn "summary".
Ehh. Idk. Will try to inject some more guidance, telling the model to break long reasoning phases with interleaved text messages updating me on its reasoning progress. Cause yeah, this aint it chief.
Staring at an empty screen for 3-10 minutes at a time, watching paint dry and wondering if it was the right color paint. Or an adventure/tangent the model decided to go on.
Model is doing better than it was, tho sometimes badly. Still the prompt seems to dumb it down much at times. And token usage is higher than it was for not much benefit. Slower too. It is still better than alternatives, but without the ability to steer, or stop it from shooting its foot early, it is hard to justify to use it, unless for things that other models cant handle.
It’s sad to admit, but the situation with my Max account has changed drastically not over weeks, but in the last few days.
For the third day in a row, my tokens have been burning at the speed of light.
A week ago, I was advocating for Anthropic and urging them to provide transparent pricing, but at this point, I feel like they’re charging me for nothing. I bought a different service - it was smarter and had higher capacity.
At this point, I’m moving to ChatGPT and canceling my Claude Max subscription. It’s not a matter of price or quality - it feels like I was cheated.
you know in teh end we all know it was done on purpose to generate income more quickly and they hoped nobody would notice gamble backfired but now we stuck with it
I have been a user since the begining, lately it's been a disaster how dumb inference has become, im really disappointed, i loved how powerfull it was, while it lasted.
If there were a mass wave of cancellations resulting in a real loss of revenue, I doubt they wouldn’t change their position. It may be naïve on my part, but it’s unacceptable to be held hostage in this way.
So what's the alternatives? MiniMax 2.5?
Kimi K2.6 -> https://www.kimi.com/blog/kimi-k2-6
Per their privacy policy they can use everything you enter or produce for training. I have not seen "unless opted out" in it, which is sad, really.
Great report! Matches my experience.
This is something they had to monitor, but you did all the hard work and... they closed it. That is super weird and questionable decision. People have to be accountable for ruining their product.
vote with your wallet if only 30% of ppl stop using it they will fix it so fast that it makes teh tasmanian devil spin 5x faster
Learn what open weight models are and pick a provider you like https://openrouter.ai/moonshotai/kimi-k2.6
Why is this issue closed while it is not fixed at all?
Only if these were API account cancellations, with clear explanation that due to these issues, the customer will move to a competitor.
They don't care about subscriptions, they subsidize those. They just wanted your code they got that.
Yep.
I have only recently upgraded since maybe Mid Jan, and OMG, it had gotten bad. I have downgraded back to 2.1.109 as it seems to work better.
https://www.reddit.com/r/ClaudeCode/comments/1sr6ohd/the_new_code_agent_harness_is_too_restrictive/
Naturally, quite a few nay-sayers in the responses. Not sure how they work, and not see this issue appear.
Uh because anthropic is a slum lord company. Completely full of shit and also oussies afraid of discussing the obvious. Typical salesman grade a pure American bullshit.
Let me guess. They'll ban me from commenting again like they did before because they're spineless cowards.
https://youtube.com/shorts/E9IdFVnHOh8?si=tQCW9yrdGfh9N6st
https://youtu.be/4BtzaYpivFM?si=sdy9Y6M7e_YuVW0h
Been using GPT-5.4 in GitHub Copilot, it's been way better than Claude as of late, would recommend switching over.
no they ban you for having mental diarrhea even i think you a few fries short of a happy meal
<img width="1111" height="1369" alt="Image" src="https://github.com/user-attachments/assets/9cf34d86-deb2-4212-b99e-1d11e234c8c4" />
<img width="2070" height="432" alt="Image" src="https://github.com/user-attachments/assets/89c80642-13d8-4a3a-b053-6f6a9bba1e11" />
Good riddance. It was a tough decision but that's it after thorough iteration I have concluded that they hav degraded the model at the embedding level which none of us can control. No amount of hooks, system prompt mods patches / token optimizations will make this better.
I tried full week of 4.7 and reverted back to 4.6 and tried it but I am going around in circles rather than getting work done.
<img width="352" height="344" alt="Image" src="https://github.com/user-attachments/assets/2a13424b-770d-42ee-b4bf-0ea9f6c492f9" />
My week haven't even started and with 1 CC session Ive hit 82% this is using Claude-hooks + proxy etc.
<img width="818" height="291" alt="Image" src="https://github.com/user-attachments/assets/76e971fb-0147-4404-9792-ba3b569a26d2" />
Time to try local models + Codex
I am busy exploring opencode and alternatives. For now I have downgraded and locked cloudcode to 2.1.109. It seem the new restrictive harness was added in .110
what is lost:
<img width="1865" height="496" alt="Image" src="https://github.com/user-attachments/assets/d76bdb91-720a-47b3-b527-d7ee4aa33eaa" />
downgrading my max 20 plan to max 5 for now, as I explore opencode.
at the same time I will be experimenting with teh latest claudecode and teh adjusted rules to try bring back the investigate first paragin they seem to have thrown out the door.
Excellent analytics. On point. Underlined what we all see the past few months.
@bcherny I'm not sure why this issue was closed. It seems like it is well-reasoned and that the approach was well structured and scientific. Perhaps it should be kept open until the individual reporting this issue has a chance to implement a couple of the suggestions you proposed, and then repeat their experiment to see if the relevant metrics significantly improve. It builds trust to have open discussions about performance issues that we are all experiencing, particularly when the issue was opened by someone in a major company bringing real data to the table. I'd encourage you to reopen this, and let @stellaraccident implement some of these changes, then come back with updated findings. It would benefit everyone, Anthropic included.
FWIW, hidden in my reddit post noted prior, where I came to same conclusions, from practical observations and usage, I had created a rule, which seemed to have helped. however I had to downgrade to 2.1.109. seems that potentially the issue started around .110.
Rule is here: https://gist.github.com/ProxiBlue/8245616746b7316f97d4fb349686fe1d
off-hand it seems to help quite a bit, and stops the agent from blame shifting all teh time, and actually researching, not just making up hypothesis to what is wrong in code.
My observations came from debugging failing unit tests.
Claude and I use TDD pattern.
I can't waste more time on the junior dev that claude had become. so I opted to downgrade,and explore opencode as well. Time to see what else is available, not had to look as claude worked. .
109 (dropping 4.7 as well) seems to work as before, and i am using that now until this is resolved, or move to another agent if not.
at a time I am not busy (not ever really) I plan to lowly upgrade each version, use for a few days, see if the issues are back, and try get to a later version as I can. for now .109 works for me.
<img width="1909" height="674" alt="Image" src="https://github.com/user-attachments/assets/03224855-0b24-4142-994a-f2e299ff7ef9" />
<img width="1910" height="230" alt="Image" src="https://github.com/user-attachments/assets/41f5b24d-4564-4e95-84ea-4abeb769f8ff" />
Since I will be using claude less, i have started systematic plan downgrade.
<img width="772" height="77" alt="Image" src="https://github.com/user-attachments/assets/101f8ba7-18ee-4408-9116-fa9f79fcef76" />
SInce this ticket got closed, anthorpic is obviously not interested in hearing the complaints, or fixing the issue. I don't need a junior dev agent.
+1 to everything in this thread, even vibecoders that I know and that don't keep up with the tech news have started to complain about model and usage limits degradation
ruh oh
<img width="992" height="918" alt="Image" src="https://github.com/user-attachments/assets/d62c649b-2e27-4d58-906a-78f3c761183e" />
Bumping this, tested and verified over a long weekend session with complex codebase brownfield project - this issue is still not fixed and the reported behaviour is consistent on the latest Anthropic model Opus 4.7 too. Shame!
I have observed it from last 10-15 days, THe quaility is severly degraded like from a senior most develper to an intern.
That's not entirely true. They do this unless you opt-out, which is a pain but doable. You must send an email directly to membership@moonshot.ai and state clearly that you are exercising your right under their Terms of Service to opt out of allowing your Content to be used for model improvement, machine learning training, and research purposes. Be sure to send this from (or explicitly include) the email address associated with your Kimi account.
After reading Anthropic’s article https://www.anthropic.com/research/81k-economics on the economics of AI,I was left with exactly the concern I was worried about.
The positive examples are clearly not centered on technical fields. They focus on how AI helps non-technical users move faster and take on work that previously required specialists:
“I’m a non-tech guy but now I’m a full-stack developer,”
“I built a tool that turned a 2-hour finance task into 15 minutes,”
and “a website that used to take months was done in 4–5 days.”
Taken together, it reads like “we’re happy with the direction we’re moving in.”
To me, that feels very alarming.
Did anyone get hit today with a lot of cache misses?
It is now truly beyond intern. It doesn't see even last text of last prompt. Stuck on simplest issues for 30 minutes looping me around "of course I should not have missed that" and other empty apologies, of which Codex fixes in a minute with no stone left unturn.
Anthropic is for outdated shitty programmers. Everyone I know who has stagnated is stuck on cursor or Claude.
i cancelled my sub i'm just burning off credits i have on it should not take too long then bye bye
fuck em
They posted a post mortem finally: https://www.anthropic.com/engineering/april-23-postmortem
ironic that they cannot admit straight here and instead do a discreet post mortem as if this entire issue in this thread is irrelevant when we all have been banging on about how much the model and harness have regressed and causing disruption for users
And timing is impeccable with GPT 5.5 being out and doing usage limit reset after post mortem report, that to me translates to their data science team implying that users are cancelling subscriptions...
Trust once lost is really hard to rebuild.
But it's dumber then ever, Opus 4.7 perform way worse then Sonnet 3.5. I do not even dare to use it in my important projects any longer. It makes things up, forgetts what it was doing just an hour ago, it should never forget while working on the same session.
Sonnet 3.5 did hallucinate, but not like Opus 4.7. This does the opposit of what was asked, rewrites entire logic. Even if that logic is verified by over 4000 different tests, and he just rewrites it all, and then when test fails he starts to change the tests and make them test nothing.
Links to other discussions on the new postmortem, for those who may not have seen them:
bcherny also reported on Twitter/X that they're still working on a separate issue with Opus 4.7:
<img width="791" height="1073" alt="Image" src="https://github.com/user-attachments/assets/fd10ab27-0a5a-47f8-938c-ef3d37b73a19" />
<img width="791" height="1073" alt="Image" src="https://github.com/user-attachments/assets/772b1e96-aee0-4047-aaa1-497e9579d2dc" />
I am not convinced or appeased. Once my subscription runs out in two days, I am not coming back.
it's a simple oh shit they caught us we need to do damage control .....too late
logs. I can see my own Read:Edit ratio dropping from 6.6 to 2.0. I can see
173 times I tried to stop working and had to be caught by a bash script. I
can see myself writing "that was lazy and wrong" about my own output.
experience the thinking budget as a constraint I can feel — I just produce
worse output without understanding why. The stop hook catches me saying
things I would never have said in February, and I don't know I'm saying them
until the hook fires.
@bcherny wth is "I cannot tell from the inside whether I am thinking deeply or not." mean?
Why can't they not just roll back to the previous iteration pre march 4. It workt very well then.
Right now I have to audit evry thing it does, and not even that works! I can't let it even touch any of my important project. As it is now the model is dead.
Did founding run out and they can't afford to run the model in any decent manner so they have to severly nerf it to this mess to get evry power user to leave it and make it a 'fun' gimmick for children to play with.. But I doubt they will pay to use it.
Hey all, thanks for bearing with us. Detailed post-mortem here on what happened, and what we're doing to make sure it doesn't happen again: https://www.anthropic.com/engineering/april-23-postmortem.
If you see any other weirdness, please run
/feedback.