Claude Haiku 5.5: Pricing, Benchmarks and Practical API Changes

Claude Haiku 5.5 is aimed at a familiar production problem: running many small model calls without letting inference costs or response times dominate a workflow. Anthropic released it on October 7, 2026, describing it as its fastest, cheapest and most capable small model. Its headline changes include a 1 million token context window, adaptive thinking, and sharply lower listed prices. The API model ID is claude-haiku-5-5.

The practical case for Haiku 5.5 is strongest on bounded, repeated work: classification, extraction, summaries, compaction and delegated subtasks. The low price makes it a candidate for high call volumes, while its improved benchmark results suggest it can take on a broader set of tasks than Haiku 4.5. But the numbers come from Anthropic, and larger Claude models still lead on the cited benchmarks. Teams should evaluate it on their own inputs before moving complex work onto it.

What changed, and what the figures show

For prompts up to 100,000 tokens, Haiku 5.5 costs $0.10 per million input tokens and $0.50 per million output tokens. Haiku 4.5 was listed at $1 and $5, respectively. For prompts above 100,000 tokens, Haiku 5.5 costs $0.50 per million input tokens and $2.50 per million output tokens; the source lists Haiku 4.5 at $1 and $5 for that tier.

The expanded context window is 1 million tokens, up from 200,000, and maximum output doubles from 64,000 to 128,000 tokens. The smallest prompt eligible for caching falls from 4,096 tokens to 512. Adaptive thinking, controlled through an effort setting, replaces a manually specified thinking budget and appears for the first time in a Haiku model.

These are Anthropic's reported results. The launch page shows Sonnet 5.5 ahead on all four benchmark measures, including 70.6% on Terminal-Bench 4.0. The scores signal a large step up from Haiku 4.5 on these evaluations, but they don't establish how the model will perform on a particular team's data or workload.

The price reduction also doesn't translate directly into a 90% lower bill for every job. Haiku 5.5 uses a newer tokenizer that counts the same text as roughly 30% more tokens. Anthropic estimates average savings of about 75%, accounting for the tokenizer and the 10% of requests that exceed 100,000 tokens. Actual costs will depend on prompt length, output size, caching and the amount of thinking used.

Migration changes that affect existing code

Several Haiku 4.5 request patterns will fail with Haiku 5.5. The model rejects requests that include temperature, top_p or top_k; assistant-prefill endings; and manual thinking configured with budget_tokens. Check existing client wrappers and shared request builders for these parameters before switching model IDs. Anthropic lists these changes on its migration notes.

Adaptive thinking is enabled by default, so a response may begin with a thinking block before its text. Those thinking tokens count toward max_tokens; leave enough headroom for them when setting output limits. Code that assumes the first content block is text may also need adjustment: select text blocks by their type. And handle stop_reason: "refusal" as a distinct outcome rather than treating it as an ordinary answer.

Anthropic says Haiku 5.5's cybersecurity safeguards are stricter than Haiku 4.5's and block penetration testing. That constraint matters for teams with security testing workflows. The model is available through the Claude Platform, Amazon Web Services, Google Cloud and Microsoft Azure. Its safety evaluations appear in the system card.

Building structured calls in Python

The examples require Python 3.10 or later, an API key from the Claude Console and an up-to-date Anthropic SDK, since they use output_config. Install the package and set the key in the shell:

pip install -U anthropic
export ANTHROPIC_API_KEY="your-key-here"

In Windows PowerShell, set the environment variable with $env:ANTHROPIC_API_KEY="your-key-here". The SDK reads the key automatically.

For repeated classification and extraction, structured JSON outputs keep responses easy to consume. Define a schema that constrains the answer—for example, a category field limited to billing, shipping, technical or other, or invoice fields for vendor, number, total, currency and due date. The structured outputs guide describes schema-constrained JSON.

import json
import anthropic

client = anthropic.Anthropic()
MODEL = "claude-haiku-5-5"

CATEGORY_SCHEMA = {
    "type": "object",
    "properties": {
        "category": {
            "type": "string",
            "enum": ["billing", "shipping", "technical", "other"]
        }
    },
    "required": ["category"],
    "additionalProperties": False
}

def classify(text):
    reply = client.messages.create(
        model=MODEL,
        max_tokens=1000,
        system="Classify the customer message.",
        messages=[{"role": "user", "content": text}],
        output_config={
            "effort": "low",
            "format": {"type": "json_schema", "schema": CATEGORY_SCHEMA}
        }
    )
    if reply.stop_reason in ("refusal", "max_tokens"):
        raise RuntimeError(f"No usable answer: {reply.stop_reason}")
    answer = "".join(
        block.text for block in reply.content if block.type == "text"
    )
    return json.loads(answer), reply.usage

