Claude Opus vs Haiku in Production: How Wrong Model Selection Costs Companies $10K+ Per Month

Claude Opus costs $15 per million input tokens. Claude Haiku costs $0.25. That's a 60x price difference. For tasks like data extraction, text classification, and document parsing, Haiku produces results that are functionally identical to Opus — at a fraction of the cost.

If your production AI system uses Opus for every API call, your development team didn't make an engineering decision about model selection. They skipped it entirely. And that skip is costing you $5,000–$15,000 per month more than it should.

Why do development teams default to Opus for everything?

Because it's the fastest way to ship a working system. Opus handles every task well — extraction, classification, summarisation, reasoning, generation. A developer building against the Anthropic API can wire every endpoint to Opus, write generic prompts, and have a functioning system in days. No need to evaluate which model handles which task. No need to build routing logic. No need to test quality thresholds across tiers.

The system works. The demo looks great. The client signs off. Then production volume arrives and the API bill becomes a budget line nobody planned for.

This isn't laziness. It's a structural problem with how AI development gets outsourced. The vendor is paid to deliver a working product, not to optimise its operating cost. Cost engineering happens at the architecture level — before any code is written — and most outsourced teams skip that phase because the client didn't ask for it and the scope didn't include it.

Which production tasks actually need Opus?

Very few. Here's how different task types map to Claude's model tiers based on what we've seen in production systems:

Haiku ($0.25/million input tokens) handles: structured data extraction from documents, text classification and tagging, entity recognition, simple summarisation, format conversion (JSON, CSV, XML transforms), input validation and filtering, and routing decisions within agent workflows.

Sonnet ($3/million input tokens) handles: nuanced summarisation that requires tone control, content generation with brand voice requirements, multi-step data analysis with intermediate reasoning, complex document comparison, and quality assurance checks on other model outputs.

Opus ($15/million input tokens) handles: complex multi-step reasoning across large contexts, tasks requiring deep domain understanding with ambiguous inputs, code generation involving architectural decisions, and edge cases where cheaper models demonstrably fail.

In most production AI systems we've audited, 70–85% of API calls are tasks that Haiku handles as well as Opus. Another 10–20% can run on Sonnet. The tasks that genuinely require Opus — if any exist in the workflow at all — are typically under 5% of total call volume.

What does the cost math look like for a real system?

Consider a production system processing 20,000 API calls per day with an average of 1,500 tokens per call (combined input and output).

All-Opus: 20,000 × 1,500 tokens × $15/M = $450/day = $13,500/month.

Routed architecture (75% Haiku, 20% Sonnet, 5% Opus): Haiku: 15,000 × 1,500 × $0.25/M = $5.63/day. Sonnet: 4,000 × 1,500 × $3/M = $18/day. Opus: 1,000 × 1,500 × $15/M = $22.50/day. Total: $46.13/day = $1,384/month.

$13,500/month versus $1,384/month. Same system. Same outputs. Same user experience. The only difference is which model handles which task.

Why can't you just swap the model parameter and call it done?

Because most systems aren't built to make that swap possible.

A system built by a generalist vendor typically has a monolithic prompt — one API call that performs multiple tasks in a single pass. "Here's a job description. Extract all fields, classify the industry, normalise the title, and write a summary." That's four tasks in one prompt. You can't route them to different models because they aren't separated.

Switching that monolithic call from Opus to Haiku doesn't work — the summary quality drops because Haiku handles the extraction fine but the generation less well. So the team switches back to Opus and concludes "we need the expensive model." They don't. They need the expensive model for one task and the cheap model for three others. But the architecture doesn't allow that distinction.

The fix requires decomposing the monolithic prompt into separate task-specific calls, each with its own prompt engineered for the target model's capabilities. That's not a configuration change. That's re-architecting the AI layer of the system.

What does the re-architecture process look like?

When we re-architect a production AI system for cost efficiency, the process follows a specific sequence:

First, we map every distinct task the system performs. Not what the documentation says it does — what it actually does. A single API call often performs multiple implicit tasks that nobody separated during development.

Second, we evaluate each task against model tiers. We run the same inputs through Haiku, Sonnet, and Opus and measure output quality against the business's actual accuracy requirements — not theoretical benchmarks but "is this good enough for what the system needs to do."

Third, we rebuild the AI layer with task-specific agents, each wired to the appropriate model tier with prompts engineered for that model's strengths. The routing layer handles model selection. The orchestrator handles task sequencing.

Fourth, we instrument cost and quality monitoring per task. This isn't optional — it's how you catch quality degradation before users notice it, and how you identify further cost optimisation opportunities as model capabilities change.

The user-facing product doesn't change. The same inputs go in, the same outputs come out. What changes is the internal architecture — and the monthly bill.

How do you know if your system has this problem?

Three signals:

Your API bill scales linearly with volume. Doubling your input volume doubles your cost. In a properly architected system, costs grow sub-linearly because caching catches repeated inputs and cheaper models handle the bulk of calls.

You use one model for everything. Check your API dashboard. If 100% of calls go to the same model — regardless of what those calls do — no routing decision was made.

Your vendor suggests "prompt optimisation" as the cost fix. Shortening prompts saves tokens but doesn't address the fundamental problem. If 80% of your calls use a model that's 60x more expensive than necessary, saving 20% on prompt length still leaves you massively overspending.

If any of these apply, the problem isn't your AI provider's pricing. It's how the system was built. And the team that built it probably isn't equipped to fix it, because fixing it requires a fundamentally different approach to AI system design — one that starts with cost modelling and task decomposition, not with API integration.