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: it's the fastest and cheapest model in the current lineup, and its thinking behaviour is controlled through the older budget-based mechanism rather than the effort levels the rest of the current lineup uses. That's not a temporary gap waiting to be patched — the two mechanisms reflect a genuinely different design for this model relative to the Opus and Sonnet generations it shipped alongside.

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're choosing between models specifically because you want a uniform tuning mechanism across your fleet, that's worth weighing before defaulting to the cheapest option: see the model picker for how the current lineup differs on this and other axes beyond price alone.