I got nerd-sniped by a pricing table last week. Someone posted a middleman listing with input, output, and cache-hit rates side by side, and the cache column made no sense at a glance. DeepSeek's `deepseek-v4.1-flash` lists cache at $0.004. Kimi's `kimi-k3` lists cache at $0.20. That's not a rounding difference. That's a 50x spread on the one line item that most people ignore when they pick a model.
And people do ignore it. In one thread a developer said switching from DeepSeek v4 to mimo 2.6 cut his monthly bill roughly in half based on last month's token usage, and the very next reply was someone asking what the cache-hit rate even was. Nobody knew. They were comparing sticker input/output rates and hoping the cache math worked out. That gap is the whole problem, and it's small enough that one person can close it in an afternoon.
Why the sticker rate lies
Effective cost per call is not the input rate. It's a blend:
effective_input = cached_tokens * cache_hit_rate + fresh_tokens * input_rate
total = effective_input + output_tokens * output_rateThe cache-hit ratio is the lever nobody puts on the table. If you run an agent loop that re-sends the same long system prompt and tool definitions on every turn, a huge share of your input tokens are cache hits. At that point the cache rate dominates and the input rate barely matters.
Run the two extremes against the listed numbers. Say a call has 20,000 input tokens and 1,000 output tokens.
At a 0% cache-hit ratio, `deepseek-v4.1-flash` ($0.20 input, $0.80 output) costs 20,000 * $0.20 + 1,000 * $0.80 per million tokens. Kimi's `kimi-k3` ($2.00 input, $10.00 output) costs about 5x more on input and over 12x on output. No surprise there.
Now push the cache-hit ratio to 90%, which is realistic for a chatty agent with a stable prompt prefix. DeepSeek's cache at $0.004 means 18,000 of those input tokens are almost free, while Kimi's cache at $0.20 keeps them meaningfully expensive. The gap between the two models widens for cache-heavy workloads instead of narrowing. The point is that the ranking can flip depending on your reuse pattern, and you can't see the flip by reading the sticker rate. You have to plug in your own numbers.
One caveat worth flagging: the listing shows no cache line for the MiniMax and Qwen entries (`MiniMax-M3` at $0.40/$1.60, `qwen3.8-flash` at $0.08/$0.27). Whether those models cache at all, and at what rate, is unverified from this evidence. A good calculator should treat a missing cache rate as an editable field, not assume zero.
What I'd actually build
A single hosted page with two inputs and a live number. The workload side takes your average input tokens, output tokens, cache-hit ratio, and calls per day. The pricing side is an editable table you own, because these rates change and vendor listings disagree.
The front end is plain HTML and a form. You can run HTML online to host the page and share a link, so a teammate can open it and tweak the cache-hit ratio without cloning anything.
The math lives in a small backend. I'd keep it in Python because the formula is trivial and the readability matters more than speed here. You can run Python online to compute effective cost per model, sort the results, and return them as JSON the page renders into a ranked table. Give it a range mode too: sweep the cache-hit ratio from 0% to 100% in steps and return the curve, so you can see exactly where one model overtakes another.
The pricing table is the part that rots fastest, so store it properly instead of hardcoding it. A small database with columns for model, input rate, output rate, and cache rate does the job, and a nullable cache rate lets you represent the models where the listing didn't publish one. Using a SQLite editor you can seed the table with the listed values and update a rate the moment a vendor changes it, without touching the calculator logic.
Seed data and the honest defaults
Start with what the listing actually gave, per million tokens:
- `deepseek-v4.1-flash`: input $0.20, output $0.80, cache $0.004
- `deepseek-v4-pro-0813`: input $0.90, output $2.70, cache $0.03
- `glm-5.3 / 5.2 / 5.1`: input $0.80, output $2.80, cache $0.20
- `kimi-k2.6 / k2.7-code`: input $0.63, output $2.67, cache $0.10
- `kimi-k3`: input $2.00, output $10.00, cache $0.20
- `MiniMax-M3`: input $0.40, output $1.60, cache not listed
- `qwen3.8-flash`: input $0.08, output $0.27, cache not listed
The defaults should carry a visible note that these came from a third-party listing on a specific day and are unverified against each vendor's official pricing. The tool's value is the model, not the seed numbers. Anyone using it should paste in the rates their own provider bills them, since middleman and aggregator pricing can differ from source pricing.
The trade-off worth naming
The cache-hit ratio is an input, not a measurement, and that's the soft spot. If you guess 90% and your real number is 40%, the ranking you get is wrong. So the tool shouldn't pretend to know it. The range sweep is there precisely so you don't have to commit to one guess. You look at the crossover point and ask whether your workload sits above or below it. That's a far better question than "which input rate is smaller."
What I like about this one is the scope. No auth, no accounts, no scraping. A form, a formula, a table you can edit, and a shareable link. It's the kind of thing that pays for the hour it took the first time you avoid picking the wrong model for a cache-heavy agent loop. Whether it saves you money in practice depends entirely on your real reuse pattern, which is exactly why the calculator asks for it instead of assuming it.