Copilot Bills Tokens Now. Context Is the Cost.
Copilot Bills Tokens Now. Context Is the Cost.
Part two. GitHub moved Copilot to token billing on June 1. For a large codebase the fix is a retrieval layer that serves minimal context and lets you query across the repos you own.
Last post I made the case that your API is the product and each surface is a client of it. This one is where that idea earns its keep, because the bill changed.
On June 1, GitHub stopped counting Copilot requests and started counting tokens. Each plan now ships a monthly pool of AI Credits, and your usage draws down against input, output, and cached tokens at each model's API rate. If you hold an annual Pro or Pro+ plan you stay on the old premium-request model until the term runs out, and your multipliers went up on the first. For the rest of us, the unit of spend is the token.
That one change rewrites how you plan Copilot usage in a big codebase. The cost of a task is now the tokens it burns, and context is where those tokens go.
The meter moved to tokens
In May, GitHub added weekly and session caps, set from token consumption times the model multiplier, and aimed them at the long agent runs that were costing more than the plan price. GitHub called those caps temporary and said it would loosen them once usage billing settled in, so treat the exact ceilings as a moving number. The direction is fixed. You pay per token, and heavy agent work is what runs up the total.
Anyone who has watched an agent chew through a task already knows where this hurts. The model reads a file, reads three more to understand the first, retries after a failed edit, and repacks half the repo into the window on the next turn. Each of those steps is input tokens, and input tokens are the bill.
Context is the line you pay for
In a large system your logic lives across ten repositories, and the answer to a question like "what still depends on this deprecated client" is spread across all of them. Copilot cannot hold ten repos in a context window, and paying to shove them in one prompt at a time is a losing trade even when it fits.
What you pay for is the context you assemble to make the work possible. The bigger and more scattered your code, the more that assembly costs, and you pay it again each time an agent rebuilds context from scratch.
That is the trap. The fix is to send the model the exact slice it needs and leave the rest on disk.
Build a retrieval layer
The move companies should make is to build a retrieval layer in front of their code and treat it as the product. Two pieces carry it. Embeddings give you semantic recall, so a question maps to the right code without keyword guessing. A code graph gives you structure, so you can walk symbols, references, and dependencies instead of grepping text.
Put that layer behind a protocol the agent can call, and expose it as capabilities. When the agent needs the definition of a symbol, it asks for that symbol and gets a few hundred tokens back. When it needs the call sites of a function, it asks for call sites, not the eight files they happen to sit in. You save the tokens by returning the minimal structured slice, and you enforce that rule once at the boundary.
Query the debt across your repos
This is the part that pays for itself in a company with real tech debt. One index that spans your repositories lets you ask questions a single prompt could not answer:
find_usages a symbol, across all repos
impact_of a package bump, mapped to affected services
locate a deprecated client, down to call sites
trace_flow a request path across service boundaries
Ask "what breaks if we upgrade this library" and get a list of services and files instead of a shrug. Ask "where does this old auth pattern still live" and get call sites across the org instead of a week of manual searching. The answer comes from a structured index, so you pay for the size of the answer, while the codebase you searched to find it stays off the bill.
Copilot on its own cannot do this without loading the world into context, which under token billing is the expensive way to get a worse result.
Route the cheap work off the meter
A lot of what teams burn Copilot on did not need a frontier model or Copilot's meter. Semantic search, usage lookups, dependency impact, "where is this defined," those run fine against your own index on a cheap or local model. Put a routing proxy in front and send that traffic to the low-cost path. Save Copilot's token budget for what it is good at, inline completion and agent edits on the code you are changing right now.
Moving that traffic off the metered path beats trimming the metered path. A small model and a good index answer that question, and you keep the premium token rate for work that needs it.
Build the product once
This is not an argument against Copilot or against a CLI. Build the core as an indexed library with a clean internal API, and each surface becomes a client of it. The agent protocol is one client. A CLI for your engineers is another. A chat box in the IDE is another. Your logic stays in one place, and each surface stays token-frugal because it pulls the slice it needs instead of hauling the whole tree around.
That is the architecture that survives token billing. The teams that build it decide what context costs them. The teams that keep dumping files pay whatever the meter says.
Where this goes
Copilot is the first big tool to move engineers onto token billing, and it will not be the last. Usage-based pricing is the direction across the vendors, which makes context management the biggest lever on your Copilot bill.
The codebases that stay cheap to work with are the ones with an index and a protocol in front of them. The ones that stay expensive are the ones where a question means loading a repo and hoping the answer is in there. Build the layer now, while the debt is smaller than it will be, and you get two things at once: a lower bill, and a codebase your agents and your engineers can query without setting money on fire.
Next post I hand this build to a coding agent, so the layer that saves you tokens does not cost you a month of your own time.
Thanks
/J