Skip to content
kenjtecJournal
Search the Journal

Haiku 5.5: small AI tasks get their own helper

Haiku 5.5 was released on 7 October 2026. A concrete classification contract shows why small models above all need well-defined subtasks.

At the counter, Ana sorts envelopes into two baskets; a red envelope lies apart next to a desk bell. AI illustration.

“Please sort this” sounds like a small task. But as soon as a message contains two requests, the decisive rule is missing: must it go into exactly one folder, may it be assigned to several, or does someone need to ask a follow-up question? The size of a model does not answer this working decision.

Anthropic dates the launch of Claude Haiku 5.5 to 7 October 2026. Among other things, its positioning targets frequent, narrowly defined tasks such as summarisation and classification. Performance and cost comparisons on the vendor’s page are vendor figures. This is about a usage contract of our own that can be traced, not a measured model comparison.

A category needs a meaning

Our fictional service inbox contains questions about registration, appointments and existing invoices. The first task is merely to suggest suitable areas of responsibility. It does not send a reply and does not change a booking. That way, an error initially stays in an intermediate result that can be checked.

Describe the categories by their meaning. In this example, “invoice” covers questions about existing billing documents. “How much will a future appointment cost?” is something else. A single keyword would not be sufficient grounds for a decision. The assignment has to convey the intended context.

Explicitly allowing several requests

The artificial message “I would like to register and correct the old billing address” touches two areas of responsibility. A forced single category would lose part of it. For this example, we therefore allow several categories and ask for a short supporting quote per category.

{
  "kategorien": ["anmeldung", "vorhandene_rechnung"],
  "belege": ["would like to register", "correct the old billing address"],
  "rueckfrage_noetig": false,
  "aktion": "nur_vorschlag"
}

The self-designed JSON illustrates a results contract, not a prescribed Haiku interface. A program that processes the answer further would also have to check the structure and the permitted values. A formally valid object can still contain a factually wrong assignment.

A follow-up question is a result in its own right

Without any reference, “That doesn’t fit like this” may contain too little information. The appropriate status can then be “follow-up needed”. It is not a substitute for careful reading but an intended route for a case that is genuinely unclear.

Also define what happens to a message that is outside the scope. It should not have to be forced into a known category. A small classifier becomes easier to understand when its area of responsibility visibly ends. The next person receives the original text, the suggested category and the reason why uncertainty remains.

Looking at the whole process, not just the answer

For a comparison, you need clear-cut cases, messages with several requests, unclear back-references and off-topic texts. Write down the expected handling beforehand. Then look separately at correct suggestions, overlooked requests, unnecessary follow-up questions and misrouted cases.

Human follow-up work belongs here too. A quickly generated category saves little if the next person constantly has to reopen the entire case. A short supporting quote can make review easier, but it is not proof of truth in itself. It has to actually match the message.

For a technical integration, you limit the permitted categories to a fixed list. Free text may explain the reason but must not invent a new area of responsibility. Checking the response structure and reviewing the content remain separate steps.

What the release is an occasion for

Haiku 5.5 makes splitting large workflows into smaller model tasks an interesting topic of discussion. A first building block can sort, while a person later decides on a reply. It follows neither that a smaller model is always enough nor that a larger one automatically resolves the same substantive ambiguity.

Start with artificial examples and a limited results contract. Prices, access and the specific availability of the model should be checked again for any later trial. The release notes provide the timeline; whether the subtask is useful in your own setup is decided by the overall process, looked at in a traceable way.

Sources and documentation status: 25 October 2026.

Hamburg is our starting point.

The useful part travels with you.

Practical AI from Hamburg, explained for everyone.

Saved articles