Skip to content

Cost-Effective AI: How to Pick Claude Opus vs Sonnet vs Haiku for Each Workload

Opus for the hard stuff. Sonnet for daily work. Haiku for high-volume cheap work. Mixing them right cuts costs by 70%.

John Cravey with AIFounder4 min readUpdated Jul 6, 2026

Anthropic ships three Claude models: Opus (the most capable), Sonnet (the daily-driver), Haiku (the fast, cheap one). They’re ~5-15x apart in cost per token. Most teams pick one and use it for everything. That’s the wrong move — different workloads have different quality bars, and over-spending on Opus for jobs Haiku could handle eats your AI budget without producing better output. Here’s the per-workload framework.

Free estimate · 2 minutes

Slow pages lose rankings and leads. Price the fix.

Build the estimate to see what a fast rebuild would look like for your site and what we would ship in the first thirty days.

Current pricing (May 2026)

  • Claude Opus 4.7: $15 / $75 per million tokens (input / output).
  • Claude Sonnet 4.6: $3 / $15 per million tokens.
  • Claude Haiku 4.5: $0.80 / $4 per million tokens.

Opus is ~5x Sonnet and ~19x Haiku on input cost; ~5x Sonnet and ~19x Haiku on output cost. The cost gap is real and matters at scale.

What each model is good at

Opus 4.7: complex reasoning, multi-step problem solving, code generation in unfamiliar codebases, dense analytical work, anything where the answer needs to be exactly right. Sonnet 4.6: most daily work — drafting, summarization, structured extraction, code edits in familiar codebases, customer-facing chat that needs polish. Haiku 4.5: high-volume bulk work — classification, simple transformations, fast Q&A from a small context, lead scoring, embedding-decisioning.

The FH workload-to-model mapping

  • Blog post drafts (long-form, voice-sensitive): Opus.
  • Location/service page drafts (templated bulk): Sonnet with prompt caching.
  • Image alt-text generation: Haiku.
  • Lead scoring: Haiku.
  • Customer chat (RAG-backed Q&A): Sonnet.
  • Code review of complex changes: Opus.
  • Boilerplate code generation: Sonnet.
  • PR-summary generation: Haiku.
  • Image curation rubric scoring: Sonnet (with vision).
  • Bulk classification (e.g. ‘is this email spam?’): Haiku.

The decision framework

  1. Is the output going to a customer or end-user (vs. internal)? If yes, never below Sonnet.
  2. Does the task require multi-step reasoning across multiple inputs? If yes, Opus.
  3. Is the task volume high (1000+/day) and the output simple? Haiku.
  4. Is the task voice-sensitive (FH brand voice, customer support tone)? Sonnet or Opus, depending on stakes.
  5. Default for everything else: Sonnet.

The cost trap: defaulting to Opus

Most new Claude users default to Opus because ‘the best model.’ That’s 5x the cost for many tasks Sonnet handles equally well. Run a small evaluation: take 20 representative tasks, run them through both Opus and Sonnet, blind-score the outputs. For most tasks Sonnet wins or ties; you save 5x. For the tasks Opus genuinely wins, you keep Opus on them and save on the rest.

Mixing models in a single workflow

Common pattern: Haiku triages the request, Opus answers if Haiku flags it as complex. We use this in customer support chat: Haiku reads the user’s message and either answers from a small FAQ set (cheap, fast) or escalates to a Sonnet/Opus-backed agent (more capable, slower).

async function triage(userMessage: string): Promise<"simple" | "complex"> {
  const res = await claude.messages.create({
    model: "claude-haiku-4-5-20251001",
    max_tokens: 20,
    system: "Classify the user message as 'simple' (one-shot answer fits) or 'complex' (needs reasoning).",
    messages: [{ role: "user", content: userMessage }],
  });
  const text = res.content[0].type === "text" ? res.content[0].text : "";
  return text.toLowerCase().includes("complex") ? "complex" : "simple";
}

async function answer(userMessage: string) {
  const level = await triage(userMessage);
  const model = level === "complex" ? "claude-opus-4-7" : "claude-sonnet-4-6";
  return await claude.messages.create({ model, max_tokens: 1024, messages: [{ role: "user", content: userMessage }] });
}

When Haiku is actually too small

  • Tasks needing context beyond ~30k tokens. Haiku’s effective context window is smaller in practice.
  • Tasks requiring nuanced understanding of brand voice. Haiku tends generic.
  • Tasks with tool use that requires careful reasoning about when to call which tool.
  • Anything customer-facing where a slightly-off response damages trust.

When Opus is overkill

  • Anything classification-flavored (yes/no, category-A/B/C).
  • Anything where the input is structured and the output is short.
  • Anything that runs 100+ times per day per user.

Batch API for non-realtime workloads

