I ran the same text through two tokenizers. They disagreed by 20%.

SpendGuard 文章 03 — Your cost estimates are 20% off

目标平台：dev.to → 拆 5 条 X thread（自动发）
定位：文章 01（定价杠杆）02（账单实测）之后的「测量误差」篇——成本工具的隐性错误
数据：tiktoken 本地实测（同文本 cl100k 2,496 vs o200k 1,949）

---

I ran the same text through two tokenizers. They disagreed by 20%.

Here's a small experiment you can repeat in five minutes. Take one Chinese paragraph, run it through two tokenizers, and compare:

• cl100k_base (the encoder behind GPT-3.5/4-class models): 2,496 tokens
• o200k_base (GPT-4o class): 1,949 tokens

Same string. Same meaning. 20% apart. Neither is "wrong" — tokenizers are just vocabularies, and different vocabularies cut the same text at different places.

The problem is what happens when you estimate cost with the wrong one.

DeepSeek estimates are structurally off

DeepSeek uses its own vocabulary, and it isn't published the way OpenAI's is. So every cost tool that claims to estimate DeepSeek usage is approximating with a tiktoken encoder that was trained on different data. The error isn't a rounding issue. It's a structural one, in a known direction, and it varies by language: Chinese text gets hit harder than English because the vocab match is worse.

I've seen dashboards show "estimated tokens" for DeepSeek calls that are off by 20-30%. Nobody flags it. The number just looks authoritative.

The fix costs nothing

Every DeepSeek API response contains the real token counts. input_tokens, output_tokens, and for cached calls, the cache hit tokens, all returned in the response object.

Read them. Stop estimating. If your cost tool shows a number that isn't coming from the actual API response, it's a guess wearing a dashboard.

Why this matters more than it sounds

Cost optimization amplifies measurement error. The 30x cache lever I wrote about last week works on cache hit tokens — if your tool miscounts the input side by 20%, your cache hit rate is also wrong by 20%, and every optimization decision you make inherits that error. You can't manage what you're measuring wrong.

What this means for your stack

1. If you track LLM costs, log the token fields from responses, not estimates
2. If a tool claims DeepSeek support, ask what tokenizer it uses
3. For Chinese-heavy workloads, distrust any estimate more than usual

That last point is why SpendGuard reads real response counts instead of estimating: cache hit rate as a first-class metric, per-model and per-project breakdowns, and no guesswork in the numbers. Open source, local-first: github.com/caresotin/spendguard.

Check your own numbers this week. If your cost tool can't show you where they come from, that's your answer.