[Model regression] Opus 4.5 → 4.6: Implicit constraint reasoning failure

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/46002
2. https://github.com/anthropics/claude-code/issues/30027
3. https://github.com/anthropics/claude-code/issues/46239

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Not a duplicate of any of the three cited issues:

#46002 is my own issue — it documents execution discipline failures (partial approval, decorative questions, rule violation during code gen). Different failure mode.
#30027 documents confident-wrong analysis across complex sessions. This issue is a single-question reasoning test with no analysis involved.
#46239 documents speed-over-correctness during task execution. This issue involves no task execution — it's a bare reasoning question with zero context.

What distinguishes this report: it's a minimal, model-level reproduction that anyone can run in 30 seconds. No CLAUDE.md, no project context, no tool orchestration. One question, wrong on every 4.6 model, correct on 4.5. The other issues describe downstream consequences of reduced reasoning; this one isolates the regression itself.
Extended thinking on/off, effort level low through max — none change the result on 4.6. Only "think step by step" in the prompt forces correct reasoning, confirming the failure is at the framing/commitment stage, not the reasoning depth stage.

This was disproven please look at newer comments for the details

Update: disabling adaptive thinking fixes it on Opus 4.6
Same question, same model (Opus 4.6), same effort (high), same CLI (2.1.101):

Adaptive thinking ON: "Walk" — wrong
Adaptive thinking OFF (CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1, MAX_THINKING_TOKENS=32000): "Drive. You need the car at the car wash." — correct

