Claude Opus 4.7: What's Actually Better and When to Upgrade

Every model release comes with the same question: is this worth switching?

With Opus 4.7, the answer is more complicated than usual. The headline is accurate: same $5/$25 pricing, real benchmark gains across 12 of 14 reported tests. But three things make this upgrade decision less obvious than it looks: a new tokenizer that can raise your real costs by up to 35%, a set of breaking API changes that require code updates, and at least one workflow type where 4.7 performs worse than 4.6.

This is a practical breakdown, not a benchmark post. The goal is a clear decision framework for whether to switch now, switch carefully, or hold.

What's genuinely better

The gains in Opus 4.7 are real and concentrated in specific areas.

Coding benchmarks jumped significantly. SWE-bench Pro climbed from 53.4% to 64.3%, and SWE-bench Verified went from 80.8% to 87.6%. CursorBench, which tests real-world coding inside an IDE environment, went from 58% to 70%. These are not marginal improvements.

Agentic efficiency improved by 2x. Opus 4.7 averaged 7.1 LLM calls to complete the same tasks that Opus 4.6 needed 16.3 calls for. p50 latency dropped from 242 seconds to 183 seconds. The model is also 60% less likely to drop subtasks in long agentic sequences compared to its predecessor. For multi-step agentic workflows, this is the most consequential improvement in the release.

The model proactively verifies its own work. In agentic contexts, Opus 4.7 writes tests, runs them, and fixes failures before surfacing results. This "verify before reporting" behavior reduces back-and-forth on complex tasks without you having to prompt for it explicitly.

Vision capability changed dramatically. Vision accuracy went from 54.5% to 98.5%, and maximum image resolution tripled from 1568px to 2576px (1.15MP to 3.75MP). The model can now read small text in screenshots, parse dense UI mockups, and extract information from high-resolution photos that previous versions couldn't process cleanly. If your workflows involve image analysis or document processing, this is a substantial capability change.

The new effort system

Opus 4.7 ships with a redesigned effort parameter.

The scale now has five levels: low, medium, high, xhigh (new), and max. Anthropic recommends starting with xhigh for coding and agentic use cases, and the internal benchmark numbers support that: xhigh scores approximately 71% on the Agentic Coding benchmark while consuming around 100k tokens. Max effort only reaches 74.5%, but consumes over 200k tokens. For most production workloads, xhigh is the better cost-performance tradeoff.

The practical change from Opus 4.6 here is not just the new level; it's that you now have explicit control over where the model sits on the intelligence-vs-cost curve.

There's also a new task budgets feature in beta. Pass the task-budgets-2026-03-13 beta header and add task_budget: {type: "tokens", total: N} to output_config, with a minimum of 20k tokens. The model sees a running countdown and prioritizes work accordingly, which is useful for long-running agentic loops where you want graceful completion rather than abrupt cutoff when token limits are hit.

What got worse

Three things to understand before flipping the switch.

Multi-source web research regressed. This is the clearest regression in 4.7. When the agent browses, reads several pages, and synthesizes findings into a report, 4.7 runs redundant queries, source attribution accuracy drops, contradiction detection weakens, and citation specificity falls. Opus 4.6 outperforms 4.7 on this specific workflow. If multi-source web research synthesis is your primary use case, this upgrade is not ready for you yet.

Instruction following got more literal. Opus 4.7 follows instructions precisely rather than inferring what you meant. Where Opus 4.6 would sometimes generalize an instruction from one context to a related one, 4.7 doesn't. Prompts that relied on 4.6's loose interpretation will produce narrower, more literal outputs. This is not uniformly bad, but it will break workflows where you relied on the model making reasonable inferences. You'll need to rewrite those prompts to be explicit.

The new tokenizer adds up to 35% more tokens. Opus 4.7 ships with a new tokenizer that can produce 1x to 1.35x as many tokens for the same input text, depending on content type. The rate card didn't change. Your invoice might. If you're running high-volume pipelines, measure your actual token counts on 4.7 before assuming your costs stayed flat.

The four breaking API changes

These require code changes, not just prompt updates.

budget_tokens is gone. The old way to control extended thinking depth (thinking: {type: "enabled", budget_tokens: N}) is removed entirely. The new approach is adaptive thinking: pass thinking: {type: "adaptive"} and the model decides how much to reason based on the task. You lose the ability to set an explicit thinking token cap.

