Until 11 August, a Copilot bill told you what you spent. It did not tell you what you spent it on, and with usage-based models on the menu that gap was becoming a real problem.
The usage report now breaks consumption down per model, and per token type: input, output, cache read and cache write, each mapped to the AI credits it cost.
What it shows
GitHub's framing is that you can now trace exactly how input, output and cached tokens add up to each model's cost. Four token types are reported separately, which is the detail that makes it useful rather than merely informative:
- Input tokens — the context you and the agent sent
- Output tokens — what the model generated, usually the most expensive line
- Cache read — context served from cache, typically at a steep discount
- Cache write — the cost of putting context into the cache in the first place
Where it is, and who can see it
It appears on the AI usage page in billing settings, and administrators can download the AI usage report to get the breakdown as a file.
Access follows the usual split: administrators on Copilot Business and Copilot Enterprise, and all users on Copilot for individuals. That second half matters — individuals get the same visibility into their own spend that an admin gets into a team's, which is not always how these features land.
Why cache read and cache write are the interesting columns
Most people will look at input and output, because those are the numbers they already have a mental model for. The cache columns are where the actionable information is.
Cached input is dramatically cheaper than fresh input — GitHub's own Kimi K3 listing prices cached input at a tenth of the standard rate. A high cache read number relative to input means your work is benefiting from that discount. A high cache write number with low cache read means you are paying to fill a cache you are not reusing, which is what repeatedly starting fresh sessions across many different repositories looks like on an invoice.
That is a working-pattern problem, not a model problem, and it is invisible in any report that only shows a total.
What it lets you finally answer
Three questions that were guesswork last week now have data behind them.
- Is the expensive model actually doing the expensive work, or is it your default for questions a small model would answer?
- Which of these costs is output — genuine generation — and which is context you are dragging along on every request?
- Did last month's increase come from more people, more tasks, or the same tasks routed to a costlier model?
A caution on what to do with it
Resist turning this straight into a per-developer spend league table. Token consumption tracks the shape of the work, not the diligence of the person: someone refactoring a large legacy service will burn more tokens than someone writing new isolated code, and they are not being wasteful.
The report is a good instrument for finding structural waste — a costly model set as a team-wide default, an automation re-sending the same context on every run, a cache that never gets read. It is a poor instrument for judging individuals, and using it that way is the fastest route to people quietly avoiding the tools you bought for them.