The effort parameter errors on Haiku 4.5

What breaks

A request built for the current model lineup, effort parameter included, gets rejected the moment it's pointed at Haiku 4.5. Everything else about the request is valid — it's specifically the effort field that this model doesn't accept.

Why Haiku 4.5 doesn't take this parameter

Effort as a parameter exists to let a model tune how much it reasons before answering, and Haiku 4.5 is built around a different trade entirely: its thinking behaviour is controlled through the older budget-based mechanism rather than the effort levels the rest of the current lineup uses. That gap was never patched on this model — it was closed by its successor. Haiku 5.5, the current Haiku, is the first Haiku that accepts effort, so the error is specific to Haiku 4.5, not to the Haiku line.

Where this actually bites

This shows up most often in code shared across a whole model lineup — a router that tries several models for cost or fallback reasons, or a shared request-building function that sets a default effort level for every call regardless of which model ends up handling it. Code that only ever called Opus or Sonnet models never has a reason to notice this; the first time it gets tested against Haiku 4.5, the shared code path breaks on a field that was silently fine everywhere else.

The fix

Branch your request-building logic on model id rather than assuming the effort parameter is universal across the current lineup — omit it, or use budget-based thinking control instead, when the target is Haiku 4.5. If you want one tuning mechanism across your whole fleet, moving the Haiku traffic to Haiku 5.5 removes the branch — see migrating: Haiku 4.5 to Haiku 5.5 for what else that move changes, and the model picker for how the lineup differs beyond price.