Less context. What did we actually save?

Start with something another person can count

An agent investigating a week of building measurements could receive every row, two relevant columns, or the readings around a particular event. Those inputs have different sizes. That is a useful observation, but it leaves the harder question open: how much work did the entire investigation require?

Our building-energy replay gives the comparison a concrete starting point. It finds the three consecutive ten-minute energy readings with the largest sum. The saved two-column CSV contains 16,838 tokens. The complete evidence packet contains 529, including its question, source references, selected readings, and limits. Both files are available to inspect and reproduce.¹

The count uses tiktoken 0.11.0 with the o200k_base encoding on the exact UTF-8 text. Headers, delimiters, whitespace, and the trailing newline are included. A tokenizer describes a particular representation; it does not turn a CSV measurement into a provider invoice.²

Choose the baseline before calculating the percentage

The arithmetic is (16,838 − 529) ÷ 16,838 × 100 = 96.8583% less input payload. The unprojected, 29-field CSV is 250,068 tokens. Comparing against that file would produce a larger percentage, but much of the gain would come from removing columns an ordinary query could already exclude.

Even the two-column projection is not the strongest baseline for this question. A short SQL query or Python calculation can return the same maximum without sending the whole column to a language model. The replay therefore demonstrates a compact, inspectable result. It makes zero model calls and does not measure an agent's resolution rate or its total bill.

This is a practical design constraint for Reific: an evidence layer should be compared with an agent that can use appropriate tools. A large raw input is a useful stress test, but it should not be the only alternative in a savings claim. Anthropic's tool-design guidance similarly treats useful response content, token consumption, and task outcomes as things to evaluate together.³

Count the run, including the work that moved elsewhere

A compact first response can lead to a long investigation. The agent may reopen the source, retrieve another interval, retry a failed query, or ask a second model to check the answer. Conversely, a larger response may let it finish in one pass. Save each request's usage record and associate every call with the task that caused it.

Count input and output across all calls, including evidence preparation when it uses a model. Keep cached and uncached input separate when their prices differ. Use the provider's reported accounting for reasoning and other token categories without adding a subcategory twice. Failed and timed-out tasks remain in the ledger; otherwise a system can look cheaper by failing early.

Then account for costs outside the model: source queries, deterministic processing, storage, network transfer, and any recurring preprocessing needed to keep the evidence current. Shared work needs an explicit allocation rule. If an index serves several workflows, charging its whole cost to one task is as misleading as charging none of it.

Quality belongs next to this ledger. Under a fixed rubric, record accepted answers, unsupported answers, justified abstentions, and human corrections. Cost per accepted task can be useful, but show total cost and the number of attempted tasks too. A low price achieved by avoiding difficult questions is visible only when the denominator survives.

Data volume describes the workload, not the token count

Gigabytes matter because they describe what the system must process. They do not determine how many tokens an agent consumes. A compressed sensor file, a verbose JSON export, and a binary array can represent the same measurements with different byte sizes. Querying an aggregate can return a small result from a large store.

For a planning estimate, use data examined per day divided by average data examined per comparable task. Measure both volumes in the same representation and include repeat reads consistently. Ten gigabytes per day divided by 100 megabytes per task gives 100 estimated tasks. These are decimal units: 1 GB = 1,000 MB. Actual task counts are preferable whenever they are available.

Suppose those tasks currently consume 20,000 total tokens each. The estimate is 2,000,000 tokens per day. Applying a hypothetical 40% reduction gives 1,200,000, or 800,000 fewer. This assumes that task mix and tokens per task stay representative as volume changes; it does not establish throughput or a universal bytes-to-tokens conversion.

From tokens to an annual estimate

Annual model-token savings equal saved tokens per day × active days per year × price per million tokens ÷ 1,000,000. With 800,000 saved tokens, 365 active days, and an illustrative blended price of 5 currency units per million, the estimate is 1,460 per year. Model-token spend falls from 3,650 to 2,190 under those assumptions.

A blended price should come from representative billed runs: divide model-token charges by billed tokens and multiply by one million. Using the same price before and after assumes the mixture of input, output, and cache usage remains stable. When it changes, price those categories separately. Vendor fees, infrastructure, taxes, and review effort belong in a net-cost comparison; the token estimate alone is not net ROI.

The landing-page calculator lets you change workload, active days, price, and currency. Enter a price in the currency you select: switching between USD and EUR does not apply an exchange rate. The starting price is illustrative, not a quoted provider rate.

Keep the reported result and the worked example distinct

Across separate benchmarks, Reific's founder reports 50% better resolution and 40% less token burn. The calculations here explain the arithmetic; they do not reproduce those benchmark runs. The public-data replay and illustrative workload are separate. The replay's 96.8583% figure measures serialized input size only.

For the calculator, “50% better” is interpreted as a relative increase: a 40% baseline becomes 60%, a gain of 20 percentage points. The starting rates are illustrative. A measured comparison should publish accepted and attempted task counts, the comparison basis, model and tool versions, complete usage, and failure cases alongside its percentage.

To test the savings on your own workflow, begin with a small set of real questions and keep both arms' complete records. Inspect which steps disappeared, which moved into preprocessing, and which still require an expert. That is the evidence needed to turn a smaller payload into a useful operating decision.