GitHub Copilot, what changed and what it costs

GitHub Copilot, what changed and what it costs

Copilot began as code completion in an editor and for years that was its whole function. Today it covers conversation about code, an agent mode running multi step tasks, change review, and a separate agent working on repository issues.

Billing changed alongside that, and it is the most important thing when planning spend. From June 2026 request units gave way to credits charged by tokens processed, so cost depends on how large the tasks you assign are rather than on how many times you clicked.

What is unlimited and what costs

That distinction drives the bill and is worth remembering before choosing a plan.

Code completion in the editor is unlimited on every paid plan. Suggestions while typing consume no credits, however many you accept.

Credits are consumed by conversations with a stronger model selected, by agent mode, and by the agent working on issues. Volume decides there: a task spanning ten files processes many times more tokens than a question about one function.

The practical conclusion runs against intuition. Heavy use of code completion all day brings you nowhere near the limit, while three large agent tasks can eat a sizeable part of the monthly allowance. Planning cost therefore means counting agent tasks rather than hours worked.

Plans

Choosing among individual plans depends solely on how much agent work you do.

Worth noticing here: on individual plans the credit allowance exceeds the subscription price. Ten dollars carries fifteen dollars of credits, thirty nine carries seventy, one hundred carries two hundred. Team plans work on a different ratio, where the allowance equals the seat price to the dollar. Through the end of August 2026 existing team customers hold a promotionally raised allowance, thirty dollars on Business and seventy on Enterprise, so a bill measured over this summer will not reflect the months that follow. If you mainly use completion and occasional chat, the base plan suffices with room to spare. If you assign multi file tasks daily, a higher plan costs less than buying credits.

Set a spending cap straight away. Without it, exceeding the allowance moves you onto usage billing, and the bill appears only at month end.

Agent mode

This is the biggest change from the original tool. Rather than suggesting the next lines, the agent plans a task, changes files, runs commands, reads their output, and corrects itself until it finishes.

Three habits separate useful work from cleaning up after it. The first is a clean repository state before starting, so the agent's changes stay distinguishable from your own. The second is tasks the size of one commit, since a diff covering forty files will not be reviewed. The third is reviewing changes before accepting, exactly as with somebody else's code.

A separate variant is the agent working on the repository side. You assign it an issue, it works in the background and opens a change proposal. That arrangement suits repeatable, well described tasks: updating dependencies, adding tests to an existing function, fixing typos in documentation.

For tasks needing a design decision the same arrangement fails, since the agent decides for you and you find out from a finished proposal. That is why the issue description drives the result more than the model choice does.

Project instructions

The cheapest thing you can do for suggestion quality and the most often skipped. An instructions file in the repository reaches the context of every request.

# Project conventions

- TypeScript in strict mode, no any type
- Function components with typed props
- API calls only through `src/api/client.ts`
- Tests next to the source file, named `*.test.ts`
- No comments in generated code

A good instruction says what not to do rather than only what to do. A model reaches by default for the most popular solutions rather than the ones you adopted, so the difference between two phrasings of the same principle is considerable.

Weak:
- We write tests

Better:
- Tests are written against behaviour, not against the implementation
- We do not mock the database layer, we use testcontainers
- Every bug fix starts with a test reproducing that bug

The first phrasing changes nothing, since the model already believes it writes tests. The second cuts off specific choices it would otherwise make on its own.

Instructions can also be scoped to areas of a repository, so front end rules stay out of the context when working on the back end.

.github/copilot-instructions.md          rules for the whole repository
.github/instructions/frontend.instructions.md
.github/instructions/api.instructions.md

An area file opens with a header naming the paths it concerns, and enters the context only for those.

---
applyTo: "src/api/**/*.ts"
---

- Every endpoint returns a Result type, never throws to the HTTP layer
- Input validation through zod in schema.ts next to the route
- Errors are logged with requestId, request bodies are never logged

In a large repository that split noticeably improves accuracy, since the context does not swell with rules that do not currently apply.

Model choice

On paid plans you can pick a model for chat and for agent mode, choosing between families from different vendors. Availability depends on plan tier.

The selection rule is simple and follows from cost. A cheaper or automatically chosen model handles questions about code, explanations, and small edits. Take a stronger one for tasks spanning many files or requiring reasoning about architecture.

Pinning the strongest model to everything is the most common cause of an allowance running out early. The quality difference on a simple question is slight, and the credit difference is several times over.

It pays to test a few models on your own repository, since the differences depend on the programming language and project style more than on general comparisons.

For that comparison to mean anything, record the result in numbers rather than impressions.

task,model,minutes,correction_rounds,passed_verify
add field to order,cheaper,18,2,yes
add field to order,stronger,12,0,yes
endpoint migration,cheaper,55,6,no
endpoint migration,stronger,31,1,yes

The correction rounds column says more than the time does. A model needing six rounds consumes the developer's attention at each one, and that is a cost no comparison table shows. An hour spent on such a comparison gives an answer no public results replace.

