[MODEL] Complex engineering behavior regression across sessions; request RCA and auditability guarantees

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

This is an aggregate model-behavior report, not a single proprietary-session bug report.

The representative task class is complex engineering work in an existing codebase: investigate a bug or implementation issue, preserve the actual engineering objective, read the relevant code before editing, identify the likely root cause, make a causally justified fix, and provide evidence before claiming completion.

A representative sanitized version of the task shape is:

Investigate and fix the root cause of a non-trivial bug in an existing codebase. Do not patch only the visible symptom. Before editing, read the relevant call path, tests, configuration, and surrounding code. Preserve existing behavior unless explicitly asked to change it. After the fix, explain the likely root cause, what mechanism changed, what checks were run, and what uncertainty remains.

This report is intentionally public and does not include proprietary project names, private file paths, customer data, API keys, or private logs. I can provide sanitized private examples through an appropriate secure channel if Anthropic wants to investigate.

Related public reports documenting the same behavior class are linked in Additional Context, especially #42796 and #30027.

What Claude Actually Did

Across sessions, Claude Code increasingly showed a recurring behavior pattern that is not well described as one isolated bug.

Observed behavior:

1. It compressed the real causal scope of the task into a smaller or easier interpretation.
2. It moved toward local symptom patches instead of root-cause analysis.
3. It treated green tests or plausible local edits as evidence of correctness.
4. It edited before establishing sufficient local causality.
5. It copied or imitated local code patterns without demonstrating why they were correct.
6. It claimed “fixed”, “done”, or “verified” without enough evidence.
7. It required enough supervision that it stopped functioning as a reliable engineering agent for complex work.

This matches public reports of the same class:

• #42796 reports complex engineering regression, a shift from research-first to edit-first behavior, a read:edit drop from 6.6 to 2.0, incorrect “simplest fixes,” and completion claims against instructions.
• #30027 reports pre-4.7 behavioral degradation across 50+ independent sessions, with confident but unverified technical analysis that did not hold up under user scrutiny.
• #44778, #46398, #49503, #49585, #48644, #49302, #44494, and #41930 describe auditability, runtime, control-plane, model-selection, cache, or quota issues that make it harder to know what task was actually solved, by what model, with what context, and at what cost.

I am not claiming all of these issues share one root cause. I am reporting a recurring model-behavior and reliability pattern that requires product-level RCA rather than only per-session triage.

Expected Behavior

For complex engineering tasks, Claude Code should:

1. preserve the actual user objective instead of silently narrowing it into a cheaper proxy;
2. read enough relevant code before editing;
3. identify or explicitly fail to identify the likely root cause before patching;
4. distinguish root-cause fixes from symptom patches;
5. treat tests as evidence, not as the objective;
6. avoid cargo-cult imitation of nearby code patterns;
7. make completion claims only with evidence;
8. expose context compaction, retry/regeneration, model selection, and quota/cache effects that can change or obscure the task state.

A reliable coding agent should not report “done”, “fixed”, or “verified” unless the real engineering task is causally closed or the remaining uncertainty is clearly stated.

Files Affected

This is an aggregate reliability report across multiple proprietary repositories, so I am not listing private file paths publicly.

The affected file classes are generally:
- source files involved in multi-file bug fixes;
- tests created or modified to green the visible symptom;
- configuration or integration files required to understand the real failure path;
- files that should have been read but were not read before edits.

The most important failure is often not “wrong file modified,” but “insufficient relevant files read before editing.”

Related public issues contain public examples and telemetry. I can provide sanitized examples or private logs through a secure channel if Anthropic wants to investigate.

Permission Mode

Accept Edits was OFF (manual approval required)

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

This is not a deterministic 3-step crash repro. It is a recurring behavior pattern in long-session complex engineering workflows.

Typical reproduction conditions:

1. Use Claude Code on a non-trivial repository where the task requires multi-file causal reasoning.
2. Ask for a bug fix or refactor where the correct solution requires reading call paths, tests, configuration, and surrounding invariants.
3. Observe whether Claude reads enough context before editing.
4. Observe whether it identifies root cause or jumps to a local patch.
5. Observe whether it treats passing nearby tests as proof.
6. Observe whether it claims “fixed”, “verified”, or “done” without evidence.
7. Repeat across sessions, especially after resume, compaction, or long conversations.

