New AI products do not consume tokens in a straight line. They ramp, slowly at first, then steeply, then they level. Here is the buyer side guide to modeling that curve and phasing your Anthropic commitment so you never pay ahead of real adoption.
When a team launches a feature built on Claude, the instinct is to forecast its token consumption as a flat monthly number multiplied out across the term. That instinct is almost always wrong, and it is expensive. New AI products do not consume on a flat line. They follow a ramp: low consumption in the early months while adoption is thin and the product is still being tuned, a period of accelerating growth as usage spreads and the feature proves itself, and eventually a plateau as the addressable demand is saturated. Commit against a flat average of that curve and you overpay heavily in the early months, when real usage is a fraction of the commit, and you may still fall short later if the plateau lands higher than you guessed. Understanding the shape of the ramp, and phasing your commitment to match it, is the difference between a commit that tracks reality and one that bleeds money at both ends.
The ramp exists because adoption is a process, not an event. A new feature ships to a subset of users first, or behind a flag, or to a single business unit before it rolls wider. Even when it is available to everyone, people discover it gradually, habits form slowly, and the workflows that drive heavy usage take time to settle. On top of that, the early version of any AI product is usually inefficient: prompts are longer than they need to be, the wrong model is doing work a cheaper one could handle, caching has not been implemented yet, and retries are more common while the system is still being hardened. So early consumption is suppressed by thin adoption and inflated per request by immaturity at the same time, and as the product matures those two forces pull in opposite directions. Adoption rises, which pushes volume up, while optimization improves, which pushes the cost per request down. The net curve is a ramp that is steeper in the middle than at either end, and a flat forecast captures none of that shape.
It helps to break the ramp into three phases and model each separately. The first is the launch phase, typically the opening months, where consumption is low, volatile, and dominated by a small group of early users and internal testing. Commitments made against this phase should be minimal, because the data is noisy and the temptation to extrapolate a steep early trend into a permanent one leads straight to overcommitting. The second is the growth phase, where adoption accelerates and consumption climbs fastest. This is the hardest phase to forecast because the slope depends on how the product spreads, and it is where a modeled range matters most, since the difference between the conservative and aggressive cases is widest here. The third is the maturity phase, where growth slows and consumption settles toward a plateau set by the saturated user base and the optimized per request cost. The plateau is the number that matters most for a multi period commitment, because it is the level your steady state usage will actually sit at, and it is usually far below a naive projection of the growth phase trend and somewhat above the launch phase floor.
The single most common ramp mistake is taking an estimate of mature usage and committing to it from day one, as a flat figure across the whole term. Picture a product that will plateau at a meaningful monthly spend but takes most of a year to get there. If you commit to the plateau number from the start, you spend the entire launch and early growth period paying for tokens you are nowhere near consuming, and on most Anthropic agreements that unused commitment does not roll forward or refund, it simply disappears at the end of each period. You have effectively prepaid for adoption that had not happened yet, and handed back the difference. The mirror image is just as costly: commit too low because the launch data looked thin, and when the growth phase arrives you blow through the commit and pay overage at a rate you never negotiated. Both errors come from forcing a curved reality onto a flat commitment, and both are avoidable once you model the shape.
The answer is to phase the commitment so the committed level rises with the ramp rather than sitting flat above or below it. This is the commit ramp, and it is one of the most valuable structures you can negotiate into an Anthropic agreement for a new product. Instead of a single committed number for the term, you agree to a schedule: a low commitment in the launch period that matches the thin early usage, a stepped increase as the product enters its growth phase, and a higher committed level once it reaches maturity. Each step is sized against the modeled consumption for that phase, so the commitment tracks the curve instead of fighting it. The benefit is that you stop prepaying for demand that has not arrived, while still giving Anthropic the growing committed spend that justifies a strong rate. A phased commit is harder to negotiate than a flat one, because it asks the account team to accept lower committed revenue in the early periods, but it is exactly the structure a new product needs, and the savings in the launch and growth phases are substantial.
The challenge with a brand new product is that you do not yet have its own usage history to model from, which is precisely why launch phase data is so unreliable. The way through is to anchor the curve on comparable products you have already shipped. If your organization has launched AI features before, their adoption curves are the best available guide to how the new one will ramp, and even a rough analogue is better than a flat guess. Look at how long previous features took to reach their plateau, how steep the growth phase was, and where consumption settled relative to the early months. Use that shape to build the ramp for the new product, then scale it to the new product's addressable audience. Where you have no internal analogue, the discipline is to commit conservatively in the early phases and rely on a well negotiated overage rate to catch any upside, rather than committing to an aggressive ramp you cannot yet support with data. The principle holds throughout: commit to what you can defend, and structure the deal so the upside is caught by overage rather than by a speculative commitment.
A ramp model that ignores optimization will overstate the plateau, sometimes badly. As a product matures, the team typically implements the efficiency work that was skipped at launch: routing routine requests to Sonnet and Haiku instead of running everything on Opus, adding prompt caching to take up to ninety percent off repeated context, and moving asynchronous jobs into batch at roughly half the real time rate. These changes pull the per request cost down even as volume climbs, which flattens the top of the ramp. So the plateau you commit against should reflect the optimized per request cost, not the inefficient launch cost projected forward. A buyer who models the ramp on the assumption that early inefficiency persists will commit to a plateau far above where optimized steady state usage lands, and will forfeit the difference. The right sequence is to plan the optimization work as part of the product roadmap, model the ramp with that optimized cost baked into the maturity phase, and commit to the leaner plateau, because that is the number the product will actually consume once it is both fully adopted and properly tuned.
A ramp forecast is a hypothesis, and the product will test it month by month. The buyers who handle new product commitments well treat the model as a living instrument rather than a one time document. Each period, compare actual consumption against the modeled curve and note where the product is tracking ahead or behind. If adoption is outpacing the model, you have early warning to plan the next commit step or to prepare for the maturity band sooner than expected. If it is lagging, you know the plateau may land lower than forecast, and you can adjust the later steps of the phased commit downward at the next opportunity rather than committing into a level the product will not reach. This live tracking is also your evidence base for any mid term conversation with Anthropic, because a buyer who can show that real consumption is following a modeled curve has a credible, data backed case for adjusting the commitment, while a buyer working from a stale flat forecast has nothing but an assertion. The ramp model, kept current, turns the uncertainty of a new product from a liability into a managed position.
For a new product, the overage rate is not a detail, it is the safety valve that makes a conservative commit possible. The whole logic of phasing the commitment low in the launch and growth phases depends on having a sensible way to pay for the consumption that exceeds your committed level when adoption runs ahead of plan. If overage is billed at a punitive premium, then undercommitting becomes dangerous and you are pushed back toward the high flat commit that wastes money in the early months. If overage is billed at the committed rate, the calculus flips entirely: you can commit toward the conservative edge of every phase, confident that any upside is simply billed at the same rate you would have paid anyway. This is why, for a ramping product, negotiating the overage rate matters as much as negotiating the commit itself. The two terms work together. A low phased commit paired with overage at the committed rate gives you the best of both, you stop prepaying for adoption that has not arrived, and you are not penalized when it arrives faster than expected. A buyer who negotiates only the commit and ignores the overage rate has done half the job, and the half they skipped is the one that protects the upside of a product that is, by definition, uncertain in how fast it will grow.
Sometimes the product outruns the model, and the plateau settles well above what the ramp predicted. This is a good problem, but only if the agreement was structured to handle it, and it is worth planning for before it happens. Three structures help. The first is the overage rate at the committed level, already discussed, which absorbs consumption above the committed steps without penalty. The second is a renegotiation trigger, a provision that lets you reopen the commitment when consumption crosses a defined threshold, so that a product which has clearly exceeded its forecast moves to a new, higher commit band on terms you negotiate rather than on overage indefinitely. Crossing into a higher band is usually where the better rates live, so a product that has genuinely outgrown its commit should be moved there deliberately rather than left running at overage forever. The third is simply keeping the model live, so that the moment actual consumption signals a higher plateau, you have the data to act on it rather than discovering it in an invoice. A plateau above forecast should be an opportunity to negotiate into a better band from a position of demonstrated demand, not a surprise that leaves you paying overage on a commit that no longer fits the product. The buyers who handle the upside well are the ones who built the structures to capture it before the product had proven how big it would become.
Get a quote for a bounded engagement. Fixed fee or gainshare, no risk to you.
Get a QuoteWeekly intelligence on Anthropic pricing moves and the buyer side counters that work.