A principal engineer spends one thousand two hundred dollars on inference and closes a major defect in one day instead of two weeks. Finance sees the one thousand two hundred dollars. The time saved appears nowhere.
Some of you would rather let that defect block revenue for two weeks than explain a larger token bill.
Another engineer spends one hundred eighty dollars and produces nothing a customer accepts. His dashboard is green.
This is backwards.
Token spend should be a function of the labor required to build the software, not a personal allowance for the engineer.
Start with a range of one percent to one thousand percent of the expected labor cost.
Token budget equals expected labor cost times one percent to one thousand percent.
That is a range, not a spending target. Easy work may need one percent. Valuable work that can be pulled forward by months may justify one hundred percent, five hundred percent, or even one thousand percent.
If you are spending less than one percent of development labor on tokens, one of two things is probably true.
You have a finely instrumented software-delivery system. You know what the work costs, what each model produces, and exactly where a small amount of inference creates value.
Or you have the opposite. Your engineers are barely using AI because access is weak, governance is slow, or everyone is afraid of the invoice.
Do not confuse low spend with efficiency until you know which one you have.
Four engineers working for ten weeks at three thousand seven hundred fifty dollars per engineer per week cost one hundred fifty thousand dollars.
That gives the project a starting token range of one thousand five hundred dollars to one point five million dollars.
Suppose thirty thousand dollars of inference helps the same team finish in five weeks. Labor falls to seventy five thousand dollars. Labor plus tokens is one hundred five thousand dollars.
The old path is one hundred fifty thousand dollars. The agent path is one hundred five thousand dollars. That is a savings of forty five thousand dollars plus five weeks.
Now add the cost of delay. If shipping this software is worth twenty thousand dollars a week, getting it out five weeks earlier is worth another one hundred thousand dollars.
Token spend can exceed labor cost and still be the right decision. Suppose the company spends the full one point five million dollars token budget, and to keep the math conservative, labor does not fall at all. Total cost is one point six five million dollars. That is one point five million dollars more than the old path. If waiting ten weeks costs the business two point five million dollars, the company is still one million dollars ahead.
Labor gives you a comparison. It does not give you a ceiling.
This is why token cost cannot be viewed alone. Put it inside the total cost of ownership: labor, tokens, infrastructure, review, rework, and support. Then put the cost of delay beside it.
Do this math at the portfolio level. Keep individual usage data for security and misuse. Do not turn it into a personal spending contest.
Your engineers do not know what every roadmap item is worth, what delay costs the company, or which project matters most this quarter. The executive team owns those decisions. Give engineers safe tools, clear boundaries, and enough tokens to build fast.
That means the budget needs to be elastic.
Some of you will have to change the annual model. Today you approve one engineering budget for the year, hand over a roadmap, and ask, "How far can we get?"
Try pricing the work instead.
Treat each proposal like a bid to deliver an accepted software outcome. For each roadmap item, ask a team to give you a labor estimate, a token range, a delivery date, and a clear definition of done. Compare that price with the value of shipping and the cost of delay. Fund the work that makes sense. Stop weak work early. Give more budget to work that proves its value.
You can still set a hard ceiling for the whole portfolio. Inside that ceiling, let money move as the evidence changes.
This may feel less predictable than giving engineering one number for the year. It is more honest. You stop pretending every roadmap item will be built, and you stop paying for low-value work simply because it survived annual planning.
Track tokens with the portfolio. Track total cost of ownership with the product. Track cost of delay with the business.
Leave the engineers to build fast.
If you do this right, your chief financial officer will probably give you more money to build. The bet becomes simple: this is what the work costs, this is what it returns, and this is what waiting costs.
That is a software budget Finance can say yes to.