We Burned Through Our $300 Copilot Budget in Three Days

The billing alert

Three days into running our full multi-agent pipeline under GitHub's new usage-based billing model, a spending alert landed. The $300 monthly cap on Copilot AI credits was gone. The session-store audit for those three days — June 2–4, 2026 — shows 5,223 Claude Sonnet 4.6 events, 308 Claude Opus 4.8 events, and 777 GPT-5.4 events, across 8–9 sessions per day. We upgraded the cap to $450, but that is a delay, not a fix. The problem was that the cost guard had never fired once.

How costs compound in multi-agent sessions

When you run a multi-step agent workflow, the billing pattern is different from a single chat session. A single-agent session charges you once. A multi-agent pipeline — where one agent plans, another implements, and a third reviews — charges you for expensive models at least twice per issue: once at the start and once at the end.

Here is why that matters. The planning pass is expensive because it requires a long context window: it reads the issue, any prior session history, and related code, then reasons through a full implementation spec. That can be 30,000–80,000 input tokens before the model writes a single word. The review pass at the end is equally expensive — it reads the full implementation output plus the original spec to evaluate them against each other. The implementation pass in the middle is cheaper because it follows a clear spec and does not need the same depth of multi-step reasoning.

The result: in a 3-issue session, you pay for expensive models at minimum six times — a planning pass and a review pass per issue. In our three-day period, that produced 308 Claude Opus 4.8 events. Opus is the most capable model in the pipeline and, at $5.00 per million input tokens and $25.00 per million output tokens, also the most expensive. One long Opus call with 60,000 input tokens and 3,000 output tokens costs roughly $0.375. Multiply by 308 events and you have $115 in Opus costs alone, before any implementation work.

A note on terminology: GitHub uses the phrase premium requests in older billing documentation. Think of it like a taxi fare — a short trip and a long trip are the same service, but a very different meter. Under usage-based billing (active since June 1, 2026), the meter is literal: you pay for actual tokens consumed, not a per-interaction flat rate. If you see "premium requests" in your billing dashboard, check whether you are on a legacy annual plan that predates the June 1 transition.

How GitHub charges now

GitHub switched from its legacy premium-request multiplier model to usage-based billing (AI credits) on June 1, 2026. Under the new model, you pay for actual token consumption. 1 AI credit = $0.01 USD; the $300 cap was 30,000 AI credits. Per-token rates for the models in our pipeline (per 1 million tokens, fetched June 5, 2026 from the GitHub Copilot billing documentation):

The audit's "GPT-5.4 events" field matches the billing table name exactly — no reconciliation needed. The math runs fast: a single long Opus call with 60K input tokens and 3K output tokens costs roughly $0.375. Multiply by 308 Opus events and you are already at $115 before counting Sonnet or GPT-5.4. The 5,223 Sonnet events and 777 GPT-5.4 events account for the rest of the $300.

One note on the legacy model: before June 1, GitHub billed in premium requests — a proprietary credit unit where each AI interaction consumed a model-specific multiplier of your monthly allotment. Under that system (still in effect for annual plans that opted out of the June 1 transition), Haiku was 0.33×, Sonnet 4.6 was 9×, and Opus 4.8 was 27× per interaction. Those multipliers are now irrelevant for anyone on the new usage-based billing, but the relative cost hierarchy is identical: Opus is expensive, Sonnet is mid-range, Haiku is cheap. If you are still seeing "premium requests" in your dashboard, check whether you are on a legacy annual plan.

Five controls that would have prevented this

The cost guard we had was not broken — it was misconfigured in five separate ways, each of which silently disabled it. Here is what broke, and what the correct configuration looks like.

