Claude Haiku 5.5 AI Agents: Build Cheap, Fast Subagents

Introduction

Most AI agent bills are not driven by the one clever planning call. They are driven by hundreds of small calls around it: summarizing logs, classifying tickets, extracting document fields, and compacting long conversations. Claude Haiku 5.5, released by Anthropic on October 7, 2026, is built for that worker layer. This tutorial shows how to use it as a subagent in Claude Code, in an API agent loop, and in n8n, with checkable cost math and quality gates.

Quick answer

Give Haiku 5.5 narrow, verifiable subtasks, keep Sonnet or Opus in charge of planning and review, and keep worker prompts under 100,000 tokens to hold the lowest price tier.

Evidence: what Haiku 5.5 changes for agents

Start with the numbers, all as of October 2026. Anthropic calls Haiku 5.5 “the cheapest, fastest, and most capable small model we’ve ever released,” and positions it for “high-volume, cost-sensitive tasks” such as summaries, compactions, database queries, and classification. The model carries a 1M-token context window and up to 128K output tokens, and it is the first Haiku model with an adjustable effort setting, so callers can trade cost against intelligence per task instead of per model.

Pricing is where the agent design follows from the price list. For prompts up to 100,000 tokens, Anthropic lists $0.10 per million input tokens and $0.50 per million output tokens on the official Claude Haiku 5.5 announcement page. Above 100,000 tokens, those rates rise to $0.50 input and $2.50 output per million tokens. Anthropic says Haiku 5.5 costs around 75 percent less to run on average than Haiku 4.5, and that prompts up to 100,000 tokens made up around 90 percent of requests to the previous Haiku model. The practical lesson is simple: the low tier is the default only if your worker prompts stay short, which is also good agent design.

Benchmarks support using Haiku 5.5 for bounded work, not for everything. On OSWorld 2.1, which measures multi-step computer use, Haiku 5.5 scored 72.4 percent on the offline subset against 15.7 percent for Haiku 4.5. On Terminal-Bench 4.0, an agentic coding benchmark, it scored 39.2 percent while Haiku 4.5 scored zero. Anthropic is explicit that Sonnet 5.5 and Opus 5.5 remain the better choices for complex agentic coding tasks, while Haiku 5.5 fits narrowly scoped work such as compaction, summarization, or subagent tasks. That is the routing rule for this whole tutorial.

A customer result from the launch page shows what the routing rule buys. Aaron Vinh, a Staff Software Engineer at Asana, said: “We saw over a 30% reduction in latency for task completions and up to 2.5x faster inference per agent turn.” Every slow worker delays the planner, the tool loop, and the user, so latency is a quality feature here.

Two cautions keep the cost story honest. The official Claude Haiku 5.5 migration guide states that the same text produces approximately 30 percent more tokens on Haiku 5.5 than on Haiku 4.5, because 5.5 uses a newer tokenizer. A prompt that counted 80,000 tokens on Haiku 4.5 can count around 104,000 on Haiku 5.5, crossing into the higher tier. The 75 percent saving is also a vendor average, not a promise for your workload, so measure your own calls before scaling.

Prerequisites

• An Anthropic API key, or access through Amazon Bedrock, Google Cloud, or Microsoft Foundry, where the model ID is claude-haiku-5-5 (anthropic.claude-haiku-5-5 on Bedrock).
• Python 3.10 or later with the Anthropic SDK installed, if you follow the API loop section.
• Claude Code installed, if you follow the subagent section.
• An n8n instance with Anthropic credentials configured, if you follow the n8n section.
• One real agent task to migrate, ideally a repetitive worker job you already run, so you can compare cost and quality before and after.

Step-by-step guide

Step 1: Split the agent into planner, workers, and reviewer

Before touching any model setting, draw the split on paper. The planner breaks the request into subtasks and decides when the job is done. Workers each do exactly one subtask and return a structured result. The reviewer checks output against the original request and either accepts it or sends one subtask back with a correction.

Haiku 5.5 belongs in the worker layer and, for well-specified checks, in the reviewer layer for format and completeness, not in the planner layer for open-ended work. A useful test: you can write its success criteria in one sentence, and a human could verify its output in under a minute. “Summarize this 2,000-word ticket into three bullets and a severity label” passes. “Redesign the billing workflow” does not.

Step 2: Price one worker call before you build the loop

