Claude Haiku 5.5

Overview

Claude Haiku 5.5 is the smallest and fastest model in the current Claude family. It is built for work where speed and cost matter most: sorting incoming messages, extracting fields from text, routing requests, tagging records and handling the many small steps inside an agent. It trades some depth for responsiveness, which is a good deal when the task is clear and the volume is high.

Seen from a data team's side, Haiku 5.5 is the high-throughput worker. It can label thousands of free text cells, standardize messy categories, parse semi-structured fields into clean columns and decide which tool or model should handle a request. It does not replace a model that learns from tables, such as those described in /model/research and /model/architecture. It prepares and routes the data that those models consume. This page is a general explainer. Exact limits, prices and release details change, so check the official documentation for current values.

What it is

Claude Haiku 5.5 is a compact large language model from Anthropic. It reads text (and, in many setups, images and documents) and returns text, structured data or tool requests, with low delay and low cost per call.

Position in the family

Everyday analogy: at an airport, the check-in desk handles most travelers in a minute each. A supervisor handles the odd case. Haiku is the check-in desk: quick, consistent and perfect for the common path.

What it does well

• Classify text into a fixed list of labels.
• Extract fields such as dates, amounts, names and product codes into JSON.
• Route a request to the right tool, queue or larger model.
• Summarize short texts and rewrite them in a given style.
• Check simple rules, such as whether a record meets a policy.
• Serve as a sub-agent that does one narrow job inside a bigger system. See sub-agents.
• Power interactive features where users notice delay.

What it is less suited to

• Long, tangled reasoning with many constraints.
• Large code refactors across many files.
• Subtle judgment on ambiguous documents.
• Tasks where a rare mistake is costly and no check exists.

For those, move up a tier or add a verification step.

Where it came from

Anthropic released its first Claude models in 2023, and the family later settled on three named tiers: Haiku, Sonnet and Opus. The names come from poetry forms, from short to long, and match the size and effort of each tier.

The ideas behind a small, fast model are general.

• Transformers. The architecture comes from the 2017 paper "Attention Is All You Need". See transformers.
• Scale and efficiency. Smaller models are cheaper to run and faster to respond. Techniques such as distillation, careful data curation and efficient serving make small models stronger than their size suggests. Details of how any specific Claude model was built are not fully public, so this page avoids claiming them.
• Instruction following and safety training. See RLHF and Constitutional AI, the latter published by Anthropic in 2022.
• Serving techniques that speed inference, such as batching and caching. See vLLM and FlashAttention for general background.
• Agents. Smaller models became useful as workers in systems built with kits like the Claude Agent SDK and tools like Claude Code.

The practical idea: not every step needs the strongest model. Systems that match model size to step difficulty are cheaper and faster.

How it works

Step 1: Tokenize

Text is split into tokens. Short prompts mean few tokens, so small calls are cheap. Analogy: a postcard costs less to send than a parcel.

Step 2: Process with attention

The model passes tokens through transformer layers where attention links related parts of the input. A smaller model has fewer layers or narrower layers than a larger one, which is why it runs faster.

Step 3: Predict tokens

It scores possible next tokens and picks one, repeating until it finishes. For classification, the answer can be a single short token, which makes responses very quick. For extraction, a compact JSON object is typical.

Step 4: Constrain the output

For routing and extraction, free-form prose is a nuisance. Use structured outputs or a strict schema so that code can read the answer. Ask for an enumerated label, not a sentence.

{
  "type": "object",
  "properties": {
    "category": {"type": "string",
                 "enum": ["billing", "bug", "feature", "other"]},
    "urgent": {"type": "boolean"}
  },
  "required": ["category", "urgent"]
}

Step 5: Call tools when needed

Haiku can request tool calls too, for example to look up an order id. See function calling. In a router design it often picks which tool to call, and a larger model handles hard cases.

Step 6: Run at volume

Because each call is small, you can run many in parallel and in batches. Prompt caching helps when many calls share a long instruction block. See cost and latency budgets.

Step 7: Check

For high volume work, add automatic checks: schema validation, allowed label lists, spot checks by people and a stronger model reviewing a sample. See evals and LLM as judge.

Key concepts and terms

A worked example

Task: a table of support tickets has a free text column message and no usable category. We want a clean category column and a flag for urgency so that a downstream model can predict resolution time.

Step 1: Write a tight prompt

System: You label support tickets. Reply with JSON only.
Allowed categories: billing, bug, feature, account, other.
If the message is too short or unclear, use "other".
"urgent" is true only if the message mentions an outage, data loss,
a security problem or a hard deadline.

User: {message}

A narrow prompt with a fixed list is ideal for a small model.

