GitHub Copilot AI Credits Explained: Estimate Your Monthly Usage Before You Upgrade

Short answer. Copilot’s AI features are metered in GitHub AI Credits. One credit is worth one US cent, every interaction costs a number of credits that depends on the model and the tokens it consumed, and each individual plan includes a monthly allowance that resets on the first of the calendar month whether or not that is your billing date. There is no fixed cost per prompt, so the only honest way to know whether your allowance will last is to measure your own rate for a few working days and project it. The calculator below does that in your browser from six numbers, shows the formulas, and does not store or send what you type.

This article is not a plan comparison. If the question is which plan, the plan-buying guide and the Plan Finder already answer it. This one is for the person who has a plan, has looked at the usage page, and wants to know whether to worry.

All figures were read from GitHub’s documentation on 16 September 2026. They change; the usage page in your own account is the authority for your numbers.

What a credit is

GitHub’s billing documentation defines the unit plainly: 1 AI credit = $0.01 USD. Copilot features that call a model — Chat, the CLI, the cloud agent, Spaces, Spark, and third-party coding agents — consume credits. Code completions and next edit suggestions do not; they are unlimited on every paid plan, and Copilot Free has its own monthly completion count.

The credit is a currency, not a count of prompts. Under it sits the actual meter: tokens. Each interaction sends input tokens to a model, the model produces output tokens, and some context is reused as cached tokens. Each model has its own price per million tokens for each of those, and the price is converted into credits at the fixed rate. That is the whole mechanism, and it is why the questions people ask — “how many prompts do I get?” — do not have an answer.

Why similar prompts cost different amounts

Two prompts of the same length can differ by an order of magnitude in credits. GitHub’s own list of what drives usage is short and worth taking at face value:

• Conversation length and complexity. A long thread resends its context each turn. Turn twenty costs more than turn two even if you typed the same sentence.
• Agentic features. Agent mode and the cloud agent make many model calls for one task — reading files, running tools, revising. One “fix the failing tests” can be dozens of calls across a large codebase.
• Model choice. Output tokens on a frontier model cost several times what they cost on a lighter one. On the pricing page at the time of writing, the cheapest listed models were around $0.20 per million input tokens and the most expensive $20.00, with output prices higher still. A paid plan gets a 10% discount on model costs while using auto model selection.

The practical consequence: your rate is a property of how you work, not of your plan. A developer who asks quick questions in Chat and a developer who runs multi-hour agent sessions on the same Pro plan will exhaust the same allowance weeks apart. That is why this article measures rather than assumes.

Where to read your actual usage

Go to github.com → Settings → Billing and licensing, then the AI usage page. GitHub’s optimisation guide describes it as a breakdown “across every feature and model”, which is what you need: the total tells you where you stand; the breakdown tells you why.

Take two readings. Note the credits used on a working morning, then again a few working days later, and keep the dates. The difference is your sample — the C in the calculator — and the number of days between the readings is D. That is all the data collection there is.

Allowances, the reset, and additional usage

Each paid individual plan includes two kinds of credit, and the documentation is precise about them:

• Base credits — “match with your subscription price and they never change.” $10 buys 1,000; $39 buys 3,900; $100 buys 10,000.
• Flex allotment — “an additional monthly amount on top of your base credits” that GitHub describes as variable, “designed to adapt as the economics of AI evolve.” Base credits are used first; the flex allotment applies automatically afterwards at the same rates.

Unused credits do not carry over. When the allowance runs out you have three documented options: upgrade (charged as the difference between plans, not the full new price), set a budget for additional usage and keep working at the same per-credit rate — a $10 budget covers 1,000 credits — or wait for the reset. The documentation frames the budget as the way to “continue working” once included credits are exhausted; without one, the options it gives are upgrade or wait. Completions are not billed in credits and are unaffected.

This article is about individual plans. Business and Enterprise allowances are per-user amounts pooled at the organisation, with budgets and policies set by an administrator; if that is your situation, the estimation method below still works for your own usage, but the allowance figure is not yours to enter.

