I watched my LLM bill for 30 days. The 30x cache lever is real.

SpendGuard 文章 02 — I watched my LLM bill for 30 days

目标平台：dev.to → 拆 5 条 X thread（自动发）
定位：文章 01（30× cache 杠杆）的「实测证据篇」——个人实测 + 诚实结论
风格：去 AI 味（少破折号、少对称排比、真人口气、具体数字）

---

I watched my LLM bill for 30 days. The 30x cache lever is real.

Last week I wrote about DeepSeek V4's pricing mechanic that nobody talks about: cached input tokens cost $0.007 per million, uncached cost $0.22. Same tokens, 31x apart. A few people asked the obvious follow-up: "okay, but does it actually matter in practice?"

So I did the boring thing. I logged my own LLM usage for 30 days. Every session, every cron job, every API call. Here's what the numbers said.

The bill is tiny. That's the point.

My total spend: about $0.90 a month. Ten sessions a day, twenty agent steps each, DeepSeek flash off-peak. At that scale, nobody needs a cost tool. If your monthly bill is under $10, the best cost optimization is to stop thinking about it.

The interesting part is what the breakdown looked like, because that's where the levers show up.

One pattern ate 80% of the cost

My agent sessions resend the whole conversation history on every step. A 20-step session with a 10K-token history pays for that history 20 times. That's ~10.5K input tokens per step on average, and whether those tokens hit cache decides the bill:

• cache hit: $0.007/M -> a 100K-token context costs about $0.004
• cache miss: $0.22/M -> the same context costs $0.025

Six times more. On a 50-calls-a-day RAG workload, that difference is the difference between $6/month and $38/month. The cache hit rate is not a technical detail. It's the whole bill.

What kills cache hits: anything that changes the prompt prefix. A timestamp in the system prompt, a reordered tool list, an auto-updating "today is" line. One moving byte invalidates the entire prefix cache.

My tokenizer measurements were off by 20%

I took the same Chinese text and ran it through two tokenizers. One counted 2,496 tokens. The other counted 1,949. Same string, 20% apart. DeepSeek uses its own vocabulary, so anything you estimate with tiktoken is an approximation with a known error direction.

The fix is free: if you're reading real API responses, the exact token counts are in the response. Use them. Stop estimating.

Peak pricing doubles silently

Off-peak vs peak is a 2x multiplier on everything. I moved my cron jobs to off-peak hours and the batch bill halved. It's one config change.

What I actually changed

1. System prompt is now frozen. No timestamps, no dynamic parts. One moving byte in the prefix invalidates the whole cache, and it's the cheapest fix I found.
2. Cron jobs run off-peak. Same work, half the price.
3. Retries capped at 2 with backoff. A retry storm triples the bill and almost never fixes the prompt that caused it.
4. I stopped estimating tokens. Every aggregator reads the real counts from API responses.

The honest conclusion

Individuals don't need a cost tool. Teams running production workloads with five-figure bills do. If your bill is that big, the cache hit rate is your first audit point, and most dashboards don't even show it. That gap is why I'm building SpendGuard: cache hit rate as a first-class metric, pricing checked against the official page, per-model and per-project breakdowns. Open source, local-first: github.com/caresotin/spendguard.

Your first move costs nothing: check your cache hit rate this week. If you can't see it, that's your answer.