DeepSeek API Real Cost: Why Your Bill Is 10x Off (Prompt Caching Explained)

Why Your LLM Bill Is 10x Higher Than It Should Be

When I first started using DeepSeek's API for my AI agent business, I estimated costs based on the published per-token prices. I budgeted accordingly, set my pricing, and thought I had the economics figured out. Then the first real bill came in at 10x my estimate. The problem wasn't DeepSeek's pricing — it was that I didn't understand how prompt caching works, and I was calculating costs as if every token was full price when in reality, most of my tokens were cache hits at 90% discount.

But here's the twist: once I understood caching, I went too far the other way. I assumed 90% cache hit rates on everything, underpriced my service, and nearly went negative on a heavy user. This article covers the real cost model of DeepSeek API usage, including the caching mechanics that most pricing calculators ignore, the peak/off-peak pricing that can double your costs during certain hours, and the actual numbers from running a production AI agent service.

DeepSeek's Pricing Structure

DeepSeek V4 has two model tiers and a time-based pricing multiplier. Understanding all three dimensions is essential:

Model Tiers

Key insight: Flash is 4x cheaper than Pro for input and 4x cheaper for output. For most AI agent use cases (chatbots, content generation, simple analysis), Flash quality is more than sufficient. Only use Pro when you specifically need its stronger reasoning capabilities.

Peak/Off-Peak Pricing

Starting July 2026, DeepSeek introduced time-based pricing:

If your customers are primarily in the US or Europe, their peak usage hours (US daytime = Beijing nighttime) fall in DeepSeek's off-peak window. This is actually advantageous — your costs are lowest when your customers are most active. But if you're doing batch processing, schedule it for off-peak hours to save 50%.

Prompt Caching: The Hidden Discount

This is where most people get their cost calculations wrong. DeepSeek implements automatic prompt caching. When you send a request that shares a prefix with a recent request, the cached portion costs only 10% of the normal input price.

Here's how it works in practice:

# First request — all tokens are cache misses (full price)
System prompt: 2,000 tokens (¥0.5/M = ¥0.001)
User message: 500 tokens (¥0.5/M = ¥0.00025)
Total input: 2,500 tokens at full price = ¥0.00125

# Second request — system prompt is a cache hit (10% price)
System prompt: 2,000 tokens (¥0.05/M = ¥0.0001)  ← 90% discount!
User message: 600 tokens (¥0.5/M = ¥0.0003)
Total input: 2,600 tokens, but effective cost = ¥0.0004

# If you hadn't accounted for caching, you'd estimate ¥0.0013
# Actual cost: ¥0.0004 — a 69% reduction

In a typical AI agent conversation, the system prompt (instructions, personality, context) stays the same across turns. This means:

• First turn: Full price for everything
• Subsequent turns: 90% discount on the system prompt (which is often the largest portion of input tokens)
• Long conversations: Cache hit rate increases as more of the conversation history is cached

Real Production Numbers

Here's actual data from running a production AI agent service for 30 days:

The effective cost of ¥0.058 per million tokens is dramatically lower than the list price of ¥0.5 per million input tokens. This is almost entirely due to prompt caching — in a conversational AI agent, the system prompt dominates input tokens, and it's almost always a cache hit after the first turn.

How to Calculate Your Real Costs

Here's the formula that actually works:

def estimate_cost(
    system_prompt_tokens,
    avg_user_message_tokens,
    avg_output_tokens,
    turns_per_conversation,
    conversations_per_month,
    cache_hit_rate=0.90,
    peak_hour_ratio=0.3
):
    # First turn: all input at full price
    first_turn_input = system_prompt_tokens + avg_user_message_tokens
    first_turn_cost = (first_turn_input / 1_000_000) * 0.5
    
    # Subsequent turns: system prompt at cache price
    subsequent_turns = turns_per_conversation - 1
    subsequent_cost_per_turn = (
        (system_prompt_tokens / 1_000_000) * 0.05 +
        (avg_user_message_tokens / 1_000_000) * 0.5
    )
    subsequent_total = subsequent_turns * subsequent_cost_per_turn
    
    # Output cost (same for all turns)
    output_cost = (avg_output_tokens / 1_000_000) * 2.0 * turns_per_conversation
    
    # Per-conversation total
    conv_cost = first_turn_cost + subsequent_total + output_cost
    
    # Peak hour adjustment
    conv_cost *= (1 + peak_hour_ratio)
    
    # Monthly total
    monthly_cost = conv_cost * conversations_per_month
    
    return monthly_cost

Pricing Your Service Correctly

The biggest mistake I see is pricing based on list prices instead of effective prices. Here's a comparison:

My pricing strategy: calculate costs at the effective rate with caching, then add a 50% margin for safety. This means if my effective cost is ¥0.058/M, I budget as if it were ¥0.09/M. This absorbs unexpected spikes while keeping prices competitive.

Optimizing for Maximum Cache Hits

Since caching is where the savings are, structure your prompts to maximize cache hits:

1. Keep the system prompt stable

# GOOD — system prompt stays the same across all conversations
system_prompt = "You are a helpful customer support agent."

# BAD — including dynamic data in the system prompt
system_prompt = f"You are a helpful agent. Current time: {datetime.now()}."

Any dynamic content in the system prompt invalidates the cache for every request. Move dynamic data to the user message instead.

2. Structure prompts with stable prefixes

# GOOD — stable prefix, dynamic suffix
messages = [
    {"role": "system", "content": STABLE_SYSTEM_PROMPT},
    {"role": "user", "content": f"Context: {dynamic_context}\n\nQuestion: {user_question}"}
]

3. Batch similar requests together

DeepSeek's cache has a TTL (time-to-live). Requests made within the cache window share the cache. If you batch similar requests close together, you get more cache hits.

Peak Hour Scheduling for Batch Jobs

# crontab — run batch processing during off-peak hours
# Beijing time off-peak: 00:00-09:00, 12:00-14:00, 18:00-24:00

# Run content generation at 2 AM Beijing (off-peak)
0 2 * * * /usr/bin/python3 /home/user/batch_generate.py

If your customers are in the US, their peak usage naturally falls in DeepSeek's off-peak window. This is a free 50% discount on your largest cost center.

Conclusion

DeepSeek's real cost is 5-10x lower than list prices suggest, thanks to prompt caching. But you only get those savings if you structure your prompts correctly and understand the peak/off-peak pricing windows. Calculate costs at the effective rate, add a safety margin, and you'll build a profitable AI service. Calculate at list price, and you'll either overprice yourself out of the market or underprice yourself into losses.