Old loops stop when Opus 5.5 reports

Claude Opus 5.5 reports progress on long tasks. Anthropic's prompting guide puts one case on the troubleshooting list: an unattended agent stops partway through a long task after reporting progress. Some of those updates end the turn as text, with stop reason end_turn, and no further tool call. A loop that treats that turn as the end of the task stops there.

The guide's instruction is to treat a text-only end of turn as a report, not as proof the task is done. A Chinese tech site discussed the guide on the evening of September 26. The practices and API changes below come from Anthropic's prompting guide and migration guide.

The guide says to keep the task's parts in a checklist the model updates, either a to-do tool or a file. If a turn ends with items still open and no blocker stated, the application sends a short user message naming them. The example says the list still has open items, migrate the remaining two endpoints and update their tests, and continue; if one is blocked, say what is blocking it.

The application can also state the completion condition up front and have a separate, smaller model check the conversation against it at each end of turn, returning its reason as the next user message when the condition is not met. Either way, stop after two or three automatic continuations on the same task, so a run that is genuinely stuck can be reviewed instead of repeating forever. If a background command or subagent the model started is still running, do not treat the task as done. Wait, then return that output as the next user message.

The guide says Opus 5.5 responds to instructions that name the early stops to avoid. The saved page lists four ways a user had seen a turn end while work was still owed. The first three are complete: a long summary that announces the next step and has no tool call, so the next step never starts; an offer to carry on unless the user would prefer otherwise, which waits for an answer that was not coming; and a list of decisions when, by the model's own account, none of them blocks the rest of the work. The fourth sentence is cut off in the copy saved for this edition. It only begins: deciding this is a good place to report because the turn has already been long.

A paragraph added at the end of the system prompt can ask the model to put status in the same message as its next tool call, which makes some of these early stops less frequent. The guide says to keep the application's own confirmation for risky or irreversible actions, and to leave the paragraph out of human-in-the-loop products where a person is there to answer. Expect more tool calls and output tokens per task. If those status notes land in thinking blocks, the default display is empty. Set display to updates to receive a summary of each one.

A separate set of changes makes old requests fail outright. The migration guide says that where a setting is rejected, the API returns a 400 error. Thinking cannot be turned off. Send no thinking field, or send adaptive thinking; the two are equivalent, and adaptive thinking is always on. Setting thinking to disabled, or sending a manual budget_tokens value, is rejected. Tool choice is auto, the default, or none. Forcing a call with any, or with a named tool, is rejected. On the Claude API and Google Cloud, declare computer use as the computer_toolset_20260801 toolset. The earlier computer_20251124 tool returns 400 there. Non-default temperature, top_p, and top_k are rejected, as is a prefilled assistant turn at the end of the message list.

Thinking blocks are tied to the model and the conversation. For accounts created on or after August 31, 2026, 00:00 UTC, replaying a thinking block after an edit to the system prompt, the tools, or earlier messages returns a 400 error by default. Append-only integrations do not need a code change for that rule. For Claude Managed Agents, the migration guide says no changes are required beyond updating the model name.

Thinking runs on every request. max_tokens covers thinking plus the reply. Thinking tokens are billed as output tokens even when the thinking text is not returned. thinking.display defaults to omitted, so the thinking field arrives empty beside its signature. Set display to summarized for a readable summary. Read the reply by block type. Do not assume the first block is text. In a tool loop, pass thinking blocks back complete and unmodified. The API rejects blocks that were dropped, edited, or reordered.

Effort is the control for how much the model thinks. Opus 5.5 defaults to medium. Opus 5 defaults to high. The prompting guide says that in Anthropic's testing, Opus 5.5 at its default medium matched or beat Opus 5 at high on multistep work in a real repository, in fewer steps and with fewer tokens. At a given level, Opus 5.5 tends to think more per turn than Opus 5, especially at xhigh and max. Keeping the Opus 5 effort value means longer turns and more output tokens. To get less thinking, lower the effort level first. That is more reliable than asking for less thinking in the prompt. The guide also says Opus 5.5 generates output tokens more than 30 percent faster than Opus 5 and tends to finish the same task with fewer tokens.

The migration guide lists a price as well: Opus 5.5 is $4 per million input tokens and $20 per million output tokens, against $5 and $25 for Opus 5. That is a price list, not an explanation of a model that stopped early. The early stop comes from an old loop treating a progress report as the end of the job.