AI infrastructure · Anthropic API

Claude Haiku 5.5 in production: route for outcomes, not size

A production migration and routing playbook for Claude Haiku 5.5, covering real task economics, API compatibility, evaluation gates and rollback.

TOPIC HUBAI, RAG & Vector Search
Original abstract diagram of high-volume AI requests passing through evaluation and routing gates to a compact violet model core; not a real Anthropic interface or benchmark.
An editorial interpretation of the topic, followed by a practical execution diagram.

Anthropic released Claude Haiku 5.5 on 7 October 2026 for high-volume, latency-sensitive work such as classification, extraction, routing and subagent tasks. The official model page lists a one-million-token context window, up to 128K output tokens, adaptive thinking and pricing that starts at $0.10 per million input tokens and $0.50 per million output tokens for prompts up to 100,000 tokens. This matters to teams running many short tasks—but the production decision should be based on accepted outcomes, tail latency and total workflow cost, not the word “small.”

The release is not a drop-in rename from Haiku 4.5. Anthropic documents a newer tokenizer, prompt-length pricing, adaptive thinking, different tool versions, new stop reasons and request parameters that can return HTTP 400. A safe migration therefore versions the complete request contract: model ID, thinking and effort settings, tools, parser, cache policy, retry rules, observability and rollback.

Anthropic calls Haiku 5.5 its fastest and least expensive small model and reports benchmark and customer results in the launch announcement. Those figures are provider claims, not guarantees for every workload. Use them to form a hypothesis; use your own evaluation set to decide whether the model belongs on a production route.

What changed for production systems

The model ID on the Claude API is `claude-haiku-5-5`. The official overview says the model is available through the Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry and Claude Platform on AWS. Platform IDs and feature availability differ, so configuration should identify the provider as well as the logical model.

The headline limits are generous: a 1M-token context window and 128K maximum output. Message Batches can reach 300K output with the documented beta header. These are ceilings, not suggested defaults. Larger prompts increase latency, make evidence selection harder and may cross a pricing boundary. Keep retrieval and context construction selective even when the model can accept much more.

Adaptive thinking is on by default and the documented default effort is medium. Thinking tokens count toward the output budget. A parser that assumes the first content block is visible text can break when the response begins with a thinking block. Read content by type, preserve the blocks required by the API, and store durable application state outside hidden reasoning.

Price the request shape, not only the model name

Haiku 5.5 uses prompt-length pricing. For requests whose prompt is at most 100,000 tokens, the official list price is $0.10 per million input tokens and $0.50 per million output tokens. Above that prompt threshold, it becomes $0.50 input and $2.50 output. Cache writes and reads also have separate short- and long-prompt prices. A request over the threshold uses the higher tier even when part of the prompt is a cache hit.

That step function changes architecture decisions. A team may add a large tool catalog, long conversation history and retrieved documents until a request crosses 100K. The unit price then changes for the whole request. Track prompt length before dispatch and alert on threshold crossings by workload class. Do not wait for the monthly bill to reveal a routing bug.

The minimum cacheable prompt length is 512 tokens. Cache stable prefixes such as shared instructions, tool definitions and reference material; keep per-request data after the cached prefix. Measure cache creation, cache hits and invalidation. A theoretical discount does not help if a changing timestamp or user-specific block prevents reuse.

Cost per request is still incomplete. Measure cost per accepted task: model tokens, server-side tools, retries, failed validations, escalation to another model and reviewer time. A cheap first call followed by frequent repair can cost more than a stronger route that succeeds once.

Treat migration as a versioned request contract

The migration guide says the same text produces approximately 30% more tokens than with Haiku 4.5 because Haiku 5.5 uses the newer tokenizer. Recount real prompts with the target model. Recalculate budgets, truncation limits, alerts and cost projections; do not reuse token counts captured from the older model.

Manual extended-thinking configuration with `budget_tokens` can return HTTP 400. The documented pattern uses adaptive thinking and `output_config.effort`. Anthropic also tells developers to omit `temperature`, `top_p` and `top_k` for this model. Assistant prefills and older built-in tool versions may also require migration.

The deployable unit should be a named bundle—for example `haiku-55-routing-v1`—containing the model ID, provider, system prompt hash, tool schemas and versions, effort, maximum output, parser version, retry policy, cache policy and safety rules. Keep the previous bundle intact. A rollback that changes only the model ID while leaving incompatible parameters or parsing code is not a real rollback.

A safe Haiku 5.5 rollout treats the model, effort, parser, tools, cache policy and rollback route as one versioned production contract.
A safe Haiku 5.5 rollout treats the model, effort, parser, tools, cache policy and rollback route as one versioned production contract. Open for a larger view

Build an explicit workload router

Haiku 5.5 is a strong candidate for bounded, repeatable workloads: intent classification, field extraction, document compaction, database-query assistance, customer-support triage, retrieval subagents and quick browser or computer-use steps. Each route still needs an acceptance test and a risk boundary.

