Claude Haiku on Amazon Bedrock — the fast, cheap-at-scale tier.

IWhat Claude Haiku is — and where it sits in the family

Claude Haiku is the fast, low-cost tier of Anthropic's Claude family on Amazon Bedrock. It is the smallest of the three Claude tiers, tuned so that the trade-off it makes — slightly less raw intelligence than its larger siblings in exchange for much lower cost and much lower latency — is the right trade for a very large share of real production traffic.

The Claude lineup on Bedrock is a ladder of three deliberate trade-offs. Opus is the most capable tier, built for the hardest reasoning and complex agentic work where quality dominates and cost is secondary. Sonnet is the balanced workhorse — strong reasoning at a fraction of Opus cost and latency, the sensible default for most real work. Haiku is the fast tier at the bottom of the ladder: the cheapest to run, the quickest to respond, and the one you reach for when a task is high-volume, latency-sensitive, or simple enough that Haiku-grade quality clears the bar. This page is about that bottom rung specifically — the others have their own pages (see the claude-sonnet-on-amazon-bedrock sibling and the flagship claude-on-amazon-bedrock).

The key mental model is that Haiku is not "the weak Claude" — it is the efficient Claude. For a great many tasks the extra intelligence of Sonnet or Opus is simply wasted: classifying a support ticket into one of eight categories, deciding which downstream model should handle a request, pulling three fields out of a form, answering a simple FAQ. On those jobs Haiku produces effectively the same answer as a frontier tier for a fraction of the price and latency — paying for Opus there is like chartering a freight jet to deliver a letter.

Because Haiku is served through the same Amazon Bedrock API as every other model, it inherits Bedrock's whole envelope without extra work: IAM auth, VPC/PrivateLink, KMS, CloudTrail, consolidated billing on your AWS invoice, region-level data residency, and — the part that matters most to a funded startup — AWS-credit eligibility. You build once against Bedrock and choose Haiku per request by setting a model ID.

One caveat, meant throughout: exact Claude version names, model IDs, regional availability, context-window sizes, and per-token prices all change as Anthropic ships new Haiku generations and AWS updates Bedrock. Everything here is representative as of 2026 to convey the tier's structure and relative economics — confirm the current Haiku model ID in the Bedrock model catalog and current rates on the AWS Bedrock pricing page before you build or budget.

IIThe Haiku model ID and enabling access

Before you can call Haiku you have to enable model access in your account — a one-time, no-cost step — and pass the correct model ID on each request. Both are quick, but getting the ID right (rather than guessing it) is what stops a deploy from failing.

Enabling access. In the Bedrock console, open Model access, find the Claude Haiku model you want, and request access. For Haiku this is typically granted effectively immediately. There is no charge for enabling access — you pay only when you actually invoke the model. Access is granted per-account and per-region, so enable Haiku in every region you intend to call from. If you want Bedrock to spread Haiku traffic across regions for better availability and throughput under load — which high-volume Haiku workloads often want — use a cross-region inference profile (see the amazon-bedrock-cross-region-inference sibling).

The model ID. Every model on Bedrock is invoked by a model ID: a string identifying the provider, model, and version, with Claude IDs namespaced under Anthropic (of the shape anthropic.claude-…haiku… with a version suffix). You pass this ID to the API to select Haiku specifically. Because the family shares one API, moving a request from Haiku up to Sonnet or Opus — or the reverse, demoting a request to Haiku to save money — is just a change of the model-ID string. Since IDs advance with each Haiku generation, do not hard-code a guessed value: read the current ID from the Bedrock model catalog in the console, or list it via the API/CLI, and treat it as configuration rather than a literal in your code.

Permissions. The IAM principal needs permission for the relevant Bedrock invoke actions on the Haiku model (and, if you use a cross-region inference profile, permission on the profile) — a least-privilege policy scoped to the specific Haiku model ARNs is the recommended posture. Once access and IAM are in place, calling Haiku is identical to calling any Bedrock chat model through the Converse API; you change only the model ID. The flagship claude-on-amazon-bedrock page shows a minimal Converse snippet that applies unchanged to Haiku.

