Model Economics
DeepSeek API Pricing: How to Read Token, Cache, and Peak-Hour Costs
A current, source-backed guide to reading DeepSeek API pricing, estimating a real workload, and avoiding surprises from cache or peak-hour rules.
What you will learn
- Estimate input, output, and cache-hit tokens separately.
- Peak and off-peak rules can materially change the rate.
- Use current provider documentation and live usage records before launch.
Before you start
- Basic HTTP and API knowledge
Leave with a concrete implementation checklist and a testable starting point.
Key takeaways
- Estimate input, output, and cache-hit tokens separately.
- Peak and off-peak rules can materially change the rate.
- Use current provider documentation and live usage records before launch.
The unit is one million tokens
DeepSeek lists input and output prices per one million tokens. The practical bill is the number of tokens used multiplied by the rate that applies to the request, so a useful estimate must separate input, output, and cache-hit tokens.
Do not compare a single headline number. A short prompt with a long answer, a long retrieved document, or a repeated system prompt can have a completely different cost shape from a short chat example.
Cache and time-of-day rules matter
The current DeepSeek pricing page separates cache hits from cache misses and documents off-peak and peak rates. If your workload repeats context, measure cache-hit volume; if it runs in scheduled batches, record the UTC hours that determine the rate.
A safe budget keeps the rate assumptions visible in the calculation and checks the provider page again before launch. Prices and model versions can change, so stale screenshots are not a production source of truth.
Build a reproducible estimate
Capture representative prompts, token counts, model name, endpoint, cache state, and request time. Then calculate input cost, output cost, and any cache component separately before multiplying by monthly request volume.
Finally compare the estimate with the live account balance and usage records. A gateway can simplify routing and reporting, but it cannot make an undocumented provider price stable.
Decision guide
| Criterion | Option A | Option B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Implementation steps
- 1
Collect representative prompts and token counts.
- 2
Record model, endpoint, cache state, and UTC request time.
- 3
Calculate each cost component independently.
- 4
Reconcile the estimate with live account usage before release.
Copy-ready example
const cost =
inputTokens / 1_000_000 * inputRate +
outputTokens / 1_000_000 * outputRate +
cachedTokens / 1_000_000 * cacheRate;Frequently asked questions
Are DeepSeek prices permanent?
No. The provider says prices may change. Treat the live pricing page and account usage records as authoritative.
Sources
- DeepSeek Models & PricingSource checked 2026-08-27
- DeepSeek Token UsageSource checked 2026-08-27