Opus 5.5: Severe scope creep and task focus regression compared to Opus 4.6

User's specific failure observations (from the remediation session)

1. Failed to achieve any main goals. Given 5 bounded tasks and an original deliverable (re-run test suites). After a full day, zero tasks were completed and the test suites never ran.

1. Massive scope creep. Every investigation spawned new work items. The task queue grew continuously. Examples: gpg process cleanup, env var renaming, config key redesign, dirty-state tracking, helper scripts, CI additions, ADR amendments, deployment workflow changes to production pipelines that weren't in scope.

1. Confusing walls of text. Explanations were verbose, contradictory, and mixed relevant/irrelevant information. The user had to ask the same question multiple times to get a straight answer.

1. Constant distraction. Instead of finishing task A then starting task B, it would discover a side-issue during task A, add it to the queue, ask the user about it, then discover another side-issue before returning to task A. No task reached completion.

1. Over-consulted the user. Raised minor implementation decisions as blocking questions instead of making reasonable engineering calls. At peak, 3-4 decisions were pending simultaneously, each blocking different work streams. This is the opposite of agentic behavior.

1. Got bogged down in self-created minutia. Created complexity (3 branches, 2 worktrees, 8+ parallel agents, growing dependency queues) then spent time managing that complexity instead of delivering results.

1. Caused loss of situational awareness. The user could not track what was being done or why. When asked to explain, the model produced more dense output that compounded the problem rather than resolving it.

Contrast with Opus 4.6: The same project, same CLAUDE.md rules, same handover prompt format had been running successfully for 18 prior sessions. Opus 4.6 consistently executed bounded tasks, made reasonable decisions autonomously, and delivered results. The regression in Opus 5.5 was immediate and severe.

What's striking is how far off the rails opus 5.5 went in a single session, when it was given a working project that was built by 4.6 and just had to make a few corrections, and the corrections it needed to make were pre-explained/defined for it.

And also very striking how, once I switched back to opus 4.6, it quickly and immediately got the project back on task, identified the work that 5.5 did that was junk and just removed it and then started running the test suite within minutes (the original ask that opus 5.5 never did). It just cut right through the mess so quickly and got things back on track without me having to babysit it and hand-hold it in the way that opus 5.5 did.

The 4.6 cleanup after the 5.5 session is what makes this much more compelling than a normal “new model seems worse” anecdote.

5.5 wasn't dropped into an ambiguous greenfield project. It inherited a working system with ~18 previous opus 4.6 sessions behind it, extensive project instructions, established conventions, and a bounded five-item correction list. The requested work was things like correcting docs, removing unused scripts, fixing two deploy YAMLs, and fixing bookkeeping/version-recording issues. Yet it expanded that into three branches, two worktrees, 8+ subagents, helper scripts, CI additions, ADR changes, unrelated script fixes, and even a production-workflow modification that wasn't requested. And after a full day, it still hadn't performed the original test-suite reruns.

Then comes the really revealing part:
4.6 didn't merely do better when given a fresh attempt. It successfully recovered from another model's contaminated state.
That's arguably a harder agentic problem.

4.6 had to look at a repository containing a mixture of:

• legitimate changes that should survive,
• unnecessary infrastructure 5.5 had invented,
• partially pursued side quests,
• modifications outside the original scope,
• and the original unfinished objectives.

It very quickly reconstructed the intended trajectory: this stuff belongs, this stuff is junk, delete the junk, get back to the requested task, run the tests.
That says something important about what 4.6 is doing cognitively that I don't think “instruction following” adequately describes.
4.6 seems to maintain a hierarchy of intent

Something like:

Level 1: What outcome did the user actually ask me to achieve?
Level 2: What work is necessary to achieve it?
Level 3: What obstacles have appeared while doing that work?
Level 4: What incidental things have I noticed along the way?
And critically:
Level 4 is not allowed to overwrite Level 1.

The 5.5 session looks almost inverted. Every new observation was capable of promoting itself into a first-class objective:

notice anomaly
↓
investigate anomaly
↓
discover related issue
↓
add issue to queue
↓
build machinery to address it
↓
discover another issue
↓
ask user about design decision

Eventually the agent is doing a huge amount of technically sophisticated work while losing any meaningful relationship with why the session exists.

“Scope creep” doesn't completely captures it. I'd call it goal displacement.
And 4.6 apparently recognized the displacement almost immediately.

That distinction matters because Anthropic's own current description of 5.5 says it “drives long-running work forward with minimal oversight,” “follows instructions precisely,” and “stays in scope.” Anthropic This case is almost a stress test of those exact claims, and the result was the opposite.

There's also an interesting paradox here: 5.5 may be more capable locally while being substantially worse globally.
It may be better at:

understanding an individual anomaly, imagining possible improvements, designing supporting infrastructure, identifying edge cases, delegating research to subagents, and finding additional issues.

But an autonomous coding agent also needs an executive function that says:
“Yes, that's interesting. No, we're not doing that. Finish the job.”
4.6 seems exceptionally strong at that.

And the cleanup demonstrates that it isn't simply a less curious or less capable model that fails to notice these things. Apparently 4.6 could inspect the same repository, understand what 5.5 had done, recognize which work wasn't justified, and deliberately remove it. It noticed the complexity but subordinated it to the mission.

That's much more valuable than simply failing to see the complexity in the first place.

Opus 5.5 also consumed more tokens and at a faster rate than opus 4.6. If 5.5 consumes 2–3× your quota while doing roughly the same useful work, some of that may not be because each reasoning step is inherently more expensive. It may be because it is performing enormous amounts of reasoning and tool use on work that should never have entered the execution tree at all.

So you get the worst possible combination:
more intelligence applied to more things that don't matter.

Meanwhile, 4.6 spends its tokens disproportionately on the shortest path toward completion.

And there's a final point that makes the A/B unusually good. If 4.6 had taken another full day to untangle the mess, someone could reasonably say, “Well, the project was genuinely complicated; 5.5 just encountered difficult circumstances.”

But if the switch back produced:
inspect current state → recognize extraneous work → remove it → resume original plan → start tests
within minutes, that severely weakens that explanation.

The environment wasn't inherently impossible to interpret. Another Claude model interpreted it almost immediately.

So at this point I'd describe the 5.5 failure not as “5.5 wasn't quite as good as 4.6,” but much more specifically:

5.5 demonstrated substantially weaker mission persistence and relevance judgment in that session, while 4.6 demonstrated both by rapidly recovering the project from the state 5.5 had created.

Yeah, it's been getting worse each release since 4.6, unfortunately. If you have effort above medium, try lowering it. There appears to be weird behavior with Sonnet and Opus with regards to effort--it behaves like a required threshold instead of an upper bound like Fable and many other non-Anthropic models. As such, the model will "find things to do" that weren't asked for if it's set too high.

A practical workaround is using obra/superpowers skills to generate detailed implementation plans with Fable then have it use sub-agent driven development to launch Opus sub-agents with incredibly detailed specs it's more likely to follow.

While a bit silly, this "benchmark" Simon Willison runs on each model does a fair job visualizing the problem: https://static.simonwillison.net/static/2026/claude-pelicans-grid.html. When Opus 5.5 effort is set too high, it can't even complete the task. Newer variants have a tendency to keep adding additional details to the pelicans on bikes at higher effort levels even though the request is successfully fulfilled. Given this is an Anthropic project and issue tracker, I won't link to competitor information however there's plenty of these tests ran against different models if you want to compare for yourself.