Context Trimming Savings Calculator

Turns a prompt reduction into a monthly figure, including the case where trimming the prefix costs you the cache discount.

Requests per month

Input tokens per request nowEverything you send: system, history, retrieved context, tool schemas

TrimShare of the input you expect to remove

Output tokens per requestAssumed unchanged by trimming

Input rateUS dollars per 1,000,000 tokens. Example figure — replace it with yours.

$/1M

Output rateUS dollars per 1,000,000 tokens. Example figure — replace it with yours.

$/1M

Share of input served from cache0 if you do not use prompt caching

Cached input rateUS dollars per 1,000,000 tokens. Example figure — replace it with yours.

$/1M

Does the trim change the cached prefix?Editing anything before the cache boundary invalidates it

Saved per month

$1,920

$0.0096 per request, $23,040 a year, 32.0% off this workload's bill.

Input tokens before: 8,000
Input tokens after: 4,800
Tokens removed per request: 3,200
Effective input rate before: $3.00 /1M
Effective input rate after: $3.00 /1M
Input cost per request before: $0.02
Input cost per request after: $0.01
Output cost per request (unchanged): $0.0060
Total per request before → after: $0.03 → $0.02
Monthly bill before → after: $6,000 → $4,080
Annual saving: $23,040

What this assumes: the trim is spread evenly across cached and uncached tokens, and the output length does not change. Both are optimistic. Cached tokens are the cheap ones, so removing them saves less than removing uncached ones; and a shorter prompt sometimes produces a longer answer, because the model has less to anchor on. Cache writes are not priced here — if your provider charges a premium to write the cache, a trim that rewrites the prefix pays that premium again. A month is 30 days.

Why the saving is usually smaller than the trim

Cutting 40% of the prompt does not cut 40% of the bill. It cuts 40% of the input half of the bill, and on most workloads the input half is not the expensive half — output tokens are typically priced several times higher per token, so a request with a long prompt and a short answer can still be output-dominated. The line to read here is the total per request before and after, not the token counts.

The second trap is the cache. Prompt caching works on a stable prefix: the provider matches the leading tokens of your request against something it kept, and charges a reduced rate for the part that matched. Trimming is an edit, and an edit before the boundary invalidates everything after it. That is why this tool asks whether your trim touches the prefix. If it does, the tokens you keep move back to the full rate, and a trim that looks like a 40% saving can be a net increase — the calculator will show that as a negative, which is the honest answer. Trim from the middle or the end, or re-order so the volatile part is last, before you trim at all.

What is not costed: quality. Context you remove was presumably there for a reason, and the failure mode of over-trimming is a model that answers confidently from less information. Run the trimmed prompt against whatever eval you have before you deploy the saving, and treat this number as the upper bound on what the change is worth.

Context Trimming Savings Calculator

Why the saving is usually smaller than the trim

The reasoning behind this

Related tools