---
title: "The best API for document summarisation"
canonical: "https://router.xark.io/use-cases/document-summarisation"
description: "What it costs to summarise documents at volume, why the input rate is effectively the entire bill, and where a long-context model stops being optional."
section: "use-cases"
updated: "2026-09-02"
source: "https://router.xark.io/use-cases/document-summarisation.md"
---

# 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.

**Availability:** 7 of the 24 catalogued models are callable today. The rest are listed at their intended rate but no configured upstream serves them, so a request naming one returns `no available channel`. Every table below marks which is which.

## Why this workload is different

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 when choosing

| Criterion | Why it decides this workload |
| --- | --- |
| 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. |

## Recommended models, priced at 20,000 documents/month, ~40K tokens each

| Model | Our monthly cost | Official monthly cost | Saving | Callable | Document |
| --- | --- | --- | --- | --- | --- |
| DeepSeek V4 Flash | $74.88 | $116.48 | 36% | Yes | [read](https://router.xark.io/models/deepseek-v4-flash.md) |
| DeepSeek V4 Pro | $232.80 | $361.92 | 37% | Yes | [read](https://router.xark.io/models/deepseek-v4-pro.md) |
| Kimi K3 | $1,624.00 | $2,640.00 | 40% | Yes | [read](https://router.xark.io/models/kimi-k3.md) |

## 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.