Migrating an application to Opus 5.5 is not just changing a model string. The integration must still produce valid requests, interpret every response block it needs, and complete its tool loop without repeating external actions.
This is a migration test plan based on Anthropic's Opus 5.5 migration guide, checked October 10, 2026. It is not a report of a paid API test or a guarantee for a particular gateway.
Audit the request contract before the first call
The official guide documents always-on adaptive thinking and rejects older explicit thinking configurations. It also rejects forced tool_choice values any and tool; supported alternatives include auto or none. Thinking-block validity and supported computer-use tool versions need review as well.
Find these fields in the code that actually constructs the request—not only in a sample configuration. A wrapper, SDK default, or gateway transformation can add a value after your application has omitted it.
Record the model ID, provider, SDK version, and relevant request options. Redact credentials before saving a fixture. Do not assume that a provider alias with “Opus” in its display name resolves to this version.
Test four behaviors separately
A successful HTTP response is only the first check. An application that reads only the first content block as text may fail when blocks have another type. A tool call that parses successfully may still contain an invalid business action.
Use the regression-evaluation guide to keep the initial task, expected outcome, and scoring rule stable across old and new configurations.
Preserve your application's authority boundary
Changing from forced tool selection to automatic tool selection does not make the model the final authority over what the application may do. Validate arguments, check the requested operation against the user's authorization, and require the same confirmations as before.
For example, a support assistant might propose a refund tool call. The application still needs to validate the order, amount, and user's authority. A model upgrade should not turn that proposal into permission to transfer money.
For coding agents, use a harmless tool or test repository first. Keep deployment, purchases, credential changes, and destructive operations outside the initial migration trial.
Make retries safe before adding them
An uncertain response does not prove that the previous external action failed. If a tool changed state before the connection dropped, blindly replaying the request could duplicate the action.
Keep operation identifiers where your system supports them, inspect the authoritative result, and retry only the missing step. Separate transport recovery from task recovery. The appropriate policy depends on your application's contract, not just the model provider's status code.
Evaluate cost only after correctness
Once the integration completes its task safely, compare whole-task usage and acceptance quality. Use the Opus versus Sonnet comparison for model-selection criteria and the API cost guide for accounting across calls.
Do not announce a cheaper migration based only on one request. Include failures and repairs, and distinguish measured results from vendor claims.
Keep API migration separate from choosing a model in a client
Selecting an available model inside a supported agent client and maintaining your own API integration are different responsibilities. Do not ask end users to edit raw request fields when the managed client owns them.
If you want Agent.Space to provide a supported project workflow, review its developer API guide and current product pricing. Verify the actual supported route before starting a workspace; a first-party API migration guide is not proof that a third-party runtime exposes every option.