With Claude Sonnet 5 landing close to Opus 4.8 at less than half the price, many teams will want to shift workloads down to save money. Done carelessly, that can hurt quality or even raise costs. Done well, it captures real savings with minimal risk. Here is a practical migration plan.
Step 1: Map your workloads
Before changing anything, list what you currently run on Opus 4.8 and sort each workload into one of three buckets:
- Routine work. Standard features, bug fixes, tests, tool use, documentation. These are strong candidates for Sonnet 5.
- Hard work. Deep debugging, large multi-file refactors, high-stakes architecture, reduced-guardrail security tasks. Keep these on Opus 4.8.
- Uncertain. Anything you are not sure about. These get A/B tested.
The Sonnet 5 vs Opus 4.8 comparison gives the decision rule: Opus 4.8 still leads on the hardest tasks (69.2 vs 63.2 percent on SWE-bench Pro), but Sonnet 5 handles the bulk of work well.
Step 2: Switch the routine bucket first
Change the model string from claude-opus-4-8 to claude-sonnet-5 for routine workloads. In Claude Code, use /model. In Aider, change --model. Through the API, change the model field. Start with the lowest-risk workloads so any surprises are cheap.
Step 3: Handle the new tokenizer
This is the step migrations skip and regret. Sonnet 5 uses an updated tokenizer that can map the same text to up to 1.35 times more tokens. Do not assume your bill drops by the full sticker-price difference. Instead:
- Run a representative sample through both models.
- Record actual input and output token counts.
- Compute the real cost delta, not the sticker delta.
See Sonnet 5 pricing explained for the full math.
Step 4: Set effort levels deliberately
Sonnet 5 exposes low, medium, high, max, and x-high effort. Default migrated workloads to medium, drop routine tasks to low, and raise to high only when needed. Avoid the trap of running everything at x-high to match Opus, since at that level Sonnet 5 can cost more than Opus 4.8 at a comparable accuracy point. See the effort levels guide.
Step 5: A/B test the uncertain bucket
For workloads you are unsure about, run Sonnet 5 and Opus 4.8 side by side on the same inputs and compare outputs. Look at success rate, number of steps, and total cost. Keep on Opus only the workloads where the quality difference clearly justifies the price.
Step 6: Keep a fast escalation path
Even after migrating, keep Opus 4.8 one switch away. In a two-model setup, Sonnet 5 handles most work and Opus 4.8 takes the hard escalations. A router like OpenRouter makes this clean; see the Sonnet 5 OpenRouter setup.
A sample migration timeline
For a team running Opus 4.8 in production, a low-risk migration might span two weeks:
- Days 1 to 2: Map workloads into the routine, hard, and uncertain buckets. Instrument token usage so you have a clean Opus 4.8 baseline.
- Days 3 to 5: Switch the routine bucket to Sonnet 5 in a staging environment. Run your normal test suite and compare outputs.
- Days 6 to 8: Run the uncertain bucket through both models on identical inputs and score the results on success rate, steps taken, and cost.
- Days 9 to 10: Promote the validated routine and uncertain workloads to production on Sonnet 5. Keep the hard bucket on Opus 4.8.
- Days 11 to 14: Monitor real cost and quality. Tune effort levels down where medium or low is sufficient.
This staged approach means any surprise shows up cheaply in staging rather than expensively in production.
What usually goes wrong
Two migration mistakes are common. The first is assuming the bill drops by the full sticker-price difference. It does not, because Sonnet 5’s new tokenizer can raise effective token counts by up to 1.35 times. Always measure real tokens. The second is running everything at high or x-high effort to feel safe, which can make Sonnet 5 cost more than Opus 4.8 would have. The whole point of migrating is to run cheaper effort for routine work. See the effort levels guide and pricing explained.
Measuring success
Define success before you start. Good metrics are cost per completed task, task success rate, and the share of work that still needs escalation to Opus 4.8. If Sonnet 5 handles most of the routine and uncertain buckets at a clearly lower cost per completed task, the migration worked. If quality drops on specific workloads, move just those back to Opus 4.8 rather than abandoning the migration.
Frequently asked questions
Will migrating from Opus 4.8 to Sonnet 5 always save money? Usually, but not automatically. The new tokenizer raises effective token counts, and maxing out effort can cost more than Opus. Measure your real costs.
What should stay on Opus 4.8? The hardest coding, deep debugging, high-stakes architecture, and reduced-guardrail security work.
How hard is the technical migration? Often just a model-string change. The real work is validating quality and cost on your workloads.
Can I run both models at once? Yes. A two-model setup with Sonnet 5 as default and Opus 4.8 for escalations is the recommended pattern.
Do I need to change my prompts when migrating? Usually not the wording, but you should re-test them. The new tokenizer changes token counts, and Sonnet 5’s stronger agentic behavior can change how it interprets loosely specified instructions. Tighten prompts where needed.
How long should a careful migration take? For most teams, one to two weeks: a few days to map and baseline, a few to validate in staging, then a phased promotion to production while monitoring cost and quality.
The bottom line
Migrating to Sonnet 5 is mostly a model-string change plus disciplined validation. Move routine work first, keep the hard tasks on Opus 4.8, measure real token costs against the new tokenizer, and set sensible effort defaults. Do that and you capture the savings without the risk. Start with the complete guide.