Estimating the rest of the period

The method is a rate projection with an honest spread. Six inputs:

• C — credits consumed during a representative sample of working days.
• D — the number of working days that sample covers. Must be positive.
• U — total credits already consumed in the current allowance period, as the usage page shows it.
• R — expected remaining working days before the allowance resets.
• A — your allowance in credits, typed or from a verified preset.
• s — a scenario spread as a fraction, 0 to 1.

The sample sets the rate and nothing else. If the sample days fall inside the current period — which they normally will — U already contains them, and adding C to U would count them twice. The calculator does not.

daily_rate         = C / D

projected_low      = U + daily_rate × R × (1 − s)
projected_central  = U + daily_rate × R
projected_high     = U + daily_rate × R × (1 + s)

additional_credits = max(0, projection − A)      for each scenario

The spread s is a judgement about how representative the sample was. It is not a confidence interval and the three results are not probabilities. If the sample week included a large agent task you will not repeat, narrow it or resample; if it was unusually quiet, widen it. Twenty-five percent is a starting point, chosen because it is easy to reason about, not because anything was measured.

Worked example

Hypothetical numbers, chosen to make the arithmetic visible. Over four working days you used 120 credits (C = 120, D = 4), so the daily rate is 30. The usage page shows 300 credits used this month (U = 300), twelve working days remain (R = 12), the allowance is 700 (A = 700) and the spread is 25% (s = 0.25).

Read that as: on the observed rate this person finishes the month within the allowance with 40 credits spare; if the rest of the month runs a quarter heavier, they go 50 credits over, which at the documented rate is 50 cents of additional usage if a budget is set. That is not a reason to upgrade. It is a reason to set a small budget, or to do nothing.

Usage calculator

Enter your own numbers. Everything runs in this page; nothing is stored, and the only thing reported afterwards is an anonymous count that an estimate was completed and whether the central case was within or over the allowance — never the amounts. The formulas above are the whole method, so the same answer is available by hand.

Three usage patterns

Hypothetical profiles, not measured users. They exist to show how differently the same allowance behaves, and each one uses the calculator’s method with made-up inputs.

The questioner. Uses Chat a few times an hour for explanations and small edits, rarely runs agent mode. A four-day sample shows 60 credits: a rate of 15 per day. With 100 used, 15 working days left and a Pro allowance of 1,500, the central projection is 325 — a fifth of the allowance. The high case is 381. This person will not exhaust Pro and should ignore any upgrade prompt that appears.

The agent user. Runs agent mode on real tasks most afternoons. A four-day sample shows 480 credits: 120 per day. With 900 used on the 12th working day, 10 working days left and the same 1,500 allowance, the central projection is 2,100 and even the low case, 1,800, is over. Additional usage in the central case is 600 credits — $6.00 at the documented rate. The choice is between a budget of that size and a Pro+ plan whose price difference is $29; the budget is cheaper for this month. Whether it stays cheaper is the next section’s question.

The bursty user. Quiet for two weeks, then a migration week where agent sessions run all day. A sample taken in the quiet fortnight projects comfortably; a sample taken in the migration week projects disaster. Neither is wrong; both are unrepresentative. This is the case for a wide spread — 50% or more — or for sampling twice and projecting from each. The honest answer for this pattern is a range, and a budget set at the top of it.

When usage is higher than expected

The AI usage page’s breakdown by feature and model is the first stop. The usual findings, in the order they are usually found:

1. One long conversation. Context is resent every turn. Start a new conversation when the task changes; GitHub’s optimisation guide lists this first among practical measures.
2. Agent sessions on a large codebase. Many calls per task. Scope the request — name the files, state the stopping condition — and set a session limit where the client offers one.
3. A frontier model on routine work. Output tokens on the most capable models are the most expensive line on the pricing page. Move routine edits to a lighter model; the model selector and the choose-a-model lesson are built for exactly this decision.
4. Mid-session model switching. GitHub’s guide notes that switching models mid-session discards cache benefits. Pick a model for the task and stay on it.
5. Third-party agents and cloud agent runs you had forgotten were configured. They appear on the same breakdown.

