Reading the AI research for government buyers, part 3.
Every cost proposal I review has a number that someone will circle. The lowest rate per user. The lowest price per transaction. The lowest monthly subscription. It goes in the council packet, and the comparison is over before it starts.
AI pricing should make every public buyer suspicious of that circle.
Cheaper on paper, pricier in practice
Reasoning models work through a problem step by step before they answer. One recent study found that when these models were compared head to head on total cost, the model with the lower list price cost more in total in about a third of the comparisons.
Why the cheap one costs more
The step by step reasoning produces text the buyer never reads, called thinking tokens. Those tokens are billed at the higher rate for text the model writes, and some models produce far more of them than others for the same job.
Here is the lesson in one sentence. The buyer sees the price per token, but the model decides how many tokens a job takes, within an effort setting the buyer picks.
That is the whole problem in a line. The buyer controls the rate. The product controls the volume.
To be fair, that finding is not a ranking of models, and it does not weigh cost against answer quality. It is a warning about how to read a price.
Government has been here before
Strip out the AI vocabulary and this is a familiar pattern in public sector technology buying.
A rate per user looks low until you count who needs a license. A rate per transaction looks low until volume grows. A subscription looks low until the modules you need are priced separately, the integrations are scoped later and the configuration hours run past the estimate. Then add the staff time to keep it running.
The unit price was real. It just was not the cost.
AI makes this sharper, because now the meter can run on its own. A feature that drafts, summarizes or reasons on every record consumes billable units every time it runs, and the system, not your staff, decides how many.
Price the work, not the line item
The fix is not to find the lowest rate. It is to change what you compare.
Define the work first. Before the RFP, write down the jobs the system has to do: run payroll, close the month, onboard an employee, answer a resident request. Describe them in your own volumes, with your own messy exceptions.
Make proposers price the work. Ask each proposer to estimate the all in cost of doing those jobs in year one and year three, not to fill in a rate card. A rate card tells you the price of a unit. You need the price of the job.
Find out who controls the volume. For every billable unit, ask what drives the count and who can change it. If the seller’s software decides how many units a job consumes, you are signing an open ended commitment.
Test on your workload. Where AI features are priced by use, run a defined sample of your own work during evaluation and look at what it actually consumed. One good demo is a sample of one.
Model growth. Ask what happens to total cost when users, transactions or AI usage double. Cheap at pilot scale is not the same as cheap at full scale.
Ask for controls. Effort settings, usage caps, alerts and reporting. If the buyer can pick an effort setting, the buyer should know where it is and who is allowed to turn it up.
Score total cost, not rate
Most evaluation scoring gives points to the lowest price. Change what price means. Score the estimated total cost of the defined work over the life of the contract, and weigh how confident you are in that estimate. A proposer who will commit to a cost for the job is giving you more than one who quotes the lowest unit.
This is Phase Zero work. It happens before the RFP is written, because once the cost form asks for unit rates, unit rates are what you will compare.
The cheapest line on the price sheet is a claim about one unit. Your budget pays for all of them.
I also publish this on Substack.
Read Chapter 1 of Start at Zero free
Planning your next move? Write to us.