Low effort suits straightforward classification because it limits the work spent thinking. The example leaves out sampling controls that Haiku 5.5 rejects, checks for refusal or a token limit, and extracts text by block type before parsing the JSON. The max_tokens setting is 1,000 even though the expected answer is short, because thinking tokens use part of that allowance too.

A portability detail matters when comparing models: Haiku 5.5 accepts a forced tool call, but Opus 5.5 rejects one with a 400 error, according to the Haiku migration guide and Opus notes. JSON outputs give the example a common format across the three-model comparison. They aren't available for Haiku 5.5 on Amazon Bedrock, however; there, prompt for the desired format and validate the response yourself.

Using Haiku as a worker model

A larger lead model can divide a job among Haiku workers, then assemble their results. Each worker handles one narrow task, such as summarizing a document, while the lead sees the shorter notes rather than every full source. This pattern can reduce the amount of input sent to the more expensive model. It also creates a dependency: the lead's answer can only be as reliable as the worker summaries it receives.

In an asynchronous Python implementation, asyncio.gather can run worker calls in parallel, while a semaphore limits concurrent requests to stay within account rate limits. Each worker can return its summary and usage, letting the application add up its cost. The lead then receives the question and the collected notes, and its usage can be tracked separately.

async def summarize(client, document, limit):
    async with limit:
        reply = await client.messages.create(
            model="claude-haiku-5-5",
            max_tokens=1500,
            system="Summarize the document in two sentences.",
            messages=[{"role": "user", "content": document}],
            output_config={"effort": "low"}
        )
    text = "".join(
        block.text for block in reply.content if block.type == "text"
    )
    return text, reply.usage

Anthropic identifies sub-agent work as a target use, and Cognition has reported using Haiku 5.5 as a sidekick to Opus 5.5 in Devin Fusion. That example illustrates the division of labor, not a guarantee that every delegated task will benefit. Summaries can omit a detail the lead needs, so preserve exact names, dates and amounts where they matter, and test the full chain for errors as well as cost.

Measure cost and latency on your own traffic

A small local comparison can reveal whether cheaper calls meet the quality bar. Run the same labeled messages through Haiku, Sonnet and Opus; record correctness, median response time, output tokens and cost. The source's example uses eight support tickets, which is useful as a smoke test but too small to settle a production choice. Replace them with representative examples from the intended workflow.

For a simple estimate, consider a request with 300 input tokens and 30 output tokens, excluding thinking tokens. At the published rates, 1,000 such calls cost an estimated $0.045 with Haiku 5.5, $0.90 with Sonnet 5.5 and $1.80 with Opus 5.5. This is arithmetic from list prices, not a latency or quality measurement.

Anthropic describes Haiku 5.5 as its fastest model at standard speed, while Opus models in Fast Mode can be quicker. Customer figures offer additional, workload-specific evidence: Asana reported over 30% lower task latency than the model it previously used, and Box reported about half the latency of Haiku 4.5. Those results give useful reference points, but latency on your account will depend on the request and deployment conditions.

Where Haiku fits

Start with Haiku 5.5 for high-volume, well-defined steps such as routing, extraction, classification, summarization and compaction. It may also work well as a worker inside a larger agent system. AlphaSense reported a score of 0.84 for Haiku 5.5 against 0.76 for Haiku 4.5 on its document question-answering workload, which handles about 8 million calls a week.

For complex agentic coding, Anthropic says Sonnet 5.5 and Opus 5.5 remain better choices. The benchmark gap supports testing those models where multi-step reasoning or code execution is central. A practical rollout is to evaluate Haiku first on each high-volume step, inspect accuracy and failure cases on real examples, then move only the weaker steps to a larger model.

Anthropic lists October 7, 2027 as Haiku 5.5's earliest retirement date. Haiku 4.5's earliest listed date is October 15, 2026, though it remains listed as active and Anthropic says it will provide advance notice before retiring a model. SDKs also gained beta support for computer use and browser use, which Anthropic identifies as possible fits for a fast, lower-cost model.

Haiku 5.5 makes small-model calls cheaper on the published rate card and expands the kinds of inputs and outputs they can handle. Migration requires changes to request parameters, token budgeting and response parsing; real cost savings also depend on the newer tokenizer. The clearest next step is to measure quality, latency and total token use on the workload itself, then reserve larger models for tasks where Haiku falls short.