The Cheapest Token Is the One You Never Send

When an analyst wants to pull a few key figures out of an investment prospectus (the expense ratio, the minimum investment, the top holdings), the fastest method is to hand the whole document to an LLM and ask. It may not be great at recognizing document structure or layout, but it returns the data on the first try, and it feels like magic.

Reaching for the model by default is one of the most expensive habits you can build. The bill hides in plain sight.

You pay twice. First, for everything the model must process to find a handful of relevant figures. Then again for the response it generates. A prospectus is packed with content that adds cost but little value to the task at hand: charts, images, metadata, and pages of legal boilerplate. Add the model's preamble and explanations, and you're paying for even more tokens that don't contribute to the answer. Two meters running, both billing for content you never needed.

For one analyst pulling one prospectus, that waste is a rounding error. But that's rarely where it stops. The moment a developer embeds that same extraction process into a pipeline, set to run unattended across endless documents, the rounding error compounds. Across a few hundred thousand documents a month, it's a line item.

Cost = (input tokens × input price) + (output tokens × output price) + any special charges (reasoning, caching, retrieval).

When working with the LLM, the unit of compute is the token. The price per unit is your per-token rate. The only term you control on a given call is how many tokens your query requires.

You don't get to negotiate the per-token price. You do get to decide how many tokens you send, and that's where nearly all the recoverable waste lives.

On a typical "dump it in" call, the tokens fall into two piles, and neither is doing work for you.

The input pile is everything you paid the model to read. A web page is mostly navigation, scripts, styling, and markup. A PDF transformed to text carries elements that repeat on every page, such as headers and footers, plus whole irrelevant sections. An API response is wrapped in envelopes and metadata. You pay the per-token rate to push all that information through the model, so it can find the small part that mattered.

The output pile is what you paid the model to write. Ask in plain language, get plain language back: "Sure! Based on the document, the values you're looking for are…". You wanted three fields of structured data. You paid for a paragraph.

The cheapest token is the one you never send.

Every move below is a variation on that idea. Right sizing your model helps. A lower per-token rate helps. But the largest, most reliable savings don't come from paying less per token. They come from there being fewer tokens to pay for, because you did the important, deterministic work of deciding what the model needed to see before you ever called it.

Most documents have structure. Tables, sections, fields, layout, that code can resolve without ever calling the model. A deterministic engine reads a page's geometry, finds the table, and isolates the relevant section, all for zero tokens. Save the LLM for the reasoning: comparing values, summarizing them, answering something that spans them. Hand it the structured result, not the raw document.

Constrain the output. When you call the model, bind it to a tight schema, so it returns the fields and nothing else.

Apryse Smart Data Extraction reads a page's geometry with a deterministic layout engine, not an AI one. That means it reconstructs a document's structure the same way every time. Purpose-built models then interpret what that structure means. They're trained specifically on high-stakes documents like contracts and forms, not general use.

The result: the LLM only sees what it needs. The expensive, token-burning work of finding what's relevant happens first, deterministically, for the cost of ordinary CPU time.

That matters for PII. Send the LLM only the data it needs, and the cheapest path and the most private path become the same one.

The tokens you never send are tokens that never leave your environment.

The table below shows processing costs for a financial prospectus at scale, comparing three approaches: sending raw documents to an LLM, pre-filtering the data, and then sending just the extracted, relevant data.

This is the LLM inference bill only. It does not reflect total cost of ownership, which depends on your volume, Apryse license, and server costs. Priced at GPT-5.4 standard API rate ($2.50/1M input tokens, $15/1M output tokens)

The per-document gap multiplies, and the cheaper path's curve grows slowly, because you're not paying a markup on noise a million times over. The dump-it-in path's curve climbs with every document.

That gap isn't a rounding error. It's the difference between a feature that's cheap to run at scale and one that eventually eats its own margin.

LLMs are precision instruments, not a bulk processor. Feed it the smallest, cleanest input that does the job, make it deliver exactly what you want, and let deterministic code do the heavy, repetitive structural work it was always better at.

Smart Data Extraction is an add-on module for the Apryse Server SDK. Get your free trial key at dev.apryse.com.

Full documentation: docs.apryse.com/core/guides/smart-data-extraction