Since June 1, 2026, GitHub's coding assistant is no longer just a subscription you forget about in your software expenses. GitHub turned on usage-based billing in AI Credits for all users and all affected plans, as announced in its June 1 changelog: Updates to GitHub Copilot billing and plans. The change is simple to sum up but important to manage: advanced uses of the assistant now consume credits, with 1 GitHub AI Credit equal to $0.01 according to GitHub's documentation for organizations and enterprises and individuals.
The right decision isn't to panic, or to switch the assistant off everywhere. It's to separate the uses that stay predictable from autonomous agent uses that can become variable, then put light governance around the latter. For a freelance developer, a small SaaS team or a technical founder, the real stake is turning this assistant into a measured lever rather than an opaque cost line.
What really changes
An important fact: not all of the assistant's features are in the same basket. GitHub states that Chat, the CLI, the coding agent, Spaces, Spark and third-party coding agents are among the features billed in AI Credits. On the other hand, code completions and next edit suggestions are not billed in AI Credits on paid plans. This distinction changes the adoption policy.
Before, many teams talked about the assistant as a single tool. In practice, you now have to talk about two families. The first is continuous assistance in the IDE: autocomplete, contextual suggestions, small local speed-ups. The second is execution by autonomous agents: long conversations, plan generation, changes spanning several files, remote agents, automated code review, the CLI and more expensive models. The first stays close to a fixed cost. The second looks more like infrastructure consumption.
On quotas, GitHub documents included monthly allowances. For individuals, the $10 Pro plan includes 1,500 credits per month, the $39 Pro+ plan includes 7,000 credits, and the $100 Max plan includes 20,000 credits. For organizations, GitHub states 1,900 credits per user per month on Business and 3,900 on the standard Enterprise plan. A promotional allowance applies from June 1 to September 1, 2026: 3,000 credits for Business and 7,000 for Enterprise. These figures should be read as starting budgets, not as a guarantee that every agent-automated workflow will go through without trade-offs.
Another concrete point: GitHub specifies that there's no automatic fallback to cheaper models when the budget runs out. A user or an organization has to either set an additional budget or wait for the renewal. That's a major operational detail: without a team rule, a developer can get blocked at the worst moment, or on the contrary consume more than planned if additional budgets are too permissive.
The sensitive case: code review and remote agents
GitHub's automated code review deserves a line of its own. GitHub announced on April 27, 2026 that Copilot code review would start consuming GitHub Actions minutes on June 1, 2026. The June 1 changelog confirms that code review consumes AI Credits, and GitHub specifies that for private repositories running on GitHub-hosted runners, it also consumes GitHub Actions minutes. Public repositories see no change on the Actions minutes side.
This is exactly the kind of composite cost that surprises teams. An automated review isn't just a model call. It can also eat into the CI allowance. For a team that triggers automated code review on every pull request, including small wording or configuration changes, the signal-to-price ratio can deteriorate. For a team that reserves it for risky PRs, migrations, security changes, cross-cutting refactorings or areas with little test coverage, the cost can stay defensible.
The same logic applies to GitHub's coding agent. The remote agent is interesting when it takes on a bounded, testable and isolated task. It becomes financially and technically dangerous when it serves as the default reflex to explore a fuzzy problem. The longer a session runs, the more the context grows, the more expensive the model called can be, and the more the output has to be reviewed. A coding agent is an excellent executor on a well-scoped task; it's a poor substitute for an unclarified product or architecture decision.
What to believe, and what to put in perspective
Articles from TechCrunch and Tom's Hardware report real tension among developers: concerns, accounts of sharp increases, a perceived sticker shock. These sources are useful for understanding the market's reaction, but they should be handled with care. Anecdotes from Reddit, X or isolated testimonies don't prove a typical cost for all teams.
The solid fact lies elsewhere: variable pricing is active, credits have a documented value, several advanced features are affected, budgets exist, and some uses can also hit GitHub Actions. The reasonable analysis is therefore: the risk isn't necessarily a universal cost explosion, but a new variance. Two teams with the same number of developers can get very different bills depending on how they use Chat, the CLI, code review, remote agents and frontier models.
It's precisely this variance that you need to instrument before rolling out further.
Action plan for a technical team
First decision: measure before expanding. For two to four weeks, keep the assistant enabled, but track consumption per user, per feature and per project type. The goal isn't to police developers. It's to identify the workflows that truly produce value: test generation, repetitive migrations, exploring legacy code, review on sensitive PRs, internal scripts, technical documentation.
Second decision: separate autocomplete and agents in the internal policy. Completions and next edit suggestions remain an everyday productivity use. Agents, long conversations, the CLI, Spaces, Spark and code review should be classified as variable-budget uses. This distinction avoids sterile for-or-against-the-assistant debates. You can be very much in favor of autocomplete and very strict about costly agent sessions.
Third decision: set budgets at the user and organization level. GitHub states that user-level budgets are generally available. For a freelancer, that means setting an additional ceiling compatible with engagement margins. For a team, it means starting with modest ceilings, then raising them for profiles that show a concrete return: a lead on a migration, the maintainer of a large monolithic repository, a developer tasked with improving test coverage or tackling identified technical debt.
Fourth decision: limit long sessions and frontier models. The best models are useful, but not for everything. A simple rule works well: a standard model for local explanations, bounded refactors or simple test generation; a more advanced model for architecture, a hard bug, a cross-cutting migration or reasoning across several systems. And in every case, ask the agent for a short plan before execution, then validate the scope. That cuts back-and-forths and unnecessary consumption.
Fifth decision: reserve automated code review for pull requests that deserve an automated second look. PRs touching dependencies, security, payments, permissions, sensitive business logic, refactoring across several modules or poorly tested code are good candidates. Trivial changes aren't. This rule is easy to document and avoids consuming both credits and, in some cases, Actions minutes without a proportionate gain.
Sixth decision: update environments. GitHub lists minimum versions for some clients: VS Code 1.120, Visual Studio 17.14.33 or 18.6.0, JetBrains plugin 1.9.1 and GitHub CLI 1.0.48. A cost policy that relies on outdated tools is fragile. Before drawing conclusions about consumption, make sure the team uses compatible versions and that budget settings are clearly visible.
Seventh decision: document a one-page team policy. No need for heavy rules. A good internal note is enough: which uses are free, which uses need a budget, when to use code review, which models to choose, how to flag abnormal consumption, and how to decide on a ceiling increase. This document should be reviewed after the first month of measurements.
Should you compare alternatives now?
Yes, but not before instrumenting usage. Comparing Cursor, Claude Code, JetBrains' assistant, open-source tools or in-house agents without knowing your own consumption profiles amounts to comparing abstract prices. The real question isn't only the monthly cost. It's the cost per useful task: PR reviewed, test added, bug fixed, migration completed, developer time saved, risk reduced.
For a freelancer, the economic criterion is blunt: the tool must either increase billable capacity, reduce unbilled time, or improve the quality delivered. For a product team, it must speed up cycles without degrading human review, tests and maintainability. In both cases, the right sequence is: measure the assistant, identify the expensive workflows, optimize the rules, then compare alternatives on the same scenarios.
My recommendation: adopt the new model with active caution. Keep the assistant for IDE assistance. Test agents on bounded tasks. Set budgets now. Reserve automated reviews for risky PRs. Review the data after a month. This isn't a crisis to react to in the heat of the moment; it's the point where coding assistants become a line of software infrastructure to be managed as such.
FAQ
Will the assistant necessarily become much more expensive?
No. Secondary sources report concerns and accounts of sharp increases, but that doesn't prove a typical cost. The solid risk is variability: autonomous agent uses can cost very different amounts depending on practices.
Are code completions billed in AI Credits?
GitHub states that code completions and next edit suggestions are not billed in AI Credits on paid plans. The affected uses are mainly Chat, the CLI, the coding agent, Spaces, Spark, third-party agents and code review.
What simple rule can I apply today?
Measure for a month, set budgets, separate autocomplete and agents, and reserve automated code review for risky or complex pull requests.
Should I switch tools immediately?
Not without data. It's better to instrument the assistant's consumption, identify the costly workflows, then compare alternatives on the same real tasks.