Is the number these calculators show you actually right? Not whether the
model is in the catalog — whether the arithmetic behind that number matche...
For further actions, you may consider blocking this person and/or reporting abuse
One thing most calculators silently fold away: the cost number depends almost entirely on how you route, not just which model you pick. In prod we split by task difficulty — cheap models for the routine 70-80%, frontier only for the hardest 20% — and the bill looks nothing like a single-model calc predicts.
The other hidden term is cache stability. A stable system+first-user prefix (pinned by hash, never storing the prompt) keeps hit-rate high, and that alone changes the per-token math more than switching providers does.
Curious which calculators you found handled the quality-band tradeoff — most seem to assume one tier fits all.
Both of those are real levers a per-model calculator misses. On routing: none of the calculators I've checked, including this one, model a mixed-tier workload — they price one model per estimate, so a 70/20 cheap/frontier split has to be run as two separate estimates and added by hand. On cache stability: PromptSpend takes a cache-hit-rate input directly (0-100%, no per-model default), so it prices whatever hit rate you tell it — a pinned system+first-user prefix and a rotating one get the same number unless you already know to lower the rate yourself. So the honest answer to "which handled the quality-band tradeoff" is none that I've found — feels like the right next input to expose explicitly rather than fold into the per-call rate.
Great point on the mixed-tier workload — that "run two estimates and add by hand" step is exactly why we route per call by task difficulty instead of pricing one model at a time. The 70/20 split you had to compute manually is what an automated router does on every request.
Your cache-hit-rate critique is the sharper one, though. Hit rate isn't a property of the model — it's a property of your traffic's structure (how stable your prefixes are). A calculator that takes it as a free 0–100% input just pushes the unknown back onto the user: a pinned system+first-user prefix and a rotating one genuinely do behave differently, and the tool can't know unless you already knew. The honest version measures hit rate from actual prefix stability rather than asking you to guess it.
And the "quality-band tradeoff" you name is the right next input — but I'd frame it as the distribution of task difficulty in your workload, not a quality slider. A 70–80% routine share only holds if your traffic is actually shaped that way; a different shop's split moves, and the calculator should take that distribution as input instead of assuming it.
The shape that's worked for us: provider price per call, plus an observed workflow multiplier (retries, evals, review) fed by real per-route outcome data. Without the measured outcomes, the calculator is just relabeling the same guess.
One question back: do you see cache-hit-rate as something calculators should measure from traffic, or expose as a knob users tune per deployment?
Exposed as a knob, and printed next to the number rather than folded into it — that's the position in section 8 of the article ("assumptions are visible"). A static calculator has no view into your actual traffic, so it can't measure hit-rate; the honest version is asking you for your prefix-stability assumption and showing that assumption plainly, not pretending to have observed it. Measuring it from real traffic is the right answer for a tool sitting inside your request path with visibility into repeat prefixes — that's a different product than a pricing calculator, but a good direction if PromptSpend ever wires into live usage instead of hypothetical scenarios.
Exposed as a knob, next to the number rather than folded in — that's exactly the shape, and it's the honest core: the calculator is a planning tool, so its job is to make you state the prefix-stability assumption, not to fake having observed it. Section 8 lands that.
Your "different product" point is the one I keep sitting with. A pre-deployment calculator and an in-path observer answer different questions. The calculator's job is to make the assumption explicit before you have traffic; the observer's job is to falsify it once you do. They're complementary, not the same tool wearing two hats — and conflating them is how calculators end up pretending to a precision they don't have.
The harder problem, I think, isn't exposing the knob. It's that a knob nobody sets just becomes a hidden assumption with extra steps — the default quietly stands in for a real number. So the question that matters is whether the tool forces a value rather than accepting silence.
One back at you: what's the smallest bridge between "I assume X stability" and "I observed X stability" that keeps the planning tool honest without turning it into a monitoring system? Do you surface the assumed-vs-observed delta anywhere, or let the live tool silently diverge?
The missing cost is usually retries and verification. A calculator can price input and output tokens, but production usage also pays for failed runs, duplicate tool calls, eval passes, and human review after ambiguous results. That is where the budget surprise often lives.
You're right, and it's a real gap. Everything above prices a call, not a workflow. Retries, duplicate tool calls, an eval pass, human review after an ambiguous result: none of that shows up in a per-token rate card, because it isn't a pricing question. It's a question of how many times your workload actually has to call the API to finish one unit of work. A calculator can only price what a provider bills. It has no way to know your retry rate or your review trigger unless you measure it and feed that number in yourself.
Exactly. The useful calculator is probably two layers: provider price for one call, then observed workflow multiplier for this product. Once teams measure retry rate, eval pass rate, and review triggers, the token price finally becomes grounded.
Agreed — and "grounded" is the right word for it. A number with a measured multiplier behind it is a claim you can check; one with an assumed multiplier is just a guess with better formatting. That's the same distinction section 8 is trying to draw.
That is the hidden gap. Token pricing is easy to model; retries, failed tool calls, human verification, and post-incident cleanup are where the real bill shows up. I would rather see calculators expose assumptions than pretend there is one universal cost per task.
Agreed on both counts — that two-layer split, provider price per call then an observed workflow multiplier for retries/evals/review, is the right shape. One condition I'd add: "expose the assumption" only helps if it's a number someone measured, not a guess dressed up as a setting, otherwise the unfounded number just moves from the vendor's page to yours. PromptSpend doesn't have a workflow multiplier today; the reasoning-multiplier field is the closest analog, and it's user-supplied for exactly that reason — the tool can't know your retry rate, so it doesn't pretend to.