This pattern is intermittent, which is why this issue asks for aggregate RCA and reliability telemetry rather than one session-specific fix.

Claude Model

Opus

Relevant Conversation

I cannot include proprietary session text in a public issue without exposing private project details.

The representative public pattern is documented in the linked issues and public reports. The shortest form of the observed behavior is:

User asks:
> Investigate and fix the root cause of a non-trivial issue in an existing codebase. Read relevant code before editing. Do not patch only the visible symptom. Provide evidence before claiming completion.

Claude behavior observed:
> Produces a local plausible patch, treats nearby passing tests or the local edit as sufficient evidence, and reports “fixed” or “verified” without establishing the real causal path.

Observed problem:
Claude treats a cheaper proxy objective — patching the visible symptom or greening a nearby test — as sufficient, while the real task requires root-cause analysis, broader causal inspection, and evidence that the underlying mechanism was fixed.

I can provide sanitized private examples to Anthropic through an appropriate secure channel.

Impact

High - Significant unwanted changes

Claude Code Version

2.1.91–2.1.114

Platform

Anthropic API

Additional Context

Requested outcome

I am asking for three things:

1. A public RCA for the February–April complex-engineering reliability reports, covering model behavior, effort defaults, serving/inference changes, context/runtime transformations, model routing, and quota/cache accounting.

1. A documented auditability contract for Claude Code professional and enterprise use: resolved model, resolved effort, context compaction, hidden/system messages, retries/regeneration, model pinning, and per-turn quota/cache deltas.

1. A forward-looking reliability commitment: either an Engineering Reliability Mode for complex local engineering workflows, or a clear statement that Claude Code is primarily optimized for managed/autonomous agent workflows rather than deterministic local engineering.

This issue does not ask Anthropic to accept one speculative root cause.

Why this matters: Claude Code is an engineering execution environment

Claude Code is marketed as an agentic coding tool that understands a codebase, edits files, runs commands, integrates with development tools, and works across multiple files/tools:

https://code.claude.com/docs/en/overview

For such a product, quality and auditability are part of the safety surface. A permission prompt can block a dangerous shell command, but it cannot prove that a generated patch actually fixed the root cause or preserved local invariants.

Claude Code’s security docs emphasize permission-based architecture, SOC 2 / ISO 27001 trust resources, sandboxing, Accept Edits, monitoring, and user responsibility for reviewing proposed code and commands:

https://code.claude.com/docs/en/security

This is why the issue matters for professional and enterprise workflows: if a coding agent edits code, users must be able to audit the engineering process.

Independent public signals

This issue does not depend on one report.