Step 2: Run it over the column in batches

import json
import pandas as pd

df = pd.read_parquet("example.internal/tickets.parquet")

def label(message: str) -> dict:
    reply = call_model(                      # your wrapper around the API
        model="claude-haiku-5-5",            # confirm the current id in the docs
        system=SYSTEM_PROMPT,
        user=message[:2000],                 # cap length to control cost
        max_tokens=60,
    )
    return json.loads(reply)

labels = [label(m) for m in df["message"].fillna("")]
df["category"] = [l["category"] for l in labels]
df["urgent"] = [l["urgent"] for l in labels]

In production you would send these in parallel or through a batch interface, retry on errors, and validate each reply against the schema.

Step 3: Validate and measure

allowed = {"billing", "bug", "feature", "account", "other"}
bad = df[~df["category"].isin(allowed)]
print(len(bad), "rows failed the allowed-label check")

# Compare with a small human-labeled sample
gold = pd.read_csv("example.internal/gold_sample.csv")
merged = df.merge(gold, on="ticket_id", suffixes=("", "_gold"))
accuracy = (merged["category"] == merged["category_gold"]).mean()
print(round(accuracy, 3))

If accuracy is low on a specific class, add a short example of that class to the prompt, or escalate the uncertain rows to a larger model.

Step 4: Add a cascade for hard cases

def label_with_cascade(message):
    first = label(message)                     # Haiku
    if first["category"] == "other" and len(message) > 200:
        return label_stronger(message)         # a higher tier, only for hard rows
    return first

Most rows are decided by the cheap model. A small share is escalated. This pattern is a standard way to balance cost and quality.

Step 5: Use the new columns

Now the table has a clean categorical column and a boolean flag. A tabular model, such as TabPFN or a gradient boosting model like XGBoost, can use them to predict resolution time. The language model did the text cleaning. The table model does the prediction.

Reading the result

• The text column became two well-defined columns.
• A quick eval gave a measured accuracy instead of a hunch.
• A cascade protected quality on tricky rows.
• All calls stayed small, fast and cheap.

A second example: extracting fields from messy text

A column holds order notes such as "Please ship 3 boxes to the Springfield depot by the 14th, PO 88-1203". We want quantity, destination, deadline_day and po_number.

System: Extract fields from the note. Reply with JSON only.
Keys: quantity (integer or null), destination (string or null),
deadline_day (integer or null), po_number (string or null).
Use null when a field is not present. Never guess.

Key design choices:

• Every field may be null, so the model has a safe way to say "not present".
• The word "never guess" is backed by validation: the pipeline checks that po_number appears literally in the note.
• Types are strict, so code can load the result straight into columns.

import re

def validate(note: str, out: dict) -> bool:
    if out.get("po_number") and out["po_number"] not in note:
        return False
    if out.get("quantity") is not None and not isinstance(out["quantity"], int):
        return False
    return True

Rows that fail validation are retried once and then sent to a stronger tier or a human queue.

How to size an eval set

Report per-class precision and recall, not only overall accuracy. A model that never predicts the rare class can still score high accuracy.

Prompt iteration loop

1. Run the prompt on the gold set.
2. Read the errors, not just the score.
3. Group errors by cause: unclear label definition, missing example, ambiguous text, wrong gold label.
4. Fix the cause with the smallest change.
5. Re-run on the whole set to make sure nothing else broke.
6. Save the prompt and result with a version label.

Often a surprising share of "model errors" are really wrong gold labels or ambiguous definitions. Fixing those improves both the model and the process.

Strengths and limitations

Strengths

• Very low latency, which suits interactive features.
• Low cost per call, which suits large volumes.
• Good at narrow, well-specified tasks such as labeling and extraction.
• Works well as a router and as a sub-agent.
• Easy to scale with parallel calls and batching.
• Often accurate enough that a verification step is the main extra cost.

Limitations

• Less depth on complex, multi-step reasoning.
• More sensitive to prompt wording, so prompts need testing.
• May miss subtle cues in long or ambiguous documents.
• Can still produce confident wrong answers; validation is needed.
• Not suitable as the sole judge of risky decisions.
• Has a training cutoff and no private knowledge unless you provide it.
• Exact arithmetic and counting need tools.
• Small context budgets in practice, because long inputs raise cost even if they fit.

How it compares with alternatives

When labeled data exists in volume, a trained classifier on embeddings can match or beat prompting at lower cost. When labels are scarce or change often, prompting a small model is quicker to start and easier to adjust.

Role in tabular foundation models

Tabular foundation models are pre-trained on many synthetic or real tables. They learn from raw rows and columns, cope with mixed types and missing cells, can work without meaningful column names, and make predictions through in-context learning. See /model/research, /model/architecture, /model/benchmarks, TabPFN, TabICL and TabSTAR.