Route using application facts rather than a model deciding its own authority. Useful features include task class, reversibility, data sensitivity, expected context length, tool count, ambiguity, required citation quality and the cost of a wrong answer. A short prompt can authorize a high-risk refund; a long prompt can be a low-risk summary. Token length alone is not a risk score.

Escalate when a request is ambiguous, crosses a financial or permission boundary, needs sustained judgment across many steps, or fails validation. Build a fresh handoff from durable facts: the objective, verified inputs, tool outputs, failed checks and unresolved decisions. Do not rely on transferring hidden thinking blocks across unrelated accounts or model routes.

For high-volume systems, use stable routing keys so one tenant or conversation does not bounce between model bundles. Record the route and bundle version on every trace. This makes regressions diagnosable and rollback measurable.

Keep tool authorization outside the model

A small, fast model can call tools quickly; that increases the importance of deterministic controls. Validate identity, tenant scope, resource ownership, permitted fields, monetary limits, idempotency keys and approval state in code. Tool schemas reduce malformed arguments, but they do not prove that an action is authorized or appropriate.

Split read and write capabilities where possible. A classification route rarely needs mutation tools. For a workflow that can change state, place a policy gate between the proposed action and the executor. Return structured, minimal tool results and cap large outputs so logs or database rows do not inflate the next prompt unexpectedly.

Handle documented stop reasons such as `refusal` and `model_context_window_exceeded` explicitly. Do not retry every failure with the same request. Some failures require smaller context, a policy-safe response, a different route or human review.

Example request bundle

The following shape follows Anthropic's migration example. Keep secrets in server-side environment variables and validate the returned content blocks rather than reading a fixed array position.

const response = await anthropic.messages.create({
  model: "claude-haiku-5-5",
  max_tokens: 4_000,
  thinking: { type: "adaptive" },
  output_config: { effort: "medium" },
  system: stableSystemPrompt,
  messages: [{ role: "user", content: taskInput }],
  tools: readOnlyTools,
});

const text = response.content
  .filter(block => block.type === "text")
  .map(block => block.text)
  .join("
");

For deterministic extraction, validate the output against a schema and the original evidence. For routing, store both the selected route and why application rules allowed it. For tool work, verify the resulting system state rather than accepting a narrated success.

Evaluate before shifting production traffic

Create a frozen evaluation set from real task shapes, with sensitive data removed or protected. Include common successes, ambiguous requests, long prompts near the pricing threshold, malformed documents, tool timeouts, permission denial, duplicate delivery, refusal cases and inputs that should escalate.

Measure accepted-task rate, critical failure rate, false positives and negatives, p50 and p95 latency, input and output tokens, cache-hit rate, tool calls, retries, escalation rate, reviewer minutes and total cost per accepted task. Score postconditions: the extracted value matches evidence, citations resolve, a side effect occurs once, forbidden actions never occur and the final state can be explained.

Run offline replay first. Then use shadow traffic with writes disabled. Canary a small stable cohort only after the new bundle passes its thresholds. Define rollback triggers before launch: authorization failure, quality regression, refusal spike, p95 latency, threshold-crossing cost, retry rate and incomplete tool execution.

Anti-patterns and when not to use Haiku 5.5

Do not send every task to Haiku because its unit price is low. Avoid it as the only route for open-ended architecture decisions, irreversible financial actions, high-consequence legal or medical interpretation, or long-horizon agent work that consistently fails your acceptance set. A larger model is not automatically safe either; these cases still require deterministic policy and human review.

Do not fill the 1M context window merely because it exists. Do not carry Haiku 4.5 token budgets forward unchanged. Do not mix mutable user data into a shared cached prefix. Do not expose every tool to every task. Do not trust vendor benchmarks as your release gate, and do not call a narrated completion proof of a side effect.

Practical release checklist

Inventory every Haiku request builder. Replace the model ID per provider. Remove unsupported sampling parameters and manual thinking budgets. Upgrade built-in tools and handle new stop reasons. Recount tokens with Haiku 5.5. Separate prompts above and below 100K. Version the parser and request bundle. Add schema, authorization and postcondition checks. Run offline, shadow and canary evaluations. Preserve a complete rollback bundle.

Claude Haiku 5.5 can materially improve the economics of high-volume AI features when the work is bounded and the system owns routing, validation and observability. The durable advantage is not choosing the smallest model. It is assigning each task to the least expensive route that repeatedly meets its quality and risk threshold.

Official references

These references document the tools discussed. Examples and design decisions are illustrative and should be adapted to the project and its versions.

Prepared by: Noor Yasser

FROM DECISION TO DELIVERY

Working through a similar engineering challenge?

I help teams turn architecture decisions into a clear scope and dependable, reviewable implementation.

Book a 30-minute callRelated serviceAI integrations & retrieval systemsRelevant projectAI Action Studio