Run the cost math on your real prompt sizes, not on marketing averages. At the under-100K tier, a worker call with 8,000 input tokens and 1,500 output tokens costs 8,000 divided by 1,000,000 times $0.10, plus 1,500 divided by 1,000,000 times $0.50, which is $0.0008 plus $0.00075, or about $0.0016. Ten thousand such calls cost about $15.50. The same token counts on Haiku 4.5 rates of $1.00 input and $5.00 output per million tokens would cost about $0.0155 per call, or $155 for ten thousand calls. That is the 90 percent token-price gap Anthropic advertises for the under-100K tier.

Now apply two corrections. Recount prompts with the Haiku 5.5 tokenizer, because a 30 percent token increase can push a borderline prompt into the fivefold tier. Cap output with max_tokens and a strict format, because a rambling worker produces the expensive half of the bill. If measured cost per successful task is more than double the estimate, your prompts are too long or your retries too frequent.

Step 3: Build the API worker loop with strict output

The smallest useful Haiku 5.5 agent is a loop with a narrow system prompt, a tool or a structured output contract, and a retry budget. The example below uses the Python SDK, sends one classification task, and forces a JSON-shaped answer so the caller can verify it without parsing free text.

pip install anthropic

import json
import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-haiku-5-5",
    max_tokens=800,
    messages=[
        {
            "role": "user",
            "content": (
                "Classify this support ticket and return JSON only, "
                "with keys category, severity, and summary. "
                "Severity must be low, medium, or high. "
                "Summary must be one sentence.\n\n"
                "Ticket: The checkout page returns a 500 error "
                "when a discount code is applied twice."
            ),
        }
    ],
)

text = response.content[0].text
result = json.loads(text)
assert result["severity"] in ("low", "medium", "high")
print(result)
print("input tokens:", response.usage.input_tokens)
print("output tokens:", response.usage.output_tokens)

Three details do real work. The max_tokens cap bounds the expensive output side. The JSON-only instruction plus the assert turns a silent wrong answer into a loud failure. Printing usage gives measured cost data to compare against the Step 2 estimate. Allow two retries, then escalate to the larger model with the failed outputs attached. Infinite retries erase the price advantage faster than any price tier does.

Step 4: Add a Claude Code subagent for the repetitive jobs

In Claude Code, the same worker pattern becomes a reusable subagent file. Create a file such as .claude/agents/ticket-triage.md in your project, with a description that tells Claude Code when to delegate, a narrow tool list, and a strict output contract. The official Claude Code sub-agents documentation describes this delegation model, and our Claude Code subagent effort levels guide covers per-agent effort control in more depth.

---
name: ticket-triage
description: Triage one support ticket into category, severity, and a one-sentence summary. Use for incoming tickets only, not for code changes.
model: claude-haiku-5-5
tools: Read, Grep
---

You triage exactly one support ticket per invocation.

Rules:
- Read only the ticket text and the files the main agent names.
- Return JSON only, with keys category, severity, and summary.
- Severity must be low, medium, or high.
- If the ticket lacks the information needed to classify it, set severity to medium and say so in the summary.
- Never edit files, never run commands, never guess a root cause.

Keep the tools list short on purpose. A triage subagent with Read and Grep cannot accidentally edit code or run a migration. The main agent gets back structured data it can verify, and the expensive planner never spends tokens reading raw ticket text. If you are migrating a Haiku 4.5 setup, read our Claude Haiku 5.5 migration guide first, because its parameter changes apply to subagents too.

Step 5: Wire the same worker into an n8n AI Agent

n8n users get the same split without writing a loop. In an n8n workflow, add an AI Agent node, attach an Anthropic Chat Model node, and select claude-haiku-5-5 as the model. Connect only the tools that one worker needs, for example a ticket lookup tool and a knowledge base search tool, and write the agent prompt as a job description with a deliverable: “Triage the ticket from the webhook, return category, severity, and a one-sentence summary, and stop.” Add a second AI Agent node with Sonnet 5.5 only on the review path, triggered when the worker output fails a format check or when severity is high.

This matches the pattern in our n8n AI Agent tutorial, with one change: the worker node drops to Haiku 5.5, and the money saved funds the review node. For a broader map, see The Complete n8n Guide. The common n8n cost mistake is giving the worker every tool in the workflow, since every tool description adds billed input tokens to every turn. Keep worker tool sets minimal.

Step 6: Log every call for one week, then decide

