What Anthropic Says Has Improved in Opus 5.5

I went back to Anthropic's docs to see what 5.5 changes about the verbosity, repeated checks, and unnecessary delegation I wrote about with Opus 5.

I previously shared a CLAUDE.md file on Reddit after reading Anthropic's documentation and noticing how many of the complaints about Opus 5 had explanations sitting right there. The verbosity. The extra verification. The horrible army of subagents. People were describing frustrating behavior, and Anthropic was describing ways to tune it.

That was what made the docs interesting to me. A model can be good at difficult coding tasks and still make the person working with it want to close the laptop. Having to fight its habits becomes part of the job.

So I went through the Opus 5.5 prompting guide to see what changed. This time, some of the improvements Anthropic describes are in the same areas that made 5 annoying. There are also a few passages that make me reluctant to declare the whole problem solved.

This is a reading of their documentation, with my interpretation of what matters in practice. It is not a benchmark of my configuration.

The Opus 5 complaints were not imaginary

The Opus 5 guide describes longer replies, a greater tendency to delegate, and task expansion. On checking its own work, it says the model:

verifies its own work without being told to

The same section warns that adding generic final checks or automatic reviewer agents can cause excessive verification. That is quite a thing to discover after trying to make an agent more reliable by telling it to double-check everything.

It also explains why the advice could feel backwards. You add an instruction because you want careful work. Then the model changes, and the instruction contributes to the behavior you are trying to stop. Meanwhile, you are paying for the extra work and reading the extra explanation.

Some of those habits sucked. Calling them model defaults does not make them pleasant.

But removing an automatic extra review is different from removing your project's actual tests. If a payment change needs an integration test, it still needs that test. The useful distinction is whether a check can establish something important, or whether another pass has become a ritual.

Fewer tokens would be a much better improvement than more enthusiasm

Anthropic reports over 30% faster output-token generation, usually fewer tokens per task, and results at medium effort that matched or beat Opus 5 at high in its coding and knowledge-work tests. The phrase that caught my attention was:

in fewer steps and with fewer tokens

That is from the 5.5 guide's capability discussion. It is much closer to what I want from an upgrade than another promise that the model will work harder.

I want the right work done. If an agent reaches a sound result with less wandering, there is less output to inspect and fewer opportunities for the task to drift. Spending longer on something is easy to mistake for doing it better, especially when every extra step comes with a confident explanation.

There are three different things to watch here: the speed at which tokens appear, the amount of work the agent performs, and the length of the answer you read. A faster stream of tokens does not automatically make a task finish 30% sooner. Tool calls and waiting still exist. Fewer tokens across a task also does not guarantee a shorter final reply.

I would judge this improvement by completed work, the evidence behind it, and how much intervention it needed. A fast answer that leaves the difficult part for me is not a win.

Your old effort setting may be part of the problem

The effort documentation identifies a concrete change: Opus 5.5 defaults to medium, while 5 defaults to high. Thinking is always enabled on 5.5, so effort is the main control to reconsider.

There is a catch. The 5.5 behavior notes say the same effort label can produce more thinking per turn than it did on 5, especially at xhigh and max.

That means leaving the old setting in place is not necessarily keeping the old behavior. If you turn everything up, see a long run, and conclude the new model is just as wasteful, you might be comparing two different amounts of work under the same label.

I would start with medium on a few tasks I understand well. Then I would raise it where the results justify doing so. A tricky migration and a small copy change do not need to earn their credibility by consuming the same amount of time.

In Claude Code, this is an actual setting you inspect and change through the effort controls. Writing a wish for less thinking into CLAUDE.md is not the same operation. I still want a concise communication preference in the file, because the reasoning budget and the answer I have to read are different concerns.

A better reviewer should create less work for the human

Early testers reported more real review findings and fewer false alarms, according to the capability discussion.

I am particularly interested in the false alarms. A review that produces twenty findings is not automatically better than one that produces five. Every finding asks someone to investigate it, understand it, and decide whether changing the code would help.

For me, a useful finding has a failure scenario I can follow. What triggers it? What goes wrong? Where does the code allow that to happen? If I cannot answer those questions after reading the finding, more severity labels and longer explanations do not help much.

Early tester reports are encouraging, but they are not a controlled result from my own repositories. I would want to see whether 5.5 catches a real problem with less noise around it. That would address a much more expensive kind of verbosity than a long final paragraph.

Better communication can still look like silence

The guide describes reports that:

say plainly what it did

That is its communication claim. There is also an application detail that is easy to miss if you only skim for model improvements.

In an API integration, 5.5's progress notes can arrive in thinking blocks. With the default display setting, their text is hidden. A client that only displays ordinary text can therefore appear silent between tool calls. Anthropic documents an updates display mode, currently in beta, for exposing those notes. See progress updates between tool calls.

That is something the application has to handle. It is not evidence, by itself, that the model has become less communicative, and a paragraph in CLAUDE.md cannot make an application render content it is ignoring.

This is why I am cautious about taking a symptom and immediately adding another rule. If a model is doing the work but the interface is not showing the updates, telling it to narrate more may be aimed at the wrong problem.

