Legal document token cost estimator
Running contracts and filings through an LLM is increasingly common for summarisation, clause extraction, and risk triage — but per-document cost adds up fast, and long legal text often brushes against model limits. This estimator counts the tokens in your document, projects the output tokens your task will generate, and prices the analysis across common models so you can budget and choose between a single long-context call and a chunked pipeline.
How it works
You paste the document and pick an analysis task. The tool estimates input tokens using a legal-aware characters-per-token ratio, then projects output tokens by scaling against the task: a summary emits a fraction of the input, while full clause extraction or a redline can match it. It multiplies input and output token counts by each model’s input and output prices to give a per-analysis cost, and checks whether input plus expected output fits a single call or needs chunking. All of this happens locally — the text never leaves your browser, which is essential for confidential material.
Why legal text tokenises differently
Legal English tokenises at a slightly lower character-to-token ratio than general prose. Dense defined terms ("Intellectual Property Rights", "Material Adverse Change"), enumerated sub-clauses, and extensive cross-references produce longer words and compound noun phrases that each consume more token units than conversational English of equivalent character length. The tool applies a legal-aware adjustment to account for this, producing a token estimate that is typically closer to the real tokeniser count than a generic 4-characters-per-token heuristic.
Output tokens by task type — what to expect
The expected output length varies significantly by task:
| Task | Typical output ratio |
|---|---|
| Executive summary | 3–8% of input |
| Section-by-section summary | 15–25% of input |
| Clause extraction (structured JSON) | 30–60% of input |
| Risk flagging (top issues only) | 5–15% of input |
| Full redline / tracked changes | 80–120% of input |
| Q&A over the document | Varies by question depth |
Getting this right matters because output tokens are typically priced at 3–5× the input rate. For a 50,000-token contract, a clause extraction task that emits 40% as output (20,000 output tokens) costs far more than a summary that emits 5% (2,500 output tokens) — even before considering which model you use.
Long-context call vs chunked pipeline
The tool flags when a single call is inadvisable due to document length relative to the model’s context window, or when the expected input-plus-output approaches the window limit. The general guidance:
- Single long-context call — simpler to implement, fewer API calls, but long-context recall can degrade on complex reasoning tasks in very long documents. Good for summarisation and high-level risk triage.
- Chunked pipeline — more reliable for clause-level citation and extraction, produces auditable per-section outputs, allows retries on specific sections. More complex to build, but more trustworthy for detailed review tasks.
Tips and notes
- Keep it local for privilege. Counting here is offline; only your eventual real API call sends data to a provider. Check your firm’s data-processing agreements before sending client-confidential text to any API.
- Match the task. Picking “Q&A” when you actually need clause extraction will underestimate output cost significantly.
- Chunk for citations. Clause-level extraction is more reliable and auditable when each section is its own call with a traceable output.
- Not legal advice. Use AI output as triage for a qualified reviewer, never as a final legal opinion. LLMs miss nuance, misread defined terms, and hallucinate clause numbers.