None of these needs a plan change. All of them change the rate, which is the number the calculator projects from — so re-sample after changing a habit.

When to upgrade, wait, or set a budget

The calculator gives three projections and the allowance. The decision uses all four, and one scenario exceeding the allowance is not a decision.

• All three within — do nothing. Re-sample next month.
• Only the high case over — set a budget for the additional credits the high case implies and wait. The cost of being wrong is cents.
• Central over, by a small margin — a budget, sized to the high case. Compare it with the price difference to the next tier: the upgrade is charged as the difference, so for Pro to Pro+ that is $29 a month for 5,500 more credits. A budget of less than that is the cheaper choice this month.
• Central over by more than the next tier’s price difference, two months running — the upgrade pays for itself and stops being a decision you revisit monthly. Two months, not one, because a single month’s sample is the thing this whole article says not to trust.
• Already over, with days left — a budget now, sized to the remaining days at the observed rate, and the investigation above. The upgrade prompt Copilot shows at this point is the most expensive of the options unless the pattern persists.

A budget is set in US dollars from github.com/settings/billing → Budgets and alerts → New budget; the budget documentation lists the types (product, SKU, or bundled AI credits), the optional alerts at 75%, 90% and 100%, and the “stop usage when budget limit is reached” control, which it says is not offered for user-level budgets because those always enforce a hard stop. Usage draws the budget down at the same one-cent-per-credit rate.

Limitations

This is a planning method, not a billing simulation.

• The projection assumes the sample rate continues. It cannot see the migration week you have not started.
• Working days are your estimate. A period with public holidays or leave needs R adjusted by hand.
• The flex allotment is described by GitHub as variable. The presets here are the totals read on the date shown; your usage page is the authority.
• The credit-to-dollar rate is shown only for additional usage, only at the documented rate on the date shown, and excludes the subscription itself, taxes, and anything not billed in AI credits.
• Nothing here applies to organisation-managed billing, where allowances are pooled and budgets are an administrator’s.
• The three scenarios are arithmetic on a spread you chose. They are not a distribution, and the words “low” and “high” describe the assumption, not the likelihood.

Frequently asked questions

Does a prompt cost a fixed number of credits? No. Cost is per token, per model. A short question to a light model and a long agent session on a frontier model are both “one prompt” and differ by orders of magnitude.

Do unused credits roll over? No. The documentation states that unused credits are forfeited and the allowance resets to the full monthly amount at 00:00:00 UTC on the first of each calendar month.

My billing date is the 14th. When does my allowance reset? On the 1st. GitHub states the reset date is fixed and independent of the subscription billing date. The two periods are different things.

Are code completions counted? No. Completions and next edit suggestions are not billed in AI credits and are unlimited on paid plans. Copilot Free includes 2,000 completions a month.

What happens when I run out without a budget? GitHub’s documented options at that point are to upgrade, to set a budget for additional usage and “continue working”, or to wait for the reset. Completions are not billed in credits and continue. A budget can be set at any point in the month.

Does auto model selection save credits? On a paid plan it carries a 10% discount on model costs, and it may pick a cheaper model than you would have. It does not change the underlying per-token pricing.

Should I upgrade because the high scenario is over? Not on its own. The high case is your own spread applied to your own sample. Set a budget sized to it and look again next month.

Recap and next step

A credit is a cent; usage is tokens times a model’s price; the allowance resets on the first of the month; additional usage costs the same rate if you set a budget. Your rate is a property of how you work, so measure it over a few working days, project it with a spread you can defend, and let the central case against the allowance — not the worst case — drive the decision.

If the projection says the plan is wrong for the pattern, the next step is the Plan Finder, which asks about how you work rather than how much you spend, and names what each plan lacks. If it says the pattern is wrong for the plan, the model choice lesson is where the rate gets fixed. The plans comparison lesson covers the feature differences this article deliberately left out.