Haiku 5.5 is not a tabular foundation model. It is a language model used around them. Its speed makes it a natural data preparation and routing layer.

Turning text cells into columns

Real tables often contain free text: notes, product titles, addresses, comments. Tabular foundation models are strong on numbers and categories but are not designed to read paragraphs well. Haiku can convert text into clean categorical or numeric columns, as in the worked example. That widens what a table model can use.

Analogy: the language model is a translator who turns handwritten notes into form fields. The table model then does the analysis on the form.

Standardizing categories

A column such as country may hold "USA", "U.S.", "United States" and "us". Haiku can map each value to one canonical label in a single pass. Because there are usually few distinct values, you can map the unique values once and join back, which is cheaper than labeling every row.

uniques = df["country"].dropna().unique().tolist()
mapping = label_values(uniques)          # one small call per batch of uniques
df["country_clean"] = df["country"].map(mapping)

Naming and describing columns

Headers may be missing or cryptic. Haiku can propose names and short descriptions from sample values and any available dictionary, and mark low-confidence guesses. Table-native models can work without names, but people and downstream tools cannot. This links to semantic sector heads, where the aim is to infer the domain a table belongs to. Treat suggestions as drafts for review.

Cleaning and missing values

Haiku can flag impossible entries (negative ages, dates in the future), spot placeholder values like "N/A" or "-999", and normalize units. It can recommend whether a placeholder should become a true missing value. Filling gaps can then use a table-native method such as those in imputation networks. A language model should not invent values for numeric cells.

Routing between models

In a data platform, many requests arrive: classify this, forecast that, explain this chart. Haiku can read the request and route it:

• A prediction request goes to a tabular foundation model tool.
• A forecasting request goes to a time series model.
• A request to explain results goes to a larger Claude model.
• A request that looks risky goes to a human queue.

Anomaly triage

Anomaly detection methods produce scores for rows. Haiku can read a flagged row with a few neighbors and write a one-line description for a reviewer, or tag the likely type (data entry error, unusual but valid, possible fraud). The tag is a hint. Humans decide.

Sub-agent inside a larger workflow

A planner such as Claude Opus 5.5 can delegate narrow jobs to Haiku workers: profile a column, label a text field, check a rule. See orchestrator workers. The planner stays focused on the plan while workers handle volume.

Few-shot prompting versus in-context table learning

Both rely on examples placed in context, but the material differs. A language model sees text examples. A tabular foundation model sees labeled rows. For text labeling, give Haiku two to five short examples per class. For numeric prediction, use the table model. See few-shot learning.

Continual change

Labels and categories drift: new products appear, slang changes. Keep a rolling eval set, re-run it on a schedule and update the prompt or mapping when accuracy slips. A table model downstream may also need refits when the new categories enter.

Limits to respect

• Do not use Haiku to fabricate numeric features.
• Do not let it decide high-stakes outcomes alone.
• Do not send sensitive columns without masking.
• Do not skip validation of the labels it creates, since errors become features and spread downstream.

Practical guidance and best practices

Write narrow prompts

• One task per prompt.
• List the allowed outputs.
• Define each label in one line, and add an example for tricky ones.
• Tell the model what to do when unsure.
• Ask for JSON that matches a schema.

Keep inputs short

• Trim long texts to the part that matters.
• Remove boilerplate such as signatures.
• Deduplicate before labeling. Many tables repeat the same text.
• Cache the shared instruction block.

Measure before scaling

• Build a gold set of a few hundred rows labeled by people.
• Score accuracy per class, not just overall.
• Check the confusion between similar classes.
• Re-test after any prompt change.

Use cascades

• Let Haiku handle clear cases.
• Escalate low-confidence or conflicting cases to a higher tier.
• Track the escalation rate. A rising rate signals drift or a weak prompt.

Control cost and delay

• Cap output tokens tightly.
• Use batch interfaces for offline jobs.
• Run in parallel within rate limits, with retry and backoff.
• Cache repeated prefixes.
• See cost and latency budgets.

Keep it safe

• Treat text in tickets, emails and web pages as untrusted. It may contain instructions. See prompt injection defense.
• Validate every output against a schema and allowed values.
• Log inputs and outputs with version labels.
• Mask personal data where possible.
• Add guardrails for sensitive categories.

Monitoring in production

When to move off a small model

• Gold set accuracy stays below target after prompt work.
• Errors cluster on long or ambiguous inputs.
• The task needs several reasoning steps rather than a single judgment.
• The cost of an error is high and a stronger tier clearly lowers it.