thinking.display default changed. It used to default to "summarized", meaning you'd get a thinking summary in the response. In 4.7 it defaults to "omitted", meaning block.thinking comes back as an empty string unless you explicitly set thinking.display: "summarized" or "full". Any code that reads thinking blocks without checking for empty strings will silently produce blank output.

Temperature, top_p, and top_k now return 400. These parameters no longer work at non-default values on Opus 4.7. If your code sets any of them, the API returns a 400 error. Remove them from your request or update your error handling.

Prefilling assistant messages is blocked. Passing a partial assistant message to steer the output format returns a 400 error. Use system prompt instructions or output_config.format instead.

Decision framework

Here's where to land based on what you're actually building.

Switch now if:

• Your primary use case is coding, code review, or software engineering tasks
• You run multi-step agentic workflows and care about completion rate on long tasks
• Your workflows involve image analysis or high-resolution document processing
• You're building new pipelines without legacy 4.6 prompts to migrate

Switch after testing if:

• You have production prompts tuned to Opus 4.6's behavior: test your prompts against 4.7's more literal interpretation before deploying
• You're cost-sensitive and running high-volume workloads: measure actual token counts on 4.7 first, since the tokenizer change can add 35% to the bill
• You use any of the four broken API features: adaptive thinking migration is the most complex; plan the refactor before switching

Hold or keep 4.6 if:

• Your core workflow is multi-source web research synthesis: this is the one area where 4.6 outperforms 4.7 as of this writing

For most people, the upgrade is worth it. The 2x agentic efficiency alone justifies it for anyone running agent loops. But "most people" is not "everyone," and the tokenizer cost increase plus the four breaking changes mean this is a planned migration, not a one-line model ID swap.

The practical migration path: use model ID claude-opus-4-7-20260416, raise max_tokens to give headroom for the tokenizer change, and start with effort: "xhigh" for agentic tasks. If using xhigh or max effort, start max_tokens at 64k minimum.

Where Agent Teams fit

Agent Teams were introduced with Opus 4.6 in February 2026 and Opus 4.7 inherits them. If you've been using the orchestrator-worker pattern, 4.7 is a clear upgrade as the orchestrator model.

The 2x reduction in LLM calls matters most here: the orchestrator on Opus 4.7 completes planning and synthesis passes faster with fewer total invocations. The proactive output verification also reduces review cycles between orchestrator and worker.

For a detailed look at how to structure these workflows, see Multi-Agent Orchestration with Opus 4.7 Agent Teams.

The real upgrade story

"Same price, better model" is the headline. The more accurate description is: significantly better for coding and agentic work, with a meaningful regression on web research synthesis, and up to 35% more expensive in practice due to the tokenizer change.

That's not a reason to skip the upgrade. It's a reason to test on your actual use cases first, update your API code for the four breaking changes, and recheck your cost estimates before you go to production.

The model is better where it counts for most builders. Just don't assume the upgrade is frictionless.

Sources

[1] Claude Opus 4.7 release announcement: Anthropic. April 16, 2026. SWE-bench Verified 87.6%, vision accuracy, Agent Teams inheritance.

[2] What's new in Claude Opus 4.7:

. xhigh effort level, task budgets beta, image resolution specs, breaking changes.

[3] Claude Opus 4.7 vs 4.6 comparison:

. SWE-bench Pro/Verified/CursorBench numbers, 7.1 vs 16.3 LLM calls, p50 latency.

[4] Claude Opus 4.7 review (regressions): MindStudio . Web research regression detail: redundant queries, source attribution, contradiction detection.

[5] Claude Opus 4.7 pricing and tokenizer impact:

. 1x–1.35x token inflation from new tokenizer.

[6] Claude Opus 4.7 benchmark analysis:

. Vision accuracy 54.5% to 98.5%, CursorBench breakdown.

[7] Claude Opus 4.7 migration guide:

. Four breaking API changes with migration paths.

[8] Effort parameter documentation:

. Five effort levels, xhigh recommendation for coding and agentic tasks.

[9] Effort level cost-performance analysis: Claudefa.st. xhigh at ~100k tokens ≈ 71%; max at ~200k tokens ≈ 74.5%.

[10] Claude Opus 4.6 Agent Teams launch:

. February 2026. Agent Teams introduced with 4.6, not 4.7.