Claude Opus 5 Enables Reasoning by Default and Supports Mid-Conversation Tool Changes, Potentially Breaking Legacy Agent Configurations

Anthropic released Claude Opus 5 on July 24 under the API model identifier `claude-opus-5`. Standard pricing remains $5 per million input tokens and $25 per million output tokens. Its sole context specification is a 1 million-token window, and it can generate up to 128,000 tokens. Thinking is enabled by default. A research-preview fast mode offers up to roughly 2.5× faster output at twice the price; it improves output throughput but does not guarantee lower time to first token.

A more practical change for agent engineering is the beta “mid-conversation tool changes” feature. Applications can add or remove tools between turns while preserving prompt caching, eliminating the need to define the complete tool list from the first turn. This is useful for long-running tasks that load browser, database, or deployment tools in stages, and it can reduce the context cost of retaining tool schemas throughout a conversation. Another beta feature allows the server to select an Anthropic-recommended fallback model based on the refusal type.

Migration involves more than replacing the model name. With Opus 5, `thinking: disabled` cannot be set when effort is `xhigh` or `max`; legacy requests using those combinations will receive an HTTP 400 response. The minimum length for prompt caching has also been reduced from 1,024 to 512 tokens. Anthropic also cautions that the new model is more likely to verify its own work, expand task scope, and spawn subagents. Retaining scaffolding such as “check again” instructions or mandatory delegation may therefore add unnecessary token usage and latency.

GitHub Copilot is rolling out Opus 5 in phases across VS Code, the CLI, cloud agents, and multiple IDEs, but Business and Enterprise administrators must explicitly enable it through policy settings. Official performance claims are still based primarily on vendor testing, without complete, reproducible agent benchmarks. Engineering teams should prioritize rerunning evaluations for effort settings, tool calls, refusal rates, and cost, and test incompatible parameters before switching.