Ship the worker with logging from day one: model ID, input and output tokens, latency, subtask type, and a pass or fail verdict from your format check. After a week, or at least 500 calls, answer three questions from the log: measured cost per successful task versus the Step 2 estimate, which subtask types drive format failures and escalations, and how many prompts crossed 100,000 tokens. Move a subtask type back to Sonnet 5.5 if its escalation rate stays above 10 percent after one prompt fix. Grant Haiku 5.5 a subtask type only after 100 logged calls with an escalation rate under 5 percent.

Troubleshooting

The worker returns good text that fails the format check

This is usually a prompt problem, not a model problem. Haiku 5.5 follows a short, explicit output contract well and drifts when the contract is buried in a long system prompt. Put the format first, give one example of the exact JSON shape, and move background context into a tool the worker can query instead of pasting it into every call.

The bill is higher than the price page suggested

Check token counts first, not rates. Recount prompts with the Haiku 5.5 tokenizer, because the roughly 30 percent increase can push prompts over the 100,000-token tier, where rates rise fivefold. Next, check output tokens: a worker without a max_tokens cap produces long answers, and output costs five times input at the low tier. Finally, check retries: an unbounded retry loop can cost more than the frontier model on the first try.

The subagent does work outside its job

A subagent that edits files or runs unasked commands has too many tools, too vague a description, or both. Shorten the tools list, rewrite the description as a one-job statement with an explicit exclusion (“not for code changes”), and verify which agent files are actually loaded, because a stale file with broad permissions overrides a careful new one.

Quality drops on multi-step tasks

Haiku 5.5 is a worker model, and multi-step tasks are planner work. If one worker call must plan, execute, and verify, split it: one planning call, one worker call per step, and one review call. If the task still fails, that subtask type belongs on Sonnet 5.5, and using the escalation rule is a success of the design.

n8n worker calls grow more expensive over time

In n8n, cost growth usually comes from conversation memory or tool descriptions accumulating across turns. Cap the memory window, keep the tool set minimal, and split long workflows so each invocation starts from a fresh, short prompt. A steady upward slope in logged input tokens means context is accumulating somewhere.

FAQ

Is Claude Haiku 5.5 good enough to be the main model in an AI agent?

For narrow, well-scoped worker tasks, yes. For open-ended planning, research, or multi-file refactoring, keep Sonnet 5.5 or Opus 5.5 in charge and let Haiku 5.5 handle the bounded subtasks. That split is where the cost saving comes from without giving up final quality.

What does Claude Haiku 5.5 cost per agent call?

For prompts up to 100,000 tokens, Anthropic lists $0.10 per million input tokens and $0.50 per million output tokens. A worker call with 8,000 input tokens and 1,500 output tokens costs about $0.0016 at those rates. Above 100,000 tokens the rates rise fivefold, so keep worker prompts short.

How do I use Haiku 5.5 as a Claude Code subagent?

Create an agent file under .claude/agents/ with the model set to claude-haiku-5-5, a one-job description, a short allowed-tools list, and a strict output format. Claude Code then delegates matching subtasks to it while the main agent keeps planning and review.

Can I use Haiku 5.5 inside an n8n AI Agent?

Yes. In the n8n AI Agent node, attach an Anthropic Chat Model node, select claude-haiku-5-5, and keep the agent prompt narrow: one tool set, one deliverable, and an explicit stop condition. Route planning or final review to a larger model when the task needs it.

What breaks when an agent built for Haiku 4.5 moves to Haiku 5.5?

API parameters break, not prompt wording. Temperature, top_p, top_k, manual thinking budgets, and assistant prefills are rejected on Haiku 5.5. Use adaptive thinking with the effort setting instead, and recount tokens, because the new tokenizer counts roughly 30 percent more tokens for the same text.

When should I not use Haiku 5.5 in an agent?

Skip it for tasks with vague success criteria, long reasoning chains, or large repository context that pushes prompts past 100,000 tokens. Those cases lose the price advantage and need the stronger reasoning of Sonnet 5.5 or Opus 5.5.

Conclusion

Haiku 5.5 does not make your agent smarter. It makes the repetitive parts cheaper and faster, provided you route honestly: narrow subtasks to Haiku 5.5, planning and review to a larger model, and every subtask type through a week of logged evidence. Start with one worker job you already run, price it, log it, and let the numbers decide how far the cheap layer extends.

Frequently asked questions