GitHub Copilot Usage Reports: Read Per-Model Input, Output, and Cache Tokens
GitHub Copilot’s AI usage report now shows the token detail behind each model’s AI credits: input, output, cache_read, and cache_write. The useful response is not to compare raw token totals and declare a winner. Download the report, sort by AI credits, then use the token columns to explain why a model or workflow consumed them.
The per-model breakdown is available to administrators on Copilot Business and Copilot Enterprise, and to individual Copilot users. Download it from the AI usage page in GitHub billing settings. The August 11 changelog describes the rollout and scope.
What each token column means
The AI usage report groups usage by date, model, and username. For each model, read the fields as follows:
| Field | What it measures | What a high value can suggest |
|---|---|---|
input | Tokens sent to the model | Large prompts, files, tool definitions, or repeated context |
output | Tokens generated by the model | Long answers, large patches, or repeated agent explanations |
cache_read | Cached tokens read for the model | Context was reused instead of sent as fresh input |
cache_write | Tokens written to the model’s cache | Context was stored for later reuse |
| AI credits | The billable AI usage associated with the row | A model-specific cost signal, not a raw token count |
The billing reports reference defines these fields and says that the AI usage report combines them with the model and username dimensions. Use the report’s AI credits and net amounts for cost analysis; two models can consume the same number of tokens but map to different credit totals.
A practical reading workflow
1. Pick one complete reporting window
The report is a usage record, not a live terminal counter. Export one bounded date range and keep the UTC dates with the file. Do not compare a partial day with a full month, or mix a report generated before a correction with one generated after it.
The billing report can be requested from GitHub’s web interface. Keep the original export before adding spreadsheet formulas or grouping rows so the source values remain auditable.
2. Sort by AI credits first
Start with the model rows that consumed the most AI credits. Then compare input, output, and cache values for those rows:
- High
inputwith lowcache_readoften points to large fresh context being sent repeatedly. - High
cache_readcan mean that a long session is reusing context; it is not automatically waste. - High
outputmay reflect a useful large change, a verbose explanation, or an agent loop. The report alone cannot tell which one. - High
cache_writeis a clue that context is being prepared for reuse, not proof of a problem.
These are investigation leads, not quality judgments. Pair them with the task, repository, and accepted changes before changing a model policy.
3. Check model changes before blaming the cache
GitHub’s guidance on optimizing AI usage notes that switching models can invalidate the previous model’s cache because a different model cannot reuse it. Returning to an old session after the cache expires can also rebuild the context. If a team sees a sudden input increase, check model selection and session timing before rewriting every prompt.
The GitHub guide to optimizing AI usage gives the operational context: preserve reusable context where it helps, but do not keep an unnecessarily large conversation alive just to protect a cache.
4. Turn the finding into one bounded change
Choose one change that can be measured in the next report:
- Reduce repeated repository instructions that are already available in a checked-in file.
- Split a large task so an agent does not load unrelated directories.
- Keep a model stable for a workflow that benefits from cache reuse.
- Use a lower-cost model for discovery and reserve a high-cost model for the small part that needs it.
- Add a completion check so a failed tool call does not trigger an unbounded retry loop.
Do not optimize for the lowest token count by removing review, tests, or security context. The goal is more useful work per credit, not fewer tokens at any cost.
What the report cannot prove
Per-model token detail improves cost attribution, but it has important limits:
- It does not measure whether generated code is correct.
- It does not prove that a large input was unnecessary.
- It does not show the business value of a completed change.
- It should not be used to compare teams without considering task mix, repository size, and model availability.
- It does not replace permission and workspace boundaries for an automated coding workflow.
For the last point, keep usage accounting separate from execution safety. A tool can spend few credits and still have too much write access; Codex --approve-for-me is an example of treating automatic review and workspace-write scope as a separate control.
Use the report for a repeatable review
A small monthly review can stay concrete:
- Save the original AI usage report and record its UTC date range.
- Group by model and username, then sort by AI credits.
- Compare input, output, cache read, and cache write for the top rows.
- Sample the corresponding tasks or repositories without exposing prompt contents.
- Make one model, context, or workflow change.
- Re-run the same report shape in the next window.
If the next report has lower credits but also lower accepted changes or longer review time, the optimization was not automatically successful. Treat cost, delivery, and quality as separate measurements.
FAQ
Q: Are input and output tokens priced the same?
A: Do not assume that. GitHub’s AI credit calculation depends on the model and its pricing. Use the model-specific pricing and the AI credits in the report instead of multiplying one raw token total by a universal rate.
Q: Does a high cache_read value mean the workflow is wasteful?
A: No. A cache read means cached context was reused. It can be a sign that a long-lived workflow is working as intended. Compare it with AI credits, fresh input, task outcome, and session behavior before changing the workflow.
Q: Can the usage report tell me which prompt caused a charge?
A: The report provides usage dimensions such as date, model, and username, plus token and credit totals. It is not a transcript or a code-quality report, so use it to identify a review slice rather than to infer the exact prompt or reason for a task’s result.
References:
GitHub Changelog: Per-model token breakdown in the usage report
GitHub Docs: Billing reports reference
Report a typo or broken link, or suggest a related topic.