Migrating: Haiku 3 to Haiku 4.5

Migrating off a model that has been retired

The source model here has been retired on the Claude API — the move is not something to plan for eventually; it should already be complete. If you're reading this because a request against the old id started failing, that is the retirement having taken effect, not a bug, and no retry will bring it back.

What changes on the move

Beyond simply working again, the destination is a different price point: Haiku 4.5 costs more per token than Haiku 3 did, and it is no longer the newest Haiku — Haiku 5.5 now costs less per token than either, so check whether going straight there suits your code. Haiku 4.5 also has a higher minimum cacheable prefix, so a short prompt that cached on the old model may silently stop caching on the new one. Re-price your workload against the destination rather than assuming the historical relationship between the two models' costs still holds, and check the usage block for cache reads after the switch.

Neither model takes an effort parameter

Effort control is absent on both ends of this move — Haiku 4.5 rejects the parameter outright. Code that shares a request builder with larger models needs to keep branching on Haiku 4.5 specifically; Haiku 5.5 is the first Haiku that accepts it.

Auditing for this id elsewhere

If one integration was still calling the retired id, check whether any other service, script or scheduled job does the same. An id this old tends to survive longest in infrequently touched code — a fallback list, a nightly job — that nobody audits until it breaks. A repository-wide search for the literal id, run once while closing out this migration, catches a second occurrence before it becomes its own incident.

Related

See the model ID you're calling has been retired for the failure, claude-haiku-4-5 for the destination's full specification, and migrating: Haiku 4.5 to Haiku 5.5 for the next step.