Savings
Measured against estimated, effective tokens against raw ones, and why a sub-percent share of effective context is not a small result.
Savings
Savings is what the platform has already captured. Efficiency is what is still on the table. They are different lenses on the same telemetry and the product never pools them.
Measured or estimated
| Kind | How it is computed | Where it is valid |
|---|---|---|
| Measured | Against a holdout control arm -- a fraction of your traffic deliberately served uncompressed. | Team scope only. It is the defensible number. |
| Estimated | Without a control arm: token deltas and blended rates. | Anywhere. Directional, and labelled. |
Per-entity savings -- a person, a service -- are estimated only, never measured. A single person's control arm is often a handful of requests or zero, so a holdout-measured figure at that scope would be noise wearing the authority of a measurement. Person and service panels therefore show ledger-derived estimates, and default to the token view.
A combined headline is allowed only with the split always visible. Wherever the product shows both, it shows them as measured and estimated side by side rather than adding them into one number.
The holdout
The holdout is the fraction of traffic served uncompressed as a control arm, so savings and quality are measured against reality rather than estimated. It is sticky per session, which means it decides which arm a whole conversation lands in.
It runs in both billing regimes. On a subscription the arm costs forgone headroom rather than money, which is what lets the evidence loop cover prepaid traffic instead of carving an exception for it.
While the arms are still filling, the interface says so -- "collecting control arm", with the control and compressed request counts -- rather than showing a number it cannot yet defend.
The two regimes, side by side
The Overview's savings block shows two panels, and their labels are the honest summary of the whole page:
| Panel | Framing | Chip |
|---|---|---|
| Subscription | Flat prepaid seats -- capacity, not billed savings. | Observe |
| Metered | Billed API traffic (API key or BYOK) -- real dollars. | Measured |
The two are reported separately rather than pooled, because pooling them would produce a share of a bill nobody receives.
And a subscription dollar figure is never rendered as measured. A zero there is structural -- no bill moved -- not a measurement that came back empty.
The savings block is team-scoped and not affected by the gateway filter, and it carries that caption permanently. Measured savings cannot be computed at gateway scope, and two differently-sourced "money saved" numbers on one page read as a bug.
Effective tokens
This is the correction that matters most, and it is worth understanding before you quote any savings figure.
A raw token count values every removed token at the full input rate. But a token removed from a warm cached prefix was billed at roughly a tenth of fresh input. Counting it at full rate overstates the saving several-fold.
Effective tokens re-express the count in fresh-input-token units, weighting each token by the price ratio of the billing stream it came from, at its own model's rates.
Measured on real traffic, the raw count reported 0.764% of the provider input bill where the honest figure was 0.0871% -- roughly a ninefold overstatement. That is the same defect class that let a competitor publish "99.8% savings" while an independent paired benchmark measured a 7.6% cost increase.
Four presentation rules follow, and the product honours all four:
- Effective tokens are shown beside the raw count, never instead of it. The gap between them is the evidence; either one alone is an assertion.
- No dollar figure is rendered on subscription traffic.
- The unattributed share is shown.
- "Not priced" is not read as "saved nothing" -- it means the catalogue could not price the window.
On screen the framing pair is Tokens removed and then Worth, in effective tokens.
Share of effective context
Effective tokens saved over the same window's effective input volume.
It is genuinely sub-percent, and it is formatted to survive that -- a whole-percent format would round it to "0%" and restore exactly the dishonesty the measure exists to remove.
It is not a share of a bill. Every model is normalised to its own input-token unit and the results are then summed, so one cheap-model token weighs exactly as much as one expensive-model token on both sides of the division.
Why a sub-percent number is not a small result
Most of the value is recurring. The saving comes largely from the cache-read stream, and those tokens sit in the cached prefix -- so the transform re-fires and removes them again on every later turn of the same conversation.
Measured as the dominant term: roughly 57% to 82% of the value, depending on how un-attributed delta is weighted, so a quoted figure has to say which weight it assumes. That is the story rather than a footnote, and it is the reason a sub-percent share is not a small result. Where it applies, the interface says how much of the saving came from the cached prefix and notes that it is already counted.
Where savings come from
The savings-by-stream view attributes savings to the billing stream each removed token came from:
| Stream | |
|---|---|
| Cached prefix | Where the saving recurs. |
| Fresh input | |
| Cache write | |
| Unattributed | Shown rather than hidden. |
| Unrecognised |
Elsewhere the same ledger is broken out by regime and by provider. Two rules hold across all of them:
- Savings are summed from the compression ledger, never from a raw before-and-after difference. One transform grows input on purpose -- it adds bytes for out-of-request benefit, such as provider cache reuse -- so an unclamped before-after pair produced physically impossible windows: a positive figure at six hours and a negative one at seven days for the same team.
- Tokens used plus tokens saved equals the pre-optimization token volume. Buckets with no traffic are absent, never zero-filled, so a gap in a chart is a gap in traffic.
Cache figures that are not savings
Subscription value is not a saving
What all subscription-seat traffic would have billed on the metered API is reported as plan-fit context, because nobody pays it on a flat prepaid seat.
Do not read it as a saving. It prices all subscription traffic, not a saved portion of it. The interface labels it as value and as informational, never as savings.
Seat-plan cost estimates are likewise a window-prorated public list price applied to observed activity. The gateway cannot tell a departed seat from an idle one -- both are zero requests in the window -- so that figure can overstate real spend when seats have churned. It is informational only.
How savings are earned in the first place
A content-dropping transform does not serve traffic until trailing holdout evidence says it may, per team, workload type and billing regime -- and it demotes automatically when that evidence degrades. See the optimization journey.