Independent buyer side advisory · Anthropic onlyNew York · London
Home · Blog · Claude API Commitment
Claude API Commitment

The Anthropic commit ramp and how to phase it.

Buyer side guide · 11 minute read

When Anthropic quotes a committed spend deal, the default structure is flat. You agree to an annual number, you start paying against it from month one, and the discount is set against that figure. The problem is that almost no enterprise actually consumes its full annual commitment in the first month, or the first quarter, or sometimes even the first half of the year. A flat commit forces you to pay for capacity long before your usage catches up to it. A ramp fixes that by phasing the commitment to match the curve of your real consumption, and getting the ramp right is often worth more than another point of discount.

Why a flat commit overpays

Consumption of a new or expanding Claude workload is a curve, not a step. Usage builds as you migrate workloads onto the API, as new features ship, as adoption spreads across product lines, and as the engineering team gets comfortable scaling up. A realistic curve might see you consuming a fraction of your eventual run rate in the first quarter and only reaching steady state by the third or fourth.

A flat annual commitment ignores that curve entirely. It assumes you consume one twelfth of the annual figure every month from the start. For the early months, when your real usage sits well below that line, the gap between what you committed and what you consumed is money you have promised and may never recover, because Anthropic commitments are generally use it or lose it. The flat structure quietly bills you for the most expensive thing in any consumption deal: capacity you were not yet ready to use.

What a ramp actually is

A commit ramp replaces a single annual number with a schedule of smaller commitments that rise over the term in line with your forecast consumption. Instead of committing to the full run rate from day one, you commit to a modest figure in the first period, a larger one in the next, and so on, stepping up to your steady state number only when your usage is actually expected to reach it.

The discount still applies across the whole arrangement. You are not giving up the benefit of committing; you are aligning the commitment with reality so the discount lands on spend you genuinely incur rather than on a flat line you cannot hit early on. Done well, the ramp preserves the full value of the discount while removing the dead weight of early overcommitment.

How to build the ramp schedule

The ramp is only as good as the forecast underneath it, so the work starts with consumption modeling rather than with the contract. Build the curve from the bottom up, quarter by quarter, using the same discipline you would bring to any capacity plan.

Start from real usage signals

If you have a pilot or an existing workload, use its actual token consumption as the base. Project forward from real numbers, not from the vendor's optimistic estimate. If you are starting cold, run a structured pilot first, because a ramp built on a guess is just a flat commit with extra steps.

Map the migration, not the headcount

Tie each step of the ramp to a concrete event: a workload going live, a feature shipping, a region turning on. This grounds the curve in things that will actually happen on a date, rather than in a smooth line that assumes uniform growth. It also gives you a defensible story when you negotiate each step with the account team.

Build in optimization from the start

The forecast should assume the architecture you intend to run, not a naive one. If you plan to use prompt caching, which can cut the cost of repeated context by up to ninety percent, batch processing at half the standard rate for asynchronous work, and model routing across Opus, Sonnet, and Haiku to cut aggregate spend by forty to seventy percent, then the ramp numbers should reflect that optimized run rate. Committing to unoptimized consumption is committing to waste.

The protections a ramp needs

A ramp without the right surrounding terms can become its own trap, so the schedule has to be paired with a small set of protections. The rate has to be fixed across every step, so a later, larger commitment is not quietly priced worse than the earlier ones. The overage rate above each step should sit at or near the committed rate, so usage that runs ahead of the ramp does not get billed at list. And there should be a reforecast right, a defined point at which you can revisit the schedule if real consumption diverges materially from the plan, in either direction.

That reforecast right is the single most valuable protection in a ramped deal. Forecasts are wrong, sometimes badly, and a ramp that cannot bend when reality diverges simply relocates the overcommitment risk to a later quarter. The right to reforecast turns the ramp from a fixed bet into a living plan, which is exactly what a multi quarter consumption deal should be.

Ramp versus flat: a worked comparison

Consider a company whose steady state run rate will be roughly two million dollars a year, reached by the fourth quarter. A flat commit asks them to pay against two million from month one, even though first quarter consumption is perhaps a quarter of the run rate. Across the early quarters, the flat structure stacks up a large gap between committed and consumed, and because the commitment is use it or lose it, much of that gap is simply lost.

The ramped version commits to the lower early figures and steps up only as the workloads go live. The same eventual run rate, the same discount applied to it, but the early quarters are priced to real consumption rather than to the steady state. The saving is not a discount on the rate; it is the elimination of paying for capacity ahead of need. On a deal this size that gap routinely dwarfs the extra point or two of headline discount that buyers spend their energy chasing.

Where buyers get the ramp wrong

The most common mistake is letting the account team set the ramp from their own forecast, which tends to be steeper than reality because a faster ramp means revenue sooner. The second is accepting a ramp with no reforecast right, which removes the entire benefit the first time the curve diverges. The third is forgetting to fix the rate across steps, so the larger later commitments quietly cost more per token. And the fourth is building the ramp on unoptimized consumption, committing to spend that good architecture would have removed. Avoid those four and the ramp does what it is supposed to do.

The buyer side takeaway

A flat Anthropic commitment is convenient for the vendor and expensive for you, because it bills you for a run rate you reach only at the end of the term from the very first month. A ramp aligns the commitment with the curve of your real, optimized consumption, preserves the full discount, and pairs with a reforecast right so the plan can bend when reality does. Build the forecast from the bottom up, tie each step to a real event, and negotiate the protections alongside the schedule. The ramp is one of the few structural moves in a commitment deal that saves money without costing you a single point of discount.

Pay for what you use, when you use it.

Download the commitment playbook, or have us build your ramp from real consumption data.

Download the playbook

The Counteroffer

Weekly intelligence on Anthropic pricing moves and the buyer side counters that work.

Get a Quote · Book a Strategy Call · The Counteroffer · New York · London Not affiliated with Anthropic PBC. Independent buyer side advisory only.