Cache pricing is not a vague optimization. For long prompts it can decide the whole unit economy of an AI feature. This article uses August 1, 2026 source checks and focuses on how developers should model cached input before shipping.
What cache pricing changes
Most AI API budgets still multiply input tokens by one price and output tokens by another. That model is too simple for modern Chinese AI APIs. Long-context providers increasingly expose a third line item: cached input. Cached input is the part of the prompt that the provider can reuse from a previous prefix, explicit cache object or stable system context. When the cache hits, the provider may charge far less than the normal input price.
DeepSeek's official rate card makes the difference visible. As checked on August 1, 2026, deepseek-v4-flash lists $0.0028 per 1M cache-hit input tokens, $0.14 per 1M cache-miss input tokens and $0.28 per 1M output tokens. That is a 50x gap between cached and uncached input on the published rate card. Z.AI's official pricing page lists GLM-5.2 at $1.4 input, $0.26 cached input and $4.4 output per 1M tokens. Alibaba Model Studio's pricing page states that some Qwen models support context cache discounts and shows detailed regional model prices. Kimi's Moonshot V1 platform docs list standard input and output rates; recent Kimi K3 discussion coverage highlights cache economics, but official current model-specific billing should be checked before production use.
The product implication is clear. You should design long prompts as cacheable assets. Keep the system instruction stable. Put large policy documents, API references and style guides before the user-specific suffix. Avoid injecting timestamps, random request IDs or user-specific text into the prefix that you expect to cache. The final user question should be late in the prompt, not mixed into the expensive reusable context.
For more implementation background, see AIWave's DeepSeek cache pricing guide, token economics primer and AI API cost reduction guide.
Cache-hit math
Suppose an engineering assistant sends a 90,000-token repository summary, a 5,000-token system prompt and a 2,000-token user request. If the first 95,000 tokens are stable and the provider bills them as cached input after the first request, the second and later requests have very different economics from the cold start. The output price still matters, but the reusable prefix no longer dominates the budget.
| Scenario | Cached input | Uncached input | Output | Budget lesson |
|---|---|---|---|---|
| Cold first call | 0 | 97,000 | 2,000 | Expect normal input billing while the prefix is new |
| Warm follow-up | 95,000 | 2,000 | 2,000 | Most prompt tokens move to the cheaper cached line |
| Broken cache | 0 | 97,000 | 2,000 | A changing prefix silently destroys unit economics |
| Verbose answer | 95,000 | 2,000 | 20,000 | Cache helps input, but output can still dominate |
This is why cache-aware routing should track four numbers, not two: cached input tokens, uncached input tokens, output tokens and retry tokens. If your provider returns token usage fields that distinguish cache hits, store them. If it does not, store an inferred cache eligibility flag and reconcile against the provider invoice. A single average cost per request hides the failure modes that matter.
Provider comparison
DeepSeek is best documented for the cache math in this snapshot. V4 Flash and V4 Pro both list 1M context, maximum output up to 384K and separate cache-hit prices. The page also notes planned peak/off-peak pricing, so a mature budget system should include request time in Beijing time as a potential multiplier.
Z.AI publishes a broad table for GLM text, vision, tools, image, video and audio models. For text models, GLM-5.2 and GLM-5.1 list the same current input, cached input and output rates, while GLM-4.5-Air is lower and GLM-4.5-Flash is marked free on the pricing page. The GLM-5.2 overview emphasizes 1M context and long-horizon engineering tasks. That makes cache design especially important: a model built for project-scale context can become expensive if every step is a cache miss.
Alibaba Model Studio requires exact model and region selection. Its pricing documentation describes context cache discounts for supported models and presents Qwen families across Beijing, Virginia, Singapore and Frankfurt sections. In practice, this means the same app may need different price metadata for a US deployment and a Singapore deployment. The safest pattern is to require model, region and deployment scope in the rate table.
Kimi and Moonshot require model-specific verification. The international Moonshot V1 pricing page lists moonshot-v1-8k, moonshot-v1-32k and moonshot-v1-128k with input, output and context windows. The Kimi model-list API documents how to list currently available models. Recent industry coverage of Kimi K3 talks heavily about open weights, large context and cache economics, which is useful for strategy, but billing code should rely on the live platform and the exact model returned by the API.
Budget calculator
The calculator below is intentionally provider-neutral. It separates cached and uncached input so you can compare a cold call, a warm call and a broken-cache call. Use official source-checked rates for the exact model, currency and region you deploy.
from dataclasses import dataclass
@dataclass
class Rate:
input_per_m: float
cached_input_per_m: float | None
output_per_m: float
source: str
checked_at: str
DEEPSEEK_V4_FLASH = Rate(
input_per_m=0.14,
cached_input_per_m=0.0028,
output_per_m=0.28,
source="https://api-docs.deepseek.com/quick_start/pricing/",
checked_at="2026-08-01",
)
GLM_5_2 = Rate(
input_per_m=1.40,
cached_input_per_m=0.26,
output_per_m=4.40,
source="https://docs.z.ai/guides/overview/pricing",
checked_at="2026-08-01",
)
def estimate(rate: Rate, cached_input: int, uncached_input: int, output: int) -> float:
cached_rate = rate.cached_input_per_m if rate.cached_input_per_m is not None else rate.input_per_m
return (
cached_input / 1_000_000 * cached_rate
+ uncached_input / 1_000_000 * rate.input_per_m
+ output / 1_000_000 * rate.output_per_m
)
cases = {
"cold": (0, 97_000, 2_000),
"warm": (95_000, 2_000, 2_000),
"broken_cache": (0, 97_000, 2_000),
"verbose_answer": (95_000, 2_000, 20_000),
}
for name, tokens in cases.items():
ds = estimate(DEEPSEEK_V4_FLASH, *tokens)
glm = estimate(GLM_5_2, *tokens)
print(f"{name:14s} deepseek=${ds:.6f} glm=${glm:.6f}")
When you run this pattern against your own prompts, save the result next to the evaluation fixture. A price estimate without a prompt shape is abstract. A prompt shape without a price estimate is risky. Together they let product, engineering and finance discuss the same workload instead of arguing about a generic per-token chart.
Operational rules
- Keep reusable context stable and early in the prompt.
- Move user-specific values, timestamps and trace IDs after the reusable prefix.
- Cap output tokens for extraction, classification and routing tasks.
- Measure cache-hit tokens from provider usage data whenever available.
- Store model ID, region, checked date and source URL with every rate.
- Re-run budget fixtures after provider pricing, model names or prompt templates change.
- Alert when cache-hit ratio falls, because the same feature can become much more expensive overnight.
The bigger lesson is that cache pricing turns prompt engineering into cost engineering. A stable 100,000-token prefix can be reasonable when cache hits are reliable and disastrous when every request is cold. If you are building with DeepSeek, GLM, Qwen or Kimi through a single gateway, make cache behavior a first-class metric in your dashboard. The team that watches cache-hit ratio will find cost bugs days before the invoice arrives.