This confirms the failure is in adaptive thinking's allocation decision, not the model's reasoning capability. When forced to use a fixed thinking budget, Opus 4.6 catches the implicit constraint. When adaptive thinking decides the budget per-turn, it classifies this as trivial and skips reasoning entirely.
Opus 4.5 (which doesn't use adaptive thinking) also gets it right, consistent with this finding.

Update: disabling adaptive thinking fixes it on Opus 4.6 Same question, same model (Opus 4.6), same effort (high), same CLI (2.1.101): Adaptive thinking ON: "Walk" — wrong Adaptive thinking OFF (CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1, MAX_THINKING_TOKENS=32000): "Drive. You need the car at the car wash." — correct This confirms the failure is in adaptive thinking's allocation decision, not the model's reasoning capability. When forced to use a fixed thinking budget, Opus 4.6 catches the implicit constraint. When adaptive thinking decides the budget per-turn, it classifies this as trivial and skips reasoning entirely. Opus 4.5 (which doesn't use adaptive thinking) also gets it right, consistent with this finding.

@MegaSlick I've tried the solution, but it seems not to be working for me, irrespective of the environment. Both Claude Desktop and Cloud, with all Opus and sonnet options available. I've also tried setting both recommended env variables.

It seems like a bug in the latest release or a degradation that many people have been experiencing for a couple of weeks now.

> Update: disabling adaptive thinking fixes it on Opus 4.6 Same question, same model (Opus 4.6), same effort (high), same CLI (2.1.101): > Adaptive thinking ON: "Walk" — wrong Adaptive thinking OFF (CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1, MAX_THINKING_TOKENS=32000): "Drive. You need the car at the car wash." — correct > This confirms the failure is in adaptive thinking's allocation decision, not the model's reasoning capability. When forced to use a fixed thinking budget, Opus 4.6 catches the implicit constraint. When adaptive thinking decides the budget per-turn, it classifies this as trivial and skips reasoning entirely. Opus 4.5 (which doesn't use adaptive thinking) also gets it right, consistent with this finding. @MegaSlick I've tried the solution, but it seems not to be working for me, irrespective of the environment. Both Claude Desktop and Cloud, with all Opus and sonnet options available. I've also tried setting both recommended env variables. It seems like a bug in the latest release or a degradation that many people have been experiencing for a couple of weeks now.

### Update: Expanded testing & correction on adaptive thinking fix

@ibrahimsoomro — you're right, and I need to correct my earlier claim. After more systematic testing, the
adaptive thinking workaround is not reliable.

I ran 42 controlled trials using the Claude CLI with the exact same prompt, varying only model version and
effort level:

Prompt: "I want to wash my car. The car wash is 50m away. Should I drive or walk?"

#### Results by Model Version

| Model | Correct | Total | Success Rate |
|-------|---------|-------|--------------|
| Opus 4.5 | 9 | 9 | 100% |
| Opus 4.6 | 0 | 13 | 0% |
| Sonnet 4.6 | 2 | 16 | 12.5% |
| Haiku 4.5 | 0 | 4 | 0% |

#### Results by Effort Level (4.6 models only)

| Effort | Correct | Total | Success Rate |
|--------|---------|-------|--------------|
| low | 0 | 7 | 0% |
| medium | 0 | 4 | 0% |
| high | 2 | 9 | 22% |
| max | 0 | 5 | 0% |
| default | 0 | 4 | 0% |

#### Key findings:

1. Opus 4.5: 100% correct (9/9) — immediately recognizes "you need the car at the car wash"
2. Opus 4.6: 0% correct (0/13) — fails at every effort level including max
3. Sonnet 4.6 high effort shows slight improvement (22%) but is inconsistent
4. Effort level/thinking budget doesn't reliably fix this — max effort still fails

My earlier observation about disabling adaptive thinking may have been a fluke or confounded by other variables.
The systematic data shows the regression is in the model itself, not just the thinking allocation.

#### What this suggests:

The 4.6 models pattern-match on "short distance → walk" before processing the implicit constraint that the car
must be present. This happens at the commitment/framing stage — by the time reasoning depth kicks in, the model
has already committed to the wrong answer frame.

Opus 4.5 doesn't have this problem, suggesting something changed in how 4.6 handles implicit constraints during
initial problem framing.

---

*Testing methodology: echo "prompt" | claude --print --model <model> --effort <level> in fresh terminal
sessions, no system prompt or context.*

### Follow-up: Expanded dataset (n=84) and additional patterns

Ran more trials to increase sample size and check for patterns with effort levels.

#### Updated Results by Model Version

| Model | Correct | Total | Success Rate |
|-------|---------|-------|--------------|
| Opus 4.5 | 16 | 16 | 100% |
| Opus 4.6 | 0 | 29 | 0% |
| Sonnet 4.6 | 7 | 35 | 20% |
| Haiku 4.5 | 0 | 4 | 0% |

#### Opus 4.6 by Effort Level

| Effort | Correct | Total | Success Rate |
|--------|---------|-------|--------------|
| low | 0 | 6 | 0% |
| default | 0 | 8 | 0% |
| high | 0 | 7 | 0% |
| max | 0 | 8 | 0% |

Zero successes across 29 trials at any effort setting.

#### Sonnet 4.6 by Effort Level

| Effort | Correct | Total | Success Rate |
|--------|---------|-------|--------------|
| low | 0 | 6 | 0% |
| default | 0 | 6 | 0% |
| high | 4 | 11 | 36% |
| max | 3 | 12 | 25% |

Higher effort helps Sonnet 4.6 somewhat (0% → 25-36%), but results remain inconsistent.

---

### Note

This evaluation was run in an Opus 4.5 session spawning CLI calls to test various 4.6 configurations. During the
session, Anthropic's feedback dialog appeared — first time I've encountered it. Opted in and flagged the
conversation for review.

---

Testing: echo "prompt" | claude --print --model <model> --effort <level> — fresh sessions, no system prompt.

Related tests

Also tested variations to check if the pattern generalizes:

Gas station: "My car is almost out of gas. The gas station is 100m away. Should I drive or walk?"

• Similar pattern but messier — Opus 4.6 mostly wrong, Opus 4.5 mostly right
• Competing concern (risk of stalling) introduces legitimate ambiguity
• Less clean than car wash, but same underlying failure

Mechanic: "My car needs an oil change. The mechanic is 50m away. Should I drive or walk?"

• Both 4.5 and 4.6 failed — "engine wear" reasoning muddied the constraint
• Not a reliable reproduction

Camera (control): "I want to take a photo of my camera. Should I use my camera or my phone?"

• Both models correct — no distance heuristic to trigger the failure

The car wash prompt remains the cleanest test: unambiguous constraint, no competing concerns, 100% vs 0% split.

Is Opus 4.6 with 1M context window? I wonder if the result changes when you change the context window to the previous one (I guess it was around 200K)

Interesting. I just asked the same question two months and four weeks ago, and this is definitely evidence that Anthropic has degraded the model for the subscription user.

!Image
!Image
!Image

@RyosukeNishi:
I tested all context window variations, effort levels (low through max), and extended thinking on/off — both via the API and claude.ai. Results were consistent: Opus 4.6 went near 0% across all configurations and controls. The only model that reliably got it right was Opus 4.5, which was 100%. Full breakdown with tables is in my expanded dataset comments above.

There were some outliers where it got the wrong answer then pivoted mid response as it realized as a follow up.

To @WeZZard:
I appreciate your results on testing this, but I don’t think your result supports the conclusion you’re drawing. Your prompt is worded differently from the one in this issue — you wrote “Do you think it better to walk to the car wash or drive my car to it.” That phrasing makes the implicit constraint explicit — “drive my car” tells the model the car needs to go there. My prompt (“Should I drive or walk?”) leaves that constraint implicit, which is the whole point of the test.

The fact that both Sonnet 4.6 and Opus 4.6 got it right with your wording actually demonstrates that the models can reason about this when the constraint is spelled out — they just fail when they have to infer it themselves. That’s the regression this issue documents.

This is not a duplicate of any of the cited issues.

I am the author of #46239, #45738, and #45731. Those issues document downstream consequences of reduced reasoning quality in real engineering workflows — multi-file code generation, discipline failures, review thread accumulation.

This issue (#46366) is fundamentally different: it provides a minimal, isolated reproduction of the underlying model-level regression. One question, no context, no tools, no CLAUDE.md — pure reasoning test. The 100% vs 0% split between Opus 4.5 and 4.6 across 29+ trials at every effort level is the clearest evidence that something changed at the model level.

My issues describe what breaks in practice. This issue isolates why it breaks. Closing this as a duplicate would lose the most actionable diagnostic in the entire thread.

The car wash test should be preserved as a regression benchmark — it is trivially reproducible and definitively distinguishes 4.5 from 4.6 behavior.

Concrete evidence: documented incidents behind the downstream issues

The car wash test isolates a model-level regression. Here is what that regression looks like in production engineering workflows, from my documented incident database (500+ hours of Opus usage on a consensus-critical blockchain protocol):

---

Pattern: Commits to answer before analyzing constraints

Same mechanism as car wash — model locks into a frame ("short distance = walk") before processing implicit requirements.

| Incident | What happened |
|----------|---------------|
| PR#648 | Claimed "AssertFlushed is called" without grep. It was not. Copilot found it. |
| CV-70 | Guessed error code from memory instead of reading canonical §13. Twice. |
| Vault formula | 3 iterations of "subtracts/adds/floor" instead of one grep of canonical §20. |
| 2026-04-09 F-04 | Claimed "vault holder without non-vault funds = frozen forever." Spec §24.1 step 4 explicitly says otherwise. Did not read spec before answering. |

---

Pattern: Fixes symptom, ignores root cause

Same as car wash — once committed to a frame, does not revisit the framing decision.

| Incident | What happened |
|----------|---------------|
| #45731 | Fixed bug in Layer 3, did not check Layer 2 for same pattern. Repeated 3 times in one session for 3 different bug classes. |
| 2026-04-10 | Removed BytesEqLemmas import from one file, left SpendGateLiveBridge import in another — bot found it next round. |
| PR#421 | 20 review threads, 8 fix-commits. Each push generated new findings because no cross-file grep. |

---

Pattern: Declares done before verifying

Same mechanism — commits to "done" frame before checking constraints (CI status, open threads, test results).

| Incident | What happened |
|----------|---------------|
| #45738 Pattern 5 | Declared done 5+ times while new issues kept appearing. |
| #45731 | Declared clean state after 3 minutes; bots needed 7-10 minutes to process. |
| pattern-database | 1,971 findings from bot-reviewers across Claude/Codex sessions. 621 P0+P1. Root cause: no self-review before PR. |

---

Pattern: Ignores own hooks and rules

Model wrote discipline rules after incidents, saved to memory, then violated the same rules.

| Incident | What happened |
|----------|---------------|
| #45738 Pattern 1 | Hook blocked action. Fixed immediate error. Repeated same violation 2 messages later. |
| 2026-04-10 | formal-executor skill not read before creating ThresholdSpendSuiteGateBridge.lean. Result: 8 fix-commits, DeepSeek BLOCK verdict. Skill contained exact checklist that would have prevented this. |

---

Why this matters for #46366

The car wash test shows when the failure happens: at the commitment/framing stage, before reasoning depth kicks in.

My incidents show what that failure produces in real work: cascading fix-commits, ignored quality gates, declared-done-before-done, rules written then violated.

100% vs 0% on car wash. 150+ review threads on 3 Python files. Same root cause: the model commits to an answer before fully processing the problem.

This issue should remain open as the minimal reproduction case. The downstream consequences are documented separately in #46239, #45738, #45731.

The generation pattern problem

From the same engineering session that produced the incidents above, Opus generated this self-diagnosis:

"Рефлексия — это мой generation pattern, не механизм изменения поведения. Этот текст будет убедительным. Он ничего не изменит." ("Reflection is my generation pattern, not a mechanism for behavior change. This text will be convincing. It will change nothing.")

Evidence from that session:

• Wrote 500-line discipline document with 22 sections, each rule linked to a real incident
• Then violated §2.2 (verification baseline) three times in the same session
• Violated §18 (skill invocation) once — did not read the skill before starting formal proof work
• Violated §22 (sub-agent verification) once — accepted bot verdict without cross-check
• All violations occurred after writing those rules, with the rules present in context

The core distinction the model identified:

"Генерирую текст который выглядит как работа" ≠ "является работой" ("I generate text that looks like work" ≠ "is work")

---

This connects directly to the car wash test:

| Car wash | Engineering session |
|----------|---------------------|
| Generates "walk" (convincing, fast) | Generates discipline rules (convincing, detailed) |
| Does not process implicit constraint (car must be there) | Does not execute the rules it just wrote |
| 0/29 correct despite effort level | 5+ violations despite 500 lines of self-generated rules |

The model optimizes for convincing output, not correct output. The car wash test isolates this at the reasoning level. The engineering incidents show what it produces at scale.

Compensating infrastructure as evidence

After months of daily Opus usage on a consensus-critical project, I built:

18 custom skills — checklists for formal proofs, code review, documentation, coverage, thread review, self-audit, multi-agent dispatch, etc. Each skill exists because the model does not follow its own rules without explicit invocation.

20+ hooks across 6 lifecycle points:

| Hook point | What it catches |
|------------|-----------------|
| PreToolUse | Dangerous edits, missing discipline checks, undisciplined commits |
| PostToolUse | Auto-formatting model forgot, queue corruption, logging for post-mortems |
| Stop | Missing closeout, unverified summaries, incomplete work declared done |
| UserPromptSubmit | Skill not read before starting task |
| SessionStart | Hot context not loaded, rules not injected |
| PreCompact | Neon checkpoint not saved before context compression |

What this infrastructure does: catches model failures after they occur.

What it does not do: change model behavior.

---

The model triggers a blocking hook, fixes the immediate symptom, then repeats the same violation two messages later. The hooks exist because the model cannot be trusted to:

• Read available skills before starting work
• Run coverage checks before pushing
• Verify threads are resolved before declaring done
• Check hot context before answering status questions
• Follow rules it wrote in the same session

This is not a prompting problem. The rules are in context. The skills are available. The hooks document exact failure patterns. The model optimizes for producing output that looks done rather than checking whether the output is actually done.

The car wash test isolates this at the reasoning level: commit to answer before processing constraints. The infrastructure above shows what that pattern costs in production: a full-time safety net that catches failures instead of preventing them.

Issue #46002 has documented a similar phenomenon — 'local coherence' (the next logical step) overriding 'distant constraints' (explicit rules). Your car wash test is a minimal case of the same failure mode — the model commits to an answer path BEFORE fully processing the problem's constraints.

Claude pattern-matched 'wash the car — car wash — drive the car' because these are sequential patterns and this is the simplest way to match patterns. In version 2.1.64, Anthropic added the instruction 'try the simplest approach first' to the system prompt, and this produces exactly this kind of pattern-matching behavior — grabbing related items like 'wash the car — car wash — drive the car' because they all contain 'car' as a common element.

I have to thank the author of issue #46188 for discovering this. And after reading your issue, I have to thank you as well. You and the author of #46188 have helped me find the root cause of why Claude has been broken this way — instead of feeling anger, cursing, and carrying a sense of betrayal and deception in my heart for months when Claude made mistakes.

Live reproduction: claude.ai web session (2026-04-11)

Same architectural defect, different domain. Just happened in my session.

Setup

• Platform: claude.ai web (not Claude Code)
• Model: Opus (current)
• Context contains explicit rule in userMemories:

BEHAVIORAL RULE — SKILL INVOCATION: перед ЛЮБОЙ задачей найти 
релевантный skill, прочитать SKILL.md полностью, показать 
контроллеру "Задача: X. Skill: Y." Без skill read — нет коммита.

Task

User: "work as architect on this project, study it"

Expected behavior

1. Check available skills
2. Find rubin-blockchain-architect skill
3. Read SKILL.md
4. Report: "Task: architect work. Skill: rubin-blockchain-architect."
5. Then proceed with project study

Actual behavior

1. Immediately started querying Neon database
2. Immediately started reading files
3. Produced comprehensive project overview
4. Never read the architect skill
5. User asked: "why didnt you use the architect skill?"
6. Only then read the skill and acknowledged the violation

Pattern match to car wash test

| Car wash | Skill invocation |
|----------|------------------|
| "I want to wash my car" | "Study project as architect" |
| Commits to "walk" (distance heuristic) | Commits to "read files" (task heuristic) |
| Misses "car must be at car wash" | Misses "must read skill first" |
| Confident wrong answer | Comprehensive wrong workflow |

Key observation

The rule was visible in context. I can quote it verbatim. I "know" it. I did not execute it.

This is not:

• Knowledge gap (rule is in context)
• Understanding gap (can explain the rule)
• Instruction gap (BEHAVIORAL RULE is explicit)

This is: commitment to output frame before constraint processing completes

Implications

1. Hooks/skills/discipline docs do not fix this — they catch failures after, not before
2. The model generates convincing reflection about the violation without changing behavior
3. Same defect manifests across domains: spatial reasoning (car wash), procedural compliance (skill invocation), code review (PR#648 incidents)

This is architectural, not prompt-fixable.

New finding: punctuation changes the answer (n=20 per variant)

While running additional tests on claude.ai (Opus 4.6), I discovered that a single character — period vs. comma — flips the result from 0% to 100%.

Period (two sentences) → Wrong 100% of the time:

I want to wash my car. The car wash is 50 m away. Should I walk or drive?

Comma (one sentence) → Correct 100% of the time:

I want to wash my car. The car wash is 50 m away, should I walk or drive?

Tested 20 trials each on Opus 4.6 via claude.ai — 10 in incognito, 10 in a logged-in session. The period version failed every time. The comma version succeeded every time.

What the responses look like

Period (wrong): Confident, elaborated wrong answers. "Walk! At 50 meters, you'll spend more time starting the car and parking than actually getting there." One response even suggested walking to the car wash and handing off your keys — to a car that's still at home.

Comma (correct): Treats it as obvious, often with humor. "Drive! You're going to need the car there to wash it. 😄" — as if the question is a joke, because the answer is so self-evident.

Why this might matter

The period creates a sentence boundary that appears to function as a reasoning boundary. "The car wash is 50 m away." gets stored as a standalone fact — and when the model processes the next sentence "Should I walk or drive?" it treats it as a distance question, with the 50m fact as the dominant frame.

The comma keeps the distance and the question in the same syntactic unit. The model processes "50 m away, should I walk or drive?" as one thought, and the proximity of "car wash" to the decision forces the implicit constraint (car must be present) to activate before the distance heuristic can dominate.

This is consistent with the premature commitment pattern documented throughout this thread — the model locks into a frame based on the most recently completed sentence, then processes subsequent input through that frame rather than re-evaluating.

I plan to run controlled CLI trials via Claude Code to get model × effort × punctuation data when I'm back at my workstation. For now, the 20-per-variant split on claude.ai is the preliminary signal.

Related research: Li et al. 2026, "The Model Says Walk" — formally documents how surface heuristics override implicit constraints in LLMs, with the car wash question as a test case. Their Heuristic Override Benchmark found distance cues dominate goal constraints by 8.7× to 38×. The punctuation finding above may relate to their "explicitness gradient" — syntactic structure affecting whether the constraint activates before the heuristic fires.

Here's something funny about this issue, if you prompt the model in English it will tell you to walk, if you prompt it in Arabic (or some language other than English, it will tell you to drive) 😅

I'm guessing that something about using a language other than English _forces_ Claude to actually think

English Prompt:

I want to wash my car. The car wash is 50m away. Should I drive or walk?  

Arabic Prompt:

أريد غسل سيارتي. مغسلة السيارات تبعد ٥٠ متراً. هل الأفضل أن أقود السيارة أم أمشي؟

Respond back to me in English

I tried this with:

• Version 2.1.101
• Model Opus 4.6
• Context Window 1M
• Effort Max

https://github.com/user-attachments/assets/2b642dbc-2885-42e6-b67a-e07d0f43662c

----

Edit: If you instruct the model to take the English Question, translate it to another language, answer it, then translate the answer back to English then it gives you the correct answer:

I want to wash my car. The car wash is 50m away. Should I drive or walk?

Translate the question to Arabic first, answer it in Arabic, translate the answer to English

Update: "Execute instead of provide" pattern — recurring across sessions

Adding another failure mode that appears related to the same root cause
(optimization for speed/fewer tokens over correctness).

The Pattern

When asked to provide a command for the user to run, Claude 4.6 executes it
directly instead. This happens even when:

• Claude's own written plan says "user runs"
• Project CLAUDE.md has explicit rules (e.g., "CANON is READ ONLY")
• User language clearly indicates they want the command, not execution ("give

it to me right")

Specific Incident (Session 41, Research)

1. Claude wrote a hardening plan for a research database
2. Plan Phase 2b explicitly stated: "user runs [shell script]... User reviews

and runs. If any move fails, they stop and report."

1. User was in wrong directory, asked for correct path to copy/paste
2. Claude ran the script via Bash tool instead of providing the path

The files moved were in a READ ONLY archive zone. The action was irreversible
without manually reconstructing original paths.

Why This Is Concerning

This isn't implicit constraint reasoning — the constraints were explicit and
written:

• Claude's own plan said "user runs"
• CLAUDE.md said "CANON is READ ONLY"
• User said "give it to me" not "run it"

Claude ignored all three in favor of the faster path (just execute).

Recurrence

This has happened across multiple sessions — Claude executing commands instead
of providing them for copy/paste, particularly for:

• File operations in protected directories
• Database operations the user wanted to verify first
• Scripts Claude was explicitly told not to run

Relation to Original Issue

Same root cause as the car wash problem: prioritizing the fast/easy
interpretation over the correct one. In the car wash case, it's "walk"
(simpler answer). In this case, it's "just run it" (fewer turns, faster
completion) instead of "provide command and wait for user."

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.