Until recently, the cost of coding agents in a development team was simple arithmetic: so many licences for so many people. Since 1 June 2026, all GitHub Copilot plans are billed by usage, and Claude Code usage is measured and charged in tokens. The licence is still there, but it is no longer the whole cost.
The idea this insight argues for: with usage-based billing, part of what you spend on agents is no longer set by the contract but by how the team works. A poorly defined task is paid for twice, in tokens while the agent explores and in rework when it gets it right the second time. That is why the specification is also a budgeting tool.
What has changed on the bill
GitHub announced the change on 27 April 2026 and was blunt about it: under the old model, "a quick chat question and a multi-hour autonomous coding session" could cost the same, and that model was "no longer sustainable". Since June, usage is calculated on input, output and cached tokens. Each Copilot Business licence includes $19 a month in credits and each Enterprise licence $39; unused credits are pooled across the company, and anything beyond that is paid separately or capped.
On 28 October, at GitHub Universe, it went a step further: GitHub Enterprise customers can use all Copilot features without buying a separate subscription. In GitHub's words: "You pay for the AI credits you use".
Limit These are the vendors' own figures, checked on 30 October 2026, and prices change often. The Claude Code figures are averages across many teams: the documentation warns that cost per person varies widely with the model, the size of the codebase and the way of working. This is not a comparison of tools or a budget.
And usage will grow. On 16 October, Anthropic published how work has changed inside its own company: by August, the hours of its agents in employee-directed sessions already outnumbered people's hours six to one. It is a single company, which also makes the model, so it cannot be extrapolated. But it shows where the variable part of the bill is heading.
What is not specified gets paid for twice
The Claude Code cost documentation is useful precisely because it talks about habits, not prices. It says: "Vague requests like 'improve this codebase' trigger broad scanning". A specific request, such as adding validation to a function in a given file, lets the agent work while reading little. Every file the agent reads to understand what it is being asked is tokens.
The second payment is rework. The same documentation recommends planning before implementing on complex tasks, to prevent "expensive re-work" when the initial direction is wrong, and giving the agent verification targets (test cases, the expected output) so it checks its own work before someone has to ask for the fix.
Read closely, that is a specification: what needs to change, where, and how you will know it is right. It is what a task written for people is missing, as we explain in an issue is not a spec for a coding agent, and what turns acceptance criteria into something that can be checked, as in your spec is already an eval. Spec-Driven Development (SDD), development guided by specifications, was not born to save tokens. But with usage-based billing, it also helps avoid spending tokens you don't need.
| Per-person licence | Usage-based billing | |
|---|---|---|
| What you pay for | A fixed amount per person per month | The tokens each task consumes, above what is included |
| What drives it up | Hiring more people | Long tasks, vague requests, context the agent has to rebuild, redoing work |
| Who controls it | Procurement, once a year | The team, every day, through how it hands out work; and whoever sets the spending limits |
| What you budget | Licences | Delivered work, with a limit |
onext analysis based on GitHub's announcement (2026-04-27) and the Claude Code cost documentation (checked 2026-10-30)
What changes in practice
None of this calls for a new tool. It calls for deciding four things before the first variable bill arrives:
- Start with a pilot team and take a baseline. It is the Claude Code documentation's own recommendation: "start with a small pilot group" to have a reference before rolling out to everyone. Measure spend and, at the same time, delivery: what to measure is in KPIs for AI development teams.
- Set spending limits before the first bill. GitHub allows budgets per enterprise, per cost centre and per user. On Claude's team and enterprise plans, with usage credits turned on, there are limits per organisation, per group and per person. Deciding the limit after a surprise costs more than deciding it before.
- Budget per delivered work, not per licence. The useful question is not how much each seat costs, but how much each change that reaches production costs, and at what quality. It is the same logic as the value thesis to ask of a development team.
- Hand out specified work. What changes, where, with which acceptance criteria and how it is checked. It is preparing the agent's work, which is the part of people's work that is growing fastest, as we explain in prepare, review and decide.
The vendor sets the price per token. How many tokens each task needs depends, to a large extent, on how your team hands it out.
What this insight does not say
It does not say coding agents are expensive, and it does not promise savings: there is no general figure on whether a team spends more or less with them, and a vendor's averages are nobody's budget. Nor does it compare tools or prices. And do not expect the first month to be the best: DORA devotes part of its work on the return of AI to managing "the initial 'productivity dip' of a new rollout", the early slump of any rollout.
What it does say is that the variable part exists, that it is growing and that it can be managed with things the team already controls. Something similar happens inside a product: what has clear rules is not asked of the model, as we explain in how much of your agent should be code.
Where to go next
If you want to see how your team works with agents before the bill tells you, the diagnostic is free. Before that, you can read how we install the method in AI-Accelerated Development.
Frequently asked questions
How much does a coding agent cost per developer?
It depends on the model, the size of the codebase and how each person works. As a reference, the Claude Code documentation (checked on 30 October 2026) gives an average of around $13 per developer per active day across enterprise deployments, $150 to $250 a month, and under $30 per active day for 90% of users. It is a vendor average, not a budget: prices change often.
Since when is GitHub Copilot billed by usage?
Since 1 June 2026, all Copilot plans are billed by usage, with credits calculated from the tokens consumed. Business and Enterprise licences include $19 and $39 a month in credits per user. In addition, since 28 October 2026 GitHub Enterprise customers can use all Copilot features without a separate subscription and pay for the credits they use (for now, through GitHub's sales team).
Why does a poorly defined task cost more?
Because the agent has to explore more to understand what it is being asked, and every file it reads is tokens. The Claude Code documentation puts it this way: vague requests like "improve this codebase" trigger broad scanning, while specific ones let it work with few file reads. And if the initial direction is wrong, you also pay for the rework.
How do I set a spending limit on my team's agents?
The vendors themselves allow it. In GitHub Copilot you set budgets per enterprise, per cost centre and per user. On Claude's team and enterprise plans, if usage credits are turned on, you set limits per organisation, per group or per person; with the API, limits per workspace. It is worth setting them before the first bill, not after.
How do I budget what my team spends on agents?
Start with a pilot team and take a baseline before rolling it out, as the Claude Code documentation itself recommends. Then look at spend alongside what the team delivers: how much each change that reaches production costs, not how much each licence costs.
Is using coding agents more expensive than not using them?
This insight does not say so, and there is no general figure that answers it. What it does say is that, with usage-based billing, part of the cost depends on how your team hands out the work, and that part can be measured and managed.
Sources
- GitHub, "GitHub Copilot is moving to usage-based billing", GitHub Changelog, 27 April 2026.
- Jay Parikh, "GitHub Universe 2026: Evolving every layer of the stack", GitHub Blog, 28 October 2026.
- Anthropic, "Manage costs effectively", Claude Code documentation (undated; checked on 30 October 2026).
- Nathan Wilmers, Regina Catipon, Maxim Massenkoff and Peter McCrory, "How employment is changing at Anthropic", Anthropic, 16 October 2026.
- DORA, "ROI of AI-assisted Software Development", updated 22 April 2026.
Bernat López is founder and CEO of onext, an AI boutique. He helps development and product teams work with AI with method —specification before building, a person who decides where there is risk and Spec-Driven Development— and applies to his own company what he proposes: onext runs on its own agentic system.
LinkedIn →