GitHub Copilot just paused new signups and is moving to token-based billing from June 1st. At the same time, Anthropic is experimenting with removing Claude Code from its $20 Pro plan. Two of the most well-funded AI companies in the world just ran into the same constraint at the same time.
This isn't a criticism — it's a structural problem. And it was always going to surface.
I'm sharing this not to relitigate their decisions, but because most of us building AI products don't have Microsoft's engineering resources or Anthropic's runway to absorb a billing rewrite. For smaller teams, getting this wrong early isn't a painful quarter — it could be the end of the product. When I sat down to design my own AI SaaS foundation, this was the first problem I knew I had to get right.
The moment I saw the crack
When I started thinking seriously about building AI-powered SaaS products, I kept coming back to one uncomfortable question: what happens when users actually use it?
Flat-rate subscriptions work when your cost per user is predictable and roughly uniform. That's how products like Spotify work — high volume, predictable cost per user. You model your average cost, add margin, and ship.
But AI is different in a fundamental way — the cost of a user session is not bounded by time, it's bounded by tokens. And tokens are wildly unpredictable.
A user asking a simple question might consume 500 tokens. The same user running an agentic workflow — where a model plans, executes, reflects, and iterates across multiple tools — might consume 500,000. Same subscription. Orders of magnitude difference in cost.
Add to that: different models have completely different price points. Claude Opus costs dramatically more than Haiku. GPT-5 costs more than GPT-4o mini. If you let users pick their model freely on a flat plan, you've handed them a lever that directly eats your margin.
I saw this before agentic workflows were mainstream. The math didn't just look bad — it was unsustainable. The only unknown was when it would break in public.
A word on why flat pricing existed
Flat pricing wasn't a mistake — it was a growth strategy. It lowered friction, accelerated adoption, and hid complexity while the market was still forming. “Pay $20 a month, use it as much as you want” is a powerful message when you're trying to get developers to change their habits.
But what works for adoption often breaks at scale. The moment agentic workflows entered the picture — long-running, parallelised, multi-model sessions — the economics collapsed. A single heavy user running agentic workflows can burn through the equivalent of a $20 subscription in minutes. A handful of them and you're subsidising their compute out of your margin.
The flat-rate era served its purpose. But it doesn't survive contact with agentic usage.
The bet I made
So when I designed my SaaS foundation, I made a deliberate architectural bet: metered, per-tenant, per-model billing from day one. Not as a feature I'd add later. As a first principle. I didn't treat billing as a feature. I treated it as a survival constraint.
Every tenant gets a hard limit at their plan quota. At 100%, they hit a stop. No overages, no surprise bills. If they need more, they can purchase additional AI credits — usable across any model or task they choose, valid for a full year from purchase. No waiting for a monthly reset, no forced plan upgrade. The user stays in control, and the business stays predictable.
Billing multipliers are tied to model choice. If a tenant uses a more expensive model, they burn through their credits faster. The cost of the model is reflected in the product experience, not hidden in my margin.
Usage syncs reliably in the background. Token consumption flows through a background service into billing events, which flow through a transactional outbox to the payment provider. If anything fails mid-flight, it retries. The billing record is the source of truth, not an approximation.
Agent token tracking is split by role. In multi-agent systems, cost isn't flat — it's hierarchical. If you don't separate supervisor token consumption from sub-agent consumption, you lose visibility into where your margin is actually leaking. Most systems don't track this at all — which means they don't actually know where their costs are coming from in production. It's one of those things that doesn't matter until it really, really does.
None of this was easy to build. Idempotent webhook processing, per-tenant rate limiting, reliable usage sync — these are genuinely hard distributed systems problems. But they were the right problems to solve early, because I knew the industry was heading here.
What retrofitting looks like
Retrofitting token-based billing onto an existing product is painful. You're not just changing a pricing page — you're changing the mental model users have of the product, the infrastructure that tracks consumption, the billing integrations, the rate limiting logic, and the way every model interaction is instrumented. Every model call now needs to be metered. Every retry needs to be idempotent. Every streamed response needs to be accounted for. If you missed that early, you're not adding billing — you're rebuilding your core execution pipeline under production load.
GitHub Copilot built for flat-rate first. That made sense in 2022. It doesn't make sense in 2026, when a single agentic session can cost more than a monthly subscription.
The deeper issue is that agentic AI fundamentally breaks the request as a unit of billing. A “request” made sense when AI was stateless — user sends message, model responds, done. But agents plan, use tools, spawn sub-agents, reflect on results, and iterate. A single user intent can become hundreds of model calls. Pricing that in “requests” is like pricing cloud compute in “clicks.”
Tokens aren't perfect — but they're the only unit that doesn't lie about cost. They reflect actual compute. They scale with actual usage. They let you build a sustainable business instead of subsidizing heavy users with light users.
What builders should take away
If you're building an AI product today — even a small one — here's what I'd tell you:
- —Design for metered billing from the start. Adding it later means touching your billing provider integration, your usage tracking, your rate limiting, your frontend, and your user mental model all at once. Do it once, do it right, do it early.
- —Treat model choice as a cost lever, not a feature toggle. Every model you offer has a different price. Your billing system needs to know that. Your rate limits need to reflect that.
- —Separate your usage tracking from your billing events. Usage happens in real time. Billing events need to be reliable, idempotent, and retryable. These are different concerns and they need different infrastructure.
- —Think in tenants, not users. Even if you're building B2C today, multi-tenant billing architecture pays off when you go B2B. Pooled credits, org-level caps, per-seat limits — these aren't enterprise features, they're billing primitives.
- —Hard limits protect everyone. Flexible top-ups respect the user. A hard cap at quota prevents runaway costs. But a good AI product also lets power users go further when they need to — and credits should last a full year, because nothing is more frustrating than paying for something that expires before you can use it.
Why this matters for the rest of us
Microsoft and Anthropic will get through this. They have the engineering teams, the capital, and the user bases to absorb a painful architectural transition and come out the other side. Most of us don't.
If you're a small team or a solo founder building an AI product on a flat-rate model, a billing rewrite isn't a bad quarter — it's an existential risk. You'd need to re-instrument every model call, rebuild your usage tracking, renegotiate with your billing provider, retrain your users, and reprice your plans — all while keeping the product running and customers happy. That's a lot to absorb without a war chest.
In AI, the differentiator isn't just intelligence. It's whether your economics survive contact with real usage.
Getting the plumbing right from day one isn't glamorous. It won't make your launch post more exciting. But it's the kind of decision that looks obvious in hindsight and costs everything to fix too late. The industry is learning that lesson right now, publicly, and at scale. Hopefully the rest of us can learn it a little cheaper.