Claude Haiku 5.5 Review: Pricing and Real Cost Per Task

What Claude Haiku 5.5 is for

Haiku represents Anthropic’s low-end layer model — the type of model that one calls on for heavy, time-sensitive workload tasks. Classification, extraction, routing, short rewrites, tool-call formatting, first-pass drafts: work where a capable-enough answer returned quickly and cheaply beats a slightly better answer that costs 20× more and takes longer.

Haiku 5.5 shipped on October 7, 2026. The headline is the price cut: Anthropic dropped the per-token rate by up to 90% versus Haiku 4.5 while keeping the frontier-tier plumbing — a 1-million-token context window, 128K maximum output, prompt caching, and the Batch API. The inexpensive version is not the stripped-down version for the very first time.

However, a lot of work is packed into that one word. There is tier break in the rate card, which silently makes your bill go up. The token cost gives little hint as to how much anything actually costs. This review explores both processes.

Claude Haiku 5.5 pricing, in full

Here is the full rate card next to Haiku 4.5 and Sonnet 5.5, so the gaps are visible in both directions.

Three things stand out.

The input price is the story. At $0.10 per million input tokens, Haiku 5.5 is a tenth of Haiku 4.5 and a twentieth of Sonnet 5.5. For input-heavy work — RAG, long context, document processing — that is where most of the bill lives, and it is where Haiku 5.5 is most aggressive.

Caching and batching stack on top. Cache reads are $0.01 per million tokens, so a stable system prompt or a reused document is nearly free on repeat calls. The Batch API takes another 50% off for work that tolerates asynchronous turnaround. Neither is unique to Haiku, but both compound the savings.

Everything above 100K tokens is a different model, pricing-wise. That is the catch, and it deserves its own section.

The 100K-token pricing cliff

Haiku 5.5 is the only model in the lineup with a two-tier, prompt-length-dependent price. Up to 100K tokens in a single request, you pay $0.10 / $0.50. The moment a prompt crosses 100K, the rate becomes $0.50 / $2.50 — five times the input rate and five times the output rate — and it applies to the whole prompt, not just the tokens above the line.

The effect is a step, not a slope. A 90K-token call with 1K of output costs about $0.0095. Push the same call to 110K tokens and it costs about $0.0575 — roughly 6× more for 22% more input. Nothing about the work changed; you just stepped over a pricing boundary.

For most workloads this never bites, because most prompts are far under 100K. But three patterns live right on the edge: RAG pipelines that stuff large retrieved contexts, full-document or full-codebase analysis, and long agentic chains that accumulate history turn after turn. If any of those routinely cross 100K, the 20× advantage over Sonnet narrows to about 4×, and the math for using Haiku at all gets closer. You want to know when your traffic is crossing that line — which, again, is a measurement problem.

Pricing is not cost per task

Here is the trap in every “it’s $0.10 per million tokens” headline: you do not buy tokens, you run tasks. And tasks have wildly different token shapes.

Four representative jobs, priced on Haiku 5.5 at its standard tier (the long-document job uses the >100K rate):

• Ticket triage — 600 input, 40 output. About $0.00008 per call, or $0.08 per 1,000.
• Support reply — 1,800 input, 350 output. About $0.36 per 1,000.
• RAG answer — 12,000 input, 500 output. About $1.45 per 1,000.
• Long-document analysis — 120,000 input, 1,500 output. About $63.75 per 1,000 — because it crosses the cliff.

That is an 800× range on a single model, driven entirely by task shape. It is why “which model is cheapest” is the wrong question. The right question is “what does my task cost on this model, at my real input/output ratio and my real volume” — and the answer moves the moment your prompts get longer or your output grows.

Two numbers decide everything: your input-to-output ratio, and whether you cross 100K. A summarizer (huge input, tiny output) behaves completely differently from a content generator (small input, huge output), because output tokens cost 5× input tokens on Haiku. Average rates hide that. Per-task measurement surfaces it.

Where teams get Haiku pricing wrong

They budget off the input rate. Output is 5× the input price on Haiku. A chatty agent that emits long responses can cost far more than its input volume suggests. Watch output tokens, not just input.

