Haiku 5.5 lowers prices and changes what a log classifier must handle

A cheaper log classifier can fail before it classifies a single line. Old request settings may be rejected; a successful response may contain thinking but no usable answer; a refusal may arrive without fitting the expected schema. Anthropic’s October 7 release of Claude Haiku 5.5 brings lower token prices and these integration changes together. Following one log event through the migration makes the work easier to separate.

The launch announcement positions Haiku for high-volume work, including classification and extraction. For prompts up to 100,000 tokens, listed input and output rates are $0.10 and $0.50 per million tokens. Above that prompt threshold, they are $0.50 and $2.50. Anthropic reports an average cost reduction of around 75% relative to Haiku 4.5, accounting for changes in token use. That is a vendor assessment, not a saving measured by AIOpsSRE.

Those prices make a narrow classification service worth evaluating. The useful question is whether the same log evidence still reaches a defensible classification, including cases where the evidence cannot establish a cause. A faster route to an unsupported diagnosis would give the responder more correction work.

The classifier is a small application around a model. It sends an event, reads a category and gives that category to the next stage. Follow that path in order when a migration fails: did the request run, did the parser find a completed answer, and did that answer describe the log correctly? Those are three different repairs, even when the user sees only a missing classification.

A timeout is evidence of a symptom

Consider a hypothetical service reading worker logs and attaching a classification to each investigation. Its input shows a timeout while a worker contacted a storage endpoint and an increase in queue age. It contains no observation from the endpoint itself. The classifier may identify a storage-request timeout, but those records alone cannot establish that the storage service caused the failure.

A useful result would say that the worker timed out while contacting storage, cite the two records, and leave the cause unresolved. It would then name the missing observation: what was happening at the storage endpoint during that interval? That is a small wording difference with a large effect on the investigation. “Storage request timed out” describes the evidence; “storage was down” adds a conclusion the evidence has not supplied. A schema can require a cause field, but it cannot make that conclusion true.

A legal category is not necessarily a defensible diagnosis. The new model should preserve the missing endpoint evidence, not receive credit for filling every field. Otherwise a tidier response can quietly make the service more certain about something the original logs never established.

The old request may fail before classification

Anthropic’s Messages API migration guide says to replace manual thinking configurations using enabled and budget_tokens with adaptive thinking. It recommends omitting temperature, top_p, and top_k, and ending the message sequence with a user turn. Assistant-prefill patterns, such as a final assistant message containing an opening JSON brace, are rejected even when thinking is off.

A classifier that used prefill to begin its output needs a supported replacement, such as structured output where available or a tool with enumerated fields. The application still owns the check that a cited record exists and supports the proposed category. Enforcing the result’s shape cannot establish that relationship.

Keep a request failure attached to the original log item. If a client catches the error and substitutes an ordinary fallback category, the downstream system may treat an unclassified event as successfully processed. A visible unresolved item gives the responder or retry worker a truthful next step; an invented category hides why the model never classified it.

A successful HTTP response can still lack the answer

The Haiku behavior documentation explains that adaptive thinking is on by default. Content may begin with a thinking block, so a parser needs to select blocks by type instead of assuming the first block contains answer text. Thinking consumes the max_tokens allowance, and a small limit can stop generation before any text appears.

The same documentation says the newer tokenizer produces approximately 30% more tokens for the same input text than Haiku 4.5, with the exact increase depending on content. Recounting the classifier’s actual prompts and reviewing output headroom therefore matter even when its requested answer is short. A one-line classification does not mean all preceding computation fits a one-line token allowance.

Structured output does not remove every unsuccessful state. Its documentation says a safety refusal can arrive with HTTP 200 and an output that does not match the schema. Token-limit termination can also leave output incomplete. Checking transport status alone would count either case as a completed classification.

For the illustrative log service, these states need different treatment:

Observed result	Classification state
Request or client error	The item remains unclassified.
Refusal or truncated output	The item needs an explicit unresolved path.
Valid shape with unsupported cause	The semantic evaluation rejects the result.
Valid result preserving evidence and uncertainty	The application can accept the classification.

These are proposed states for the application, not built-in Haiku labels. They let the queue keep an honest account of what happened. An API error means the classifier never got to decide; a truncated answer means it did not finish; a confident but unsupported diagnosis means it finished the wrong job. Each needs a different next step, even though all three might otherwise disappear behind a single “failed” counter.

Compare the exception, then tune effort

Use the model-evaluation approach: keep evidence and acceptance criteria comparable while evaluating the configuration. For the timeout case, retain the same logs and require both candidates to preserve the missing endpoint evidence. Add a case with independent endpoint evidence so the test also checks whether the service can recognize a supported conclusion.

The replay should exercise request validation, response parsing, and the eventual classification. Record which stage failed instead of merging all failures into a model-quality score. That distinction tells the engineer whether to repair the integration or adjust the model’s instructions and effort.

Anthropic’s prompting guidance identifies effort as the main cost and quality control. It also describes a specific interaction: with thinking off and structured JSON output, Haiku may skip a needed tool call. If this classifier must retrieve an endpoint observation, test that lookup directly; well-formed JSON is not evidence that it occurred. The same guide says repeated identical requests usually repeat a refusal, so an automatic retry is not a substitute for handling that result.

This migration guidance applies to Messages API integrations. The migration guide says Managed Agents requires only updating the model name, and Haiku 5.5 does not support Priority Tier. A Haiku 4.5 capacity commitment therefore needs separate planning, even if the classifier’s correctness checks pass.

Return to the worker’s timeout. A successful migration gets the request through, handles the actual response and still distinguishes “the worker timed out contacting storage” from “storage was down.” Lower rates make the experiment attractive. Those paired examples tell you whether the cheaper path leaves the responder with the same useful account of what happened.