Full narration of the briefing. Click a section heading to jump the player to that moment.
Every consumption agreement turns on one number: how much you commit to spend. Commit too little and you leave discount on the table and renegotiate from weakness later. Commit too much and you have bought shelf space, because unused commitment in a consumption contract is money you have already promised. I am Tom, Daniel is with me, and in our experience most first commitments in this category are guesses dressed up as forecasts.
This episode is how to do it properly.
Start with measurement rather than modelling. You want at least sixty to ninety days of actual token consumption, broken down by application, by model tier, and split between input and output. If you are already running through a cloud provider, that data is in your billing export. If you are direct, it is in your usage console.
What you must not do is derive a number from headcount, because there is no reliable ratio between how many people you employ and how many tokens your applications consume. We have seen the same headcount produce bills that differ by fifty times.
Then clean it before you commit to it, because whatever you measure becomes the floor you are pricing against. Apply prompt caching where context repeats. Move anything that does not need an immediate answer onto batch. And run the routing exercise: for each workload, test whether a smaller model is genuinely good enough, and be honest about the answer.
Every one of those reduces your baseline. Doing them after you sign means you have committed to a level of consumption you no longer need, which is the single most expensive mistake available here.
Now growth, and there are two curves pulling in opposite directions. Adoption pushes consumption up, often sharply, because a successful pilot becomes three departments in a quarter. But efficiency pushes it down: prompts get tighter, caching gets applied, cheaper models absorb more of the work, and published rates in this market have generally fallen rather than risen over time. If you model only adoption you will overcommit.
If you model only efficiency you will undercommit. Model both, and be explicit with your own finance team about which assumption is doing the work.
And here is the part we say plainly to clients, because pretending otherwise does them no favours. The error bars on an AI consumption forecast are wider than anything else we benchmark. A single new feature can double consumption in a month. A model change can halve the tokens needed for the same task.
There is no published benchmark set for what comparable enterprises commit, in the way there is for Microsoft or Oracle, because these agreements are young and private. So treat any forecast as a range, and negotiate for the flexibility to be wrong.
Which leads to the method we actually recommend. Do not commit your expected case. Commit your confident floor, the consumption you are certain of even if every new project stalls, and then structure the rest as a ramp that steps up on defined dates or on defined triggers. You will get a slightly weaker headline rate than committing the big number.
You will also not be sitting on unused commitment in month nine, and unused commitment is a hundred percent loss while a slightly thinner discount is a few percent.
So what you should walk into the room with. Ninety days of measured consumption, already optimised. A range rather than a point, with the assumptions written down. A confident floor you would be comfortable committing even in a bad year.
And a proposed ramp for everything above it. That is a defensible position, and it survives the question every vendor asks, which is how you arrived at your number. Next time, Claire and I go through what the agreement itself has to say.
Redress Compliance works on contingency: our fee is 25 percent of what we save you. Nothing saved, nothing paid. Independent, buyer side only, never vendor funded. Want Redress to contact you? Reach out and we respond the same day.
Talk to a Anthropic negotiator