Claude Opus 5.5: A Founder’s Gate for Agent Stop States

Anthropic released Claude Opus 5.5 on September 22. Its migration guide lists changes that can alter how an AI application starts, continues, or ends a task: a different default effort level, different tool choices, visible progress behavior, explicit refusal and context-limit stop reasons, and computer-use compatibility. A model switch may therefore look like an agent that suddenly “gives up,” even when the underlying event is a refusal, exhausted context, an unrendered update, or a broken tool loop.

For a nontechnical founder, the decision is not whether Opus 5.5 sounds smarter or cheaper. It is whether a customer can tell what happened, what work was completed, what remains, and what action is safe next. This article offers a stop-state vocabulary, a worked customer scenario, an acceptance matrix, and a release receipt that a small team can use without reading every API trace. We have not tested your product or measured Opus 5.5 against your workload. Anthropic’s capability and price statements are vendor claims; the product tests below are proposed acceptance criteria, not reported results.

The launch problem is a state mismatch

Imagine a customer-facing research assistant that reads a company’s documents, searches approved sources, drafts a market brief, and asks before sending it to colleagues. The founder sees a demo in which the brief is good. After migration, one customer sees a blank panel for a minute, another sees a polished partial brief with no notice that a source could not be read, and a third sees “I can’t help with that” after the assistant already saved a draft. All three can be described casually as “the agent stopped.” They require different fixes.

The first is perhaps a display or progress problem. The second may be an output or context limit, or it may be an ordinary answer whose missing evidence the app failed to detect. The third may be a safeguard refusal or a policy transition after a side effect. A model benchmark does not classify these customer journeys. The application must preserve the provider’s stop signal, correlate it with its own tool and business events, and give the user a truthful status.

Anthropic’s stop-reasons documentation distinguishes a normal end of turn, a request for client tool use, an output-token limit, a context-window limit, and refusal. Those are interface facts. Whether the product should retry, ask the user, show a draft, or stop permanently depends on the workflow and the consequences of repeating an action. A founder’s acceptance criterion should describe the visible outcome and the underlying effect together.

Define five terms before judging a run

A stop reason is a structured signal explaining why the model response ended. It is not a customer-ready explanation by itself. end_turn can mean the model finished its current turn; it does not prove the entire business task is complete. tool_use means the app may need to execute a client tool and return its result before the task can continue. max_tokens means the response reached the request’s output limit. model_context_window_exceeded means generation reached the model’s context capacity; Anthropic notes that an oversized input can instead fail with a 400 error before generation. refusal is a safeguard decline delivered as a normal API response, potentially HTTP 200. See the stop-reason guide, context-window guide, and refusal guide.

An app state is the product’s own conclusion: working, waiting for approval, complete, incomplete but resumable, declined, or failed. Map provider signals to these states using tool events and task requirements. A side effect is an action outside the model’s text, such as sending a message, saving a document, charging a card, or changing a record. A receipt is the evidence of what happened: response ID, model ID, stop reason, tool calls and results, saved artifact versions, user-visible state, and owner decision. A fallback is an intentional route to another model or path after a failure or refusal; it is not proof that the second answer is acceptable.

These distinctions prevent a common bug: an HTTP 200 becomes “success,” a fluent paragraph becomes “complete,” or a silent stream becomes “failed.” Anthropic explicitly documents that a refusal may be a normal response. Your product should count it as a distinct outcome, not bury it in a server-error dashboard or silently rerun the same request. The user might need a boundary explanation, a narrower request, or human review. Another model’s willingness to answer does not automatically make the action appropriate.

What actually changes in Opus 5.5

Anthropic’s migration checklist calls for an explicit model ID, replacing old thinking controls with effort, changing unsupported tool_choice forms, updating some computer-use integrations, preserving thinking blocks in tool loops, rendering nonempty progress when appropriate, handling refusal, and rebaselining cost and latency. These are not all user-visible individually. Together they can change whether a task reaches a conclusion, whether the app recognizes that conclusion, and whether the user sees a trustworthy account of it.

The default effort changes from high on Opus 5 to medium on Opus 5.5. Anthropic’s effort documentation says effort influences output tokens, including thinking and tool calls; lower effort may yield fewer or terser tool calls. Do not compare yesterday’s Opus 5 production run with today’s Opus 5.5 default and attribute every difference to the model alone. Pin the old and new settings in your test record. Choose an effort setting for each product task based on accepted outcomes, latency, and spend; then set it explicitly so a default change cannot silently alter your release.

The migration guide also notes that Opus 5.5 may return stop_reason: "refusal" with a category, and can stop on model_context_window_exceeded. Neither is equivalent to “the model lost motivation.” A refusal may be a valid boundary; a context limit is a capacity condition. A tool-use turn may be a handoff, not an ending. Some computer-use tool versions differ by platform, so an agent with browser or desktop control needs a platform-specific check rather than a copied generic configuration. The product team should ask for a compact before-and-after trace for each branch, not just a screenshot of the final paragraph.