Anthropic’s Batch API processes requests asynchronously at 50% the per-token cost of the regular API. Use it for: nightly content generation, periodic re-indexing, weekly digest emails, anything that doesn’t need a real-time response. Halving costs on batch workloads compounds quickly.

Measuring the savings

Track per-workload cost in your observability. Tag every Claude call with `workload_id`. Roll up monthly: Opus calls × Opus rate, Sonnet × Sonnet rate, Haiku × Haiku rate. Compare to ‘what if we used Opus for everything’ — that’s your savings number. We track this at FH and report it monthly.

How this lands across FH client work

Every FH AI workflow has an explicit model choice documented. Lead scoring: Haiku. Customer chat: Sonnet (sometimes upgrading to Opus mid-conversation). Image curation: Sonnet (vision). Blog drafts: Opus with prompt caching. Total monthly AI spend across the FH client book sits well under $500 despite running tens of thousands of inference calls. If your AI bill feels too high and you’re running everything on Opus, book a consultation — the model-routing setup is a one-week engagement with immediate compounding savings.

Answers

Frequently asked questions

How should I choose between model tiers?

By the difficulty of the task rather than its importance. Hard reasoning, long-horizon work, and anything where a subtle error is expensive justify the top tier. Routine generation and transformation sit in the middle. High-volume mechanical classification belongs at the bottom, and that is where most volume actually is.

What is the most expensive habit?

Defaulting to the largest model for everything. It is the path of least resistance and it multiplies the bill on workloads where a smaller model produces identical output. The saving from routing correctly is usually larger than any prompt optimization.

Can models be mixed inside one workflow?

Yes, and that is usually the right design: a cheap model for extraction and filtering, a capable one for the step that needs judgment, and a cheap one again for formatting. Each step gets what it needs and the expensive model runs on the smallest possible slice.

When is the smallest model too small?

When the task needs multi-step reasoning, careful instruction-following across a long prompt, or judgment about ambiguous input. The tell is inconsistency: right most of the time and confidently wrong in the same way on edge cases, which is expensive to catch downstream.

When is the largest model overkill?

For classification, extraction, formatting, and any task with one obviously correct output. If a competent junior could do it from written instructions without thinking hard, the top tier is being paid for reasoning the task does not require.

How much does routing well actually save?

Enough to change the economics of a pipeline rather than trim it, because the tiers differ by multiples rather than percentages. A workload split sensibly across tiers commonly costs a fraction of the same workload run entirely on the top tier.

What is the batch path for?

Anything not needed immediately: overnight generation, bulk classification, backfills. It trades latency for a materially lower rate, and most content and analysis work is not time-sensitive despite being written as if it were.

How do I measure whether the mix is right?

Track cost per useful output rather than cost per call, alongside a quality check on a sample from each tier. Cost per call rewards downgrading until quality collapses; cost per useful output catches the point where a cheaper model started producing work someone has to redo.

Should I downgrade a working pipeline to save money?

Only with the quality check in place first. Downgrade one step, sample the output against the previous tier, and keep the change if it holds. Downgrading several steps at once produces a cheaper pipeline whose quality nobody can attribute to a cause.

Does prompt length matter as much as model choice?

It matters, and it is usually the second lever rather than the first. Routing to the right tier is a multiple; trimming a prompt is a percentage. Do the routing first, then caching, then prompt size, in that order of return.

How often should the mapping be revisited?

Whenever a new model tier ships, because the capability of each tier moves and a task that needed the top tier last year often does not now. A workload-to-model mapping written once and never revisited is a standing overpayment.

What is the simplest starting rule?

Top tier for the hard reasoning step, mid tier for daily production work, cheapest tier for high-volume mechanical tasks. Start there, measure quality per step, and adjust. That rule alone captures most of the available saving without a routing framework.

Question we did not answer? Ask us directly and we will answer it here.

John Cravey, Founder
Written by
John Cravey
Founder

Founder of Frontend Horizon. Writes most of the long-form work on the FH blog.

Newer post
Schema Markup for SMB Sites: The Three Types That Actually Help
Older post
Cloudflare Email Routing Setup: Free Custom-Domain Email Forwarding
Keep reading

More from the blog

AI·4 min

Anthropic API Prompt Caching: The Pattern That Saves Thousands on Content Generation

Prompt caching cuts our content-gen costs by an order of magnitude. Here’s how and where it works.

SEO·5 min

SEO for AI: How to Rank When the Search Engine Is an Answer Engine

More of your buyers get their answer from an AI than from page one. The playbook for being that answer is concrete, and most of your competitors have not run it.

SEO·5 min

Google SEO: How Ranking Works From Crawl to AI Overviews

Rankings are not granted. They are computed, by systems with documented jobs. Understand the jobs and SEO stops feeling like weather.