Claude Opus 4.7 is GA: the migration checklist for agentic coding

Claude Opus 4.7 is now generally available as Anthropic’s Opus 4.6 upgrade, with unchanged $5 input and $25 output per million tokens pricing and availability across Claude products, the API, Bedrock, Vertex AI, and Microsoft Foundry. If you run coding workflows, the story is not just “better coding”: Opus 4.7 changes the migration surface, the control surface, and the safety surface. (Source: Anthropic announcement)

The important idea is not “Opus 4.7 is better at coding.” It is that it tightens the delegation contract for long-running software work: more literal instruction following, effort-scoped autonomy, and a handful of harness parameters that can now hard-fail if you leave them in place. (Sources: Anthropic announcement, Migration guide: Opus 4.7)

Claude Opus 4.7 is Anthropic’s generally available Opus model positioned as a direct upgrade over Opus 4.6, with unchanged pricing and new controls aimed at long-running, tool-heavy work. In practice, upgrading is both a model id swap (claude-opus-4-7) and a harness audit. (Sources: Anthropic announcement, Models overview)

Primary sources: Anthropic’s GA announcement, the Opus 4.7 migration guide, and the effort-control docs that define xhigh. (Sources: Anthropic announcement, Migration guide: Opus 4.7, Effort docs)

What shipped

From Anthropic’s announcement and accompanying docs, the Opus 4.7 release includes: (Sources: Anthropic announcement, Models overview)

• Anthropic is positioning Opus 4.7 as a generally available, direct upgrade over Opus 4.6 with particular gains on advanced software engineering and the hardest tasks. (Source: Anthropic announcement)
• The model is available via the Claude API as claude-opus-4-7, and across Bedrock, Vertex AI, and Microsoft Foundry, with the same $5 per input MTok and $25 per output MTok pricing Anthropic quotes for Opus. (Sources: Anthropic announcement, Models overview)
• Opus 4.7 is described as better at literal instruction following, including a warning that prompts tuned for earlier models can produce “unexpected results” because Opus 4.7 takes instructions more literally. (Source: Anthropic announcement)
• Opus 4.7 adds a new xhigh effort level between high and max, and Anthropic recommends starting at high or xhigh for coding and agentic use cases. (Sources: Anthropic announcement, Effort docs)
• The release includes higher-resolution vision, with support for images up to 2,576 px on the long edge, framed as enabling dense screenshot reading and diagram understanding. (Source: Anthropic announcement)
• Anthropic is rolling out real-time cyber safeguards that can block requests suggesting prohibited or high-risk cybersecurity use, with an application-based Cyber Verification Program for eligible defensive users. (Sources: Anthropic announcement, Cyber safeguards / CVP)
• The migration notes for Opus 4.7 include token-count changes from a new tokenizer and explicit API-level breakages that teams should remove from harnesses. (Source: Migration guide: Opus 4.7)

The key benefit is not raw coding scores. It is safer delegation contracts for long runs.

Opus 4.7 is positioned as more literal about instructions and more consistent over long runs, which is exactly what you need when you are trying to delegate “finish the task and prove it’s correct,” not “produce plausible code.” (Sources: Anthropic announcement, Migration guide: Opus 4.7)

Quotable stat: Anthropic reports a 13% lift on its 93-task coding benchmark versus Opus 4.6, and frames the benefit as reduced friction in complex, long-running coding workflows. (Source: Anthropic announcement)

Practitioner payoff: a stricter instruction follower is easier to manage in parallel. The flip side is that prompt sloppiness stops being a minor annoyance and becomes a real failure mode. (Source: Anthropic announcement)

The shift is not “use Opus 4.7 for coding.” It is “treat Opus 4.7 as a new delegation contract”: literal instructions, effort-scoped autonomy, and harness knobs that can now break migrations. (Sources: Anthropic announcement, Migration guide: Opus 4.7)

Snippet answer (what changed vs Opus 4.6): Opus 4.7 is positioned as a direct upgrade for long-horizon work: more literal instruction following, new effort controls including xhigh, higher-resolution vision, and migration changes that can break older harnesses (for example, certain thinking and sampling parameters). Treat it as an upgrade in both capability and operational contract, not a pure model id swap. (Sources: Anthropic announcement, Migration guide: Opus 4.7, Effort docs)

Migration: what can 400 your requests (and what to remove from payloads)

If you integrate Claude through an SDK, a gateway, or an agent harness, the highest-leverage work is a request-payload audit. The migration guide is explicit that some harness knobs can now produce 400 errors on Opus 4.7, and the safest path is often “remove the knob,” then re-add behavior with prompts and effort. (Source: Migration guide: Opus 4.7)

Operator note (first-hand): before you flip production traffic, grep your codebase for thinking: {type: "enabled", budget_tokens, temperature, top_p, and top_k, then remove them from Opus 4.7 payloads and re-run evals. Make the payload minimal first, then add behavior through prompting and output_config.effort. (Source: Migration guide: Opus 4.7)

1. Manual extended thinking is no longer supported

Opus 4.7 removes manual extended thinking in the shape thinking: {type: "enabled", budget_tokens: N} and directs teams to use thinking: {type: "adaptive"} with the effort parameter as the control for depth. If your harness sets manual thinking by default, treat this as a hard migration task: the request will error until you remove or replace it. (Source: Migration guide: Opus 4.7)

2. Sampling knobs can become breaking changes

The migration guide states that setting temperature, top_p, or top_k to any non-default value can trigger a 400 error on Opus 4.7. If your stack sets temperature: 0 for determinism, the migration path is “remove the knob” and enforce behavior through prompting, structured outputs, and tests. (Source: Migration guide: Opus 4.7)

3. Tokenization and token counting assumptions change

Quotable stat: the migration guide notes the new tokenizer can map the same text to roughly 1.0x to 1.35x as many tokens, depending on content. If you rely on client-side token estimation or strict ceilings, re-baseline on Opus 4.7. (Source: Migration guide: Opus 4.7)

Effort as a control plane: why xhigh is a workflow choice, not a vibe

Effort is Anthropic’s control for how eagerly Claude spends tokens, trading thoroughness for speed and cost. For Opus 4.7, the docs add xhigh between high and max, and recommend xhigh as the starting point for coding and agentic work, with the API default staying high unless you set it explicitly. (Source: Effort docs)

Snippet answer (what is xhigh effort): xhigh is an Opus 4.7 effort level between high and max intended for long-running agentic and coding work. The API default remains high unless you set effort explicitly. (Source: Effort docs)

Decision rule for teams: start at xhigh for long-running tool use, use high for interactive loops, and treat max as an eval-gated option. (Source: Effort docs)

Token and cost planning: same $/MTok, different effective budgets

Opus 4.7 pricing is stated as unchanged at $5 per million input tokens and $25 per million output tokens. The operator trap is assuming your costs are unchanged: the migration guide’s tokenizer note means token counts can move even when the $/MTok line does not. (Sources: Anthropic announcement, Migration guide: Opus 4.7)

Practitioner payoff: measure “success per MTok,” not “tokens per response,” then adjust budgets based on solved-task cost at high versus xhigh. (Sources: Effort docs, Migration guide: Opus 4.7)

Safety posture: real-time cyber safeguards and CVP boundaries

Cyber Verification Program (CVP) is Anthropic’s application-based program designed to reduce interruptions for legitimate defensive work that overlaps with “high-risk dual use” categories that are blocked by default. CVP does not apply to prohibited-use categories, and the help-center page notes additional eligibility and surface constraints. (Source: Cyber safeguards / CVP)

Quotable constraint: the CVP page states the program is not available on Amazon Bedrock or Google Vertex AI at this time, and that organizations on Zero Data Retention (ZDR) are not currently eligible. (Source: Cyber safeguards / CVP)

This matters for agentic coding because “tool-using developer agent” and “security tooling” can look similar at the request layer. Plan for refusals and escalation paths in security-adjacent workflows. (Sources: Anthropic announcement, Cyber safeguards / CVP)

Context: why controls and safeguards are shipping with the model

The Opus 4.7 announcement frames the release as part of a sequencing strategy: Anthropic says it is keeping its most capable cyber-focused preview model limited while testing safeguards on less capable models first, and it positions Opus 4.7 as the first such model to ship with real-time cyber safeguards. (Source: Anthropic announcement)

If you are building long-running agents, this is the adjacent curve to track: the control surfaces that shape long runs (effort, budgets) plus the guardrails that define what the model will refuse at runtime. For the control-plane side, see our breakdown of harness vs sandbox for long runs, which matches the “control vs execution” split you will end up building anyway. (Source: Anthropic announcement)

Security note: treat agent upgrades as security upgrades too. If your stack accepts tool configuration from users or repos, the failure mode is not “the model is wrong,” it is “config becomes execution.” For a concrete example, see our coverage of MCP STDIO security risks. (Inference: operator framing based on AgenticWire coverage.)

Adoption notes: decision rules for teams

Treat Opus 4.7 as a harness and policy migration, not a pure model swap. (Sources: Migration guide: Opus 4.7, Effort docs)

Decision rules for teams:

• Audit payloads before routing production traffic to claude-opus-4-7: remove manual extended thinking and sampling parameters, then re-test token-count assumptions. (Source: Migration guide: Opus 4.7)
• Start at xhigh for long-running agent runs, then step down only if evals hold at lower effort. (Source: Effort docs)
• For security-adjacent workflows, document CVP eligibility and build refusal-safe UX. (Source: Cyber safeguards / CVP)
• When behavior changes, assume more literal instruction following first and tighten invariants. (Source: Anthropic announcement)

Related coverage

• OpenAI's Agents SDK update: harness vs sandbox for long runs - Why long-running agents need a control plane and a compute plane.
• Microsoft Agent Framework 1.0 ships graph workflows and MCP - Tool contracts and explicit workflow topology as reliability primitives.
• MCP STDIO risk: when config becomes command execution - How tool surfaces become security boundaries in real systems.