Haiku 5.5: Where a Cheaper Small Model Helps Coding Agents

Anthropic has made strong large models for coding, but I have long found its smaller models disappointing. Haiku 4.5 was expensive for its capabilities, and I configured my tools to avoid it. Haiku 5.5 changes that picture: it looks fast, inexpensive and potentially useful for the work surrounding a larger model.

I want a small model that other agents can call to search files, check changes and handle repetitive work without spending frontier-model prices. Previously I sometimes routed those tasks to OpenAI models instead. I am excited to see Anthropic offer an option in its own family that may finally make sense.

Anthropic positions Haiku 5.5 for high-volume, cost-sensitive tasks such as summaries, compaction, database queries and classification, as well as a coding sub-agent. Its announcement says average running cost is around 75% lower than Haiku 4.5. Actual savings depend on the workload and pricing tier.

The release also halves Sonnet 5.5 cache-read pricing from $0.20 to $0.10 per million tokens. That matters to me because cached context can make up a large share of an agentic workload's bill. Comparing only input and output prices can miss that part of the economics.

For Haiku 5.5 prompts up to 100,000 tokens, the displayed API prices per million tokens are $0.01 for cache reads, $0.125 for cache writes, $0.10 for input and $0.50 for output. These are the prices shown at release, and the cache-write rate in the table should be read with the provider's applicable cache terms.

Above 100,000 prompt tokens the displayed rates increase fivefold: input becomes $0.50 and output $2.50 per million, with cache rates also increasing. That is an important distinction for long-running coding agents. My explanation that the threshold reflects infrastructure and pricing incentives is a hypothesis, not an internal accounting of Anthropic's costs.

I mention a suggested Claude Code setting that compacts Haiku's context around 100,000 tokens to help keep sub-agent work in the lower tier. That can reduce context available to the model, so cost and task quality must be evaluated together; a setting alone does not establish the quality of the result.

Anthropic's displayed benchmarks show Haiku 5.5 at 39.2% on Terminal-Bench 4.0, compared with 0% for Haiku 4.5 and 16.4% for GPT-6 Luna in that table. The same table reports 72.4% on an OSWorld 2.1 offline subset. These are selected benchmark results, not a universal measure of coding or computer-use quality.

The reported speed ranges from roughly 100 to 200 tokens per second depending on provider; my own Claude Code test was around 180. Prime reported a worse pass rate and slower performance than Luna in an automation with reasoning off. I suspect that setting matters, but one person's workload is not enough to rank the models generally.

Token efficiency matters as well as token price. In the Artificial Analysis data I examine, Sonnet 5.5 at maximum reasoning used a very large number of tokens per task. Removing that setting changes both the cost chart and the apparent tradeoffs. Always check the reasoning level before interpreting a benchmark point.

I first compare Anthropic's own models on a cost-versus-intelligence chart. Haiku occupies a cheaper range, while Opus and Sonnet occupy higher ranges. The Pareto line shows the best measured score for a given task cost among the models and settings selected; changing that selection changes the line.

Adding competitors changes the picture. In this benchmark snapshot, Luna is generally cheaper, Haiku occupies a nearby capability range, and GPT-6.1 Sol fills another part of the frontier. Those results do not cover every possible application, and updates to cache prices or benchmark data can move the points.

Even where another provider has a slight benchmark advantage per dollar, there are reasons to use a model from one family: existing subscriptions, contracts, a common API, or how well agents coordinate. I have not established that same-family coordination is always better, but Haiku now feels like a reasonable option rather than an automatic exclusion.

After the benchmark data is updated to reflect Sonnet's cheaper cache reads, its cost position improves. The exact effect varies with how much of a task's bill comes from cache reads, so the revised chart is a better comparison for that benchmark, not a guarantee of the same savings in every agent session.

