Note : Article self-written. AI-assisted editing
Software development teams have been using GitHub Copilot as a coding assistant for a few years now. Predominantly, the usage has been from within the IDE, especially VS Code.
Teams do see productivity benefits from its use, though the techniques for measuring the impact and effectiveness of AI across the SDLC are still evolving at an industry level.
Until recently, most teams did not have to worry too much about how they prompted, how much context they provided, which model they used, or how their agents behaved.
That is changing.
From June 2026, GitHub introduced usage-based billing with AI Credits (AIC). For perspective, the $19 Copilot Business plan includes a standard allowance of 1,900 AIC per user per month, pooled at the billing entity level.
I observe, and also hear from other engineering teams, that many teams are using a large part of their available credits by the middle of the month.
When this happens, it is no longer only an individual problem. It starts affecting teams and, eventually, iteration plans and delivery.
The immediate reaction could be: “Can we buy more credits?”
Of course, we can.
But that should probably be the last option and not the first.
Before buying more capacity, it is worth understanding where the credits are going and whether our agents are using them effectively.
This is yet another article covering a few aspects of managing GitHub Copilot usage, specifically for teams using Copilot agents through VS Code and Copilot CLI.
You cannot optimize something you cannot see. The first step is to establish visibility into AI credit consumption.
GitHub provides REST APIs to get AI credit usage reports. At an organization level, usage can be filtered by time period, user, model and product, providing a useful starting point to understand consumption patterns. At the individual level, VS Code also provides visibility into monthly AI credit usage.
Ref : GitHub billing and usage APIs
For a deeper view, VS Code can export Copilot agent telemetry using open telemetry. Enabling the github.copilot.chat.otel.enabled setting gives visibility into agent interactions, LLM calls, token usage, tool executions and agent turns. The telemetry can be sent to an OTLP-compatible observability backend.
For someone wanting to explore this locally, the Aspire Dashboard provides a simple starting point. Run the dashboard, point VS Code’s OTel endpoint to it, and the traces show how an agent interaction moved through model calls and tool executions. Copilot CLI agent activity can also be traced through an OpenTelemetry setup.
These views answer different questions:
at an individual level, why did this task consume so much?
at a team level, which workflows consistently consume more?
at an organization level, are we getting useful engineering outcomes for what we are consuming?
The objective is not to police people based on the number of tokens they consume. It is to understand the consumption pattern.
Without monitoring and auditability, conversations about AI credit optimization quickly become opinions.
One of the mistakes we can make when working with coding agents is treating them like human developers.
They are not.
At the core, the model is a probabilistic system. Given the context available to it, the model predicts a likely response from what it has learned. It does not have the intuition of an engineer who has worked on your application for three years.
It does not automatically know that a particular architectural decision was made because of an incident two years ago, or that a utility already exists somewhere else in the repository.
When the context is poor, irrelevant or incomplete, the output can also be poor, circuitous or completely wrong. The agent might then search more files, try another approach, rewrite the implementation, run more tools and correct itself. Sometimes it may even correct the correction.
All of this consumes tokens and, eventually, AI credits.
The problem therefore may not be that the agent needs more context. The problem may be that it needs better context.
There is a natural tendency to assume that a larger context window will produce a better result.
If the model can read the entire repository, why not give it the entire repository Because more context is not necessarily better context.
Large amounts of irrelevant information compete with the information that actually matters for the task. They also increase the amount of input the model needs to process.
The goal of context engineering should therefore not be:
“How much context can I provide?”
It should be:
“What is the minimum high-quality context required to solve this task effectively?”
This is where techniques such as context forking become interesting. A useful context can be built once and then forked into focused pieces of work instead of repeatedly rebuilding large conversations or carrying the entire history into every task.
The same principle applies when designing custom agents. A testing agent probably does not need all the context required by an architecture agent. A migration agent does not need every instruction used by a code-review agent.
Context should be treated as an engineering resource, not as an unlimited buffer.
VS Code has an excellent introductory guide on context engineering Guide
The same thinking applies to tools. An agent with access to more tools is not automatically a better agent. Every available capability expands the space the agent has to reason about and potentially explore.
If an MCP server is required for the task, enable it. If it is not required, there is little value in making it part of every agent interaction.
This is especially important when teams start building increasingly capable agents. The temptation is to create one agent that can access the repository, browser, databases, documentation systems, ticketing tools and every internal service.
“Capability is useful. Unnecessary capability is noise.”
Not every task needs the same model.
The cheapest model is not necessarily the right model, and the most capable model is not necessarily the right model either. The work should drive the model selection.
A developer starting a complex feature may use a reasoning model to understand and task the work. Once the tasks are clear, writing and testing the code may be handled effectively by a workhorse coding model. Understanding a simple technology concept may need neither.
The same idea applies to other SDLC roles and workflows.
Using an expensive reasoning model for a trivial task wastes capacity. Using an insufficient model for a complex problem can also waste capacity through repeated failures and corrections.
Plan the work first. Then choose the model.
AI credit efficiency and token efficiency are not identical. GitHub’s usage-based billing considers the model and the tokens consumed. But in real software teams, much of the day-to-day work happens on a smaller set of workhorse models. In those workflows, bloated context and unnecessary agent loops can materially increase consumption.
The quality and efficiency of an agent is not determined by the model alone.
The harness around the model determines how the model gets context, what it remembers, which tools it can use and what happens before and after it acts.
For example,
if a useful discussion has already happened in one session, consider what context should be persisted as memory instead of rebuilding it in the next session.
if the agent is repeatedly searching for information using a poor approach, suggest or provide the right tool.
if something must happen whenever a particular action occurs, use a hook instead of asking the model to remember the rule every time.
Orchestration, context, memory, tools, skills and hooks all influence how efficiently the model works.
The next few sections cover some of these in more detail.
Sometimes the most token-efficient prompt is a tool.
Provide scripts and deterministic tools where they make sense.
We have spent decades building deterministic software. There is no reason to replace every deterministic operation with probabilistic exploration simply because an agent can execute it.
Consider something as simple as finding files or searching for a known pattern. A find, grep or git command may provide the answer directly instead of asking the agent to repeatedly explore the repository.
The same applies to more specialized engineering work.
Most teams have linters, scanners, build tools and repository-specific scripts. There are also countless generic variants of these tools. If a deterministic tool already knows how to find a dependency, identify a vulnerability, validate a convention or inspect repository history, let the tool do that work. Then let the model reason over the result.
If the organization already knows how a task should be performed, there is little value in making every agent rediscover the process every time.
Use memory, but do not confuse memory with context
Memory can help an agent retain useful information across interactions.
The purpose is to preserve information that is likely to improve future decisions: project conventions, architectural decisions, known constraints or useful information discovered during a session.
This can also help optimize sessions. Instead of carrying an increasingly large conversation forward or rebuilding the same understanding in the next discussion, persist the useful knowledge and start the next session with the context required for that task.
Context is what the agent needs for the task in front of it. Memory is what may help the agent across tasks.
Treating both as unlimited storage will eventually recreate the same context problem in another form.
VS Code and GitHub Copilot make it relatively easy to define custom agents. That does not mean we should build one agent to run the entire SDLC.
Large workflows create large contexts and make failures harder to understand. When an agent takes a wrong path, a large autonomous workflow can also consume significant tokens before anyone notices.
Instead, consider smaller agents with clearly defined responsibilities: understand and task a feature, implement a well-defined change, review code, test a change or investigate a particular type of failure.
These agents can still be part of a larger workflow, but each should know what it is responsible for and what it is not.
Agent skills can help keep the base agent smaller. Instead of putting every instruction into the agent definition, specialized skills can be loaded when the task needs them.
Certain deterministic guardrails can be executed through hooks instead of repeatedly explaining them to the model and hoping it follows the instructions every time.
Again, the objective is not merely to save tokens. It is to make the agent system more predictable.
Token efficiency is often a side effect of good engineering.
Formatting, validation, policy checks, telemetry and other predictable actions can often be triggered at specific points in the agent lifecycle.
“If A happens, do B” - that is usually a better job for a deterministic hook than another paragraph in the agent’s instructions.
As teams build more agents, skills and hooks, duplication will naturally appear.
One team creates a review agent. Another creates something similar. Multiple teams build variations of the same skills and hooks, each with different instructions and different consumption patterns.
Github copilot plugins provide a way to package and share agents, skills, hooks and integrations for Copilot CLI.
This creates an opportunity to take effective agent patterns beyond one team. Useful agents can be reviewed, improved and shared across the organization. Duplicate implementations can be reduced, governance can be introduced, and expensive or inefficient patterns can be identified once rather than rediscovered by every team.
Over time, an organization can build a governed collection of proven agent capabilities. This is not only about distributing agents. It is also a way to manage how agents are engineered and used across the organization.
Evals help teams understand whether an agent is achieving the expected outcome and whether changes made to optimize it actually improve the system.
This is important because reducing tokens does not automatically mean improving efficiency.
An agent that consumes more tokens but produces a correct result in one attempt may be more effective than one that consumes fewer tokens per attempt but needs repeated retries and human intervention.
Evals provide the evidence to make that distinction.
They can also help identify where consumption is being wasted.
Is the system prompt unnecessarily verbose?
Is redundant context repeatedly being loaded?
Is the agent searching for information that could have been provided through a tool?
Is its reasoning circuitous for the problem?
Are self-correction loops improving the result or simply consuming more credits?
... and more
Without evals, teams may optimize for fewer tokens and accidentally reduce effectiveness.
This becomes even more important for autonomous and semi-autonomous agents. Self-correction is useful when it improves the outcome. Unbounded self-correction is simply an expensive loop.
AI credits are becoming another engineering resource that organizations need to manage.
That does not mean asking people to use AI less or creating arbitrary token budgets.
Start with monitoring and auditability. Understand which workflows consume credits and why. Engineer the context, models, tools, memory, skills, hooks and agents based on what you observe. Use evals to check whether the changes actually improve the outcome. Then measure the consumption and cost again.
If the system is well engineered, the usage is understood and the organization is getting meaningful value from the additional consumption, buying more credits is a reasonable capacity decision.
But if credits are being consumed by bloated context, unnecessary tools, poor model choices, duplicated agents or uncontrolled self-correction loops, buying more credits only funds the inefficiency.
AI credit management may therefore not really be a billing problem.
It is becoming an agent engineering problem.
And like most engineering problems, the answer starts with understanding the system before adding more capacity.
GitHub — Usage-based billing for organizations and enterprises https://docs.github.com/en/copilot/concepts/billing/usage-based-billing-for-organizations-and-enterprises
GitHub — Copilot plugins https://docs.github.com/en/copilot/concepts/agents/about-plugins
VS Code — Context engineering guide https://code.visualstudio.com/docs/agents/guides/context-engineering-guide
VS Code — Agent best practices https://code.visualstudio.com/docs/agents/best-practices
HumanLayer — Skill Issue: Harness Engineering for Coding Agents https://www.humanlayer.dev/blog/skill-issue-harness-engineering-for-coding-agents