Summary
Anthropic released Claude Haiku 5.5 (claude-haiku-5-5) on October 7, 2026. It is aimed at classification, extraction, routing and subagent work. Prices start at $0.10 per million input tokens and $0.50 per million output tokens, with a 1M-token context and adaptive thinking. It is available through the Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry and Claude Platform on AWS. Read together, the release notes and model page show the routes are not equivalent for stateful agent traffic. Gateway failover assumes they are.
What happened
The headline numbers come from Anthropic's model docs. Prompts up to 100K tokens cost $0.10 per million input tokens and $0.50 per million output tokens. Above 100K, the rates are $0.50 and $2.50. Batch calls get 50% off. The context window is 1M tokens, maximum output is 128K, default effort is medium, and the knowledge cutoff is June 2026.
Two details matter for this take. First, according to the release notes as summarized in our evidence pack, the old computer_20250124 tool now returns 400 errors. API and Google Cloud users are sent to computer_toolset_20260801, while Bedrock users are sent to computer_20251124. We did not have the verbatim release-note line. Second, the model page says Haiku 5.5's "thinking blocks work only in the…", but our copy of the excerpt cuts off there. We cannot confirm exactly how far that restriction reaches. On October 22, Anthropic also made an Anthropic-managed Claude route on Google Cloud generally available, alongside the existing Google-managed route.
What the archive adds
The archive adds three useful pieces. According to d1, API version 2026-10-21 is Anthropic's first versioned API release since 2023-06-01, and it includes breaking request changes. The 400 errors for temperature, top_p, top_k, manual budget_tokens and assistant prefill most likely belong to that wider migration, not to Haiku 5.5 specifically.
OpenRouter's Haiku 5.5 listing names five providers: Google Vertex, Claude Platform on AWS, Azure, Anthropic and Amazon Bedrock. It says requests are "routed to the best available provider, with automatic failover to the others." OpenCode's model catalog warns that a model reached through a gateway "may perform differently," and says it tests model/provider pairs before recommending them.
According to d2, Anthropic claims Haiku 5.5 is about 75% cheaper than Haiku 4.5. Our evidence does not include Haiku 4.5 pricing, so we cannot check that claim. Google's blog (d3) dates the Anthropic-managed GA to October 22. It also says that on that route Anthropic, not Google, is the data processor.
Trend signal
Small models now sit in the hot path of every request. They classify the input, route it, and spin off subagents. Because so much depends on them, they get placed behind gateways with automatic failover, and that only works if providers are interchangeable.
Anthropic is moving the other way. The 2026-10-21 API version, SDK classes that run the tool loop with approval callbacks, adaptive thinking, and an Anthropic-operated route inside Google Cloud all add behavior that depends on the platform and on state. Our read is that the cheap tier is now pulled in two directions. It is a commodity for single-shot calls, but tied to a specific route once it runs as an agent.
Why now
1) Anthropic shipped API version 2026-10-21, its first versioned break since 2023-06-01 (d1). That release removed sampling parameters and prefill and moved computer use to new tool IDs, so route-level differences now show up as hard 400 errors. 2) Our inference: Anthropic is deliberately adding server-side, platform-specific behavior, such as SDK-run tool loops with approval callbacks and adaptive thinking. Behavior like that does not move between providers the way plain completions do. 3) The Anthropic-managed Google Cloud route (d3) creates a second Claude processor inside a single cloud. Our inference is that Anthropic wants control of features and data processing even inside hyperscaler accounts. 4) Haiku is positioned for high-volume routing and subagent work, which puts it behind failover gateways like OpenRouter's five-provider setup. Those gateways are exactly where the route differences cause failures.
Connections to other events
The platform risk is concrete. It sits in the failover path, not in the price list.
1) Tool IDs. Per the release-note summary, a computer-use agent built against the API or Google Cloud declares computer_toolset_20260801, while on Bedrock it has to declare computer_20251124. Suppose a gateway fails a Vertex request over to Bedrock without rewriting the tool definition. The likely result is a 400 error, not a successful fallback. We have not tested this, and OpenRouter may already translate tool definitions.
2) Thinking blocks. The model page limits where thinking blocks work, but our excerpt is truncated, so the scope is unverified. If the restriction is tied to the account, multi-turn agents that replay earlier thinking blocks could fail when a later turn lands in another provider's account. We have not confirmed this. It is the scenario to test first.
3) Data processor. On Google Cloud alone, two routes serve Claude with different processors: Anthropic on one, Google on the other (d3). A failover between them changes who processes your data, even though the bill still comes from Google.
4) Cost on failover. This risk applies on every route. The new tokenizer counts the same text as about 30% more tokens than Haiku 4.5, per the model page. Below 100K tokens, that makes the effective input price about $0.13 per million old-tokenizer-equivalent tokens. A prompt of roughly 77K old-tokenizer tokens now measures about 100K. Any prompt past that line is billed at the upper tier, 5x the lower rate for input and output. Long-context classification jobs that fit comfortably under the line on 4.5 may not fit on 5.5. If d2's 75% figure is a per-token rate cut, the same text would come out about 67% cheaper, not 75%. That is arithmetic on an unverified claim.
The upshot: classification and extraction calls carry no tools and no thinking-block history, so they fail over cleanly. Agent turns may not.
Why it matters
For builders: split traffic by statefulness. Let stateless Haiku calls use gateway failover freely. Pin agent sessions that use computer use, or that replay thinking blocks, to one route and one account for their whole life. Keep a separate tool manifest for each route. Measure prompt sizes with the new tokenizer and alert when they approach 100K.
For buyers: the Anthropic-managed Google route lets you spend Google commitments on Anthropic's own feature set. It also makes Anthropic the processor. Check that your DPA covers every route your gateway can fail over to, not only the one you meant to use.
For gateway vendors: Claude agent traffic is likely to need sticky sessions and per-provider tool translation.
What happens next
- Anthropic documentation will list the same computer-use tool version for Amazon Bedrock as for the Claude API, ending the split between
computer_20251124andcomputer_toolset_20260801. (6 months, 50%). Watch for: A release-notes or Bedrock docs entry namingcomputer_toolset_20260801(or one shared successor) as supported on Bedrock. - OpenRouter will document provider pinning, sticky sessions, or tool-version translation specifically for Claude requests that carry thinking blocks or computer-use tools. (12 months, 40%). Watch for: An OpenRouter docs or changelog entry naming Claude thinking-block or tool-version handling across providers.
- Anthropic will publish a dated retirement for Claude Haiku 4.5, forcing pipelines onto the 2026-10-21 request semantics. (6 months, 45%). Watch for: Haiku 4.5 marked deprecated or legacy with a retirement date on Anthropic's models or deprecations page.
Limits and uncertainty
We did not have the verbatim release-note text for the per-route computer-use tool IDs, and the thinking-block sentence on the model page is truncated in our excerpt. Both central claims therefore rest on summaries and partial text. The thinking-block restriction may allow linked accounts across clouds, which would remove that half of the risk. The Bedrock tool-ID difference may be a temporary lag. OpenRouter may already pin sessions or rewrite tools; we have not tested it. We have no latency, quality, rate-limit or regional data for any route. Haiku 4.5 pricing is not in our evidence, so the 75%-cheaper claim (d2) is unverified.
Skill to build now
Build a compatibility matrix that lists each route against each feature. First exercise: run one three-turn computer-use agent conversation on Haiku 5.5 via the Claude API, Bedrock and Google Cloud. Log which tool IDs each route accepts and whether a thinking block from one route's turn is rejected when replayed on another. Also log the token count of a fixed 80K-token Haiku 4.5 prompt under the new tokenizer, to see whether it crosses the 100K pricing tier. Commit the results next to your router config.
Reader takeaway
Before you put Haiku 5.5 behind a multi-provider gateway, tag every request as stateless or agentic. Let stateless requests fail over. Pin agentic ones to a single route and account. Then force one failover on purpose: send a computer-use agent turn built for Vertex to Bedrock, and send a turn that replays thinking blocks to a different account. Record the errors you get before production traffic finds them.
Open question
What does the full thinking-block restriction on Haiku 5.5's model page actually say? If it covers only one provider account, can a stateful Claude agent fail over across clouds at all? Or does multi-cloud redundancy protect only the single-shot classification traffic Haiku is marketed for?