Claude Opus Pricing: When Flagship Rates Pay Off

Claude Opus is the most capable — and most misused — model in coding: teams default everything to flagship judgment, then wonder why the invoice resembles a second payroll. Opus earns its premium on a narrow slice of tickets where mistakes cost hours, and wastes it everywhere else. This guide prices Opus honestly, defines the judgment-heavy work that deserves it, and builds escalation routing that reserves flagship firepower for flagship problems while everything else flows to cheaper tiers.

Opus pricing without illusions

Opus bills flagship rates on input, output and cache reads — each a multiple of Sonnet's, justified only where judgment earns the gap. Hard tickets also carry long-context profiles that multiply every rate further: architecture reviews spanning services, debugging with full histories attached. Estimates built from averages understate real Opus spend because Opus tickets are never average.

Price from representative hard tickets instead: take five recent judgment-heavy tickets, compute their fully-loaded cost, and project that unit economics across expected volume. Add supervision savings on the other side — prevented wrong-direction refactors, caught design flaws — because those offset tokens dramatically. Honest Opus math almost always concludes: narrow share, high value, strict gates.

• Flagship input, output and cache rates
• Long-context profiles of hard tickets
• Spiky usage that averages hide
• Estimate from hard tickets, not means

Tickets that deserve flagship rates

Reserve Opus for work where mistakes cost hours: system architecture with blast radius, subtle concurrency and distributed bugs, security-sensitive reviews, irreversible migrations. These tickets leverage judgment — the one input where Opus demonstrably exceeds cheaper tiers. Everything mechanical, routine or well-specified belongs below regardless of who requests otherwise.

The discipline is directional: tickets escalate upward to Opus on triggers, never default there by prestige or habit. Prestige routing — flagship for everything important-sounding — is the most expensive common misconfiguration in AI-assisted engineering. Gate with explicit triggers: known-hard categories plus stall signals from lower tiers. Every Opus ticket should be explainable in one sentence; unexplained ones get rerouted.

• Architecture with blast radius
• Subtle bugs and security reviews
• Irreversible decisions
• Everything else escalates upward, never defaults

Prove the premium per category

Trial Opus against Sonnet on identical hard tickets — the categories claimed to need flagship judgment. Score merged results per dollar with review time weighted heaviest: Opus wins where its judgment prevents expensive mistakes, Sonnet matches where the difficulty was overstated. Require two winning periods before granting any category permanent Opus status.

Quantify supervision savings explicitly: hours not spent redirecting, mistakes not made, reviews shortened. These dwarf token differences whenever Opus genuinely fits. Where trials show parity, downgrade permanently regardless of prestige — paying flagship rates for Sonnet-equivalent outcomes is status spending, not engineering. Let data assign every category without sentiment.

• Identical hard tickets, both tiers
• Review time as deciding metric
• Supervision savings quantified
• Data over prestige, always

Flagship as fallback, always ready

Keep Opus configured permanently even where trials favor cheaper tiers: escalation path, outage fallback, and judgment reserve for the tickets that truly need it. Flagship fallback costs nothing idle and rescues exactly the high-stakes situations where alternatives falter. Test the path routinely with trivial requests so readiness is real, not assumed.

Define rise triggers clearly: stall signals from lower tiers, category flags for known-hard work, human override for ambiguous cases. Document them where dispatchers find them. The fallback's value compounds during incidents — provider outages, quota crunches, deadline escalations — when having flagship firepower one toggle away turns emergencies into procedures.

• Opus warm for escalation
• Triggers define the rise
• Outage coverage included
• Zero idle cost, full readiness

Guard the flagship gate

Review Opus assignments quarterly as generations constantly move the adequate boundary upward — today's Opus-only ticket becomes tomorrow's Sonnet routine. Maintain triggers from telemetry, retiring escalation where steady lower-tier success proves sufficiency. Police prestige routing explicitly: flagship-by-default requests get rerouted with data, not debated with opinions.

Track the adequate boundary as a metric: share of tickets genuinely needing Opus over time. Healthy organizations watch it shrink as models improve and specs sharpen. Teams that guard the gate enjoy flagship outcomes at blended bargain prices indefinitely. Teams that don't fund prestige out of engineering budgets while wondering where the money went.

• Quarterly boundary reviews
• Trigger hygiene from telemetry
• Prestige routing policed
• Adequate boundary tracked upward

Frequently asked questions

How do I estimate Opus spend?

Input, output and cache rates at flagship levels, multiplied by long-context profiles typical of hard tickets. Estimate from representative hard tickets, not averages — Opus usage is spiky by nature and averages mislead.

What belongs on Opus?

Route only judgment-heavy work here: architecture, subtle debugging, security-sensitive reviews. Everything mechanical belongs on cheaper tiers; Opus as default is the most expensive common misconfiguration.

Opus or Sonnet for hard tickets?

Compare identical hard tickets on Opus versus Sonnet with review time included. Opus wins where its judgment prevents expensive mistakes; elsewhere Sonnet matches it for less. Let data, not prestige, assign the share.

Should Opus stay as fallback?

Yes. Keep Opus configured for escalation and outages on any stack, with triggers defining when tickets rise to it. Flagship fallback costs nothing idle and rescues the tickets that justify it.

How often should Opus routing be reviewed?

Review quarterly as generations move the adequate boundary upward constantly. Maintain triggers from telemetry; retire assignments that steady lower-tier success obsoletes.

Related guides

• Claude Opus vs Sonnet for Coding: The Honest Split
• Claude Sonnet Pricing: Real Costs and the Routing That Controls Them

Last updated: 2026-09-28