The Flat-Rate Era Is Over: Budgeting AI Tools When Every Token Is Metered

Today is the last day of GitHub's promotional Copilot credits. When Copilot moved every plan to usage-based billing on June 1, Business accounts got an extra $30 per user per month and Enterprise accounts an extra $70, for June, July, and August. That cushion is gone tomorrow. September is the first month most organizations see what their engineers' usage actually costs.

Some of them are going to be surprised. A Copilot Business seat is $19 and now includes $19 of credits, billed against token consumption at each model's API rates. For an engineer using completions and the occasional chat, that's plenty. For an engineer running agents for hours a day, it's gone in the first week — and GitHub was explicit that when credits run out, there is no fallback to a cheaper experience. You've either set a budget that allows overage or the tool stops.

This isn't a Copilot story. It's the whole market arriving at the same place. Bloomberg reported that Uber exhausted its annual AI coding budget in four months and responded with a cap of $1,500 per employee, per month, per tool. When a company with thousands of engineers needs a four-figure monthly ceiling per person, the twenty-dollar seat is over as a planning unit.

Why seat count stopped working

Under flat-rate pricing, cost was headcount times price. Finance could forecast it in one cell.

Under metered pricing, cost follows behavior, and behavior is wildly uneven. The same distribution that shows up in every adoption dataset I look at — a few power users, a broad middle, a tail near zero — is now your cost distribution too. A handful of engineers doing heavy agentic work can account for most of the bill.

That's not a problem by itself. Those are often your most productive people, doing exactly what you hoped everyone would do. It's a problem when nobody can say whether the spend bought anything.

Budget by tier, not by seat

The budgeting model that holds up has three parts.

Tier your engineers by usage pattern. Pull the last ninety days of usage data and you'll find natural bands: light users who live inside the included credits, mixed users running agents regularly, and heavy users with long-running agentic work. Budget each band separately. An average across all three describes nobody.

Set limits where the decisions get made. Copilot's admin controls let you set spending limits at the enterprise, cost-center, and individual level; most other tools have an equivalent. Put the budget with the engineering manager who can judge whether the usage was worth it. A single org-wide cap just means the heavy users burn it by the 20th and everyone else gets cut off.

Measure cost per outcome. Tokens per engineer tells you who's spending. Cost per merged change — or per completed ticket — tells you whether it's working. An engineer spending $900 a month and shipping twice the reviewed, merged work is cheap. An engineer spending $200 on abandoned agent runs is not.

The mistake to avoid

The reflex when a bill spikes is a blanket cap. I'd resist it. A flat ceiling treats your best delegators as the problem and teaches the middle of the team that using the tool is risky. You'll save money and stall adoption in the same month.

Model routing does more than caps do. Most agent work doesn't need the most expensive model; teams that default routine tasks to a mid-tier model and reserve the frontier model for hard problems cut spend substantially without anyone noticing a quality change. That's a configuration decision, not a policy fight.

Budget season starts now

Q4 planning is weeks away, and the AI line needs a real number next to it for 2027. "Seats times price" will be wrong. "Last quarter's bill plus 20%" will be wrong in the other direction once agent usage spreads past the power users.

The defensible version is a tiered forecast with a cost-per-outcome number attached. That takes a quarter of data to build, which means September's invoice is the first input, not the surprise.

Building that tiered view of usage, cost, and delivery is what our adoption reporting engagement produces — a number your CFO can plan around.