Why GitHub Copilot Changed Its Billing for Agent Workflows

Copilot began as an autocomplete tool and became an agentic coding product. GitHub announced a move from premium request counts toward usage-based AI Credits, and some users were angry. I want to explain why the economics of a single message change when an agent can keep working for hours.

I have received significant Azure credits and a complimentary Copilot Pro+ subscription, so I have a connection to Microsoft that matters here. I previously tested Azure inference latency and say the team responded and improved it. Those results and my account usage are examples from my setup, not a general performance benchmark.

At the time of recording, my Pro+ plan had a monthly premium-request allowance. I say I had used less than 5% while estimating hundreds of dollars in equivalent inference. That estimate uses assumptions about public API rates and caching; it is not evidence of Microsoft's actual internal cost or a bill owed by me.

There are several ways to charge for inference. One is a subscription with limits over a time window: you pay a fixed fee, but the service restricts how much work you can do in a session or week. The exact allowance may be hard to map to tokens and can change with the provider's policies.

That uncertainty makes changes hard to interpret. Customers get used to a workflow and a certain level of use, even when they cannot see its underlying cost. If a provider changes the limit, the same task may consume a different share of the allowance and people reasonably want to understand why.

A second approach is a subscription with a fixed message allowance. T3 Chat once gave a larger quota for cheaper models and a smaller one for premium models. Another variant shows a dollar-denominated usage allowance and permits additional spending; each approach trades predictability against transparency and cost control.

API billing is different: prices are generally quoted per million input and output tokens, sometimes with a separate cached-input rate. A request containing a large document can cost much more than a short question. As a provider of T3 Chat, I pay for that inference even when customers see a message quota.

A fourth perspective is dedicated compute. A company can provision capacity for an inference workload instead of buying every request at a public per-token rate; model licensing and infrastructure terms vary. Labs must manage the capacity they own or rent and decide how to allocate it among their customers.

A billing change changes customer expectations. A person who built a routine around a fixed number of requests may lose capacity under a new meter, while another user may gain. It is possible to understand the provider's cost problem and still recognize why an abrupt change frustrates customers.

When T3 Chat launched, inexpensive models made a generous message allowance seem workable. We then added a more expensive model and saw a large cost increase despite its smaller share of traffic. We separated normal and premium message quotas and offered extra premium credits as an initial patch.

That did not solve the underlying problem. A short request can cost very little, while a long request with extensive context or tools can cost far more. I have seen individual requests cost over $10 at API rates. A message is a unit of interaction, not a consistent unit of compute.

A small number of heavy users could use their premium messages in ways that were much more expensive than their subscription. Lowering every user's quota enough to cover the most expensive case would punish ordinary short requests. My frustration with large codebase uploads reflects my role as a small service operator; users may reasonably have understood those uploads as allowed by the advertised plan.

We changed T3 Chat's billing and lost some revenue because some customers were unhappy. In my view, the variability grew much larger for coding agents. The comparison is not simply between two models: it is between a single response and a workflow that may make many model calls after one prompt.

A simple answer can require one model call. If the model requests a search, the application executes the tool, adds the result to the conversation, and calls the model again. Each continuation can add input and output usage. T3 Chat limits the number of searches, but other agent workflows can run many more steps.

That makes a fixed price per user message a poor proxy for an agent's work. One prompt might finish quickly; another may spend hours reading files, running tools, and reasoning. Actual limits and billing rules vary by service, so a long run should not be assumed to be unlimited everywhere.

I show one cryptography run that lasted about 16 hours and report around 111 million input tokens and 1.6 million output tokens across the run. Those are cumulative counts across repeated calls, not a single context window. My calculator estimates about $62 using assumed cached-input pricing.

Prompt caching can reuse previously computed state for a repeated prefix rather than processing it all again at the uncached rate. Cache eligibility, hit rates, and prices vary. My estimate is an API-price equivalent, not a measurement of the provider's marginal cost; extrapolating it to every allowance is hypothetical.

The long run came from a cryptography puzzle. I enjoy puzzles that ask people to decode clues rather than break into systems. I created one, offered a $1,000 bounty, and a community member solved it in under ten minutes. I also tried the challenge on AI models to see how long they would work.

The first puzzle's second line decoded into a hint pointing toward a Git commit in my Dogecoin simulator. I had altered a branch's history to place a seed needed to decode the first line. A model eventually solved it, but access to the gist or knowledge of my GitHub account made the connection easier.

I also used a deliberately unconventional base-23 alphabet as a T3 hint. A cryptography-minded friend disliked the arbitrary convention, which made me think about how encodings depend on agreed alphabets. Recognizing a familiar character set can suggest an encoding, but it does not guarantee which mapping was used.

For the second puzzle I removed the GitHub hint, made the next step less obviously JSON, and changed the encoding. The community took around ten hours and needed hints; my agents needed more help. Some submitted answers were hallucinations, showing why a plausible-looking agent response still needs verification.

The clue pointed to my first YouTube video, while the apparently familiar encoded text used a reversed Base64 alphabet. Even after decoding, the next payload did not immediately look like the prior puzzle's JSON. This was a puzzle-design trick, not a claim that reversing an encoding is strong cryptography.

I then used the puzzle to test how much work a single Copilot request could trigger. The model and reasoning setting had an effect on usage, while the old plan assigned model-dependent request multipliers. The specific multipliers I show were historical plan rules and should not be treated as current rates.

I ran many sessions on a deliberately altered puzzle and attempted to make them work for a long time. The runs varied widely in output, and my reported dollar totals are estimates based on list pricing and assumptions about caching. They do not prove how much Microsoft paid or that the same result can be repeated by others.

GitHub announced that monthly plans would move to AI Credits measured using input, output, and cached-token consumption, with paid plans able to purchase additional usage. The original announcement described a separate transition for annual subscribers. GitHub's later updates and documentation should be consulted for actual current terms.

My argument is that a long multi-step agent run no longer fits the economics of a flat request count. GitHub itself said rising inference demands made its prior model unsustainable. But my inference about precisely how much capacity Microsoft had, or what it could have sold instead, is not verified financial information.

I strongly defend changing the meter, but customers can still reasonably object if the value they relied on changes or the transition is poorly communicated. Subscription prices, included usage, caching discounts, and service limits are contractual product details, not a universal rule that a $40 subscription must deliver exactly $40 of inference.

The broader lesson is to compare a subscription with the actual workload it supports, not only the headline price or message count. Agents have made the cost of one interaction much more variable. Providers need sustainable limits and clear communication; users need enough information to predict the effect on their work.