• Open the Bedrock console → Model access → request access to Claude Haiku (free; usually instant).
• Enable Haiku in each region you will call from; for high-volume traffic consider a cross-region inference profile.
• Read the current Haiku model ID from the model catalog or via the API — never hard-code a guessed version string.
• Attach an IAM policy granting the Bedrock invoke actions on the specific Haiku model ARNs (least privilege).
• Call it via the Converse API exactly as you would any model — Haiku is just a different modelId. You are billed only on invocation.

IIIHaiku pricing — the lowest in the Claude family

The whole argument for Haiku is economic, so the pricing is the heart of this page. Haiku is billed per token like every Bedrock model — a rate per 1,000 input tokens and a higher rate per 1,000 output tokens — but its rates are the lowest of any Claude tier by a wide margin. The gap between Haiku and the larger tiers is what makes model choice the single biggest cost lever on Bedrock.

The table below gives representative 2026 on-demand rates for Haiku set against Sonnet and Opus-class, shown per 1,000 and per 1,000,000 tokens (the per-million column is the per-1K figure × 1,000; providers increasingly quote per-million). Read it to anchor the relative economics — Haiku versus the tiers you might otherwise default to — not as an audited price sheet. The headline is the spread: Haiku input runs on the order of a quarter of a dollar per million tokens while Opus-class input runs in the tens of dollars, roughly a 60× difference for the same unit of input. Two further levers, covered in section VII and not shown here, push Haiku lower still: prompt caching (stop re-paying input price for a repeated prefix) and Batch (roughly half price for non-interactive async work).

What that spread means in practice: a workload that costs real money on Opus can cost almost nothing on Haiku. If you run one million short classification requests a month, the difference between doing them on Haiku and doing them on a frontier tier is the difference between a rounding error and a line item your finance team asks about. This is why high-volume systems are built Haiku-first and only escalate the requests that truly need more.

IVWhen Haiku is the right call

Haiku earns its place on tasks where the work is high-volume, latency-sensitive, or simple enough that its quality clears the bar — which, in most production systems, is a surprisingly large fraction of total traffic. These are the workloads to put on Haiku by default.

The pattern across all of these is the same: the task is well-defined and repetitive, the volume is high, the per-request value is low, and a fast, good-enough answer beats a slow, perfect one. Those are exactly the conditions under which Haiku's cost and latency advantages compound.

• High-volume classification and labelling: Routing tickets into categories, tagging content, sentiment and intent detection, moderation triage, spam and quality scoring, deduplication checks. These run constantly at scale and rarely need frontier reasoning — Haiku does them fast and for cents, often via Batch for the non-interactive volume.
• Routing and triage (the tier-1 of a model router): The single highest-leverage Haiku job: a cheap first pass that reads each request, handles the easy majority itself, and decides which harder requests to escalate to Sonnet or Opus. Because Haiku is so cheap and so fast, the cost of running it on every request is trivial relative to what the escalation logic saves.
• Simple chat and FAQ-style assistants: Customer-facing chat that mostly answers common, bounded questions — order status, policy lookups, how-to responses, first-line support — feels noticeably snappier on Haiku, and the lower latency improves the conversational experience directly. Hand off only the genuinely hard or high-stakes turns to a larger tier.
• Data extraction and transformation: Pulling structured fields out of unstructured text (forms, emails, invoices, resumes), normalizing messy inputs, reformatting and light summarization at volume. Well-specified extraction is squarely in Haiku's wheelhouse and a natural fit for Batch jobs over large backlogs.
• Sub-agents and inner-loop steps in agentic systems: In a multi-step agent, many internal steps are mechanical — deciding the next tool, parsing a tool result, checking a condition, drafting an intermediate note. Running those sub-agent steps on Haiku keeps an agent fast and cheap, reserving the expensive tier for the steps that actually require deep reasoning.
• Anything you run thousands or millions of times: The general rule: the higher the request count, the stronger the case for Haiku. At low volume the price gap is immaterial and you might as well use Sonnet; at high volume the gap dominates your bill, and Haiku (plus caching and Batch) is what keeps the workload economical.

VWhen you should pay up for Sonnet or Opus instead

A neutral reference has to say where Haiku is the wrong choice. The efficient tier is not the universal tier: on genuinely hard work, reaching for Haiku to save money is a false economy that costs you in errors, retries, and rework. Here is where to escalate.

The deciding question is never "what is cheapest?" in isolation — it is "what is the cheapest tier that clears the quality bar for this task?" For the jobs in section IV that tier is Haiku. For the jobs below it is not, and forcing Haiku onto them is the most common way teams get a bad first impression of small models. Escalate when:

