Haiku 5.5: The Prompt-Length Boundary in a Cheap Rate
MODELS & COSTS
Haiku 5.5: The Prompt-Length Boundary in a Cheap Rate
Haiku 5.5's lowest rate looks attractive for small repeated jobs. That rate has a prompt-length boundary, and billed thinking belongs in the output total. A worker-agent budget needs those two details before multiplying a cheap headline price by thousands of calls.
In this article
Anthropic released Haiku 5.5 on October 7, 2026. It is available through the Claude API and major cloud platforms under the model ID claude-haiku-5-5. Its lowest standard rates are $0.10 per million input tokens and $0.50 per million output tokens. Those rates apply to prompts up to 100,000 tokens.
The model documentation lists a 1M-token context window, up to 128K standard output tokens, text and image input, and text output. Adaptive thinking is on by default, with medium as the default effort. This article checks the sources as of October 8 and adds my own cost calculations; I have not run a paid API evaluation.
The short-prompt bill
Here are the current direct Claude Platform rates, in US dollars per million tokens. Cache reads have their own price; they are not ordinary uncached input. The previous Haiku and the current Sonnet provide two useful reference points within the same product family.
| Model / prompt length | Input | Output | Cache read |
|---|---|---|---|
| Haiku 5.5 · up to 100K | $0.10 | $0.50 | $0.01 |
| Haiku 5.5 · over 100K | $0.50 | $2.50 | $0.05 |
| Haiku 4.5 | $1.00 | $5.00 | $0.10 |
| Sonnet 5.5 | $2.00 | $10.00 | $0.10 |
For an illustrative workload, suppose I run 10,000 requests, each with 5,000 input tokens and 500 billed output tokens. That is 50 million input tokens and five million output tokens. Using standard rates without caching, batch discounts or tools gives $7.50 for Haiku 5.5, $75 for Haiku 4.5 and $150 for Sonnet 5.5.
That price difference gives narrowly defined background work room to exist. I would still count the rejected results and retries. If the output is a category label, the useful cost is a correctly classified ticket. If it is a database extraction, it is a validated field, rather than a response that merely looks plausible.
For short prompts, the input and output unit rates are 90% below Haiku 4.5; above the boundary they are 50% below. Anthropic’s average running-cost claim is around 75% less. A unit-price cut and an actual bill reduction are different calculations because token use, effort and workload mix can change.
The price boundary inside the context window
The full window is available, but the lowest price stops at 100,000 prompt tokens. Under the published request-length tiers, a longer prompt moves both input and output to the higher rates. The higher tier is five times the lower tier.
To make the boundary visible, I calculated 1,000 requests with exactly 1,000 billed output tokens each. At 100,000 prompt tokens per request, the total is $10.50. At 100,001 prompt tokens, it is approximately $52.50. This is pricing arithmetic, not a recorded invoice or an API test.
The migration guide says the same input text produces approximately 30% more tokens than on Haiku 4.5, depending on the content. As an illustration, an old 80,000-token prompt multiplied by 1.3 becomes 104,000 tokens. That could cross the price boundary. It is not a token count I measured, so I would recount the real prompt with the new model.
The context-window documentation also explains why an agent’s history matters: system instructions, tool definitions, tool results and retained thinking can occupy the window. Cached prefixes still occupy it. Caching changes what those tokens cost; it does not remove them from the conversation.
This makes small, focused helper requests appealing. I would send the document excerpt and instructions needed for the assigned job, then verify that the result retains the required context. Splitting a large task into pieces needs its own quality check; a lower token count is not useful if it removes the evidence needed to answer.
Partial scores and strict passes
The launch shows a substantial improvement over Haiku 4.5. I checked two evaluations against the system card, pages 115 and 128. These are Anthropic’s reported agent-system results, with the exact benchmark versions kept intact.
| Vendor evaluation | Haiku 4.5 | Haiku 5.5 | Sonnet 5.5 |
|---|---|---|---|
| OSWorld 2.1 offline · partial score | 15.7% | 72.4% | 83.9% |
| OSWorld 2.1 offline · strict pass rate | 1.7% | 37.1% | 48.8% |
| Terminal-Bench 4.0 | 0.0% | 39.2% | 70.6% |
The OSWorld headline needs care: 72.4% is the partial score, while the strict pass rate is 37.1%. The test covers the official offline subset of 82 tasks, with five attempts per task. It does not show a 72.4% probability of completely finishing any arbitrary desktop job.
The configurations also differ. Haiku 4.5 used a fixed thinking budget and lacked server-side compaction on OSWorld. Terminal-Bench used Claude Code in --bare mode, with max effort for the 5.5 models, different trial counts and different fallback policies. These rows compare deployed systems, not an isolated change to model weights.
Independent evaluator Artificial Analysis reports an Intelligence Index v4.3.2 score of 34 at medium and 43 at max. That is another reason to keep effort beside a score. Its launch analysis also warns that provisional cost figures omit the over-100K price step, so I would not use those figures as a complete bill forecast.
I would start Haiku evaluation with extraction, routing and tightly scoped helper tasks. The larger model still deserves a trial on long coding jobs. In my earlier Sonnet 5.5 analysis, effort was already a major part of the cost decision. Since that article, Sonnet’s cache-read rate has fallen from $0.20 to $0.10; the pricing table here uses the October 8 rate.
Migration beyond the model ID
Existing Messages API integrations deserve a migration pass. Four changes I would check first are below. This is a shortlist; the full migration guide also covers conversation handling, tools, refusals and capacity support.
| Existing behavior | What to check for Haiku 5.5 |
|---|---|
| Reusing Haiku 4.5 token counts | Count again with claude-haiku-5-5; review output limits and the 100K price boundary. |
| Explicit thinking budget | Replace thinking: enabled plus budget_tokens with adaptive thinking and an effort setting. |
| Reading content block zero as the answer | Select response blocks by type. Thinking may precede text, even when you did not explicitly enable it. |
| Sampling parameters or assistant prefill | Omit temperature, top_p and top_k; replace final assistant prefill with a supported output-format or prompting approach. |
The official migration guide documents errors and replacements for these patterns. I would test a small set of real requests, including tool calls and refusals, before a wider change. An integration that returns HTTP 200 still needs checks for parsed answers, task accuracy, billed tokens and latency.
There is also a separate monthly API-credit program for eligible Max and Team subscribers: $100 for Max 5x, $200 for Max 20x, and a Team pool capped at $500. Claiming requires linking a Console organization and meeting the eligibility rules. These credits do not increase interactive Claude Code usage limits.
Start with a bounded job whose answer can be checked. Compare the total bill and response time per correct result with the current worker. A low token price is useful when the cheaper model can finish that job without enough retries or supervision to erase the saving.
Keep actual prompt length, effort and the success definition in the run log. Those details explain the gap between the ten-cent headline, the 1M context window and the reported 72.4% computer-use score. A deployment decision needs the workload’s own results as well.
Comments
Post a Comment