Change review and team work

Beyond the editor the tool also runs in the browser, on change proposals. It can generate a change description, suggest comments, and point at places worth a reviewer's attention.

The value sits somewhere other than expected. A generated review does not replace a person, since it knows neither the business context nor what the team fears in that module. It does help as a first pass catching the obvious: missing error handling, inconsistent naming, a skipped edge case.

The practical arrangement runs like this: automated review as a pre filter, a person as the decision. The reverse order, accepting changes on the strength of an automated review alone, shifts responsibility onto a tool that cannot carry it.

Team plans add access management and organisation wide settings, including excluding chosen repositories and directories from context. That is the first thing to configure when rolling out inside a company.

Working with context in chat

Answer quality depends above all on what the model sees. In chat you attach context explicitly, by naming files, a selection, or command output.

Referencing a selected fragment is simplest and suffices for questions about a specific function. Naming a file or directory helps when the matter concerns structure. Attaching an error from the terminal turns a general question into one about a specific situation.

Know also what the model does not see by default. Unsaved files, files outside the open directory, and dependency contents usually stay out of context, so a question about an external library's behaviour rests on the model's knowledge rather than on the code in your project.

The practical rule: the more specific the question and the narrower the context, the better the answer. Asking to "fix this code" without saying what is wrong yields an arbitrary change. Asking "this function misses the empty list case, add handling and a test" yields exactly what you meant.

Rolling out to a team

A tool bought for ten people without agreements yields ten different ways of working. A few decisions made at the start save tidying up later.

The first concerns the instructions file. It should be written once, live in the repository, and go through review like any other code. Instructions kept in personal settings work for one person only and drift between team members.

The second is exclusions. Directories holding secrets, production configuration, and test data belong outside the context at organisation level, before somebody asks a question touching them.

The third is rules for accepting an agent's changes. A proposal opened by the agent goes through the same review as one from a person, and whoever assigned it answers for its content.

The fourth is a usage review after the first month. It usually turns out that two people consume most of the allowance and the rest almost none, which is a signal to change plans rather than to raise everybody's limit.

Copilot against the alternatives

This tool's biggest advantage is where it sits. It runs in the editor you already use, in the browser during change review, and in the repository itself on issues. For a team working on that platform it means one bill and one permission set rather than a separate tool alongside.

A dedicated editor's advantage is deeper project understanding, since it indexes the repository and works on more context. The difference registers on architecture questions and is slight on code completion. One assistant has dropped out of that comparison. Amazon Q Developer no longer accepts new subscriptions, and its IDE plugins together with the paid plans reach end of support on 30 April 2027, so teams that kept it for in editor Java and .NET modernisation have to finish those transformations earlier or move to Kiro. The AWS Console version is unaffected, so the migration only concerns work inside the editor.

These tools do not exclude each other, and some teams run two at once: this one during change review and issues, another while working on code. The cost of that arrangement is often lower than one top tier plan, since each tool handles what it is cheaper at.

Remember, though, that the differences between tools are smaller than the difference between using them with the project conventions written down and without. Before switching tools because the suggestions are poor, check whether the repository holds anything describing them.

Common mistakes

The first is working without an instructions file. The model then suggests popular solutions rather than the ones adopted in your code, and every suggestion needs fixing.

The second is pinning the strongest model permanently. The credit allowance runs out mid month, and the quality difference on simple questions is slight.

The third is no spending cap. Once the allowance is exceeded, billing moves to usage, so the bill grows quietly until month end.

The fourth is tasks too large for the agent. A change proposal covering forty files enters the repository unreviewed, since nobody will read it end to end.

The fifth is accepting generated tests as proof of correctness. A test written by a model for code written by a model confirms what the code does rather than what it should do.

The sixth is assigning the agent issues described in one sentence. The result matches the description, so an issue like "improve performance" ends in a proposal you can neither accept nor sensibly reject.

FAQ

What does GitHub Copilot cost?

The free plan gives two thousand completions a month plus a limited number of chats. The base plan costs ten dollars and carries fifteen dollars of credits, the higher tiers thirty nine and one hundred dollars with allowances of seventy and two hundred dollars respectively. Team plans are nineteen and thirty nine dollars per person.

Does code completion consume credits?

No, it is unlimited on paid plans. Credits are consumed by chats with a stronger model selected, by agent mode, and by the agent working on issues, charged by tokens processed.

Copilot or Cursor?

Choose Copilot when you want to stay in your editor and work in a team on that platform, since the integration also covers change review and issues. Choose Cursor when you want deeper whole repository context while working across many files at once.

Is my code used to train models?

On team and company plans code is not used for training. On individual plans check the settings, since some options are on by default and can be switched off in the account configuration.

How do I improve suggestion quality?

Add an instructions file to the repository describing project conventions, particularly what you do not do. It is the cheapest possible improvement, applying to every request, and noticeably more effective than switching to a stronger model.

Documentation sits on the GitHub site, and current price tiers on the plans page.