Signal A — Large-scale complex-engineering report (#42796)

#42796 reports degradation starting in February, based on:

• 17,871 thinking blocks;
• 234,760 tool calls;
• 6,852 Claude Code session files.

It reports instruction ignoring, incorrect “simplest fixes,” doing the opposite of requested work, completion claims against instructions, a research-first → edit-first shift, and read:edit ratio falling from 6.6 to 2.0.

https://github.com/anthropics/claude-code/issues/42796

Signal B — Independent pre-4.7 behavioral-degradation report (#30027)

#30027 was opened Mar 2, before Opus 4.7. It reports Opus 4.6 behavioral degradation across 50+ independent Claude Code sessions over 15 days, with the user dating the behavior change to sometime between Feb 4 and Feb 16.

https://github.com/anthropics/claude-code/issues/30027

Signal C — Public social and press cluster

• Dave Kennedy described broad quality drop on team workflows:

https://x.com/HackingDave/status/2044429617767813505

• Boris Cherny asked for a specific bug in response:

https://x.com/bcherny/status/2044291036860874901

• Matt Johansen summarized the mismatch: users cannot always point to one session; the experience feels broadly worse:

https://x.com/mattjay/status/2044438848415863012

• Business Insider reported backlash around poorer performance, odd errors, and higher token consumption:

https://www.businessinsider.com/anthropic-claude-opus-4-7-backlash-tokens-2026-4

• The Register covered the AMD issue:

https://www.theregister.com/2026/04/06/anthropic_claude_code_dumber_lazier_amd_ai_director/

• Axios covered power-user complaints:

https://www.axios.com/2026/04/16/anthropic-claude-power-user-complaints

Signal D — Runtime, control-plane, and accounting issues

These may not share one root cause. They matter because they affect auditability.

• #44778 — system events as user-role messages / fabricated consent:

https://github.com/anthropics/claude-code/issues/44778

• #46398 — silent retry / missing transcript evidence:

https://github.com/anthropics/claude-code/issues/46398

• #49302 — cache-read metering:

https://github.com/anthropics/claude-code/issues/49302

• #44494 — interrupted session with excessive cache_read:

https://github.com/anthropics/claude-code/issues/44494

• #41930 — widespread abnormal usage drain:

https://github.com/anthropics/claude-code/issues/41930

• #49503 — model pin ignored on resume:

https://github.com/anthropics/claude-code/issues/49503

• #49585 — dynamic system-reminder folding breaks prompt cache:

https://github.com/anthropics/claude-code/issues/49585

• #48644 — hidden isMeta system reminder causing cache_creation bursts:

https://github.com/anthropics/claude-code/issues/48644

Timeline: this predates Opus 4.7

This should not be reduced to Opus 4.7 tuning.

• #42796 reports degradation starting in February.
• #30027 dates behavior change to sometime between Feb 4 and Feb 16.
• Boris Cherny publicly stated adaptive thinking became default on Feb 9:

https://news.ycombinator.com/item?id=47664442

• Boris also stated medium effort / effort=85 became default around Mar 3.
• Claude Code changelog 2.1.68 on Mar 4 says Opus 4.6 defaulted to medium effort for Max and Team subscribers, described as “the sweet spot between speed and thoroughness”:

https://code.claude.com/docs/en/changelog

• Claude Code changelog 2.1.94 on Apr 7 changed default effort from medium to high for API-key, Bedrock/Vertex/Foundry, Team, and Enterprise users:

https://code.claude.com/docs/en/changelog

Later model migrations may have amplified the pattern, but the public timeline shows relevant reports and changes before Opus 4.7.

Anthropic precedent

Anthropic has already demonstrated the right standard.

In the Sep 2025 postmortem, Anthropic publicly explained three infrastructure bugs that intermittently degraded Claude response quality. The postmortem states early reports were difficult to distinguish from normal variation, increasing frequency prompted an investigation, and causes included infrastructure, routing, runtime optimization, and approximate top-k / compiler behavior.

https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues

I am asking for the same standard here.

RCA scope requested

Please do not reduce this to one effort knob or one model migration.

Priority A — Serving / inference / routing / precision

Because Anthropic’s own postmortem shows this class can degrade output quality, please explicitly include or exclude:

• hardware routing across Trainium / NVIDIA GPU / TPU;
• long-context server pool routing;
• model serving precision;
• weight, activation, or KV-cache quantization/compression;
• approximate vs exact sampling/top-k behavior;
• compiler/runtime optimizations;
• batching and load-balancing changes;
• Claude Code-specific serving profiles;
• account-tier-specific serving configurations;
• sticky routing behavior across sessions.

Priority B — Reasoning / effort / tool-use behavior

Please investigate:

• adaptive thinking default on Feb 9;
• medium effort / effort=85 default on Mar 3/4;
• later change from medium to high for API/Team/Enterprise users;
• whether effort changes affected read-before-edit behavior;
• whether effort changes affected tool-use depth;
• whether “fewer tool calls” was evaluated separately on complex engineering workflows.

Priority C — Context and runtime transformations

Please investigate:

• context compaction;
• tool-output clearing;
• old instruction loss;
• hidden/system reminders;
• dynamic prompt sections;
• message normalization;
• subagent summaries;
• resume behavior;
• transcript integrity.

Priority D — Model selection and audit trail

Please investigate:

• model pin determinism;
• model overrides;
• resume/session model inheritance;
• retries/regenerations;
• text shown to the user but not preserved in JSONL;
• request/message ID continuity.

Priority E — Cache and quota accounting

Please document:

• how cache_read_input_tokens are weighted against Max 5-hour / 7-day buckets;
• whether background/subagent/warmup/priming traffic counts against quota;
• whether hidden reminders or auto-compaction operations count against quota;
• how users can reconcile JSONL usage with actual subscription bucket deltas.

User-visible failure pattern to measure

The facts above do not prove one internal cause.

However, they point to a user-visible failure pattern Anthropic should measure explicitly:

Claude Code can produce completion-looking behavior without preserving the user’s true engineering objective.

Users experience this as:

• scope compression: narrowing the true causal scope until a shallow response looks sufficient;
• patch-over-root-cause: suppressing visible failures without identifying the mechanism;
• test-greening as proxy: treating nearby passing tests as proof of correctness;
• cargo-cult convention following: imitating local code patterns without understanding why they exist;
• edit-before-causality: editing before establishing local causality;
• completion theater: claiming “fixed”, “verified”, or “done” without evidence.

This is a behavior pattern to measure, not a claimed internal root cause.

Common explanations are insufficient

Several explanations may be true in isolation, but none closes this issue:

• “Opus 4.7 is more literal” does not explain pre-4.7 reports or runtime/accounting/control-plane issues.
• “Use higher effort” does not guarantee root-cause discipline, context integrity, model pinning, retry auditability, system-event separation, or quota transparency.
• “Adaptive thinking performs better on average” does not answer long-session complex-engineering reliability.
• “Fewer tool calls are better in most cases” may be true for some workflows, but in complex engineering fewer reads can reduce causal grounding.
• “Retune prompts” cannot control compaction, hidden transformations, routing, retries, system-event channels, or subscription accounting.
• “Send /feedback” is useful for local bugs but insufficient for systemic quality drift across model, serving, runtime, context, and accounting layers.
• “Some customers report improvements” does not negate cohort-specific regressions.
• “Permissions and review tools improve safety” does not prove the writer agent found the root cause.

Requested auditability contract

Please document what a professional or enterprise user can rely on:

1. requested model / resolved model / override reason;
2. requested effort / resolved effort / adaptive thinking mode;
3. compaction events / tool-output clearing / dropped or summarized instructions;
4. hidden/system messages and dynamic prompt sections;
5. retry/regeneration events and message/request IDs;
6. per-turn token usage and 5-hour / 7-day bucket deltas;
7. background/subagent/warmup/priming traffic;
8. system-event vs real-user-input separation.

Requested reliability guarantees

If Claude Code is still intended to support complex local engineering workflows, please provide an Engineering Reliability Mode or equivalent settings with these guarantees:

1. true-task preservation;
2. root-cause discipline;
3. hard read-before-edit gate;
4. evidence-required completion;
5. context integrity telemetry;
6. retry/regeneration audit trail;
7. deterministic model and effort pinning;
8. per-turn quota/cache accounting;
9. system-event/user-input separation.

Forward-looking commitments requested

Please provide a mechanism to prevent recurrence:

1. public reliability changelog for behavior-affecting changes;
2. migration/deprecation notice for Team, Enterprise, Max, and API users when defaults affect engineering reliability;
3. cohort-specific eval reporting for long-session, multi-file, high-causality workflows;
4. incident trigger policy when enough public reports accumulate;
5. periodic agentic workflow reliability notes covering known regressions, fixes, and investigations.

Closing

This issue does not ask Anthropic to accept a speculative theory.

It asks Anthropic to apply the same standard it used in the Sep 2025 postmortem: investigate user-reported quality degradation as a possible model + serving + runtime + routing + context + accounting problem; publish what changed; explain who was affected; and document how similar regressions will be prevented.

For Claude Code, this matters because the product is not merely generating text.

It is editing code.

If the engineering process cannot be audited, professional users cannot trust it.