Fast Mode Is Now 3× Cheaper. Your Routing Logic Just Got Competition.

Opus 4.8 fast mode runs at 2.5× the speed of standard Opus 4.8, and costs three times less than the previous generation’s fast tier.

That is a pricing move, not a capability move. But pricing moves on the effort dial have structural consequences for how you build.

The Numbers

Standard Opus 4.8: $5 per million input tokens, $25 per million output tokens. Same price as Opus 4.7.

Fast mode Opus 4.8: $10 per million input tokens, $50 per million output tokens. Three times cheaper than fast mode on previous models. Triggered with /fast.

At 2.5× the speed and a substantially lower price point than its predecessor, fast mode is now a genuinely attractive default tier for a wide range of tasks — not just the low-stakes, low-complexity work you previously routed to a smaller model to manage cost.

The Effort Control Stack

Fast mode sits at the bottom of a four-level effort system that ships with Opus 4.8:

→ low — fastest, lightest

→ high — the new default; similar token spend to Opus 4.7's default, but with better performance

→ extra (or xhigh in Claude Code) — recommended for difficult tasks and long-running async workflows

→ max — full compute, highest quality ceiling.

Anthropic’s own framing for high is instructive: it spends a similar number of tokens as Opus 4.7's old default, but scores higher. The baseline improved without increasing cost. The new default is not a more expensive version of what you had — it is a better version at the same price.

The effort system is also available to users directly in claude.ai and Cowork, not just via API. That matters for teams where non-engineers are consuming Claude in production contexts.

What This Does to Your Routing Layer

If you built a routing layer — logic that sends easy requests to a small, cheap model and hard requests to the frontier model — you were solving a real problem. The gap between cheap-and-fast and accurate-and-slow was wide enough that the routing code was clearly worth maintaining.

Opus 4.8 narrows that gap at the fast-mode end. The vendor is making it genuinely attractive to default to fast mode for a broader set of tasks rather than routing to a smaller model. That is not a reason to immediately retire your router. It is a reason to benchmark it against the new tier and check whether it is still earning its keep on cost or latency for your actual traffic.

The honest question: is your routing logic still saving meaningful money, or did it make sense in a pricing environment that no longer exists?

Some routing logic will still win. Domain-specific routing based on query classification, task type, or risk level is still yours. What gets squeezed is the generic cost-based routing that existed purely because the frontier model’s cheaper tier was not cheap enough to default to.

The Practical Recommendation

Anthropic’s own guidance: use extra effort for difficult tasks and long-running asynchronous workflows. Use high (the default) for standard work. Fast mode for high-throughput, lower-stakes tasks where latency and cost matter more than maximum quality.

The rate limits in Claude Code were increased alongside the higher-effort levels to accommodate the additional token usage at extra and max. That is a deliberate signal: Anthropic expects people to run at higher effort levels more often on this model than on previous ones, and has capacity-planned accordingly.

Start by running your most common task types through each effort level and measuring quality against cost for your specific workload. The right tier is not universal — it depends on what you are building and what “good enough” means for your use case. But the calibration exercise is now worth doing again, because the tiers shifted under you.

💡 Prompts

Re-evaluate your routing logic:

I have a routing layer that sends requests to different models based on [describe your routing logic, cost targets, and what models you route between]. Given Opus 4.8 fast mode is now 3× cheaper than the previous fast tier at 2.5× speed, help me determine whether my routing logic is still saving meaningful cost or was calibrated to a pricing environment that no longer exists. Suggest which request types I should benchmark first and what I should measure — latency, cost per request, and quality threshold — to make a data-driven decision about whether to simplify.

Calibrate effort tiers for your workload:

I want to calibrate which Opus 4.8 effort tier is right for different task types in my workflow: [list your common task types — code review, documentation, refactoring, analysis, etc.]. For each task type, help me design a small benchmark: what quality dimensions matter, what a passing result looks like, and how to measure the cost-quality tradeoff across high, extra, and fast mode so I can set effort levels deliberately rather than defaulting to max everywhere.