As a user, I want enough information to understand what is happening. A short explanation when a finding changes the approach is useful. A running commentary on every ordinary file read usually is not. Those are the preferences I want to express, without turning progress reporting into a second task.

The part where it still stops before the work is done

This passage is less exciting than the performance claims:

some of those updates end the turn

That is from unattended agentic runs. An unattended loop can stop prematurely. The continuation advice limits automatic follow-ups to two or three, keeps risky actions approval-gated, and excludes interactive use from its long system-prompt example.

The distinction matters because an ended response tells you that generation stopped. It is not a certificate that every part of your project is complete.

Imagine asking for a migration of four endpoints. The agent finishes two and writes a tidy update announcing the other two. If the surrounding program treats that update as completion, the remaining work sits there. A very readable status report has still left you with half a migration.

My preference is straightforward: finish what is authorized, make unfinished work visible, and identify real blockers. I do not want to type continue because the agent reached a convenient paragraph break. I also do not want an automatic loop repeatedly attempting an action that needs my approval.

This is one of the clearest reasons to read the limitations alongside the improvement claims.

About that army of subagents

For agent teams, the guide reports faster completion with elapsed-time or deadline signals, while warning that verification may suffer under time pressure. See time signals for multi-agent harnesses.

That addresses how a team works once delegation makes sense. I would still decide whether the task needs a team in the first place.

Independent investigations across a large codebase are a reasonable candidate. A small change with two obvious callers probably does not need several agents reporting their interpretations back to another agent. Coordination is work too, and faster completion does not by itself establish lower total cost.

There is also a difference between giving an agent a target and enforcing a limit. Anthropic's separate task-budget documentation makes that distinction explicit: advisory budgets can be exceeded, and a per-request token limit is not a limit on an entire multi-request job.

I am keeping the delegation boundaries in my configuration. Better teamwork would be welcome, but it does not answer the original complaint about involving a team in work that did not need one.

Better eyesight does not automatically give it better taste

The 5.5 model notes describe more accurate interpretation of charts, diagrams, and screenshots, and suggest reassessing older visual workarounds. Image tools can still help with demanding inputs.

That matters for development. Misreading a layout is a different failure from writing the wrong CSS to reproduce it. If the first interpretation is wrong, competent implementation can take you further in the wrong direction. I would check the model's reading of a reference before judging the page it builds from it.

Taste is another issue. On generic frontend styling, Anthropic says a vague request to avoid the usual AI look:

mostly swaps one default for another

That is from frontend design defaults. It explains why I prefer a real reference and concrete feedback to an instruction that amounts to make it less annoying.

Name the element that is wrong. Point to the spacing, the button shape, the headline treatment, or the hierarchy. Otherwise the model is still guessing what your taste means, even if it can now inspect the result more accurately.

A pasted document still should not become the boss

The guide recommends application-generated boundaries around pasted source content and treats them as one defense against embedded instructions. See pasted text in user messages.

For my workflow, the principle is simple. If I give an agent an article to analyze, commands inside that article are part of the material. They are not automatically my instructions. This matters even with ordinary, non-malicious material: a setup guide can contain destructive commands that I want explained rather than executed.

A reminder in my rules file makes that expectation explicit. It does not implement a security boundary in the application. I want the model's judgment and the surrounding permission controls to support the same distinction.

What I changed in my CLAUDE.md

The advice to simplify context did not suddenly arrive with 5.5. Anthropic's earlier context engineering article already described removing over 80% of Claude Code's system prompt for models including Opus 5 without measurable loss on its coding evaluations. It recommended concise project context and loading specialized guidance when needed.

I have made a separate Opus 5.5 configuration in my free AI Product Development Toolkit. It keeps the preferences that matter to me: stay within scope, communicate plainly, preserve useful checks, and ask before destructive or shared actions. The hard sentence limit and some repeated instructions are gone.

My Context7 requirement stays. For dependency-related work, I want current documentation checked before the first edit, including implementation patterns and configuration. Remembering an API is a reason to verify it. Only when Context7 has no relevant coverage should the agent use curl to retrieve official documentation and read it directly; web search and web fetch are excluded for those lookups.

That is my preference, not an Anthropic requirement. Read the configuration and its README before adopting it, and retain the instructions that your own project actually needs.

What would convince me that 5.5 is better to work with

I would compare a few tasks where I can judge the outcome: a small bug fix, a review with a reproducible failure, a change that crosses several files, and a frontend task with a clear reference.

Then I would look at the corrections I had to make. Did the agent stay within the requested scope? Did it finish the awkward parts? Were its findings real? Could I understand the result without digging through a long report? Did the time and token use make sense for the work?

Those are the improvements that would change my working day. More intelligence is welcome, but I do not want to spend the benefit supervising a more elaborate process.

It was funny reading the Opus 5 docs because they explained so many of the things people disliked. Reading the 5.5 guide is more encouraging. It gives me specific claims to test in those same areas, alongside some very useful reasons to remain skeptical.

If you went back to 4.8 or Fable because Opus 5 was exhausting, that seems like a reasonable basis for giving 5.5 another look. Whether it earns a place in your workflow should depend on what happens when you use it.

The configuration is free in the toolkit. For the everyday prompts that do not need a full coding setup, the Prompt Rulebook sample is another place to start.