By Sean Donahoe · Published July 16, 2026 · accurate as of this date
The fast model is dumb. The smart model is slow and dear. The cheap model is a coin flip. And you keep hunting for the one model that's somehow none of those things.
It doesn't exist. Never has.
Every engineer who's shipped anything knows the old triangle. Fast, cheap, good. Pick two. Ops has it, manufacturing has it, your last freelance client definitely had it. LLMs are no different, except the corners have new names and the decision comes back around on every single request.
Here's the bit nobody teaches: which corner you give up isn't a property of the model. It's a property of the job.
Latency vs cost vs quality: can't you just have all three?
No. Every model sits somewhere on a three-corner tradeoff, latency, cost, quality, and buying two means giving up the third. Nothing beats the triangle. The actual skill is choosing which corner to sacrifice for each workload, because that corner moves. A nightly batch job and a live support turn should not be paying the same tradeoff, and if they are, you picked once and stopped thinking.
The third corner everyone forgets
Most of the writing on model choice lives on one line: cost versus quality. Don't overpay for a model that's smarter than your task needs. That's the whole argument in the ferrari-prices-corner-shop piece, and it's a good argument. Go read it. I'm not running it again here.
But cost and quality are only two corners. There's a third, and it sits ignored until the day an app feels sluggish and someone finally asks why.
Latency.
And latency is spendable. That's the part that changes everything. A workload where nobody is waiting, an overnight enrichment run, a batch of documents to extract, an eval sweep, can buy top quality AND low cost by spending the one thing it has going spare. Time. Slow is free when no human is blocked on the answer.
So the corner you can afford to drop is dictated by the workload, not the leaderboard. Which is why the same team can be right to use a frontier model here and a throwaway one two functions over.
Which corner can you afford to drop?
Three ways to spend the triangle. Find your workload in the middle column, and the corner falls out.
| Corner you drop | What you keep | Where it fits | What you reach for |
|---|---|---|---|
| Latency | Cost + quality | Batch extraction, nightly enrichment, eval runs, offline report generation. Nobody's blocked. | The strong model, run slow. Time is free, so spend it. |
| Cost | Latency + quality | A paying user's live support turn. A fraud or triage call. The agent step the whole chain hangs on. | The fast, strong class. The token bill is a rounding error next to a wrong or late answer. |
| Quality | Latency + cost | Autocomplete, typeahead, bulk classification, internal tooling, first-draft scaffolding. | The fast, cheap class. "Good enough, right now" wins far more than pride admits, as long as there's a floor. |
That floor in the bottom row matters, and it's exactly the trap the quality-cliff piece is about. Cheap and unwatched is where things quietly rot. Read that one before you go all-in on the cheap corner. I'm not re-arguing it here either.
One honest caveat before anyone in the comments beats me to it. The triangle is a reasoning tool, not a law of physics. The frontier moves, and every so often a genuinely better model wins on two corners at once, cheaper AND smarter than what it replaced. That's real, and it's half the point of the ferrari piece. Use the triangle to think. Don't use it to argue.
Reasoning models don't play by the rules
Now the thing that breaks the clean picture.
A reasoning model doesn't spend one corner to buy quality. It spends two.
Per a Towards Data Science write-up on test-time compute, extended-thinking models generate a pile of extra internal tokens before they hand you an answer, and those tokens are typically billed as output and produced one after another. Which hits you twice. The bill goes up, because you're paying for all that hidden thinking. And the wall clock goes up, because sequential tokens take real time to produce. Two corners, latency and cost, both spent, to buy the one corner called quality.
So a reasoning model is only a good deal in exactly one situation: quality dominates so hard that you'll happily pay on both other axes. The answer is expensive to get wrong, and nobody's tapping their foot waiting for it. That's the sweet spot. Anywhere latency-sensitive or cost-sensitive, reaching for a reasoning model is a reflex to fight, not follow.
And more thinking isn't always more answer. An arXiv survey on adaptive test-time compute makes the efficiency case: reasoning models tend to apply a fixed compute budget no matter how hard the task is, so they routinely overthink simple problems, burning tokens and seconds to deliberate over a decision they'd already reached. The fix it points to is controllable compute. Some models now expose a depth knob, a dial for how hard the thing thinks before it answers, so you can tune that tradeoff instead of taking it all-or-nothing. Worth using where you have it.
"Latency" is two numbers, and streaming lies about one of them
When someone says a model is slow, ask them which slow they mean. There are two, and they're not the same number.
Artificial Analysis, in its performance benchmarking methodology, splits them cleanly. Time to first token is the seconds between sending your request and the first token coming back. Output speed is the tokens per second you get after that first one lands. Add input processing and, for a reasoning model, all that thinking, and you get end-to-end latency: total time to a finished response. And here's why a reasoning model can look quick and finish slow. Its first token can arrive on time, because the first token is a reasoning token, not an answer token. The answer itself is still being generated.
Now, streaming.
Streaming does not make a model faster. It doesn't shave a millisecond off total generation time. What it does is hand you the early tokens the instant they're produced, so the wait feels shorter while the model keeps working. That's a perceived-latency lever, and for a human reading along it's a great one. Words appearing beats a spinner every time.
For a machine, it's useless. If your caller needs the whole JSON blob before it can do anything, front-loading the first few tokens buys you nothing. The last token is the only one that matters, because that's when the payload is complete and the code can move.
So pick your latency metric by who's on the other end. Human reading? Optimize time to first token, stream your heart out. Code that needs the full answer to act? Total completion is the only number, and streaming is decoration.
The two questions that pick the corner for you
You don't need a spreadsheet for any of this. You need two questions.
One: who is waiting on this answer, and what does the wait cost them?
Two: what does a wrong answer cost?
That's it. Run any workload through those two and the corner you can drop falls right out.
A customer-facing weekly digest, emailed out Sunday night. It says "customer-facing," so the reflex is to reach for the fast model. Don't. Ask the questions. Who's waiting? Nobody. It generates Sunday, the user reads it Monday. What's a wrong summary cost? A slightly-off digest, low stakes, and you can re-run it. Drop latency. Take the slow, strong, cheap path and let it grind. This one looked live and bills like batch. The label lied; the two questions didn't.
Live agent step that every later step depends on. Who's waiting? A paying user, and the whole chain downstream of this call. What's a wrong answer cost? The entire run, plus their trust. Drop cost. Buy the fast, strong model and don't flinch at the token bill.
Autocomplete in an internal tool. Who's waiting? A developer, and they want it instant. What's a wrong suggestion cost? They ignore it and keep typing. Drop quality. Fast and cheap, with a sane floor, and move on.
Three workloads, three corners, and the first one wore a label that lied. That's the whole game, and it's why you run the questions instead of trusting how a job looks from the outside. Stop hunting for the model that wins everywhere and start asking those two per job.
You don't pick the triangle once
Here's where most stacks go wrong. They hard-wire one model into the app, and now every request pays the same tradeoff forever. The batch job and the live turn, the autocomplete and the fraud call, all frozen at one fixed spot on the triangle. You optimized for the average of workloads that have nothing in common.
But the corner you can sacrifice changes request to request. So the decision should too.
That's the shape of the problem a router is built for, and it's where Flux fits. One API key across many models. Each request routed to a fitted model instead of one you nailed down at deploy time. And on every non-streaming response, headers that tell you which model actually answered and what that request cost in USD, so you can see the tradeoff you just made instead of guessing at it.
That's the WHAT. Point your call at the router, let the pick fit the request, read back what happened.
If you want the other two corners in depth, the ferrari-prices-corner-shop piece takes cost versus quality, and quality-cliff takes the floor you can't drop below. Or grab a key from the quickstart and run the two-question test against your own traffic. That's the only test that counts.
Receipts
Framework and opinion in this piece are ours. The factual claims trace to these public sources, fetched July 16, 2026; recheck before relying on them.
- Time to first token, output speed, end-to-end latency definitions, and reasoning-model first-token behavior: Artificial Analysis, Performance Benchmarking methodology
- Reasoning models bill internal thinking as sequential output tokens, raising both cost and latency: Towards Data Science, "Inference Scaling (Test-Time Compute)"
- Reasoning models often overthink; the case for adaptive, controllable compute budgets: arXiv 2507.02076, "Reasoning on a Budget: A Survey of Adaptive and Controllable Test-Time Compute in LLMs"
- Flux: one key across many models, per-request routing, and per-request model and USD cost surfaced on non-streaming responses: Transparency headers · Quickstart
- Further reading (Flux blog): Ferrari prices at the corner shop (cost vs quality) · The quality cliff (the floor you can't drop below)