Migrating from Claude Opus 4.7 to Opus 5: What Actually Changed for Agentic Coding

If you run coding agents in production, you have already seen the Opus 5 announcement. The benchmark charts look great. The blog posts all say the same three things. But none of them tell you what breaks when you flip the model string in your own pipeline.

I migrated a working agent stack from Opus 4.7 to Opus 5 last week. Here is what actually mattered, what did not, and what I would do differently.

The Cost Math Is the Real Story

Everyone leads with capability. The bigger deal is price per completed task.

Opus 5 landed at roughly half the cost per task compared to the previous frontier tier, with list pricing unchanged. That combination is unusual. Normally you pay more for a better model. Here you pay the same rate but finish in fewer tokens.

For agentic workloads the effect compounds:

• Fewer retry loops means fewer wasted tool calls
• Better first-pass tool selection cuts your average turn count
• Shorter reasoning chains reduce input tokens on every subsequent turn

In my own harness the average task went from 14 turns to 9. The per-token price did not change. The bill dropped by about a third anyway.

Measure this yourself before and after. Track turns per completed task, not tokens per call. Token counts lie when the model is making better decisions.

Prompts You Should Actually Rewrite

Most of your prompts will carry over untouched. A few categories will not.

Over-Specified Tool Instructions

Older models needed hand-holding on when to call which tool. Long conditional blocks like "if the user asks about X, first call search, then call fetch, then summarize" were load-bearing.

Opus 5 routes better on its own. Those blocks now fight the model instead of helping it. I deleted about 40 lines of tool routing logic from my system prompt and tool selection accuracy went up.

Replace prescriptive routing with descriptive tool definitions. Write good tool descriptions and let the model plan.

Defensive Retry Scaffolding

If you built retry wrappers because the model kept returning malformed JSON, test whether you still need them. Structured output reliability improved noticeably. Keep the wrapper as a safety net, but drop the aggressive reprompting.

Context Padding

Some teams pad context with examples to stabilize behavior. With a stronger model that padding is pure cost. Trim it and watch your eval scores.

What Did Not Change

Be realistic about the parts that stay the same.

• Long-horizon planning still drifts past a certain task length. Checkpointing is still your job.
• The model is still confidently wrong on unfamiliar codebases. Field reports on agent-driven modernization consistently flag this. Speedups are real, but so is eloquent nonsense.
• Rate limits and concurrency still shape your throughput more than model choice does.
• Your evaluation harness is still the only thing standing between you and a silent regression.

Do not skip your eval suite because the model is better. Better models fail in less obvious ways.

A Migration Checklist That Works

Here is the sequence I would follow again.

1. Pin your current model string and capture a baseline. Run your full eval set and record turns per task, cost per task, and pass rate.
2. Swap the model string in a staging branch only. Change nothing else.
3. Run the same evals. Compare against baseline before touching prompts.
4. Remove prescriptive tool routing from system prompts. Re-run evals.
5. Trim retry scaffolding and few-shot padding one at a time. Re-run after each.
6. Review failure cases manually. Automated scores hide category shifts.
7. Roll out behind a flag with per-request model selection so you can revert instantly.

The discipline here is changing one variable at a time. Teams that swap the model and rewrite prompts simultaneously cannot tell which change helped.

Keep a Router, Not a Favorite

The frontier moved from three labs to five this year. Several strong open-weight models shipped in the same window. Betting your architecture on one provider is a bad trade.

Structure your code so the model is a per-task configuration value:

• Cheap classification and routing steps do not need frontier models
• Long-context synthesis and code generation usually do
• Bulk summarization is often fine on an open-weight model you host

I keep a small routing table mapping task type to model. When a new release lands, I benchmark it against the table rather than rewriting the application.

Conclusion

Migrating to Opus 5 is mostly an economics story with a prompt-simplification bonus attached. The key takeaways:

• Measure turns per completed task, not raw tokens
• Delete prescriptive tool routing and let the model plan
• Keep your eval harness and change one variable at a time
• Treat the model as configuration, not architecture

The migration itself took me an afternoon. Reworking the prompts to take advantage of it took a week and delivered more value.

If you are running agents in production, get started by capturing a proper baseline this week, before you touch anything. You cannot measure an improvement you never benchmarked. Have a migration story of your own? I would like to hear what broke on your stack.