Claude Haiku 5.5: When the Cheap Tier Stops Being a Compromise

Anthropic released Claude Haiku 5.5, describing it as the cheapest, fastest and most capable small model it has shipped. The target workloads are unglamorous and enormous: summaries, compactions, database queries, classification requests. Anthropic also positions it as a subagent alongside Opus 5.5 and Sonnet 5.5 on coding work, and notes it is its fastest model to date, which matters for live customer support and browser use. Pricing starts at $0.10 per million input tokens and $0.50 per million output tokens, with a 1M-token context window and up to 128K output tokens.

Route by task, not by habit

What shipped

Haiku 5.5 keeps a one-million-token context window - a fivefold jump from the 200K ceiling Haiku 4.5 shipped with - and up to 128K output tokens. Anthropic says that on average it now costs around 75% less to run than Haiku 4.5. It is the first Haiku-class model with an adjustable effort setting, so you can trade cost against intelligence per call rather than per deployment. Alongside the launch, Anthropic halved the price of Sonnet 5.5 cache reads, which it says makes Sonnet 5.5 around 20% cheaper on most agentic work, and introduced a monthly API credit for Claude Max and Team subscribers.

# Price the pipeline, not the model. Published list prices for
# Haiku 5.5: $0.10 per 1M input and $0.50 per 1M output for prompts
# up to 100K tokens; long-prompt tier above that; cache reads $0.01.
def monthly_cost(mix, price_in=0.10, price_out=0.50):
    total = 0.0
    for job in mix:
        total += (job['in_tokens'] * price_in + job['out_tokens'] * price_out) / 1e6
    return round(total, 2)

# The number that decides anything is the delta against whatever
# model those jobs run on today, not the sticker price.
def delta(before_usd, after_usd, retries_before=1, retries_after=1):
    return {'before': before_usd, 'after': after_usd, 'saving_pct':
            round((1 - after_usd / before_usd) * 100, 1),
            'retry_penalty': round(retries_after / retries_before, 2)}

Read the benchmark table like an engineer

Anthropic's own table is unusually honest about the gap that remains. On Terminal-Bench 4.0, a test of agentic coding, Haiku 5.5 scores 39.2% against Sonnet 5.5's 70.6%. On the offline subset of OSWorld 2.1, computer use, it reaches 72.4% against Sonnet 5.5's 83.9%. On Humanity's Last Exam it gets 45.9% without tools and 57.4% with them, versus 56.9% and 64.5% for Sonnet 5.5. On knowledge work it posts 1620 on GDPval-AA v2.1 and 1578 on AA-Briefcase v1.1. The pattern is consistent: Haiku 5.5 is strong on high-volume work and clearly behind on the hardest agentic loops.

# The 1M window is the real unlock: it removes the reason to upgrade
# mid-pipeline just to fit the document.
MAX_OUTPUT = 128_000

def route(doc_tokens: int, task: str) -> str:
    if doc_tokens > 1_000_000:
        raise ValueError('chunk it - no model will silently absorb this')
    if task in {'classify', 'summarise', 'compact', 'db_query'}:
        return 'claude-haiku-5-5'          # cheap tier, long context
    if task in {'synthesise', 'judge', 'plan'}:
        return 'claude-opus-5-5'           # pay for judgement
    raise ValueError(f'unclassified task: {task}')

# An unclassified task is a bug in your router, not a reason to
# default to the expensive model. Defaults are where budgets die.

A cheap model that retries three times is not cheap

The 1M window is the actual unlock

Price cuts get the headlines, but context is what changes architecture. Context limits are usually the reason teams upgrade from a cheap model to a pricier one in the middle of a pipeline, because the document will not fit. At one million tokens with 128K of output, a large share of retrieval-then-reason patterns can stay on the cheap tier end to end. That eliminates a tier switch, and a tier switch is where latency, prompt drift and cost surprises live. Treat 1M as finite anyway: instrument truncation, because a long-context model still hits a wall and you want to see it in a chart before your users do.

# Caching changes the arithmetic more than a list-price cut does.
# Cache reads are an order of magnitude cheaper than fresh input.
def effective_input_rate(cache_read_tokens, fresh_tokens,
                         read_rate=0.01, fresh_rate=0.10):
    blended = (cache_read_tokens * read_rate + fresh_tokens * fresh_rate) / 1e6
    return {'blended_input_usd': round(blended, 6),
            'cache_hit_rate': round(cache_read_tokens / max(cache_read_tokens + fresh_tokens, 1), 3)}

# If cache_hit_rate is flat while traffic grows, you have a stable
# prefix problem, not a model problem. Fix the prompt layout first.

Cost per finished task, not cost per token

Every price comparison that stops at dollars per million tokens is measuring the wrong thing. What matters is the cost of a task that actually completes. A model that fails and retries three times can be more expensive than the pricier model that succeeded first time, and it also burns wall-clock time your users feel. Build the comparison on ten real tasks from your own repository, in your own harness, and record pass rate, p95 latency and retry rate alongside spend. Anthropic's customers describe improvements in these terms: Asana reported over 30% lower latency on task completions and up to 2.5x faster inference per agent turn, while Box reported an 11-point gain over Haiku 4.5 at about half the latency.

# Benchmark on your own tasks. Anthropic publishes benchmark numbers;
# you need numbers for YOUR distribution.
import statistics, time

def run_suite(model, tasks, call, retries=3):
    lat, ok, attempts = [], 0, 0
    for t in tasks:
        for _ in range(retries):
            attempts += 1
            t0 = time.perf_counter()
            r = call(model, t)
            lat.append(time.perf_counter() - t0)
            if r.ok:
                ok += 1
                break
    lat.sort()
    return {'pass_rate': round(ok / len(tasks), 3),
            'p50_s': round(statistics.median(lat), 2),
            'p95_s': round(lat[int(len(lat) * 0.95) - 1], 2),
            'retry_rate': round((attempts - ok) / attempts, 3)}

# p95, not the mean. Averages hide the calls your users complain about.

Measure cost per finished task, not cost per token

Adjustable effort is a routing dimension

Before this release, effort was effectively something you chose by choosing a model. Haiku 5.5's adjustable effort setting makes it a per-call parameter, which means your router gets another axis. Classification and extraction can run at low effort; summarisation and query work at medium; genuinely hard reasoning at high. The trap is turning it up globally after one bad eval, because that is how a 75% saving quietly becomes a 20% saving with nobody noticing until the invoice. Tune effort against your own pass rate per task type, and re-check when the task distribution shifts.

# Adjustable effort is the new dial. Treat it as a routing dimension
# you tune per task, not as a global setting you set once.
def effort_for(task, budget_ms, observed_ms):
    if task in {'classify', 'extract'}:
        return 'low'        # cheapest, still accurate on short work
    if task in {'summarise', 'db_query'}:
        return 'medium'
    return 'high' if observed_ms > budget_ms else 'medium'

# Tune effort against YOUR pass rate. Turning it up everywhere is
# how a 75% saving quietly becomes a 20% saving.

How to actually migrate

Start with a costed inventory: which pipelines run today, at what volume, and what share of that volume is high-volume repetitive work. Move one pipeline, measure pass rate and p95 before and after, then decide. Fix prompt layout before you blame the model, because cache hit rate is dominated by whether your stable prefix is actually stable - and it is now cheaper than ever to get that wrong quietly. Keep a fallback to the previous model wired up from day one, log which model served each request, and put the effort setting in config rather than in code so you can change it without a deploy.