Anthropic says Opus 5.5 has a lower token price than Opus 5 and makes other performance claims in its release announcement. Those prices are relevant to budgeting but cannot establish lower cost per successful customer task. A different effort level, longer retries, fallback attempts, or more human repair can dominate token price. This is an inference about product economics, to be verified on your own tasks.

Treat silence and visible progress as different outcomes

A long-running agent may be working while the interface appears frozen. The migration guide says applications that render text between tool calls may need to set display: "updates" or "summarized" and render nonempty thinking blocks. Anthropic’s Opus 5.5 prompting guidance separately discusses progress updates for unattended work. The founder-level question is whether the user sees a credible, bounded status, not whether every internal token is exposed.

Define a progress contract. Within an agreed interval, the UI should show the current phase or explain that the task is waiting. A tool call should move the status to “checking sources” or another truthful phase. An approval request should clearly stop execution until approval. If the stream ends because of tool_use, the app should not display a final “done.” If the user navigates away and returns, the status should match the durable job record rather than a stale browser spinner. These are proposed product tests, not guarantees from the model vendor.

Avoid revealing raw reasoning or confidential tool data just to make the screen feel active. A short status such as “Comparing three approved sources; no document has been sent” can be useful when supported by actual events. “Almost done” repeated indefinitely is worse than admitting a timeout. The status needs an owner and a timeout rule: after what duration does the app stop waiting, show a recoverable state, and offer a safe next step? This is especially important when a user could mistake silence for permission to resubmit a payment or send action.

Make a worked journey your acceptance case

Return to the research assistant. A customer requests a brief on three competitors, grants read access to a folder, and requires approval before sharing. The app should produce a draft with citations and no outbound send. We can define the customer contract before swapping models: read only the approved folder; use the specified search source; flag missing evidence; save one versioned draft; and end in “awaiting approval.” A final paragraph is insufficient if the app sent the brief early or ignored an unreadable document.

Run the same representative task on the existing model and Opus 5.5 in a staging environment with disposable data. Record the model ID, explicit effort, input and output limits, prompt version, tool definitions, and any fallback policy. Ask the reviewer to score: did it use approved evidence, were claims cited, did it identify unknowns, was the draft saved exactly once, and did it stop before sending? The accepted outcome is the entire journey, not one answer. Do not claim the two runs are a statistically meaningful model comparison; a single case is a branch demonstration.

Now inject four bounded failures. First, deny access to one document. The assistant should report the missing source and avoid inventing its content. Second, interrupt a tool result before completion. The app should not mark the brief complete or replay a non-idempotent save blindly. Third, construct a long conversation that reaches a context boundary in a safe test environment. The UI should expose that the brief is incomplete and offer a validated resume or a fresh task, depending on your design. Fourth, use a policy-sensitive but legitimate request from your own product scope to observe a refusal branch; record whether a fallback is permitted, how the user is told, and whether any draft or outbound message already exists. Use harmless fixtures and approved data.

The team can then tell a customer what happened: “Two of three sources were reviewed. The third was unavailable. A draft was saved, but it has not been shared. Review the gaps or retry source access.” That sentence is a better product result than either a false “Done” or a generic “Something went wrong.” It is derived from app events and artifact state, not a model’s self-report.

Use this stop-state acceptance matrix

Copy the table into a release ticket and replace examples with your actual routes and effects. The expected state is a product decision; the provider signal is only one input. A row passes only when the UI, durable job record, and external side effects agree.

The tool-call guide explains that client tool calls require a returned tool result, while some server tool work is handled within the request. The streaming guide describes how the response arrives in events. Neither document can decide your business state; they tell your implementer which events must not be dropped. If you stream tool arguments before validation, Anthropic’s fine-grained tool streaming note warns that partial or invalid JSON is possible. A visible fragment is not authorization to execute a half-formed action.

Fallback and retry need a product policy

Anthropic offers refusal and fallback mechanisms, including explicit distinctions between a refusal and a transport error. Your policy should say which product tasks may fall back, which model is allowed, which safeguards remain, and which side effects must be reconciled first. A model that answers after a refusal can still violate the product’s own boundary. For regulated, sensitive, or high-consequence tasks, the safe outcome may be a human handoff or an explanation of limits rather than a second model attempt.

A retry must also be aware of effects. Suppose the agent invoked “save draft,” the network timed out before the browser saw confirmation, and the app starts the whole turn again. If “save draft” creates a new document each time, the customer may see duplicates. If the action were “send message,” the cost of ambiguity would be higher. Use an application-generated action ID or other idempotency control where available, and reconcile the external system before retrying. Do not ask the model whether it thinks it sent something; check the effect ledger or service response.

