What GitHub Copilot Users Wish They Had a Week Ago

GitHub Copilot moved to usage-based pricing, and the bills landed fast. Ars Technica covered the reaction: developers reporting that they burned through a full month of credits in a single day under the new model (Ars Technica).

If you have shipped anything with an AI coding tool lately, you know the feeling. The flat monthly fee was predictable. You knew the number. Now the number moves with how hard you work, and nobody told you where the ceiling is.

What actually changed

Copilot went from flat-rate to usage-based. There is no firm public quota tier you can point at and say "I will never pass this." Power users hit a wall they could not see coming. Thirty days of nominal credits, gone in one focused day of work.

The same week, Microsoft pushed small cheap models as the stay-under-budget option inside the same product. That is the tell. When a vendor ships a "use this to spend less" feature alongside a pricing change, the cost problem is real and they know it.

This is the failure mode, not a Copilot problem

Copilot is the headline. The pattern is bigger. Every AI dev tool that charges per token or per request has this shape now. You write code, the meter runs, and you find out the total at the end of the cycle.

Uber reportedly caps AI coding spend at $1,500 per developer. That cap exists because without it, the number runs. A big company can absorb a surprise. A solo builder or a small shop cannot.

The fix is not "use the tool less" or "switch to the cheap model and hope." The fix is a budget envelope at the call site. A hard limit that lives in your code, watches spend in real time, and stops the run before it overshoots.

What a runtime budget cap looks like

This is the wedge for AgentGuard, the open-source budget and rate limiter I maintain (pip install agentguard). It wraps your AI calls and enforces a ceiling you set. When you hit it, the run stops. No surprise invoice.

Here is the shape of it:

from agentguard import BudgetGuard

# Hard ceiling for this session. Pick a number you can defend.
guard = BudgetGuard(
    max_usd=5.00,
    max_tokens=500_000,
    on_exceeded="stop",  # kill the run, do not keep spending
)

@guard.track
def call_model(prompt: str) -> str:
    # your normal AI call, any provider
    return client.complete(prompt)

# Run your agent loop as usual.
# When spend crosses $5.00, the guard raises and stops.
for task in work_queue:
    try:
        result = call_model(task.prompt)
    except guard.BudgetExceeded:
        print(f"Hit the cap. Spent {guard.spent_usd:.2f}. Stopping.")
        break

Thirty lines, give or take. The point is not the syntax. The point is that the limit lives in your code, not in a billing dashboard you check after the damage is done.

Why the call site matters

You can set alerts in a vendor console. Alerts tell you after the fact. By the time the email arrives, the credits are spent. A runtime cap is different. It runs in the same loop as your work, counts every call, and refuses to make the call that would put you over.

It is also cross-provider. Copilot today, some other tool next quarter. If your budget logic lives in your code instead of one vendor's settings page, you do not start over every time you switch.

The takeaway

Usage-based pricing is not going away. It is the default direction for AI dev tools, and Copilot just made the cost real for a lot of people in one news cycle. Predictable spend is now something you build, not something the vendor hands you.

Put the limit at the call site. Set a number. Let the code enforce it. That is the difference between a tool you control and a meter you watch.

If you want the runtime budget cap without writing it yourself, that is exactly what AgentGuard does: bmdpat.com/tools/agentguard.