A volume commitment trades a discount for a floor on what you pay. The discount is quoted; the floor is where the money is. This works through the structures these clauses take and derives what each one costs at any level of actual usage, from placeholders you substitute with your own figures.
No real prices or discount rates appear on this page. Every figure below is a placeholder you replace with the numbers in front of you. Commercial terms are negotiated per customer and change without notice, so a quoted rate here would be wrong for almost every reader. This is also not legal or financial advice.
The four structures
Commitments in inference contracts are usually one of these, sometimes combined. The differences matter more than the headline number.
- Prepaid credits with an expiry. You pay up front, draw down against usage, and unused balance expires at the end of the term. Simple, and the harshest on shortfall: unused credit is simply gone. Ask whether expiry is at term end or rolling, and whether unused balance rolls over on renewal — rollover conditioned on renewing is a renewal incentive, not a refund.
- Annual minimum with a true-up. You commit to spend at least some amount over the term. If actual usage falls short, you are invoiced the difference at the end. Economically identical to prepaid credits with no rollover, but the cash flow is later and the shortfall is visible as a line item, which is politically different inside a company.
- Tiered rate card. The unit rate depends on the volume band you land in, assessed monthly or annually. There may be no explicit commitment at all — the “commitment” is that dropping a band raises your rate retroactively or prospectively. Ask which, because retroactive re-rating turns a quiet month into a surprise invoice.
- Ramped multi-year commitment. A commitment that increases each year of a multi-year term. These are the ones to model carefully: year one is usually comfortable and set against a forecast, and year three is a number somebody guessed while optimistic.
Two secondary terms modify all four. The overage rate is what you pay above the committed volume — check whether it is the committed rate or list, because a commitment that reverts to list on overage punishes growth as well as shortfall. And what counts toward the commitment: whether fine-tuning, embeddings, batch usage, storage and support fees draw down the same pool, or whether only one product line does.
The arithmetic
Four placeholders, all of which you take from your own agreement and your own telemetry. Name them explicitly because every result below is a function of these and nothing else.
L = list price per unit (from the public rate card)
d = committed discount, as a fraction (e.g. 0.20 for 20% off)
C = committed spend over the term (the contract's floor, in currency)
U = actual usage over the term, in units (from your own logs, forecast)
What you pay under the commitment is the greater of the floor and your discounted usage:
pay_committed = max(C, U * L * (1 - d))
pay_list = U * L
The break-even usage is the point where discounted usage exactly reaches the floor. Below it you are paying for units you did not consume:
U* = C / (L * (1 - d))
That formula is the whole page in one line, and its shape is worth noticing: the deeper the discount, the higher the usage you need to break even against the same commitment, because each unit draws down the floor more slowly. A larger discount attached to a larger commitment is not automatically a better deal, and comparing two offers on discount alone is comparing them on the wrong number.
What a shortfall actually costs
Define utilisation as the fraction of the floor you actually consume:
u = (U * L * (1 - d)) / C // 1.0 means you exactly hit the commitment
When u is below 1 you still pay C, so your effective rate per unit is the committed rate divided by utilisation:
effective_rate = C / U = L * (1 - d) / u
u = 1.00 -> effective_rate = L * (1 - d) the quoted rate
u = 0.80 -> effective_rate = L * (1 - d) / 0.8
u = 0.50 -> effective_rate = L * (1 - d) * 2
Substitute any discount you like. At half utilisation, a 20% discount produces an effective rate of 1.6 × L — a 60% premium over the list price you would have paid with no commitment at all. At 80% utilisation the same 20% discount nets out to a 0% saving exactly: 1 − d = u is the general condition for a commitment to be worth precisely nothing. Anything below that line is worse than not signing.
Two things follow. First, the break-even utilisation is 1 − d, which is easy to hold in your head: a 20% discount needs 80% utilisation, a 30% discount needs 70%. Second, the sensitivity is asymmetric — overshooting the commitment costs you at worst the overage rate on the excess, while undershooting costs you the entire shortfall. The penalty for guessing high is much steeper than for guessing low, and commitments are almost always sized off a forecast that is optimistic by construction.
Sizing the commitment
- Build the usage forecast from tokens, not from spend. Spend already embeds a price that may change and a model mix that certainly will. Take input, output and cached-input tokens per month from your own logs and forecast those.
- Produce three scenarios, not a number. A pessimistic case, a base case, and an optimistic one. The base case is what product planning believes; it is not what you commit to.
- Commit to the pessimistic case. The asymmetry above is the entire reason. Buy the discount on the volume you are confident about and pay list on the rest — you keep most of the saving and none of the shortfall exposure.
- Subtract what you plan to remove. Prompt caching, a cheaper model on a high-volume path, better truncation, moving a batch workload to a discounted batch endpoint: every efficiency project on your roadmap reduces the usage that services the commitment. Teams routinely commit to a volume and then spend the year successfully engineering their way beneath it.
- Model the tokenizer effect if a model switch is planned. The same text measured by a different tokenizer is a different number of billable units, so a mid-term model change moves your draw-down rate without changing a single request. the bill impact of a tokenizer difference works that through.
- Ask what a shortfall actually triggers. Invoice for the difference, forfeited credits, retroactive re-rating of every unit consumed, or a renegotiation right. These are very different outcomes and the clause will say which.
Commitments and migrations interact badly
The interaction is the reason this clause belongs in a migration cluster at all. A safe provider cutover is gradual: you dual-run, shift a small share of traffic, compare, and increase. Every point of traffic you shift away is usage that no longer services the commitment — so during the migration you pay the new provider for real traffic and the old one for traffic you did not send.
That double-pay window is bounded by the remaining term, not by your engineering schedule, and it is why the commitment end date should be on the same plan as the cutover. Practically: time a migration to start early in a term only if you can absorb the shortfall, or run the comparison on a small percentage of traffic during the term and do the bulk shift at renewal. Where a decision to leave is already made, the shortfall is a sunk cost and should not be allowed to justify staying another term — that is exactly the incentive the clause is designed to create.
The measurement this needs — spend per provider per period, against a committed floor, while traffic is split — is awkward to assemble from two vendor dashboards on different billing cycles with different unit definitions. Multigrid records per-request cost across providers behind one API and one key, so a traffic split during a cutover shows up as one attributable series rather than two invoices you reconcile by hand. The arithmetic on this page is the same either way; the difficulty is only ever getting U.
Before signing, read the commitment together with the exit terms rather than separately: notice period, renewal window and shortfall treatment compose into a single date after which leaving is cheap and before which it is not. The other clauses that set that date are in contract terms worth checking before you commit.
Top comments (0)