You asked AI Agent to migrate a code repository overnight. The next morning, I opened the terminal full of anticipation, only to see this message:
Three interface migrations have been completed. Next, I will handle the remaining two endpoints and carry out the necessary testing.
And then, there's no further progress. If you want it to complete the remaining tasks, you have to type two more words: "Continue." You'd expect it to finish everything in one go, but instead, it just shows you a "Next Step" icon, and then the program shuts down for the day on its own. This isn't just a unlucky experience for one person.
As soon as Opus 5.5 was released, developers of Agent noticed that although the model's capabilities had improved, it tended to stop working on its own. If you didn't urge it to continue, it wouldn't move at all.
Anthropic I saw it myself. Just a few days after it was released, a guide to prompts was already available, specifically to fix this kind of issue.
In the initial troubleshooting checklist, the official directly mentioned this type of “drifting away halfway”:
The unattended Agent stopped halfway after reporting its progress.
The reason behind this might surprise you: Opus is just too fond of reporting.
When doing long-term tasks, it will proactively update you on its progress. The problem is that after some reports are submitted, it stops working again. The signal sent by API is “end_turn”, which means “I have finished my part for this round”.
However, there are still many Agent programs that follow the old logic, which adhere to a rigid rule: once the model no longer calls the tools, it is considered that the task is completed.
A progress report was simply treated as a formality to fulfill the requirement.
On this point, the official guide also explains it very clearly:
The end of a round of plain text should be regarded as a report, and must not be taken as proof of task completion.
So, the real problem is that AI wasn't trying to be lazy at all; it was your program that clocked out for it first.
Harmful habits of top students
The official has categorized these mid-project stoppages into four situations, and as long as you frequently engage in Agent, there's a high probability you've encountered them before.
The first is simply talking the talk without taking any action.
Wrote a long summary at the end announcing what the next step would be, but didn’t actually use any tools at all; the next step always remained just an idea on paper.
The second type is being overly polite.
While working, they suddenly stop and ask, “If you don’t mind, I’ll continue to handle this matter next,” then just hang up there, waiting for you, who isn’t even in front of the computer, to reply.
The third method is to pretend to seek instructions.
It lists a long list of decisions that require your approval, but in its own words, these decisions actually have no impact on its ability to continue with the remaining work.
Fourthly, there's the issue of reporting obsessive-compulsive disorder (OCD).
The model feels that there are enough words in the current round, or it has just completed a small phase, so it must stop to give you a summary.
Ironically, in the official promotion of Opus 5.5, "more proactive communication and clearer summaries" are precisely its core selling points.
Who would have thought that these good habits of the top students, when applied to an old unattended program, would instead become a cause for downtime?
Official Three Tactics: Take Back the Acceptance Power from AI
How to make it continue working without falling into an infinite loop?
The official has come up with three strategies.
First trick: a task list.
Break down large tasks into smaller items and hand them over to to-do tools or text management systems, allowing the model to tick them off as it works on them.
At the end of a round, if there are still unfinished tasks on the list and the model doesn't explain what's holding it back, your application must automatically send a message to remind it to continue working on those tasks.
An example given by the official for continuing the task: "There are still unfinished items on your task list: migrate the remaining two endpoints and update their tests. Keep working on them. If you get stuck on any item, identify where the problem lies."
Tactic number two: the strict inspector.
Set a standard in advance for completion. At the end of each round, pass it on to a smaller model for comparison and inspection. If it doesn't meet the standard? Treat the reasons for not meeting the standard as the next piece of information and send it back to that model, asking it to redo the work.
Third trick: hard braking.
If the same task gets stuck in the same state after two or three automatic retries, it must be forcibly stopped and handed over to a person for re-examination. For tasks that are truly stuck, don't let them consume all of your API quota unnecessarily.
In addition to that, prompts also need to be provided accordingly.
The official provided a set of system prompts that can be directly copied, which essentially means being trapped with no way out on both sides:
It is necessary to clearly state that one absolutely does not want the above four types of pauses, but it is also important to specify when pauses are allowed. For example, when it becomes truly impossible to proceed without the user's assistance, or when one encounters core resources that are deliberately protected.
Why is the old code suddenly reporting a 400 error?
If stopping work halfway can be considered as procrastination, then the following migration pitfalls will directly cause the program to crash.
Switching from Opus 5 to Opus 5.5, there are four changes in API. Requests originally written for Opus 5, if not modified, will be sent to the new model and will be directly rejected, returning a 400 error.
1. The thinking parameter cannot be turned off anymore.
If you set thinking to disabled, or manually specify budget_tokens, the system will directly reject the request. Either do not pass the thinking field, or set it to adaptive, and let the effort parameter control the depth of thought.
2. tool_choice can no longer force the invocation of tools.
Setting tool_choice to any or specifying a certain tool will result in a 400 error. The official recommendation is to use auto in conjunction with strict tool invocation or structured output, and to clearly indicate which tool to use at which point within the prompts.
3. The thinking block binds the model and context.
Accounts created after August 31, 2026, that have changed the system prompts, tools, or historical messages midway, will directly result in an error when replaying the old thinking blocks. The usage of only appending without rewriting is not affected.
4. Old version of computer operation tools is taken offline.
On Claude API and Google Cloud, it should be replaced with computer_toolset_20260801. On Amazon Bedrock, the old computer_20251124 can still be used.
There are also those hidden pitfalls that don't cause errors...
Firstly, it's impossible to see the process of work being done.
On Opus, the progress text written by the model between two tool calls is ordinary text (the text blocks).
At Opus 5.5, this text was moved into the thinking block ( thinking block), and by default, the thinking block does not display content ( display is omitted ), so it returns empty.
If your interface only displays the text, then long tasks run quietly without any issues. None of the requests fail, yet users think the system has frozen.
The solution is to set display to updates (or beta), in which case only the progress summary is obtained; or to set it to summarized, in which case both the progress and the reasoning summary are returned together.
Secondly, the answer was cut off.
`max_tokens` controls the total amount of thinking plus the main text. The upper limit set in the past when "thinking" was disabled might not be sufficient now; answers may get interrupted halfway through writing.
Thirdly, without any visible reasoning, they still burn token.
Even if the thought content is not returned to you, it will still be billed according to token.
In the code that processes the returned results, there are two other areas that are easily overlooked when it comes to making modifications.
First, when reading the results, it is important to distinguish between different types. In the content returned by the model, the thoughts and the main text are separate; do not assume that the first paragraph is the answer by default.
Secondly, when calling the tool back and forth, the model's thought records must be transmitted back intact. Deleting any part, making a few changes to the text, or swapping the order will result in rejection.
This list is aimed at developers who call Messages API to write code themselves.
For those marked with Claude Managed Agents, all that's needed is to change the model name.
The same medium file no longer has that old flavor of yesteryear.
Since thoughts cannot be shut off, effort has become the only lever for controlling costs.
Opus 5.5 supports five gears from low to max.
According to the official statement, by opening the medium file now, it is possible to catch up with and even surpass the previous high file that had a score of 5 in the Opus category. Moreover, if handling simple tasks with the low file, the cost is astonishingly low.
It sounds like a bargain that’s almost too good to be true, but the official immediately added: In the same tier, Opus requires much more thinking per round (5.5) than Opus (5), especially in the higher tiers.
In other words, if you copy the high files from an old project verbatim, not only will the round duration become longer, but the output token numbers will also soar dramatically.
Also named high, but what it thinks about is completely different now.
A practical suggestion is: start from medium, use your own data to test it out, and only increase the settings in areas where there is truly a need for improvement.
If you want to make it think less, simply downgrade it; this is much more effective than you patiently shouting “don’t overthink it” in the prompt words.
Getting rid of the AI taste depends entirely on using a blocklist.
Finally, there's a trick in the guide for creating front-end pages.
If you don't provide a clear design direction and let the model develop on its own, it will most likely produce those uniform, stereotyped AI style interfaces.
At this time, if you write "Please avoid the common AI feeling" in the prompt words, it will only switch from one set of AI templates to another set of AI templates.
The truly effective method is to simply put them on a blocklist.
In the official demonstration, it is directly stated: no cream-colored or grayish-white backgrounds, no italicized emphasis words in titles, no chapter numbering like 01/02, no equal-width font tags, and no capsule-shaped buttons.
The model can understand specific statements like “I don’t want this,” but it cannot comprehend the abstract expression “I want to look better.”
After reading this official guide, my biggest takeaway is:
The model is racing ahead, but the scaffolding for many applications is still stuck on the previous generation.
In the past, I was afraid it wouldn’t use its brain, so I forced it to write out its reasoning step by step. Now, on the other hand, I have to persuade it to think less; in the past, I went to great lengths to make it report on time, but now it reports too frequently, and as a result, the work comes to a halt halfway through.
Can a single Agent complete the task? The model's capability only accounts for half of it. The other half depends on how you define "completion," how you preserve context, and how you allocate the reasoning budget.
Next time, when your Agent quits halfway through again, don't rush to accuse it of being lazy. First, take a look at the loop you wrote yourself.
Reference materials:
https :// platform.claude.com / docs / en / models / opus-5-5 / migration-guide # text-between-tool-calls %20
https :// platform.claude.com / docs / en / build-with-claude / prompt-engineering / prompting-claude-opus-5-5 # unattended-agentic-runs
