DeepSeek API Cost Calculator: Tokens, Cache & Peak Hours

What the estimate is based on

The calculator multiplies your usage by DeepSeek's published per-token prices. Nothing is measured and nothing is sent anywhere: all the arithmetic runs in your browser, and you can see every number it uses.

The two models listed are deepseek-flash and deepseek-v4-pro; per the pricing page, the legacy deepseek-v4-flash names are billed at the Flash price.

DeepSeek bills input and output tokens separately, bills input tokens that were served from its context cache at a much lower rate than input tokens that were not, and charges half price outside peak hours. The estimate keeps those four ingredients visible instead of hiding them behind one averaged rate.

The formula

For one request:

cost = ( input × hit%       × cache-hit price
       + input × (1 − hit%) × cache-miss price
       + output             × output price ) ÷ 1M

Then, with peak% as the share of requests in peak hours:

blended = cost(peak prices) × peak% + cost(off-peak prices) × (1 − peak%)
monthly = blended × requests per day × active days per month

Values above 100% are clamped, empty or invalid fields count as zero, and the result is never negative.

A worked example

Take a session whose requests carry 100k input tokens, 80% of them cache hits, and 2k output tokens, on deepseek-flash at off-peak prices (0.003 USD per million for cached input, 0.15 for uncached input, 0.6 for output):

• cached input: 80k tokens × 0.003 ÷ 1M = $0.00024
• uncached input: 20k tokens × 0.15 ÷ 1M = $0.003
• output: 2k tokens × 0.6 ÷ 1M = $0.0012
• per request: $0.00444

At 50 requests a day for 20 days a month, that is $4.44 a month. Drop the cache-hit share to zero and the same workload costs $16.20 a month, about 3.6 times as much. The "What the cache is worth" block on the calculator shows that curve for your own numbers.

Why input tokens dominate

In a chat you type a sentence. In an agent session every call carries the system prompt, the conversation so far and the results of every tool call, so a request that looks small to you can carry tens of thousands of input tokens. The output, by contrast, is usually a fraction of that.

This is why the biggest levers are usually on the input side: keeping a stable prefix so the cache keeps hitting, and keeping the context short. The token optimization guide and the context compaction guide cover both, and the usage tracking guide shows how to read the numbers from a real session.

What moves the bill most

1. Cache-hit share. The cached rate is a small fraction of the uncached one, so this is often the largest lever.
2. Request volume and context size. Cost scales linearly with both.
3. Model. The comparison block prices the same workload on each model.
4. When you work. Peak hours cost twice as much. If you can move heavy sessions outside the peak windows, the bill drops accordingly.

Limits

• The prices are a dated snapshot. Check the pricing page before relying on a number, and edit the table if it has changed.
• The calculator models the token prices only. It does not know about top-up bonuses, taxes, currency conversion or any plan other than pay-per-token.
• It uses one average request. Real sessions vary a lot between a small question and a large refactor; for a budget, use averages from a real week.
• Starting values are illustrations, not measurements of a typical user.

Frequently asked questions

How accurate is the estimate?

It is arithmetic on two things: the numbers you enter and the prices in the table, which were copied from DeepSeek's pricing page on 2026-11-13 and can be edited. It is as accurate as those inputs. It is an estimate, not a quote and not a bill.

Where do I find my token counts and cache-hit rate?

In the usage numbers your harness or the API reports. Every DeepSeek Harness session has a status bar under the composer that totals input and output tokens and the cache-hit rate; the usage tracking guide shows where. Start from a real session if you can; the pre-filled values are only illustrations.

Why are the input tokens per request so large when I only type short messages?

An agent resends the whole accumulated prompt on every call: the system prompt, the conversation so far and every tool result. The input of one request is therefore the entire context, not your last message. That is why the cache-hit share matters so much.

What counts as peak hours?

Per DeepSeek's pricing page on 2026-11-13, peak is 01:00-04:00 and 06:00-10:00 UTC on weekdays, excluding Chinese public holidays. Every other hour is off-peak, at half the price. Enter the share of your requests that fall into peak hours; about 21% if your use is spread evenly through the week.

Are the prices up to date?

They were checked on 2026-11-13 and the date is shown beside the table. Prices change, so every value is editable and the pricing page is linked. If the official numbers differ from the table, trust the official page.

Related

• Token optimization, context compaction and usage tracking
• Plugin install command builder