Use case
The best API for document summarisation
Summarisation is the most input-lopsided workload there is — a long document goes in and a few hundred tokens come out — so the input rate is effectively the whole bill and the output rate barely registers; DeepSeek V4 Flash carries the lowest input rate of any generation model we serve and is the right default for any document that fits its context window.
The token shape is the argument. A report goes in whole and a paragraph comes out, so for every token you are billed on output you are billed on tens of input. Comparing models on their headline output rate — the number most pricing pages lead with — ranks them by the smaller half of the bill.
The one thing that overrides the input rate is context. A document longer than the model's window has to be chunked, summarised in pieces, then summarised again — which re-reads the same text twice and adds a second round of input tokens. Past a certain document length, paying for a larger context window is cheaper than paying to read the document more than once.
What actually matters here
- Input rate
- The document is the request. On this workload the input column is almost the entire monthly total, so the cheapest input rate you can accept wins outright.
- Context window
- It decides whether a document is one call or a map-reduce. Chunking is not free — it re-reads the source and adds an extra pass, so the window is a cost decision before it is a capability one.
- Faithfulness over fluency
- A summary that invents a figure is worse than no summary. This is the workload where a cheaper model fails silently rather than loudly, so it has to be checked on your own documents rather than assumed.
- Batch tolerance
- Almost nothing here is interactive. Latency can be traded away entirely, which removes the usual reason to pay for a faster tier.
What it costs, at 20,000 documents/month, ~40K tokens each
Worked from this catalogue’s published rates at 800M input and 16M output tokens a month. Your figure will differ; the arithmetic will not.
| Model | Input | Output | Per month | At official rates |
|---|---|---|---|---|
| DeepSeek V4 Flash36% | $0.090/M | $0.18/M | $74.88 | $116.48 |
| DeepSeek V4 Pro37% | $0.28/M | $0.55/M | $232.80 | $361.92 |
| Kimi K340% | $1.85/M | $9.00/M | $1,624.00 | $2,640.00 |
Excludes cached-input savings, which on a repeated-prefix workload typically reduce the input column substantially. Cached rates are published per model on the pricing page.
Questions
- Is a bigger context window worth paying for?
- Only when your documents actually exceed the smaller window. Below that line you are paying a much higher input rate for capacity you never use; above it you are paying a lower rate to read the same document twice. Measure your document length distribution before choosing — the answer is usually that a small tail of long documents should be routed to the long-context model and everything else should not.
- Does cached input help here?
- Less than on agent or chat workloads. Your instruction block repeats and can be cached, but it is small next to the document, and the document itself is different every time — so the cacheable share of input is the part that was already cheap.
- Should I summarise in one pass or map-reduce?
- One pass whenever the document fits, because map-reduce bills the source text once per chunk and then bills the intermediate summaries again in the reduce step. Map-reduce is a workaround for a context limit, not an optimisation.
- Can I run this asynchronously?
- Yes, and you should. Nothing about summarisation needs a low time to first token, so you can queue the work, run it at whatever concurrency your rate limit allows, and pick the model on price alone rather than on latency.