Claude Code latency vs cost: is the fast model worth the extra spend

Short version: pay for speed when a person is blocked watching the cursor, and pay for price when the agent is running unattended. Fast mode on Claude Opus 5 is a research preview that raises output tokens per second by up to 2.5x, and it is billed at $10 per million input tokens and $50 per million output, against $5 and $25 for the same model at standard speed. That is a straight doubling of the token bill for a speedup that only exists on the generation phase of the request.

So the real question is not whether the fast model is faster. It is. The question is what fraction of your wall-clock time is actually generation, and whether shaving that fraction changes anything you care about. In an interactive session where you read every diff as it lands, it changes a lot. In an overnight refactor, you are paying double for a result nobody is awake to see arrive sooner.

The number to optimise is cost per finished task

Cost per token is a trap, and so is cost per request. A cheaper model that needs three passes to land a working change is more expensive than an expensive model that lands it once, and it is also slower, because each pass carries its own context re-read, tool round trips, and your time re-reading the output. I have watched a downgrade to a cheaper tier cut the per-request cost by 60 percent and raise the per-task cost, because the task went from one attempt to two and a half.

The tiers, at list price per million tokens, in and out: Claude Haiku 4.5 at $1 and $5, Claude Sonnet 5 at $3 and $15 (currently $2 and $10 on an introductory rate through the end of August 2026), Claude Opus 5 at $5 and $25, Claude Fable 5 at $10 and $50. The spread between the cheapest and the most capable is 10x on both sides. A task that needs two Haiku attempts and still fails costs more than the Opus attempt that worked, once you count the tokens the failed attempts burned reading your codebase.

• Count attempts, not requests. One task that took four turns is one data point, not four.
• Include the tokens spent on abandoned work. A rejected diff still cost you its input.
• Separate your own idle time from the model's. If you tab away for three minutes after firing a prompt, the model's latency did not cost you three minutes.
• Track the tail, not the mean. A p50 of 8 seconds with a p95 of 90 seconds feels slow no matter what the average says.

Most of the latency is not generation

A coding agent turn is not one API call. It is a sequence: read some files, think, call a tool, read the result, think again, write. Fast mode speeds up exactly one part of that, the token emission. It does nothing for the time your machine spends running tests, nothing for the tool round trips, and nothing for a cold prompt cache.

Prompt caching is where the interesting latency lives, and it is also where the interesting money lives. Cache reads cost roughly a tenth of the base input price; cache writes cost 1.25x at the five-minute TTL and 2x at the one-hour TTL. With the five-minute TTL you break even on the second request. Which means a long session with a stable prefix is cheap and fast, and a session that keeps invalidating its prefix is expensive and slow, on any model.

Two things silently invalidate that prefix, and both are things people do while chasing speed. Switching models mid-session invalidates the cache, because caches are per-model. So does switching between standard and fast speed. If you flip to the fast model halfway through a long conversation to hurry the last step along, you pay a cold cache write on the entire accumulated context, at the fast model's doubled input rate. The step you were trying to speed up may finish slower than if you had left it alone.

Effort is the lever most people never touch

Before reaching for a faster model, try asking the same model to do less thinking. The effort setting runs from low through max, and it controls how much the model deliberates, how many tool calls it makes, and how much preamble it writes. Lower effort means fewer and more consolidated tool calls and terser confirmations, which shows up as lower latency and a smaller bill at the same time. That is a rare combination, and it costs nothing to test.

My rough allocation, which you should treat as a starting point rather than a recommendation: low effort for anything mechanical, high for work where a wrong answer is expensive to discover later, and the top of the range only when correctness matters more than the invoice. Sweep it on your own tasks. The right setting is workload-specific and the defaults carried over from a previous model are usually wrong.

A test you can run this week

• Pick ten tasks you actually do, not benchmark tasks. Bug fix, small feature, test writing, a refactor across three files.
• Run each on two configurations. Same prompt, same repo state, one variable changed.
• Record wall-clock time to a result you would accept, total tokens, and number of attempts.
• Compute dollars per accepted result and minutes per accepted result. Look at both columns before deciding.
• Repeat when the model lineup changes, because it will, and the answer moves with it.

If you do this honestly, one of two things usually happens. Either the cheaper tier turns out to be fine for six of the ten tasks, and you route by task type from then on. Or the expensive tier wins everywhere and you stop worrying about it, which is also a useful outcome, because you can stop second-guessing every prompt.

You need a ledger before you can decide anything

All of the above assumes you can see per-request latency, model, token counts, and real cost, attributed to the process that made the call. Most people cannot, which is why I built Probe0. It is a local proxy on macOS, currently in private beta. Install it once with a certificate and every coding agent CLI on the machine routes through it, Claude Code and Codex and Cursor together, with no per-tool configuration.

The Recording module keeps a full request ledger: model, tokens, real cost, latency, and which process made each call. That is the raw material for the experiment above. Because it sits in front of every agent rather than inside one, you can compare a Claude Code session against a Codex session on the same axis. Other modules are individually switchable and each reports what it saved: Local Routing sends work to a model already running in Ollama or LM Studio and retries weak answers on the cloud, Model Tiering tries the cheap model first, Exact Cache and Semantic Cache serve repeats from local disk, Request Coalescing collapses simultaneous identical calls, and Spend Guard caps a run or a day and pauses when you hit it. Probe0 also reads your actual usage and tells you when you are paying for a plan tier above what you use.

Every module is off by default and reports its own savings, because a cost tool you cannot audit is just another thing to trust.

The honest limits: macOS only, private beta, sign-in through Google or GitHub with a young account system. It is not a team gateway and there is no Probe0 server, so there is nothing multi-user to point at. Provider coverage is whatever coding agents call, not a catalogue of a hundred providers. If you want hosted dashboards, org-wide rollups, or long-term retention across a fleet, a hosted gateway is the better fit and I would use one.

But for the specific question in the title, on one developer's machine, the thing you need is a truthful local record of what each request cost and how long it took. Get that first. The fast-model decision answers itself once the numbers are in front of you, and in my experience it answers differently for interactive work than for anything you kick off and walk away from.