• Hard multi-step reasoning: Problems that require chaining several non-obvious inferences, careful math, or holding many constraints at once are where larger tiers separate from Haiku. If a wrong intermediate step quietly corrupts the final answer, pay for Sonnet — or Opus for the hardest cases — rather than debugging silent errors at scale.
• Complex coding, refactoring, and analysis: Non-trivial code generation, multi-file refactors, debugging subtle logic, and research-style synthesis benefit materially from the stronger reasoning of Sonnet and Opus. Haiku can handle simple snippets and boilerplate, but reach for a larger tier when correctness and depth matter.
• High-stakes or low-tolerance outputs: When a single wrong answer is expensive — legal, financial, medical-adjacent, or anything customer-trust-critical — the marginal cost of a stronger model is cheap insurance against the cost of being wrong. Reserve Haiku for the bounded, low-risk portion of such systems.
• Nuanced long-form generation and judgment: Tasks that hinge on subtle tone, careful instruction-following across a long brief, or fine judgment between close options tend to reward Sonnet's extra capability. Haiku is excellent at short, well-specified generation; it is not the tier for your most nuanced writing or evaluation.
• The hardest agentic steps: Within an agent, run the mechanical inner-loop steps on Haiku (section IV) but escalate the genuinely hard decisions — the plan, the ambiguous judgment call, the step where an error compounds — to Sonnet or Opus. The right agent mixes tiers rather than committing to one.

VILatency — why Haiku feels near-instant

Cost is half of Haiku's appeal; latency is the other half. Being the smallest Claude, Haiku is also the fastest — it starts responding sooner and finishes sooner than Sonnet or Opus on the same prompt. For interactive and high-throughput workloads, that speed is a feature in its own right.

Two things drive perceived speed: time-to-first-token (how quickly the model starts replying) and tokens-per-second (how fast it streams once started). Haiku leads the family on both, which is why a Haiku-backed chat assistant feels snappy and responsive where a frontier-tier one can feel deliberate. For user-facing chat, that responsiveness often matters more to the experience than a marginal quality difference the user never notices.

Latency also compounds in agentic and pipeline systems. An agent that takes ten internal steps pays the latency of each step in series; running those steps on Haiku rather than a slower tier can be the difference between an agent that responds in a couple of seconds and one that visibly stalls. The same logic applies to any multi-stage pipeline — the faster the per-stage model, the lower the end-to-end latency. Pairing Haiku's speed with streaming (the converse_stream variant) makes interactive responses feel immediate because output appears token-by-token as it is generated.

For non-interactive bulk work, latency per request matters less — there Batch is the right tool, trading immediacy for roughly half the price (section VII). The clean split is: use Haiku's low latency where a human or another service is waiting; use Batch where nothing is waiting and throughput-per-dollar is all that counts.

VIIMaking Haiku cheaper still — prompt caching and Batch

Haiku is already the cheapest Claude, but two Bedrock levers stack on top of its low rate and routinely cut the effective cost of a high-volume Haiku workload by a large fraction again. Both apply to Haiku exactly as they do to the larger tiers.

VIIIHow to fund Haiku usage, and who files it

Everything above prices Haiku as if you pay AWS directly. Two kinds of AWS money can pay that bill instead, and different people file them.

AWS Activate credits. Haiku on Bedrock is AWS spend, so Activate credits can pay for it. AWS made them redeemable for third-party models on Bedrock, Anthropic’s included, in April 2024 (AWS announcement). They do not apply to the direct Anthropic API. You apply for Activate credits yourself. Activate Founders is $1,000 to start, up to $5,000, with no investor needed. Activate Portfolio is up to $200,000, using the Org ID from your VC, accelerator or angel group if it is an AWS Activate Provider. A consulting partner cannot file Activate for you.

Partner-filed funding. Your matched AWS partner can file POC (proof of concept) funding to test the workload, or incremental workload (IW) funding if you already run on AWS and this is new work. For startups that is $50K to $150K. Depends on the workload; AWS approves. A partner can also build the workload with you: the high-volume classifier, the tiered router with Haiku as tier one, the Batch pipeline and prompt caching.

Startups pay CloudRoute nothing. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding. For the details, see how POC funding works.