Kimi vs DeepSeek API Cost: Long Context, Output and Caching
By Nicho
For an equal-token workload, DeepSeek V4.1 Flash costs substantially less than Kimi K3 at the gateway prices below. The useful next question is how your application spends those tokens: reading a document once, repeatedly querying it, or producing long answers.
This comparison covers Kimi K3, not every Kimi model. Kimi describes K3 as its previous-generation flagship, with a 1M-token context. It is not the latest Kimi release. Kimi K3 documentation
DeepSeek's direct API currently maps deepseek-flash to DeepSeek-V4.1-Flash-1017, also with a 1M context. The gateway uses the identifier deepseek-v4-1-flash; identifiers and provider routes should be recorded separately. DeepSeek model details
Prices were checked on October 26, 2026. These are calculated budgets, not benchmark results or measured production bills. We have not independently tested backend revision equivalence between routes.
Start with the route and the token category
cheapaimodel lists these USD rates per million tokens:
| Gateway model | Input | Output | Cache read |
|---|---|---|---|
kimi-k3 |
$2.093511 | $10.467555 | $0.209351 |
deepseek-v4-1-flash |
$0.209351 | $0.837404 | $0.004187 |
Source: cheapaimodel live pricing.
For an uncached text workload, calculate:
Token cost = (input tokens × input rate + output tokens × output rate) / 1,000,000
Count all billable output reported by your route, rather than estimating from the visible answer's word count. Keep tool-service charges, retries and any other separately billed items outside this simple token formula, then add them to the application budget.
A shared context-window size does not establish equal answer quality, latency or usable capacity in your client. It only gives you one limit to check. Reserve room for the rest of the conversation and the requested output instead of treating an entire context window as free document storage.
Three long-document budgets
The following examples assume no cache reads and ordinary input billing, with no additional cache-write premium. They isolate token rates. They do not predict identical tokenization or answers across models.
| Hypothetical workload | Total input / output | Kimi K3 gateway | DeepSeek Flash gateway |
|---|---|---|---|
| 100 documents, 50,000 input and 2,000 output tokens each | 5M / 0.2M | $12.56 | $1.21 |
| Same input, 20,000 output tokens per document | 5M / 2M | $31.40 | $2.72 |
| 100 documents, 500,000 input and 2,000 output tokens each | 50M / 0.2M | $106.77 | $10.64 |
For example, the first Kimi estimate is 5 × 2.093511 + 0.2 × 10.467555 = $12.561066. Its DeepSeek equivalent is 5 × 0.209351 + 0.2 × 0.837404 = $1.2142358.
The second row answers a different budgeting question from the third. More generated output raises one part of the bill; resending a much larger source raises another. Separate those changes when investigating a cost increase. Otherwise, a more verbose response can look like a long-context pricing problem.
For document extraction, define the required fields before testing. For summaries, set an appropriate length target. For multi-step analysis, record the entire run, including intermediate calls, rather than costing only the final response.
Direct DeepSeek pricing depends on the time
DeepSeek's direct Flash rates are lower off-peak:
| USD per million tokens | Direct peak | Direct off-peak |
|---|---|---|
| Cache-miss input | $0.30 | $0.15 |
| Cache-hit input | $0.006 | $0.003 |
| Output | $1.20 | $0.60 |
Peak periods are 01:00–04:00 and 06:00–10:00 UTC, Monday through Friday, excluding Chinese public holidays. Other periods are off-peak. Official DeepSeek pricing
The first document workload therefore costs $1.74 direct at peak or $0.87 direct off-peak, versus $1.21 through the gateway. At this snapshot, the gateway undercuts direct peak pricing but not direct off-peak pricing. Do not use a peak-price discount to claim savings for every schedule.
For an overnight document queue, compare the actual execution window. For interactive requests, use the observed distribution of calls across pricing periods.
Repeated context needs a separate cache model
DeepSeek caches prefixes on a best-effort basis. Its current documentation requires a complete match to a persisted prefix unit. In its document-Q&A example, two different questions first establish their common document prefix; the third request can reuse it. Repeated text alone does not prove that the second request received a cache hit. Inspect prompt_cache_hit_tokens and prompt_cache_miss_tokens. DeepSeek caching documentation
Suppose direct DeepSeek reports 1M missed input tokens, 4M hit input tokens and 0.2M output tokens, all at peak rates. The token bill is:
1 × $0.30 + 4 × $0.006 + 0.2 × $1.20 = $0.564
This is conditional on the reported hit mix. It is not a promised 80% hit rate.
Kimi's direct API separates uncached input, cache writes and cache reads into mutually exclusive token categories. For K3, rates per million are $3 uncached, $3 for a five-minute write, $6 for a one-hour write and $0.30 for a hit. The default TTL is five minutes; hits renew it. Kimi cache billing
Consider only a reusable 1M-token prefix, requested at minutes 0, 10 and 20. Assume each request is eligible for caching. Five-minute entries expire between calls: three writes cost $9. A one-hour entry costs $6 + $0.30 + $0.30 = $6.60. Two avoided rewrites recover the longer TTL premium; just one does not. Output and changing suffixes are excluded from this prefix-only calculation.
Do not transplant those direct-provider write rules into a gateway bill. The gateway's cache-read rate is published, but its Kimi write/TTL billing semantics were not established for this comparison. Confirm them before quoting a complete cached Kimi total.
Choose using accepted results, then optimize the bill
Build a small evaluation set from your own document types. Keep the source material and acceptance criteria fixed, while allowing for different token counts. Record:
- Correct fields, citations or other required outputs.
- Total billed tokens and charges across every attempt.
- Cache reads and writes actually reported.
- Completion time, failures and manual review needed.
Then calculate total run cost divided by accepted results. This gives you a decision metric without inventing a quality advantage for either model.
For setup and broader budgeting, see the DeepSeek API pricing guide and multi-model pricing comparison. Recheck the live rate table before committing a large workload.