Most production LLM traffic is not hard. It is classification, extraction, short rewrites, and routing, the kind of work a small fast model does correctly and cheaply. Yet the common pattern is to wire every call to the biggest available model, because it "just works," and then wonder why the bill and the latency are both high. On Amazon Bedrock, Claude Haiku 4.5 and Claude Opus 4.5 are both available, and the engineering win is not picking one, it is routing by task class so the cheap model handles the majority and the expensive one is an escalation path, not a default.

The reframing: model choice is a per-task decision, not a project-wide one. Sizing every request to your hardest request is the same mistake as running every workload on your biggest instance type. Right-sizing means matching the model to the difficulty of the specific call, and for a large share of calls the right size is small.

Why the big model is the wrong default

Defaulting to the frontier model feels safe and is expensive in two dimensions. Opus-class models cost several times more per token than Haiku-class ones, so a workload that is 90 percent mechanical is paying frontier prices for work a small model does perfectly. They are also slower, because more capable models generally take longer to respond, so you inflate latency on exactly the high-volume, simple calls where users notice speed most.

The hidden cost is that a big model on a simple task rarely produces a better result. Extracting a date from an email or classifying a ticket into one of six buckets does not improve when you throw more capability at it. You pay more and wait longer for an answer that a smaller model would have gotten right.

Route by task class

The design that works is to classify the request by difficulty and send it to the model that fits. Not per user, not per feature, per task class:

  • Mechanical work goes to Haiku. Classification, extraction, format conversion, short summaries, tool-argument construction, and routing decisions. High volume, low ambiguity, and a small model is both cheaper and faster with no quality loss.
  • Judgment work goes to Opus. Multi-step reasoning, ambiguous instructions, long-context synthesis, and anything where a wrong answer is expensive. Lower volume, and worth the premium because the capability actually changes the outcome.
  • The router itself is cheap. A heuristic on input length and task type, or a single small-model call, decides the class. The routing cost is a rounding error against what you save by not defaulting everything to the top.

Big model as the escalation path

The most reliable pattern is to make the frontier model an escalation, not a front door. Try the small model first. If it succeeds, and for the mechanical majority it will, you are done at a fraction of the cost and latency. If it fails a check, low confidence, a schema-invalid output, an explicit "I am not sure", escalate that single request to the larger model.

result = invoke(HAIKU, task)
if not passes_check(result):
    result = invoke(OPUS, task)   # escalate only the hard cases
return result

This inverts the economics. Instead of paying Opus prices on every request to cover the rare hard one, you pay Haiku prices on the common case and only reach for Opus when the cheap attempt visibly fell short. The trade is one extra call on the minority of requests that need it, against a large saving on the majority that do not.

Measure before you assume the split

The place teams go wrong is guessing the task mix instead of measuring it. Before routing, sample real traffic and label how much of it is genuinely mechanical versus genuinely hard. The number is almost always more mechanical than the team expects, which is exactly why defaulting to the big model wastes so much. It also tells you where to set the escalation trigger: if the small model handles 92 percent of traffic cleanly, your escalation rate should be near 8 percent, and a much higher rate means your check is too strict or your routing is miscalibrated.

The takeaway

Both Haiku and Opus have been on Bedrock for months, and the point is not to choose between them, it is to use each where it fits. Route by task class: send the mechanical majority to the small fast model and reserve the frontier model for the judgment-heavy minority, ideally as an escalation path triggered by a failed check rather than a default. Measure your actual task mix before you tune the split. Model right-sizing is the same discipline as instance right-sizing, and the fastest, cheapest system is the one that stops paying frontier prices for work a small model does correctly.

Read this next

For the platform side of routing and capacity across models, the cloud field notes live at ercan.cloud, and the hub is at ercanermis.com.