They ignore the cliff until the invoice. A RAG system that creeps from 80K to 110K average context as the knowledge base grows doesn’t fail — it just quietly gets ~6× more expensive per call. Without per-request visibility, nobody notices until finance asks.

They compare sticker prices instead of blended cost per task. The model that wins on a spec sheet can lose on your actual traffic mix. The only honest comparison is your own tasks, measured.

They leave caching on the table. A stable system prompt re-sent on every call is pure waste at $0.10/M when it could be $0.01/M cached. On high-volume Haiku traffic, cache hit rate is a real line item.

Want per-model cost control before the invoice?

Book a demo

How to track real Haiku cost in TrueFoundry

The theme above is the same every time: you cannot manage what you cannot see per task. The TrueFoundry AI Gateway sits in front of every model call and meters it, so “what does Haiku actually cost us” becomes a dashboard rather than a spreadsheet exercise.

Public and private pricing, applied automatically

When you add a model, the gateway attaches a cost basis. Public Cost pulls provider-published rates from TrueFoundry’s open-source pricing catalog (github.com/truefoundry/models), auto-populated and kept current — including region-specific and tiered rates, which is exactly how Haiku’s 100K tier is handled. Private Cost lets you enter negotiated or custom rates for contracts and fine-tuned models.

Because the catalog models tiered pricing, Haiku’s jump from the $0.10 tier to the $0.50 tier above 100K tokens is tracked correctly per request, rather than billed at a flat average that would understate your long-context calls.

Cost per model, user and team — not just a total

Once calls are flowing, the Metrics dashboard shows total spend, a Cost of Inference trend, and one-click breakdowns by model, by user, and by team.

The model view answers “how much is Haiku costing us versus Sonnet this month”; the team view supports chargeback; the user view surfaces the one power user driving a third of the bill.

Cost-by-model breakdown. Source: TrueFoundry docs.

Attribution by any dimension, and export

Beyond the built-in views, you can attach custom metadata — application, environment, customer_id, cost_center — and group cost by it. Virtual-account tags and team-associated tokens inject that metadata automatically, so you get per-application and per-customer cost attribution without changing a line of client code. You can enforce it with a metadata-validation guardrail that rejects requests missing a required key, and export the raw data grouped however you need for finance.

For the token-level mechanics behind these numbers — cached text versus cached image rates, audio billing, and how cancelled streams are costed — the cost-tracking documentation has the full formulas.

A worked example: a support bot on Haiku 5.5

A SaaS company runs a customer-support assistant: 50,000 conversations a day, averaging 1,800 input tokens (system prompt + retrieved context + history) and 350 output tokens per reply.

On Haiku 5.5 at the standard tier, that is about $0.355 per 1,000 replies, or roughly $17.75 a day — call it $533 a month. The same traffic on Sonnet 5.5 would be about $7.10 per 1,000, or $355 a day — $10,650 a month. The model choice is a 20× swing on an identical workload.

Now add caching. The system prompt and tool definitions are ~1,200 of those 1,800 input tokens and never change. Cached at $0.01/M instead of $0.10/M, the input cost on repeat calls drops substantially — the gateway’s cache metrics show the exact dollar savings and hit rate, so you can prove the optimization paid off rather than assume it did.

The point is not the specific figures; it is that each lever — model tier, caching, the 100K boundary — is measurable per task, which means it is manageable.

Gotchas worth knowing

• The cliff is per request, not per day. It is triggered by a single prompt exceeding 100K tokens, so one oversized RAG call pays the high rate even if your average is well under.
• Output dominates on generation-heavy work. At 5× the input rate, output tokens are where a verbose agent burns money. Trim max-output and system verbosity before blaming the model.
• Caching needs a stable prefix. Reorder your prompt so the unchanging parts (system, tools, retrieved docs) come first; cache hits depend on a matching prefix.
• Batch halves the bill for async work. Overnight enrichment, evals, and bulk classification don’t need synchronous latency — route them through the Batch API.
• Blended cost drifts. As prompts grow and traffic mix shifts, your real cost per task moves even when the rate card doesn’t. Track it continuously.

‍