How we calculate savings

Last updated July 3, 2026  ·  Questions? support@smashcost.com

SmashCost's success fee is a percentage of the savings figure described on this page. Because that number determines what you're billed, this page documents exactly how it's computed — every input, every exclusion, and every rounding rule — so the calculation is reproducible and auditable from your own request logs.

📐What "savings" means here

Savings is an estimate, not a measured, independently-verified number. For every routed request, we compare two figures:

• Baseline cost — what the request would have cost on the model your application originally asked for (model_requested).
• Actual cost — what the request actually cost on the model SmashCost routed it to (model_used).

Savings for a request is max(0, baseline_cost − actual_cost). The per-request result is capped at zero: if a routing decision happened to cost more than the original model, that request contributes $0 to savings — it is never counted as a negative and never offsets savings from other requests.

🔢Token-equivalence assumption

Both baseline and actual costs are computed from the same input/output token counts for a given request — we do not re-run the request on the baseline model to measure what it would actually have produced. This is a deliberate simplification: SmashCost prices the same token counts against each model's per-1K-token rates, rather than estimating how token usage might differ had the other model generated the response (different models can tokenize and respond with different lengths for the same prompt).

This means the figure is best understood as "what these tokens would have cost on each model," not "what your bill would literally have been if you had never used SmashCost." For the vast majority of routing decisions — where the swapped models are close in capability and response style — this is a close approximation. It is the basis disclosed in your API response as savings_basis: "token_equivalence_estimate".

🚫What's excluded

Not every request counts toward savings. The following are always excluded from the calculation:

• Manual overrides — if your application specifies a model explicitly and SmashCost's routing didn't influence the choice, there is no routing decision to attribute savings to.
• Shadow-mode requests — during the free observation period, traffic runs in passthrough mode. SmashCost computes what it would have routed to for reporting purposes, but these are projections, not billable savings.
• Rollout-excluded requests — traffic held out of routing as a control group for comparison.
• Requests without consent — routing decisions made before routing mode was explicitly activated for a project.
• Requests with no baseline available — if we can't determine what the original model would have cost (e.g. missing pricing data), the request is excluded rather than assumed to have zero or full savings.

🧊Prices are frozen at request time

The per-1K-token input/output prices used to compute both baseline and actual cost are captured and stored at the moment the request is processed. If a provider changes its pricing later, past savings figures are not recalculated — every historical number stays reproducible from what was actually stored on that request's log entry, independent of the current price table.

💵How the success fee is derived

The success fee is 10% of total savings (as defined above) accrued over a billing cycle, billed in arrears. The first 30 days of routing (Month 1) are a fee-free preview: the same savings calculation runs and is shown to you, but the resulting fee is waived — you can see exactly what would have been charged before any fee applies.