Claude Haiku

Claude Haiku — Fast/Cheap Tier

Concept of the skill

What it is: claude-haiku is the routing decision for a model provider's fast, cheapest tier — the floor of the roster, used for work where throughput, latency, and cost dominate and deep reasoning is not the binding constraint.

Mental model: A model roster is a tiered ladder, and just below the bottom model rung sits "no model at all — a script." The fast tier is the rung you take when a task needs a little judgment (more than a regex) but not reasoning depth, and runs often or fast enough that a higher tier's cost and latency are wasteful.

Why it exists: The expensive failure mode is using a premium reasoning model for mechanical work — transcription, polling, slot-filling — where it adds cost and latency with zero quality gain. An explicit fast tier gives that work a correct home: cheaper and faster than the implementation lane, while still being a model when a deterministic script can't quite do the job.

What it is NOT: It is not the lane for multi-step synthesis, architecture, or hard debugging — those need a higher tier's reasoning and tunable depth. It is not a universal cost-cutter either: routing a task that needs reasoning to the fast tier to "save money" produces wrong answers, which is the most expensive outcome of all.

Adjacent concepts: the balanced implementation tier (the escalation target for ordinary multi-step work); the frontier reasoning tier (the escalation target for the hardest work); a deterministic script (the drop target below any model for fully repeatable work); cost-aware delegation (the policy that routes mechanical work down to here or to a script).

One-line analogy: The fast tier is the quick, low-cost assistant for high-volume routine paperwork — perfect for the form-filling that floods the inbox, the wrong choice for the case that needs an analyst's judgment.

Common misconception: That the cheapest model is the safe way to cut costs across the board. It is not — it is the right choice only for work that does not need reasoning depth or large context; pushing reasoning-heavy or large-context work down to it trades a small token saving for wrong answers and re-work.

Coverage

• What the fast tier is for: transcription, parsing, polling/status loops, format conversion, config updates, slot-filling, small-diff review, simple classification
• The two-sided boundary: escalate up to the balanced/frontier tier on reasoning-depth or context-size signals; drop below to a deterministic script on fully repeatable work
• The two distinct upward boundaries kept separate: the structural 200K-context ceiling vs the reasoning-difficulty limit (a task can exceed 200K while being mechanically trivial)
• Capability/limit facts that drive the decision: lowest per-token cost, 200K context window, the missing effort parameter, the separate rate-limit pool, often-lower load (overload fallback)
• The high-correctness-cost trap: small-looking tasks (security, money math) whose wrong-answer cost outweighs the token saving

Philosophy of the skill

The fast tier defends against the single most expensive routing failure: using a premium reasoning model for mechanical work that gains nothing from reasoning. But its mirror failure is just as costly — pushing reasoning-heavy or large-context work down to the cheapest model to "save money," which buys wrong answers and re-work at a fraction of a cent of apparent savings. The fast tier therefore lives between two hard edges. Below it sits "no model at all — a script," the correct home for fully deterministic work. Above it sit two separate escalation boundaries that must not be conflated: a structural 200K-context ceiling (a task can exceed it while being mechanically trivial, and that alone forces escalation) and a reasoning-depth limit (the fast tier has no effort knob, so anything needing tunable depth belongs higher). Cheapness is a property to exploit only inside those edges, never a reason to cross them.

When to reach for Haiku vs alternatives

Route a task to Haiku when throughput/latency/cost dominate and reasoning depth is not required:

• Transcription / parsing — turning a structured payload (webhook body, log line, raw record) into a target shape.
• Polling and status loops — repeated cheap checks where per-call cost matters because volume is high.
• Format conversion and config updates — mechanical reshaping with a clear target.
• Slot-filling — keyword/frontmatter additions, boilerplate generation, structured-output extraction against a fixed schema.
• Small-diff review and simple classification — bounded, low-stakes judgment over many items.

Escalate up to the balanced tier (claude-sonnet) when the task becomes genuine multi-step implementation; up to the frontier tier (claude-opus) when it needs the hardest reasoning. Drop below Haiku to a script when the task is fully deterministic and repeatable. The fast-tier test: does this need a little judgment but not reasoning depth, and does it run often or fast enough that a higher tier is wasteful? If a script can do it deterministically, use the script; if it needs reasoning depth or more than 200K of context, escalate.

Capabilities (current generation — verify live before quoting)

Concrete model IDs, exact prices, context, and the effort/rate-limit details change with each release. Read them live from the provider's models API / pricing docs (or the claude-api reference) before quoting. Current verified facts: references/model-facts.md.

Strengths and weaknesses

Strengths: lowest cost and latency of the three tiers; ideal for high-volume mechanical work, transcription, polling, format conversion, and slot-filling; often less loaded, making it a useful overload fallback.

Weaknesses: 200K context ceiling (a hard structural limit, not just a quality one); no effort knob, so reasoning depth cannot be tuned; under-performs on multi-step synthesis, architecture, and hard debugging; wrong choice for high-correctness-cost tasks (security, financial calculation) even when they look small.

Verification

Before concluding "route this to Haiku," confirm:

• The task needs a little judgment but NOT reasoning depth, and runs often/fast enough that the balanced tier's cost-latency is wasteful.
• The context fits within 200K tokens (if it exceeds 200K, escalate regardless of how mechanical the task is — this boundary is structural).
• The task does NOT carry a high correctness cost that a wrong answer would make expensive (security checks, money math route up even when they look small).
• A deterministic script can NOT do it identically (if it can, use the script — no model is needed).
• Any capability fact used (context ceiling, missing effort, rate-limit pool, pricing) was read live or from references/model-facts.md, not from memory.

Do NOT Use When

References

• references/model-facts.md — verified current-generation Haiku facts (ID, 200K context, pricing, missing effort knob, separate rate-limit pool) with sources
• claude-sonnet — the balanced implementation tier this skill escalates up to
• claude-opus — the frontier reasoning tier this skill escalates up to for the hardest work