Move only those steps. Keep the rest on Haiku. The goal is a system where each step uses the smallest tier that meets its quality bar.

Review and maintain

• Sample outputs weekly.
• Keep prompts under version control.
• Pin the model version in production and test upgrades on the eval set first.
• Keep a record of known failure modes.

Common mistakes

• Using a vague prompt and expecting a stable label set.
• Letting the model invent new labels because the list was not enforced.
• Skipping a gold set and trusting the labels by eye.
• Labeling every row of a column that has only a few distinct values.
• Sending very long text when a short excerpt would do.
• Using Haiku for tasks that need careful multi-step reasoning, then blaming the tier.
• Using a top tier for trivial labeling, wasting cost.
• Forgetting to handle empty strings, odd encodings and very long inputs.
• Not validating JSON output, so one malformed reply crashes a pipeline.
• Allowing instructions inside the data to change the labeling behavior.
• Feeding model-created labels into a table model without checking their quality.
• Ignoring class imbalance, so rare but important classes are labeled poorly.
• Leaving prompts unversioned, so nobody knows why accuracy changed.

Frequently asked questions

What is Claude Haiku 5.5 used for?

It is used for fast, high volume tasks such as classification, routing, field extraction, short summaries and narrow sub-agent steps. It is chosen when latency and cost matter more than the deepest reasoning.

How is Haiku 5.5 different from Sonnet 5.5?

Haiku is the smallest and fastest tier, while Sonnet is the balanced tier with more capacity for coding help, drafting and general analysis. Haiku is cheaper and quicker per call, and Sonnet is better when tasks are more open ended.

Can Haiku 5.5 replace a trained classifier?

Sometimes. For tasks with few labels and little training data, prompting a small model is a fast way to start. When you have plenty of labeled data and steady volume, a trained classifier on embeddings may be cheaper and more stable. Compare both on the same eval set.

Can it process a whole table?

It can help with tables, but it is better used on specific columns, such as labeling a text field or mapping unique categories, than on reading large tables cell by cell. Numeric learning and prediction belong to table-native models and code.

How does it fit with tabular foundation models?

It works around them. Haiku turns text into clean columns, standardizes categories, proposes column names, triages anomalies and routes requests. The tabular foundation model then learns from the cleaned rows and columns and makes predictions.

Is it accurate enough for production?

It can be, for well-defined tasks, but you should measure on your own data. Build a gold set, track accuracy per class, validate outputs automatically and keep an escalation path for unclear cases.

What is a model cascade?

A cascade tries a cheap model first and escalates to a stronger one only when needed, for example when the answer is unclear or fails a check. It keeps average cost and delay low while protecting quality on hard cases.

How do I stop it from returning free text when I need a label?

Use a strict schema or structured output with an enumerated list of allowed values, keep the prompt short and explicit, and validate each reply in code. Reject and retry anything that does not match.

Can it act as an agent?

Yes, as a worker with narrow tools and a clear task. For long, complex plans, a stronger tier usually leads, and Haiku handles the many small steps. This keeps the whole system fast and affordable.

Where can I find current limits and prices?

Check the official provider documentation. Numbers change over time, and this page does not quote specific figures.

Glossary

• Batch: many requests grouped together for efficiency.
• Cascade: a design where a cheap model decides first and a stronger model handles uncertain cases.
• Classification: assigning one of a fixed set of labels.
• Distillation: training a smaller model to imitate a larger one.
• Enum: a fixed list of allowed values in a schema.
• Extraction: pulling fields from unstructured text.
• Gold set: trusted labeled examples used for scoring.
• Latency: delay between request and response.
• Prompt caching: reusing a processed prompt prefix.
• Prompt injection: text that tries to override instructions.
• Router: a component that chooses where a request goes.
• Schema: a formal description of valid output.
• Sub-agent: a helper with a narrow task.
• Throughput: work completed per unit of time.
• Token: a unit of text for the model.
• Validation: automatic checking of outputs.

Summary

Claude Haiku 5.5 is the fast, light tier of the Claude family, suited to classification, routing, extraction and sub-agent steps at high volume. For tabular work it acts as the preparation and traffic layer: it turns text cells into columns, standardizes categories, suggests column names, triages anomalies and routes requests, while table-native models such as TabPFN and TabICL do the learning from rows and columns. Keep prompts narrow, outputs schema-bound and quality measured on a gold set, and use cascades to send hard cases to Claude Sonnet 5.5, Claude Opus 5.5 or Claude Fable 5.1. For the table-native side, read /model/research and /model/benchmarks.

Related

It belongs to Frontier models in my stack, under LLMs, retrieval, and evaluation. Others in the same group: