The Hidden Meter

Early this year, my team at Recurly noticed something subtle in our AI coding tools. Output quality would degrade partway through the month. Not fail, just quietly get worse. The cause turned out to be hidden caps: when usage crossed an invisible threshold, the tool silently fell back to a cheaper model. No notification, no log entry, no signal to the developer that anything had changed. From the engineer's chair it looked like the tool was having a bad day. From mine, it looked like a quality incident we could not diagnose because the vendor was making cost decisions on our behalf, invisibly.

That experience drove a deliberate choice. We moved directly onto usage-based plans, and we built our own governance layer to go with them: per-user spending caps, managed by an automated system, in place since the beginning of the year. We chose the visible meter on purpose.

On June 1, GitHub made that choice for everyone.

What just happened

All GitHub Copilot plans moved to usage-based billing this month. Premium requests are gone, replaced by AI Credits that meter actual token consumption at published API rates. Annual plans are being retired. And the detail I find most significant: the silent fallback to cheaper models when you exhaust your allotment has been eliminated entirely.

GitHub's stated reason is the honest one. Agentic usage is becoming the default, and agents consume compute in a way that bears no relationship to headcount. Per-seat pricing breaks when marginal cost per user is high and highly variable. This is why cloud infrastructure was never sold per seat, and AI tooling is infrastructure now.

The same week, Bloomberg reported that Uber capped AI tool spending at $1,500 per employee per month. A vendor restructuring how it charges and a sophisticated buyer building defenses against unbounded spend, in the same news cycle, is not a coincidence. It is a regime change.

The part nobody is saying

Most of the commentary treats June 1 as a new burden: now you have to think about tokens. I think that gets it backwards.

Per-seat AI pricing was always metered. The meter was simply hidden from you. Allotments, model multipliers, and silent downgrades were usage-based economics wearing a flat-rate costume. The vendor managed consumption against their own margin targets, and the management mechanism was degrading your results without telling you.

A hard cap you set yourself is a governance decision. A hidden fallback the vendor sets is a quality incident you cannot root-cause. Between those two options, the visible meter wins every time. The developers currently filling GitHub's community forums with reports that identical work consumed wildly different amounts of quota are discovering the same thing we did in January: you cannot plan engineering work against an accounting model you cannot see. Their frustration is real, but it is aimed at the wrong era. The hidden meter was the problem. The visible one is the fix, even when the fix is uncomfortable.

What the visible meter breaks

Honest pricing still creates real work, and most engineering organizations have not done it.

Forecasting is the first casualty. Your cloud bill correlates with traffic, and a decade of FinOps practice tells you how to model it. Token consumption correlates with developer behavior, agent autonomy levels, and context growth. None of that maps to an existing forecasting model, and the variance is enormous. Two comparable coding sessions can differ in cost by multiples. And unlike cloud, you cannot negotiate your way out of the problem. Almost no buyer has real pricing leverage with AI vendors today, which means governance on your side of the meter is the only cost control you actually own.

And the most dangerous failure mode is behavioral. A meter that developers can see changes how developers work. Engineers who watch the counter run will ration usage, downgrade to cheaper models, and avoid the agentic workflows that justified the spend in the first place. Get the cap design wrong and you silently destroy the productivity you bought. The cap has to be an instrument of governance, not a source of anxiety, which is why we automated ours: the system manages the budget so engineers do not have to think about it until a threshold genuinely matters.

What I would do this quarter

Instrument before you cap. You cannot set a rational per-user budget without a baseline of actual consumption, and you do not have one yet.

Automate the enforcement. A spending cap that requires a human to notice and act is a spending cap that fires two weeks late. Build or buy the system that watches the meter so your engineers do not have to.

Decide who absorbs the cost deliberately. Central absorption, team chargeback, and per-user budgets each shape behavior differently. Pick one on purpose. The default you drift into will pick for you.

There is a counterargument worth taking seriously: inference costs keep falling, and vendors may eventually revert to generous flat tiers. Maybe. But the metering infrastructure, the budget hierarchies, and the consumption telemetry are built now, on both sides of the transaction. That ratchet does not reverse. The era of pretending AI tooling has flat economics ended on June 1. The organizations that win the next phase are the ones that stopped pretending earlier.

I run engineering for a company whose business is subscription billing, so I have watched the seat-to-usage transition from the vendor side for a decade. It is one of the hardest moves in pricing, it always produces a backlash cohort, and it always happens anyway once marginal costs start scaling with usage. AI tooling was never going to be the exception. The only question was whether you would build your governance layer before or after your vendor forced the issue.

We built ours in January. GitHub shipped theirs in June.