Reviewed 11 October 2026
Opus 4.7 was an April 2026 release. It is no longer the newest model in Anthropic’s October catalog. Its migration lesson remains useful: an unchanged price per token does not guarantee unchanged cost per task, and a model upgrade can alter input usage, reasoning and tool behaviour.
Direct answer: retain the April facts as historical evidence, then select your current target from the official catalog. Recount tokens, replay real tasks, verify supported request parameters and stage the rollout before changing production defaults.
What the April announcement actually established
Anthropic announced Opus 4.7 on 16 April 2026. The release described a new xhigh effort level and an updated tokenizer that could map the same input to roughly 1.0–1.35 times as many tokens, depending on content. It also warned that higher effort could increase output usage during agentic work. Those are scoped release facts, not a universal 14–35% invoice increase.
The launch’s standard rates were $5 input and $25 output per million tokens. Current pricing still distinguishes legacy model rates from newer catalog rates, cache writes, hits and batch use. Read the exact row and processing mode instead of treating “Opus” as a single permanent price.
The current model overview includes Fable 5.1, Opus 5.5, Sonnet 5.5 and Haiku 5.5. A team migrating today should first decide whether it needs 4.7 for a validated legacy dependency or a current model for a new deployment. Do not repeat April’s “latest” language in an October recommendation.
Unsupported claims about 47 migration cases, 14 production deployments and private incident results are removed. This guide provides a migration procedure; it does not claim those tests were performed or that a new model fixes every production issue.
Inventory the complete request surface
| Surface | Inspect | Failure to catch |
|---|---|---|
| Model identifier | Exact platform ID and lifecycle | Alias silently changes behaviour |
| Request parameters | Supported effort, thinking, sampling and output controls | Old parameter causes rejection or ignored assumptions |
| Prompt and tools | Instructions, schemas and allowed actions | Different interpretation or unsafe tool choice |
| Token accounting | Input, output, cache and tool overhead | Price row unchanged while usage grows |
| Context and images | Limits, formats and actual document fidelity | Nominal capacity mistaken for quality |
| Operations | Timeout, retry, logging and fallback | A faster draft creates an ambiguous write |
Export actual request configurations before editing them. Include SDK version, platform, system prompt, tools and any middleware that modifies requests. A migration checklist copied from another version can be wrong. Validate every parameter against the target model’s documentation and a real test call.
Do not change model, prompt, tool schema and orchestration simultaneously unless the change requires it. Separate changes make regressions easier to diagnose. Preserve an accepted baseline so a failed upgrade can be reversed with a known configuration rather than reconstructed from memory.
Recount tokens and cache economics
Use representative inputs to compare token counts and billed usage. Include tables, code, non-English text and long conversations because tokenizer effects can vary with content. Keep the same raw input when measuring the historical tokenizer effect; otherwise a prompt rewrite confounds the comparison.
A hypothetical input containing 100,000 tokens under an old configuration might contain 120,000 under a new tokenizer. At $5 per million, the input charge changes from $0.50 to $0.60. That is 20% more input expense. It does not establish a 20% increase in total cost because output, cache behaviour, tools and retries remain separate.
Anthropic’s caching guide documents five-minute and one-hour cache options and usage reporting. Check the target model’s minimum eligibility, cache placement, expiry and hit rate. A cache write has a different price from a hit. A new model identifier or changed prefix can invalidate the economic assumptions even when the business task is unchanged.
Keep mutable customer data out of a shared cached prefix unless the design correctly scopes it. Test changed permissions and policy versions. Cache optimization must not cause one tenant to receive another tenant’s context or preserve an obsolete instruction after the source changed.
Replay the failures that matter
Build a held-out set from the actual workload. Include missing fields, conflicting policy, incorrect identifiers, unavailable tools and a write whose response is lost after the server processes it. Assess final authoritative state, not only whether the model returned a plausible summary.
For coding, run meaningful repository checks and inspect the diff. For document work, verify extracted numbers and source passages. For support, verify policy and escalation. Compare quality, elapsed time, review effort and cost separately. Do not average an unauthorized action into a harmless score for writing style.
Retain outputs and error responses. Some migrations fail because the API rejects a parameter; others because the output is semantically worse despite successful responses. Those require different remedies. Treat refusals and uncertainty as behaviours to inspect against the intended task rather than automatically scoring them as defects.
Test the fallback path too. It should preserve data and permission boundaries and avoid duplicate writes. A fallback model can have different limits or tool support. It is an operational component that needs its own acceptance evidence, not an emergency name inserted into the code.
Stage the switch and keep the rollback
Begin with read-only tasks or shadow execution where outputs can be reviewed without actions. Move a small cohort after the target passes the acceptance gates. Record the exact model/version and configuration alongside each result. Monitor failure classes, latency and usage against the baseline.
Choose rollback triggers before the cohort starts. Examples include unsupported request errors, a material increase in incorrect policy answers, unacceptable p95 latency or any unauthorized mutation. Thresholds belong to the workflow owner and risk boundary; no universal readiness percentage replaces them.
After rollout, update the runbook, pricing worksheet and retained acceptance set. Remove dead parameters and obsolete fallback configurations only after confirming they are no longer needed. Read the current model decision guide and action validation guardrails for adjacent decisions. Your next step is an inventory of real requests and a small replay test, not a blind replacement of the model string.
Frequently asked questions
Is Opus 4.7 still the newest Claude model?
No. Anthropic’s current catalog lists newer families. Opus 4.7 is retained here as a historical migration case.
Did its tokenizer guarantee a 35% bill increase?
No. The announcement described roughly 1.0–1.35 times input tokens depending on content. Total cost also depends on output, caching, tools and retries.
Can I reuse an old migration checklist unchanged?
No. Verify parameters, limits, platform identifiers and SDK behaviour for the exact target model.
What should trigger rollback?
A predefined quality, latency, request compatibility or risk failure, including unauthorized actions and ambiguous writes.
Sources checked 11 October 2026
Research Path