Migrating: Haiku 3 to Haiku 4.5
| Input / MTok | $0.25 → $1 |
|---|---|
| Output / MTok | $1.25 → $5 |
| Min cacheable prefix | 2,048 → 4,096 tokens |
| Effort levels | none → none |
| Thinking | budget-tokens → budget-tokens |
Migrating off a model that's already past retirement
The source model here has already passed its published retirement date — this isn't a forward-looking migration to plan for eventually, it's one that should already be complete. If you're reading this because a request against the old id just started failing, that's the retirement having actually taken effect, not a bug.
What actually improves on the move
Beyond simply working again, the destination model brings real capability the source never had — effort-level control was not available at all on the older generation, and per-token pricing context differs meaningfully between the two. Re-price your actual workload against the destination rather than assuming the relationship between the two models' costs matches whatever it happened to be historically.
Auditing for this id elsewhere in your systems
If one integration was still calling the retired id, it's worth checking whether any other service, script, or scheduled job in your systems does the same — an id this old tends to persist longest in exactly the kind of infrequently-touched code that nobody thought to audit until something broke. A repository-wide search for the literal id string, run once as part of closing out this migration, is a cheap way to catch a second occurrence before it becomes its own separate incident later.
Related
See the model ID you're calling has been retired for what to check first if this migration wasn't planned for and a production request just started failing, and claude-haiku-4-5 for the destination model's full specification.
Verified 2026-08-08 against ClaudeHow facts module (src/data/facts/) — see /about/#accuracy.