The announcement also describes monthly API credits for Claude Max subscribers: $100 for 5x and $200 for 20x, with separate team provisions. These are described as API credits for building applications, distinct from the subscription's interactive usage. Anthropic also announced beta computer-use and browser-use support in its Python and TypeScript SDKs.

My preferred use is to embed Haiku in applications or let stronger agents delegate focused work to it: categorizing incoming data, exploring a repository or checking individual possibilities. It is not necessarily the model I would choose to lead a difficult end-to-end coding project.

Anthropic's egg-drop demonstration compares Opus alone with Opus orchestrating ten Haiku sub-agents. Theo reports the solo run at about three and a half minutes, 25 designs and $0.47, versus 58 seconds, 86 designs and $0.14 for the combined run. It is a vendor demonstration of one task, useful for illustrating parallel search rather than proving a general speedup.

The pattern is most attractive when many cheap attempts can be verified and the difference between an ordinary attempt and a carefully reasoned one is small. Searching for a hard-to-identify file or testing several possibilities can benefit from parallelism. A stronger agent still has to choose suitable tasks and assess the results.

A community member also showed a generated video that reportedly cost about $0.60 in API usage and took under 20 minutes. I was impressed by the result for the price. That is one demonstration with its own prompt and workflow, not a reproducible cost for every video.

In frontend examples, I liked some of the typography and animation, and the design skill made a visible difference in the examples I viewed. My aesthetic judgment is subjective. The output is usable for a cheap model, but I would not claim it replaces every specialist design workflow.

I also asked Haiku to audit and categorize T3 Code pull requests, including performance-related changes. An early result found around 40 relevant PRs, but its label of merge readiness seemed to rely on GitHub's clean status rather than a thorough independent audit. I sent a promising example to Opus for deeper review.

The Fish Slap game demo was rough: it lacked mouse movement and sound, had awkward corners and failed to reproduce some timing from the original. I initially thought it avoided severe mistakes, then noticed additional problems. Compared with more capable models, its highs were lower even when some failures were less immediately dramatic.

The two Fish Slap runs used about $0.97 at API-equivalent rates in the displayed accounting. Forty-seven of 51 requests exceeded 100,000 input tokens and therefore used the higher price tier. Capping context could have reduced cost, but I expect it might also have made the game worse.

I generally prefer a stronger model to write the critical code. In my experience, gathering context, testing, verification and failed retries often cost more than producing the final code itself. A cheap model is valuable when it reduces those surrounding costs, but a failed run that burns far more tokens can be expensive too.

If several candidate implementations can be checked cheaply, a small model may be useful for generating them. It can also read documentation, compare projects or investigate several theories. The important question is whether the work is easy to partition and whether the resulting answers can be checked.

My broad PR audit ran into GitHub's rate limit. The script saved an error response as if it were data, and 181 PRs needed to be fetched again. The model said it would wait for the quota to reset, but I saw no wait scheduled, so the thread stopped until I intervened. This is one observed failure, not a measured failure rate.

I retried the idea with Opus as the orchestrator and Haiku as the delegated workers, asking Opus to minimize its own work outside collecting data and coordination. Opus considered batching the roughly 1,495 PRs. The video does not show a completed outcome for that larger follow-up, so I cannot claim that it solved the rate-limit problem.

A low unit price is not the whole story. If a stronger model solves a task in 100,000 tokens while a smaller one uses a million and still fails, the cheaper model can cost more overall. I use the benchmark cost points as clues, not as a replacement for testing the full workflow.

For my own workflow I still like Opus and GPT-6.1 Sol together. I find Sol useful as an auditor because it can bring a different perspective and catch things Opus misses. Haiku can join that portfolio for collecting information, reading large quantities of material and categorization when a stronger agent decides those tasks are appropriate.

My final assessment is that Haiku 5.5 fills a real gap in Anthropic's lineup. It is sometimes worth using, especially for well-scoped, cost-sensitive work, but it does not eliminate the need to select tasks carefully or verify results. I am excited to see where the rest of the model family goes.