Haiku 5.5 Changes the Bill and the Agent Contract

Anthropic has made a much stronger case for putting a small model to work between the expensive steps of an agent. Claude Haiku 5.5, released October 7, targets repetitive jobs such as classification, extraction, summaries and narrowly scoped assistance to larger models. The useful question is no longer just whether those jobs deserve a separate model. It is whether a team can preserve the savings after accounting for context, reasoning, rejected requests and the software that connects the calls.

The posted short-prompt rates are $0.10 per million input tokens and $0.50 per million output tokens. Prompts above 100,000 tokens move to $0.50 and $2.50, respectively. Haiku 4.5's listed base rates are $1 and $5. That is a substantial reduction at either length, but the new model does not have one universal price. A workload distribution belongs next to any proposed savings figure.

Consider a deliberately simplified calculation: 100 million input tokens and 10 million output tokens, spread across requests that all qualify for the short-prompt tier, cost $15 at the new base rates rather than $150 at the old ones. This holds token counts fixed and excludes caching, tools and other charges. It is arithmetic, not a forecast of an application's bill. Once the same task produces different token counts, the comparison must be recalculated.

Anthropic estimates an average saving of around 75%, accounting for its earlier request mix and the changed tokenizer. That is the company's estimate, not an independently measured saving for a new customer's production workload. The announcement also halves Sonnet 5.5's cache-read rate from $0.20 to $0.10 per million tokens. A team already using Sonnet should therefore compare Haiku against the updated alternative, not a price sheet from before the launch.

The tokenizer change deserves an actual measurement. Anthropic's model-change documentation says the same text uses approximately 30% more tokens than with Haiku 4.5, with the increase depending on content. It also lists a million-token context window and up to 128,000 output tokens, compared with 200,000 and 64,000 for the predecessor. More capacity is available, but it does not erase the cheaper tier's boundary.

That combination changes how a migration should be sampled. A team whose ordinary requests sit well below the threshold has a different exposure from one whose documents cluster near it. In our view, the most revealing initial report would plot the new token counts for existing tasks, rather than multiply last month's aggregate usage by a discount. Otherwise, the distribution that determines the bill remains invisible inside an attractive average.

Simon Willison's independent hands-on account offers a useful, limited cross-check. His long test prompt used roughly 1.25 times as many tokens with the new model. That is not identical to Anthropic's approximate 30% increase, but neither source presents a universal conversion factor. Willison also reports a seven-second low-effort illustration attempt and a five-minute-nine-second maximum-effort attempt. These are individual creative tests, not a representative latency benchmark. They illustrate why the selected effort belongs in any description of model speed.

There is a specific disagreement worth preserving. Willison writes that reasoning cannot be disabled. Anthropic's current effort documentation says Haiku 5.5 permits disabled thinking at low, medium and high effort, while rejecting it at xhigh and max. For implementation, the current provider contract is the relevant reference. The disagreement is a reason to test the precise request being deployed, not silently blend the two accounts into a supposedly settled feature description.

Effort itself is not a hard spending cap. The provider describes it as a behavioral control affecting explanations, tool calls and thinking. Haiku offers five levels and defaults to medium. Lowering the setting can change what the agent does, not merely how many words it uses to report the result. A shorter response may represent a more efficient route, or less work. An evaluation needs to distinguish those outcomes.

The same documentation introduces a subtler cost interaction: changing top-level effort during a conversation invalidates its cached prefix. A beta per-message mechanism preserves caching and is supported for Haiku 5.5 on the Claude API and Google Cloud. That distinction matters for a router that alternates between easy and difficult turns. The proposed saving from less reasoning should be measured alongside any lost reuse of earlier context, with platform support checked rather than assumed.

Anthropic's Haiku-specific prompting guide gives a concrete warning about that tradeoff. In its long-agent-prompt tests, moving from low to medium effort roughly halved early stopping, but more than doubled output tokens per attempt. These are vendor test results, not an application-wide reliability guarantee. They do establish that the lowest-cost attempt and the lowest-cost completed task are different objectives.

