Committed Use: When Discounts Are Worth the Lock-In

Every cloud market eventually develops the same second act: the first act is pay-as-you-go, and the second is the commitment — spend a floor, get a discount, lock in a rate. The model market is entering its second act now, and the commitment conversation is arriving with it.

This post is about that conversation: what a commitment actually buys, what it costs in flexibility, and how to read the terms. It is the enterprise sibling of the serverless-vs-dedicated post — that one was about buying capacity; this one is about buying a price.

And the first discipline is the same as everywhere else on this blog: the commitment is a purchase, not a relationship milestone. It deserves the same scrutiny as any other purchase, and more, because it is paid in advance.

Three things, and only one of them is the discount. The discount: a lower per-unit rate in exchange for a spending floor, sometimes tiered, sometimes flat. The rate lock: protection against price movement for the term — the price-list post's dated-snapshot discipline becomes a contract clause. And the capacity signal: a commitment tells the provider your traffic is real, which in a capacity-constrained market can buy scheduling priority that no invoice line shows.

The discount is the headline and the least interesting part. The rate lock and the capacity signal are the parts that matter to a production workload, and they are the parts that are hardest to compare across providers.

And the floor is the fine print: the commitment is a minimum, not a maximum. Spend below it and you pay for tokens you did not use; the discount is the price of that risk.

The arithmetic is a break-even, and it is the same shape as the serverless-vs-dedicated post's crossover: the discount saves money on every token above the floor, and the floor costs money on every token below it. The commitment is worth it when your spend is predictable enough that the floor is a formality and the discount is pure savings.

The honest inputs are your own history, not the provider's projections: your trailing spend, its variance month to month, and your growth plan. The invoice-teardown post's reconciliation habit produces exactly the history this calculation needs.

And the variance is the whole game. A workload that spends the same amount every month is a perfect commitment candidate; a workload that spikes and collapses is buying a floor it will miss. Predictability is the asset being sold, and it is yours to price.

Three classic ways. The floor outruns the product: the commitment was sized for the growth plan, the growth plan was a hope, and the floor becomes a monthly tax on a product that did not grow. The lock-in outlives the market: prices fall during the term — the catalog post's dividend — and the locked rate becomes the expensive rate, which is why commitment terms in this market should be short. And the flexibility loss: a commitment to one provider is a reason not to use the two-line-switch optionality the migration post described, and optionality is worth real money in a market this young.

The common thread: commitments transfer risk from the provider to you, and the discount is the payment for taking it. The question is never "is the discount good" but "is the risk priced correctly for my workload".

The uncomfortable truth of commitment negotiations: the provider has done this more times than you have, and the terms are written by people whose job is the floor. The counterweights you actually have are few and real: your usage history (the invoice-teardown discipline, again), your alternatives (the OpenAI-compatible surface means the exit is cheap, and saying so is leverage), and your willingness to walk.

The terms worth fighting for are not the discount points but the structure: a short term, a floor that starts low and steps with real usage, and a clause for what happens when the provider deprecates the model you committed to — the versioning post's lifecycle, written into the contract.

And the strongest position is the one the vendor-checklist post ends on: the ability to say no. A commitment you can decline is the only kind worth signing.

For most teams, most of the time. On-demand is the price of flexibility, and flexibility is the correct default in a market where prices fall, models change, and traffic is unproven. The commitment is for the moment the workload has proven its shape — the same graduation logic as the serving-modes post, applied to the bill instead of the hardware.

The test is simple: if you cannot predict next quarter's spend within a margin you would bet your own money on, you are not a commitment customer yet. And there is no shame in that — the batch post's whole argument is that unproven workloads deserve pay-per-use.

Commitments are for the steady state. Get to the steady state first, then buy the discount.