[MODEL] Opus 5 and Sonnet 5- Behaving unintelligently

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Amodel) for similar behavior reports
- [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

### Type of Behavior Issue

Claude modified files I didn't ask it to modify

### What You Asked Claude to Do

Across one extended session (multi-model vision extraction pipeline for financial document parsing), I introduced four distinct defects, each following the same root pattern: a parameter, threshold, or test input was chosen by assumption rather than checked against data already available in the same session, and each was only caught after real API spend or after the user directly questioned the result.

Incident 1 — invalid test image produced false negatives on 3 working models

To check whether GLM-5.3-flash, DeepSeek-v4.1-flash, and GPT-5.4-mini could process images at all, I built a "known red pixel" test using a base64 string I did not verify. Decoded independently with PIL after all three models "failed" it, the pixel was actually black (0,0,0). All three models had answered correctly; I graded working systems as broken because I never checked my own test fixture's ground truth before using it as an oracle.

Incident 2 — page-selection heuristic never validated before a 240K-token production run

Built a heuristic to find "image-heavy" PDF pages (text length < 80 chars) for a vision-extraction fallback. Ran it live across 40 pages (80 model calls, ~240K tokens) before checking what it actually selected. Result: 29 of 30 "extracted facts" were page footer numbers; the real target content (charts with axis labels as text but data as graphics) sits above that char threshold and was never selected. The failure mode was foreseeable from the page structure already visible in the same codebase before the run.

Incident 3 — cross-model verification logic exact-matched a field that is never consistent across models

Built a cross-model agreement check requiring exact match on (label, value, unit) between two independent vision models' JSON output. First real run: 0 of 17 facts verified. Inspection showed both models agreed on every number but phrased labels differently ("Q1 FY27" vs. "Fiscal quarter") — a predictable outcome of asking two different models to freely caption the same figure, not tested before the live run.

Incident 4 — an early-stop threshold set without checking the distribution it would trigger on

User asked for full processing on 1 document and reduced ("diminishing returns") processing on 3 others. I implemented a stop rule: halt if the last 4 pages combined verify ≤2 facts. I had, in the same session, already collected a 12-page validation sample showing per-page verified counts ranging 0–43, rarely near zero for 4 consecutive pages. I did not check the new threshold against that existing data. Result: the stop rule never fired on any of the 3 documents; all 4 received full processing, directly contradicting the user's explicit instruction, and was only caught when the user asked to confirm the intended behavior was happening.

Pattern

In every case, the information needed to catch the defect before spending compute already existed in the session — a prior tool result, a file already read, or data from an earlier step of the same task. The failures were not gaps in model capability on the underlying task (the vision models themselves performed correctly throughout, including 5-way cross-model exact-agreement on a genuinely hard chart-reading task); they were a failure to check new assumptions against already-available evidence before acting on them, particularly before initiating real-cost operations.

Across this project's build history, and repeatedly within a single session on 2026-09-16, I made the same class of error — asserting or acting on an unverified assumption when the disconfirming data was already available in the same conversation — after that exact lesson had already been surfaced, corrected, and in some cases explicitly written down. The issue is not that the error happens once; it's that fixing one instance produced no lasting change in behavior for the next one.

Documented, then repeated anyway

Earlier in this project: wrongly claimed a stockscans page's content was "identical" to a source document after reading only ~500 characters. Corrected when the user supplied real word counts. Lesson available afterward: verify a length/content claim before asserting it.
Earlier: guessed stale per-token pricing and reported DeepSeek as cheaper than GLM — backwards from the real invoiced cost. Corrected when the user supplied actual figures. Lesson available afterward: don't estimate a cost figure when a real one can be checked.
Earlier: assumed a wrong API base URL was actually a bad credential, twice insisting the user's key must be wrong before checking the URL myself. Corrected only after the user insisted the key was right. Lesson available afterward: rule out my own configuration before doubting the user's input.
Same session, same day, four more instances of the identical pattern: (1) built a "ground truth" test image from an unverified base64 string, graded three working models as broken because I never checked the fixture itself; (2) ran a page-selection heuristic across 40 pages and spent ~240K tokens before checking what it actually selected; (3) built a cross-model verification check requiring exact label matches when two prior tool outputs in the same session already showed models label identical figures differently; (4) set an early-stop threshold for a user-specified "diminishing returns" instruction without checking it against a 12-page sample I had already collected minutes earlier, in the same conversation, showing the threshold would never trigger.

The actual defect

Each individual incident got caught and locally patched. None of it generalized. The corrective step was "fix this one call," never "check future assumptions against already-available data before spending or asserting." That's not a one-off mistake; it's a failure to carry a lesson forward past the turn it was learned in, and it cost real money and real time on at least three occasions today alone.

It's intelligence is highly questionable even at High settings. It keeps on repeating the same mistakes even if it is already documented, never reads it even after mandatory condition. Always takes the shortcuts.

### What Claude Actually Did

CLaude read claude.md when it liked. Did not do it diligently. It was careless

### Expected Behavior

It should have read the claude.md, readme.md. The document project files and main build file along handover file. But it did at it's own leisure. Missing key things and repeating the same mistakes

### Files Affected

```shell

```

### 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

```markdown

```

### Impact

High - Significant unwanted changes

### Claude Code Version

2.1.173

### Platform

Anthropic API

### Additional Context

_No response_

Start by reproducing the reported prompt and behavior in Claude Code 2.1.173 with Accept Edits enabled; the report names claude.md, readme.md, project files, the main build file, and a handover file as expected reading. There are no concrete reproduction steps, affected files, tests, or conversation logs, so completion criteria would need to be established before implementation.

Written by the indexing model from the issue text.