1. Scope your API call to match your account type.

   If your Copilot account is org-managed (your company or team pays for it), your billing API calls must use org scope — not user scope. A user-scope call to an org-managed account returns a 403 error silently. The script records the status as "unknown" and exits. Your cost guard never fires because it never received a number to act on.

   What right looks like: set COPILOT_USAGE_SCOPE=org and COPILOT_USAGE_ORG=yourorg. Then test the call directly before trusting it: curl -H "Authorization: token $GITHUB_TOKEN" https://api.github.com/orgs/yourorg/copilot/billing. If you get billing data back, the scope is correct. If you get 403, it is not. Do not assume — test it once.

2. Make the cost check mandatory, not optional.

   If your cost check runs only when an environment variable is set — for example, if [ -n "$COPILOT_PLAN_LIMIT" ]; then check-usage; fi — and that variable is never configured, the check silently skips on every session. The code that is supposed to protect you never runs. This is not a guard; it is a guard-shaped decoration.

   What right looks like: the cost check runs unconditionally at session start. If COPILOT_PLAN_LIMIT is not set, the session fails immediately with a clear message: "COPILOT_PLAN_LIMIT is not configured. Set it before starting a session." Optional safety checks are not safety checks.

3. Set the warning threshold at 50% consumed, not 70% or higher.

   At 70% consumed on a $300 cap, you have $90 remaining. A single 3-issue pipeline session with expensive models can burn $50–100. By the time the trigger fires, there is not enough headroom left to change behavior before hitting the cap.

   What right looks like: enter fallback mode at 50% consumed ($150 remaining on a $300 cap). At 50%, you still have enough budget to complete the current session at a cheaper model tier. Fallback mode is not a degraded experience: implementation passes already run on cheaper models by default, and those models handle planning and review well on routine issues. The quality difference for non-complex work is small; the cost difference is large.

4. Route trivial work away from expensive models.

   A 5-word README edit dispatched to your most expensive model costs the same as a full feature-spec session. The model's extra capability is entirely wasted on mechanical work, but the billing meter runs at full rate. One long expensive-model call on a formatting fix costs roughly the same as 15 cheap-model calls — and those 15 calls could have handled real work.

   What right looks like: before dispatching any agent, classify the work. Documentation updates, typo fixes, version bumps, and formatting changes do not need your most capable model. Route them to a cheaper tier. Classification can be as simple as checking labels — docs, chore, refactor, mechanical — and skipping the expensive planning pass for those categories. The cost difference is approximately 15×; the quality difference for mechanical work is negligible.

5. Persist fallback-mode state across context resets.

   If you track budget state in-session — for example, "fallback mode is ON" held as a variable in the current agent context — that state disappears when the session is compacted, summarized, or restarted. A resume from a checkpoint looks like a fresh session. The cost guard triggers, sets fallback mode, then a context reset silently drops the flag. The next turn runs at full expensive-model tier with no warning.

   What right looks like: write the fallback-mode flag to a file the moment it is set — for example, ~/.copilot/fallback-state or equivalent. Read that file at every session start, including resumes. In-context state does not survive compaction; file state does. The guard only works if its output outlasts the session that created it.

The takeaway

The multi-agent pipeline architecture is sound. Sequential specialist passes — planning, implementation, review — produce better output than a single all-purpose agent. The problem was not the design. It was that the cost guard was wired to an API call that had been returning 403 for weeks without anyone noticing, because the session tooling treated a failed check as a quiet no-op.

Every multi-agent pipeline needs a cost guard that can actually compute burn: one that fails loudly instead of silently, triggers before the budget is gone, and persists its state across context resets. The cap increase bought time. The five controls above change the behavior.

If you are running a similar setup and want a minimum viable configuration to check:

1. API scope matches account type (org vs. user) — tested with a direct API call, not assumed.
2. Spending limit variable is set — and the session start fails loudly if it is not.
3. Warning threshold is ≤ 50% consumed — not 70%, not 80%.
4. Fallback state is written to a file — not held in session context.
5. Trivial work is classified before model dispatch — mechanical tasks skip expensive models.

Questions or running a similar multi-agent setup? Reach out — we read every reply.