The guide also warns that, with thinking disabled and structured JSON output requested, the model may omit a necessary tool call. A syntactically valid object is therefore an insufficient acceptance check for a task requiring retrieval. Our recommendation is to record whether the required evidence was actually obtained and used. A successful parser should not be allowed to turn an unsupported answer into a successful business transaction.

Some failures are neither weak reasoning nor infrastructure outages. The prompting documentation says safety classifiers can return a refusal, benign work can sometimes trigger them, and Haiku 5.5 has no server-side fallback. Repeating the same declined request usually produces another refusal. An application needs an explicit way to report or review that outcome. Treating it as a generic transient error risks spending more without making progress; bypassing safeguards is not a substitute for a legitimate escalation path.

The migration guide makes clear that this is not always a model-name substitution. Manual thinking budgets, unsupported sampling settings and assistant-prefill patterns can require changes. Responses can begin with thinking blocks, so an integration that assumes the first block is the answer needs attention. These are interface-contract issues. They should be exercised before comparing response quality, because a broken client can obscure what the model actually returned.

Stored conversations require equal care. The guide says thinking blocks are usable only within the originating account or a linked account. It also documents checks that invalidate returned thinking blocks when earlier system instructions, tools or messages change, with an exception for older accounts unless they opt into the specified behavior. Teams replaying saved sessions across customers or changing prompts mid-session should consult those exact conditions. A successful fresh conversation does not validate every replay path.

Token counting offers a practical way to inspect the input side before rollout. Anthropic provides a free endpoint with separate rate limits that accepts structured messages, including system prompts and client-tool definitions. Its result is an estimate, not a final bill. The endpoint does not apply prompt-caching logic, and it rejects several inputs that the Messages API accepts, including most server tools and the MCP connector. For those requests, the documentation points to actual response usage.

That limitation is operationally useful information. A team should not discover during its cost audit that the estimator silently omitted the very tools its agent uses. Keep the original request shape when the endpoint supports it, document unsupported cases, and reconcile estimates against observed usage. Count against the target model rather than reuse measurements from the predecessor. This produces an auditable basis for routing decisions without pretending that a preflight estimate predicts the number of future agent turns.

Context retention adds another difference between generations. Anthropic's context-window guide says Haiku 5.5 keeps earlier thinking blocks by default, while Haiku models through 4.5 strip previous thinking blocks when they are passed back. Retained blocks occupy context and are billed as input in later requests. The output generated now can therefore become part of the input budget later, even when it is not ordinary user-visible conversation text.

Caching does not make that context disappear. The same guide says cached prefixes still occupy the window, and input usage is split among ordinary input, cache reads and cache creation. A review that watches only the first field will not describe the whole request. For longer sessions, the guide identifies compaction and context-editing options. Their presence is not permission to discard information indiscriminately: the application still needs the facts and constraints required to finish its task correctly.

Distribution is already visible beyond a launch page. Glean's October 7 release note makes Haiku 5.5 selectable in its Assistant and Agents products, subject to administrator enablement, and warns that usage-based pricing may apply. This is first-party evidence of an integration, not an independent validation of accuracy or customer savings. It also shows why availability and permission are separate questions: a model can exist in a product while remaining unavailable to an individual user's workflow.

For a builder, that separation suggests a bounded rollout. Start with a task whose output can be checked, such as extracting a specified field from a supplied document. Keep the accepted-output criteria fixed while comparing the old and new paths. Include representative ambiguous inputs, missing evidence, long documents and declined requests. A test made entirely from easy successes would reveal little about the cases that force expensive review or escalation.

Measure the cost of accepted results, the proportion sent for review, and the slow end of completion times. Keep token categories and effort settings attached to each result so a change can be explained. If Haiku performs the preliminary work and another model finishes it, count both. This is our evaluation recommendation, not a claim that any particular routing arrangement has already beaten a single-model baseline.

The strongest case for adoption is consequently specific rather than universal. A verified short task that becomes cheap enough to run frequently can justify a new product behavior. A task that needs prolonged reasoning, repeated correction or sensitive authority may call for a different path. Haiku 5.5 expands the options materially. The opportunity is to buy the right amount of work for each job, while keeping responsibility for completion in the application rather than in the price headline.

LaunchPad positionCompare accepted-task cost after recounting tokens, validating conversation replay and measuring the work skipped at lower effort.