Claude Haiku
ModelsDefinition
The fastest and most cost-effective Claude model tier, optimized for high-throughput, low-latency tasks like classification, extraction, and simple Q&A. Carries a 200K-token context limit (vs 1M on Sonnet/Opus) and is the recommended first-pass router in tiered pipeline architectures.
Example Usage
Deploy Haiku as a forced-tool-call classifier that assigns each incoming request a complexity tier before dispatching to Sonnet or Opus — keeping P99 latency low and cost-per-request minimal.
Why It Matters for the CCA-F Exam
Haiku appears in CCA-F questions about cost optimization, model routing, and high-throughput pipeline design. Expect questions asking which tier to use as a classifier or pre-screener, which models support both temperature and top_p, and scenarios that test whether you know Haiku's context-window limit (200K — smaller than Opus and Sonnet's 1M).
In Depth
Haiku's Role: Speed and Economy at Scale
claude-haiku-4-5 is the fastest and most cost-effective model in the current Claude lineup. Its 200K-token context window — significantly smaller than the 1M-token windows on Sonnet and Opus — is the single most important constraint to know for the exam. The 64K output ceiling matches Sonnet. Speed and cost are Haiku's primary strengths; reasoning depth is not.
The architectural insight behind Haiku is that most tokens in a high-volume system don't need Opus-level reasoning — they need fast, reliable, cheap responses. Routing those calls to Haiku rather than Claude Sonnet or Claude Opus significantly reduces both cost and P99 latency for the pipeline as a whole.
Haiku as a Classifier-First Router
One of Haiku's most important production roles is as a complexity classifier — a first pass that decides which tier should handle each request:
- Every incoming task hits Haiku first with
tool_choice: {type: "tool", name: "classify"}to force a machine-readable JSON output rather than free-form prose. - Haiku returns a structured complexity verdict (e.g.,
{"tier": "haiku" | "sonnet" | "opus"}). - The orchestrator routes to the appropriate model.
This pattern is covered in Task Decomposition & Routing Strategies and is a core CCA-F exam scenario in the model routing domain.
The 200K Context Limit in Practice
Haiku's 200K context is a hard architectural constraint that distinguishes it from the rest of the tier lineup. It matters when:
- Inputs include very long documents — inputs exceeding 200K tokens cannot be processed in a single Haiku call and must be chunked, summarized, or routed directly to Sonnet/Opus.
- A routing pipeline passes full conversation history — at high turn counts, truncation or summarization is needed before routing to Haiku to avoid context overflow.
Always verify that task inputs fit within 200K before defaulting to Haiku as the cheap option in a pipeline.
Sampling Parameter Support — What Haiku Retained
Unlike Opus 4.7+ and Fable 5, Haiku 4.5 still supports both temperature and top_p. This is a subtle but exam-tested point: a question may describe a system that sets sampling parameters and ask which Claude models it is compatible with. Haiku 4.5 is compatible; Opus 4.7+ is not (HTTP 400). On Sonnet 4.6, at most one of the two may be set at a time. In practice, even where supported, best practice is to steer behavior through prompting and structured outputs rather than relying on sampling parameters as a primary lever.
For the full cross-tier comparison table (context windows, output limits, cost, latency, and sampling support), see Claude Opus — Full Tier Comparison.
How It Compares
| Feature | Claude Haiku 4.5 | Claude Sonnet 4.6 |
|---|---|---|
| Context window | 200K tokens | 1M tokens |
| Max output tokens | 64K | 64K |
| Sampling params | Both temp & top_p supported | At most one |
| Cost | Lowest | Mid |
| Best for | Classification, triage, routing | Production default, generation |
*For the complete three-tier comparison including Claude Opus, see Claude Opus — Full Tier Comparison.*
Example
Haiku as a forced-tool-call classifier that routes each request to the appropriate tier. tool_choice type:"tool" guarantees a machine-readable JSON output rather than prose.
import anthropic
client = anthropic.Anthropic()
CLASSIFY_TOOL = {
"name": "classify",
"description": "Classify the complexity of a user request.",
"input_schema": {
"type": "object",
"properties": {
"tier": {
"type": "string",
"enum": ["haiku", "sonnet", "opus"],
"description": "Which model tier should handle this request?"
},
"reason": {"type": "string"}
},
"required": ["tier", "reason"]
}
}
TIER_MODELS = {
"haiku": "claude-haiku-4-5",
"sonnet": "claude-sonnet-4-6",
"opus": "claude-opus-4-8",
}
def route_request(user_message: str) -> str:
# Step 1: cheap classification pass
classify_resp = client.messages.create(
model="claude-haiku-4-5",
max_tokens=256,
tools=[CLASSIFY_TOOL],
tool_choice={"type": "tool", "name": "classify"},
messages=[{"role": "user", "content": user_message}]
)
# Parse the forced tool call result
tool_block = next(b for b in classify_resp.content if b.type == "tool_use")
tier = tool_block.input["tier"]
model_id = TIER_MODELS[tier]
# Step 2: dispatch to the right model
final_resp = client.messages.create(
model=model_id,
max_tokens=4096,
messages=[{"role": "user", "content": user_message}]
)
return final_resp.content[0].text
if __name__ == "__main__":
reply = route_request("Summarize this sentence in one word: The cat sat on the mat.")
print(reply)Frequently Asked Questions
What is the context window limit for Claude Haiku and why does it matter?
Claude Haiku 4.5 has a 200K-token context window — significantly smaller than Sonnet and Opus's 1M-token windows. This means very long documents or large conversation histories may not fit in a single Haiku call. Always verify input size before routing to Haiku in a cost-optimization pipeline.
Can I use temperature or top_p with Claude Haiku 4.5?
Yes. Unlike Opus 4.7+ and Fable 5 (where temperature and top_p return HTTP 400), Haiku 4.5 still supports both sampling parameters. However, best practice on current Claude models is to steer behavior through prompting and structured outputs rather than relying on sampling parameters.
Is Haiku accurate enough to use as a routing classifier?
Yes, for binary or categorical classification tasks Haiku is reliable enough for routing decisions. Using `tool_choice: {type: "tool", name: "..."}` to force a structured JSON output (rather than free text) further improves reliability. The classifier's job is to distinguish broad complexity categories — a task that fits naturally within Haiku's capability ceiling.