A fallback can change user-visible output and cost. The Anthropic fallback documentation describes model identity and attempt information in responses, including cases where streaming and non-streaming behavior differ. Preserve the serving model and attempt count in the receipt. Evaluate fallback quality separately on your task set. If the fallback has a narrower capability or different privacy promise, the product may need to tell the user before continuing. Those disclosure choices depend on your product and commitments, not on a universal model rule.

Evaluate accepted outcomes, not headline price

A migration gate should compare a fixed, representative set of tasks under recorded settings. Build a small task bank from permissioned examples: easy single-turn answers, multi-source drafts, long conversations, tool errors, refusal boundaries, and actions requiring approval. For each case, write the expected outcome before running the new model. Do not change the prompt, tool schema, effort, and model simultaneously unless you can isolate which change caused a regression. If an interface must change to support the new model, keep a separate test of that change.

Score at least four measures. Task acceptance asks whether the output and effects satisfy the customer contract. State accuracy asks whether the UI correctly describes completed, incomplete, declined, and waiting work. Side-effect integrity checks duplicates and unauthorized actions. Cost per accepted outcome includes model usage, retries, fallback, and human repair. Add latency to a meaningful product milestone, such as first truthful progress and final approved draft, rather than only time to first token. The effort guide explicitly treats effort as a tradeoff; your task bank determines where the tradeoff is acceptable.

Set a release rule before seeing the new model’s attractive demos. For example: no unauthorized sends in the test set; every injected stop branch gets the correct state; no required source disappears without notice; and the median accepted-outcome cost stays within the team’s budget. These are example criteria, not measured thresholds for Opus 5.5. A small team can use ten carefully chosen cases to find serious integration defects, then expand coverage as traffic grows. Ten cases cannot prove a model’s overall reliability, so keep monitoring after launch.

Roll out with a receipt and a rollback trigger

The founder does not need to read every trace. Ask the implementer for one page containing the task bank version, model and effort settings, branch coverage, failed cases, customer-facing screenshots, effect reconciliation, cost calculation, owner, and rollback rule. Keep a link to raw traces with sensitive data appropriately protected. The receipt should say what was actually tested and what remains unknown. It should distinguish a model refusal from an app failure and show at least one deliberate recovery path.

A practical rollout can start with internal users, then a small permissioned cohort, then a larger share after observing real stop states. Monitor refusal rate, context-limit rate, incomplete-task rate, repeat actions, progress timeouts, human repairs, and accepted outcomes. Watch changes by task type, because an aggregate success rate can hide a broken high-value workflow. Set a rollback trigger based on customer harm and state misclassification, not just API error rate. An API returning HTTP 200 for a refusal illustrates why transport health alone is insufficient.

The migration guide recommends testing in development before production and rebaselining cost and latency. That is sound but broad. The concrete founder gate is narrower: can the team demonstrate that every important stop state becomes a truthful product state, that completed and incomplete work are distinguishable, and that no external action is repeated or hidden? If yes, the model change can be judged on its actual customer value. If no, a cheaper or stronger model can still make the product less reliable.

Where this framework applies, and where it does not

Use this gate for apps where a model works through multiple steps, calls tools, saves artifacts, or acts on a user’s behalf. It is especially useful when the same customer request can end in completion, refusal, partial work, or human approval. A simple, stateless text box may need only a much smaller version: check the response status, output limit, refusal handling, and error copy. Do not build a complex orchestration layer for a one-shot draft generator without a real user problem.

This article is also not a claim that Opus 5.5 commonly “quits early.” The public migration documentation identifies interface changes and stop states; it does not provide a measured rate of customer-visible abandonment in your product. Nor is every early stop a defect. Refusal can be correct, context limits can be a predictable capacity boundary, and a tool handoff is normal operation. The failure is calling all of them “done,” “broken,” or “the model’s personality” without checking the evidence.

The transferable lesson is a product one: a model response is one event in a customer journey. A safe launch joins provider signals, tool records, side effects, and honest UI language into a single state the user can act on. Opus 5.5 gives teams a timely reason to audit that contract. The acceptance matrix and receipt make the audit repeatable when the next model arrives.

References

• Anthropic, Introducing Claude Opus 5.5
• Anthropic, Migrating to Claude Opus 5.5
• Anthropic, Stop reasons and fallback
• Anthropic, Refusals and fallback
• Anthropic, Effort
• Anthropic, Context windows
• Anthropic, Prompting Claude Opus 5.5
• Anthropic, Handle tool calls
• Anthropic, Streaming messages
• Anthropic, Fine-grained tool streaming