Claude Haiku 5.5: Cheap, Fast AI Agents in Python

Prices of Haiku, Sonnet and Opus 5.5 side by side, the specifications confirmed with the Models API, the benchmarks Anthropic published, and the jobs Haiku was built for: classification, routing, extraction, summaries and subagent work.

Your first call from Python with the Anthropic SDK 1.13, why you must read content blocks by type, and the real errors you get from code written for Haiku 4.5: temperature, assistant prefill and thinking budgets. Plus the new tokenizer, which counts about 30% more tokens for the same text.

The same 30 labeled tickets at low, medium and high effort and with thinking switched off, with accuracy, thinking tokens, time and cost for each run. Higher effort thought nine times more without getting more tickets right; you will learn how to choose the setting.

Build CostCutter's triage step with structured outputs and a cached support policy, then run it with Haiku, Sonnet and Opus 5.5. Haiku matched Opus on accuracy at about 1/29 of the cost. You will also see why the first version of the policy only got 23 of 30 right, and what fixed it.

Count tokens for free with count_tokens and measure the new tokenizer: the same support policy, ticket and ticket set count 33 to 37% more tokens on Haiku 5.5 than on Haiku 4.5. You will see why a price ten times lower per token was 7.4 times cheaper per task, and estimate a monthly input bill before the first call.

Let Haiku's triage pick the writer: Haiku drafts routine replies and Opus 5.5 only the escalations. Measured on the 30 tickets against Opus writing every reply, with the cost per model, where the routed bill goes, and the checks to run before you trust a router.

An Opus orchestrator writes the weekly support report and delegates reading to Haiku workers through a strict tool, eight at a time. On short tickets it saved nothing, and you will see exactly why; on long email threads (71,630 tokens) the same report was 80% cheaper.

Cache the long, fixed support policy with one field (Haiku 5.5 caches from 512 tokens), watch a cold cache call by call, and send 30 requests through the Batch API at half price. Plain calls, batch and caching compared on the same tickets.

Haiku 5.5 accepts 1M tokens, but over 100,000 prompt tokens the whole request costs five times more. Measured: 94,189 tokens for under a cent, 103,869 tokens for 5.5 times the bill. How CostCutter prices it and how to stay under the line.

Read the screenshots customers attach: an image block, a schema with error_visible and error_text, and three real PhotoShare screenshots. Haiku and Opus gave the same answers, copied the error text exactly, and Haiku cost about a hundredth of a cent per screenshot, 1/40 of Opus.

Two ways to get a successful response without an answer: thinking that uses up max_tokens (measured: stop_reason max_tokens with only a thinking block) and refusals, which have no server-side fallback on Haiku 5.5. One small function guards against both, plus every stop_reason you should handle.

Regression tests against the real API with pytest and the 30 labeled tickets: a margin for team accuracy, zero tolerance for missed escalations, and one pinned case. When to run them: after policy edits, before model or effort changes, and in CI.

The whole system on three tickets it has never seen: a how-to question, a double charge and an account takeover. Triage, routing and drafts, all correct, then a close reading of the drafts (a placeholder link, an internal note at the top) and the ledger for the three tickets.

Turn a measured cost per ticket into a monthly budget: about $129 a month at 1,000 tickets a day with routing, against $311 if Opus wrote every reply, and 73 cents for the cached triage alone. Where to cut next, and a recap of what you built.