GitHub Copilot is now usage-based. What's your team doing about it?
by•
Starting June 1st, @Github Copilot moved to a usage-based billing model.
Question for engineering leaders after this change:
What's your team actually doing about it?
591 views
Starting June 1st, @Github Copilot moved to a usage-based billing model.
Question for engineering leaders after this change:
What's your team actually doing about it?
Replies
For solo indie builders the usage-based switch is actually less painful than it sounds. No team governance headache, no justifying a flat seat cost when you're shipping slowly. You only pay when you're productive.
The harder question is whether to stay in the VS Code + Copilot orbit at all. I've been spending more time in Claude Code directly, and the context-window approach it takes feels more useful than inline autocomplete for the kind of feature-building work that actually moves a project forward.
Curious how others are weighting the "inline suggestion" tools vs the "whole session" tools at this point — the use cases feel increasingly distinct.
Kilo Code
Good point, although using a terminal like @Claude Code is a different workflow, a different way of doing things. some people might feel too "zoomed out" from the code in this context.
See this thread: What's your preferred agentic engineering interface?
Usage-based was always the model, it just used to be hidden behind a flat rate. The "unlimited" messaging was always an abstraction over a quota.
What's changed is that the new pricing makes the constraint visible — and that visibility cuts both ways. Teams that were casually over-indexing on Copilot for tasks where a cheaper model works fine now have a reason to route. But it also means every task becomes a micro-cost decision, which adds cognitive load most devs didn't sign up for.
The hybrid approach (burn + route) makes sense as a transition, but it only works if you know which tasks are actually premium-request-worthy and which aren't. Most teams don't have that map yet.
Interesting that "hard spend caps" is sitting at 0% — that's exactly the gap I'd watch. We've started treating AI tokens like any other COGS: tracked per project, with a rough budget before we build. The cost isn't the surprise; what changed is it makes you intentional about what you ship vs. what you just tinker with.
The bigger shift: for non-technical makers riding the "vibe coding" wave, an unpredictable bill is scary in a way a flat $10/mo never was. Whoever makes usage legible — not just cheaper — wins that crowd.
Curious why caps are so unpopular — too blunt an instrument, or just kills the agentic workflows?
usage-based pricing is the moment the 'just expense it' era ends for solo devs — every prompt has a meter now. it's pushing me to watch which tasks actually need a frontier model vs a local one. curious if teams are just eating the bill.
Kilo Code
@qifengzheng the poll suggests a hybrid approach. also curious how they actually run this burn-the-allocation-then-route in production.
@fmerian honestly the routing logic is the part nobody has instrumented — you need per-request cost attribution before you can even decide when to spill over to a cheaper model. most teams find out they blew the allocation at invoice time, not at request time.
@qifengzheng @fmerian I start tracking my agent usage in a local database last month (when Anthropic sent out their email about shifting automated usage to a different monthly budget). Now I'm tweaking them by leaving very consciously chosen runs on Claude (various models) and routing other work to OpenRouter, Ollama Cloud and local LLMs. I've already reduced their cost substantially.
Vokal
The 50% on "hybrid: burn + route" is the
tell — teams aren't dropping AI coding tools,
they're getting smarter about when to use
which model.
The real frustration isn't the price. It's
unpredictability. When you can't estimate
your monthly bill, you can't budget, and
when you can't budget, you get spending
freezes that kill adoption entirely.
We built AUREM CTO Dev specifically around
flat-fee pricing after watching this exact
pattern play out. $19/month Pro — ship 5
tasks or 500, same price. No token math,
no bill surprises, no spend cap anxiety.
The other thing we noticed: most of the
Copilot/Cursor frustration isn't really
about cost — it's that they suggest code
but you still do all the work. Copy, paste,
test, commit, push. That's not an AI
engineer, that's autocomplete with a
subscription fee.
AUREM commits directly to GitHub — no PR,
no terminal. Might be worth a look if
your team is re-evaluating right now.
Happy to share more if anyone's curious.
Most people here are looking at this through a “developer cost” lens, but the shift is bigger than that. Usage‑based billing isn’t designed for humans it’s designed for agents. Flat seats made sense when the workload was human‑scale. Now the majority of premium requests are coming from automated systems, background tools, and dormant accounts that never should’ve been billed in the first place.
This change quietly cleans out dead seats, zombie orgs, and idle subscriptions. It aligns billing with activity, not identity. Humans pay subscriptions. Agents pay per action. GitHub just moved to the agent‑economy without announcing it, and most people haven’t noticed yet.
My clients have been leaving copilot and moving to claude. Strong trend, at least in my humble slice of the world.
sidebar: some clients showing interest in replacing enterprise AI products with their own local models.
I think the real change is that teams now need a routing policy, not just a tooling preference. “Use the best model/tool” sounds fine until every dev has to make tiny cost/quality calls all day.
The practical version I’d want: keep Copilot or Cursor for low-friction inline work, reserve Claude/agentic sessions for larger changes where context and planning matter, and make the default path obvious enough that engineers don’t have to think about billing while coding.
The vendor lock-in is real though — even when switching tools, the GitHub ecosystem (repos, PRs, workflows) still keeps you in that orbit.