What does it actually cost to summarize a 300-page PDF with AI?

By LW Forge — maintainer of LLM Scout · Updated July 27, 2026

"Just paste it into ChatGPT" works fine for a five-page memo. For a 300-page report, the question changes shape: does it even fit in one request, what does the API actually charge for it, and when does the free tier stop being an option? This article does that math in the open, using the same assumptions our PDF summary calculator runs on.

The token math, page by page

A dense, text-heavy page — think a contract or a research report, not a slide deck — runs around 400 tokens once tokenized, plus a small fixed overhead (roughly 150 tokens) for the summarization instructions themselves. A 300-page document lands at approximately 300 × 400 + 150 ≈ 120,000 input tokens.

Output is the smaller side of the ledger: a genuinely useful summary of a document that size tends to run around 10-15% of the input length once you account for compression — call it roughly 14,000-15,000 output tokens for a summary with real substance, not a two-line blurb.

Does 300 pages even fit in one request?

Yes, comfortably, on nearly every current model. At around 120,000 tokens, the document uses about 60% of Claude's 200k context window and roughly a tenth of GPT-5.6's 1.05M window — plenty of headroom left for instructions and the model's answer. You don't need to chunk a document this size for it to fit; chunking becomes a real question in the 500-1,000+ page range, or for models with much smaller context windows. Check exactly how many pages fit at a given model's limit in how many pages fit in GPT.

What it actually costs

Plugging 120,000 input and roughly 14,500 output tokens into current per-model rates lands the single-summary cost somewhere in the 20-cent to just over $1 range, depending on tier: a budget model comes in under a quarter, a flagship-tier model comes in around a dollar. Run your own numbers — including your document's actual page count — in the PDF summary calculator, which uses this same per-page estimate.

Two things move that number more than the model choice does. First, document density: a slide deck or a form with lots of whitespace can run well under 400 tokens per page, while dense legal text, tables, or embedded code can push past 600-700 — measure your actual document with the token calculator rather than trusting the average. Second, how many times you ask: the model is stateless, so a follow-up question re-sends and re-bills the entire document, not just the new question. Ten follow-up questions on one PDF cost roughly ten times the input, even though nothing about the document changed.

Volume changes the picture too, and predictably: summarizing one 300-page report a month is a rounding error on any budget, but a pipeline that ingests hundreds of similar documents a day turns that same per-document cost into a real monthly line item — worth modeling explicitly if that's your use case, since it's simple multiplication once you know the per-document number.

Free vs. paid, honestly

The chat apps (ChatGPT, Claude.ai) will summarize a 300-page PDF for free or as part of a flat monthly subscription, and for occasional, one-off use that's the right tool — there's no reason to write API code to summarize a document once. The tradeoffs show up at volume: free and subscription tiers cap file size and the number of uploads or messages you get in a period, and once you're summarizing dozens of documents a day, a pay-per-token API becomes both cheaper and less rate-limited than a human clicking through a chat UI. The API also lets you automate the pipeline — batch-summarize a folder overnight, for instance — which the chat interface simply isn't built for.

There's a middle case worth naming: a handful of long documents a week, done by a person, not a script. That's usually still cheaper and less friction on a subscription than building anything — the API only starts winning once the task is repetitive enough to be worth automating in the first place.

Single pass vs. hierarchical summaries

A single request that reads the whole document and produces one summary is the cheapest option and works well for documents with a clear throughline — a report with one argument, a single contract. For documents that are really several distinct sections stitched together (an annual report with unrelated departmental chapters, a compiled research corpus), a single flat summary tends to flatten nuance: minor sections get crowded out by whatever the model judged most salient.

The alternative is hierarchical (map-reduce) summarization: summarize each section separately, then summarize the summaries into a final synthesis. It preserves detail better at the cost of roughly 1.5-2.5x the tokens of a single pass, because you're paying the summarization overhead once per section plus once more for the final combination. Reach for it when the document's sections are genuinely independent; skip it when a single-pass summary already reads coherently.

Run your own document through the numbers

Page count and density are the two inputs that matter — everything else follows from them. Estimate your document's real token count with the token calculator, then price out the summary across models in the PDF summary calculator. If the document is close to a model's context limit rather than comfortably under it, how many pages fit in GPT and the context window calculator will tell you exactly where that ceiling sits.