Turn GitHub minutes, core-hours, and Copilot credits into real cost

How does GitHub bill for usage?

GitHub’s costs split into two kinds. There’s the plan you’re on — Free, Pro, Team, Enterprise — a fixed subscription that comes with an included allowance each month. Then there’s metered usage: the consumption that runs past that allowance, charged by what you use and tallied on a calendar-month cycle, the 1st through the last day. The subscription is predictable. The metered part is where the bill moves, and the three products that move it most for a working developer are Copilot, Actions, and Codespaces.

Copilot, GitHub’s AI coding assistant, is billed by usage, metered in AI credits. How many credits a request spends depends on the model and the kind of request, so two developers on the same plan can run very different Copilot bills. Each plan includes a monthly credit allowance, and usage past it is metered. The one difference that matters for tracking: Copilot is metered per seat and per request rather than per repository, so it lands in your spend by SKU (the Copilot credit lines) rather than against a single repo. It rides the same usage feed as everything else, so it folds into your GitHub total. For an AI-spend dashboard, Copilot credits sitting next to your model-API calls is exactly the view you want.

GitHub Actions, GitHub’s built-in automation — where a workflow (an automated job triggered by a push, a pull request, or a schedule) runs on a hosted runner — is billed by the minute, but not every minute costs the same. GitHub sets a per-minute rate for each runner type, and they’re far apart: Linux is the cheapest, Windows costs more, and macOS costs the most by a wide margin. The runner you pick can swing a job’s cost more than its runtime does. Each plan includes a monthly pool of free Actions minutes and a slice of artifact storage (shared with GitHub Packages) before metering starts:

Plan	Free Actions minutes / month	Included storage
Free	2,000	500 MB
Pro	3,000	1 GB
Team	3,000	2 GB
Enterprise	50,000	50 GB

Those allowances cover private repositories; usage on public repositories with standard runners is free. Actions cache is separate — a 10 GB per-repository limit GitHub evicts from when it fills, not metered storage. (Per-minute rates for each runner live on GitHub’s Actions billing reference, and the allowances on the included-usage reference — both were revised at the start of 2026, so treat any number you’ve memorized as provisional.)

Codespaces, GitHub’s cloud development environments, is billed on two axes at once: compute, metered in core-hours while a codespace is actively running, and storage, metered in gigabyte-months while the codespace or its prebuild data is retained. Compute scales with the size of the machine: a bigger machine burns core-hours faster. Only an actively running codespace is billed, so a suspended one stops the compute clock while its storage keeps ticking. Personal accounts include a monthly allowance — 120 core-hours and 15 GB-month on Free, 180 core-hours and 20 GB-month on Pro; organizations get no free Codespaces quota, so every org core-hour is metered from the first minute. The Codespaces billing reference carries the current figures.

Those three don’t account for everything. GitHub also meters Packages and storage and Git LFS in the same report, each with its own allowance and unit. CostCompass reads GitHub’s billing feed whole, so any metered product GitHub itemizes for you shows up. Copilot, Actions, and Codespaces are just the ones most likely to dominate a developer’s bill.

What you’re paying for	How GitHub meters it
Copilot usage	AI credits, by model and request (per seat, not per repo)
Actions runtime	Minutes × the runner’s per-minute rate (Linux cheapest, macOS priciest)
Codespaces compute	Core-hours, while the codespace is actively running
Codespaces storage	Per gigabyte-month, while the codespace or prebuild data is kept
Plan allowance	A free pool each month; metered charges begin once you pass it

Why is GitHub spend hard to keep ahead of?

The metering is what makes GitHub flexible, and it’s also what makes the spend resist a quick glance. Most of the difficulty comes down to the gap between using and being charged:

• The number settles late, and stops at GitHub. GitHub does show a running spend estimate while the cycle is open, but it’s a single figure for GitHub alone, with no forecast of where the month lands, and it only finalizes once the cycle closes. By then the runs that drove it are behind you. (GitHub’s usage-summary endpoint also reaches back only about two years, so the long view isn’t there to pull either.)
• The free allowance hides the cliff. Usage inside your plan’s allowance costs nothing, so spend reads as zero right up until you cross the line and, on private repos, every further minute is billed. The running view doesn’t announce the moment you go from free to metered.
• A small change moves the bill silently. Switch a job from a Linux runner to macOS, add a matrix leg, or let a workflow trigger more often, and the cost moves even though your code didn’t. Because runner rates are far apart, where a job runs can matter as much as how long it runs.
• The units don’t add up by eye. One product bills in minutes, another in core-hours, a third in AI credits, and there’s no common denominator until GitHub resolves them to money, which it does only after the fact. The raw usage view won’t put them side by side as cost, ranked by product.
• GitHub is rarely your only provider. Alongside it you’re likely calling Anthropic for Claude, building on OpenAI or Gemini, maybe reaching for DeepSeek, and paying for inference hosts and serving, so GitHub is one slice of a bill you otherwise stitch together by hand from a stack of dashboards.

Is the GitHub cost exact or estimated?

Exact, as GitHub reports it. This is where GitHub differs from a token-metered API. Claude and OpenAI hand back counts and leave you to price them; GitHub’s billing feed already carries the money for each usage line, the billable amount after your plan’s included-usage discount has been applied. CostCompass records that figure as reported and doesn’t recompute it from a rate table, so there’s no estimate to drift and the free-tier discount is already baked in. The per-product number you see is the one GitHub reports for that usage, not a reconstruction of it.

How can you reduce your GitHub bill?

Tracking shows you where the minutes go; a few levers slow the burn:

• Mind the runner. Because the spread between runner rates is wide, moving a job off macOS or Windows onto Linux where it can run there is usually the single biggest lever, far more than shaving seconds off a job that was already cheap per minute.
• Trim what runs, and how often. Cancel superseded runs on a branch, scope path filters so a workflow only fires when relevant files change, and prune matrix legs that don’t earn their minutes.
• Suspend idle Codespaces. Compute is only billed while a codespace is actively running, so letting them suspend promptly stops the meter, and cleaning up ones you’ve finished with stops the storage charge too.
• Watch Copilot credits. Copilot bills by model and request, so leaning on premium models or heavy agent runs burns credits faster than routine completions. The per-SKU view catches a Copilot climb before the month closes.
• Watch the per-product split. A ranked, by-product view catches a runaway workflow or a Copilot spike in days, while the month-end total would only show it once it’s already been paid.

How do you forecast next month’s GitHub bill?

Forecasting metered usage doesn’t need anything exotic, just a burn rate: take your spend over the last several days, turn it into a daily average, and project that across a full month.

CostCompass does exactly this. It scales your trailing seven-day burn rate to the number of days in next month and adds any fixed subscriptions you’ve entered, your plan fee included, and the result is one forward number for what next month costs if the current pace holds. Seven days is the window we settled on: long enough that one heavy CI day doesn’t throw the average, short enough to pick up a recent change like a workflow that started leaning on a pricier runner. For most solo developers that trade-off matters more than a perfectly attributed historical figure. Because GitHub reports cost exactly, that projection rides on real figures, and it’s the same engine that runs across every provider you’ve connected, so GitHub folds into one whole-stack number.

How does CostCompass track your GitHub costs?

CostCompass reads GitHub’s billing usage API one day at a time and records the money GitHub reports for each line, by product and by SKU. Because that feed already carries the net cost, there’s no pricing table in the loop and no estimate to drift; CostCompass keeps GitHub’s own figures and arranges them so you can read the month as it builds. When you first connect, CostCompass pulls a recent window of usage rather than your whole history, and each refresh brings the running total current.

Two things make that practical for a solo developer. First, your token is encrypted in your browser before anything is stored. The token you paste is sealed with your vault password on your own device, and only the sealed version is ever saved: a blob CostCompass can’t open, because the vault password stays with you. When it’s time to read your usage, your browser unseals the token and passes it to a relay that uses it for that one call to GitHub and is built not to log or keep it. The only copy we keep at rest is that ciphertext. The plaintext lives in your browser, and passes through that relay only for the instant of a fetch.

Second, GitHub doesn’t sit alone. The same dashboard rolls its running total up with every other AI and compute provider you’ve connected — Claude, OpenAI, your hosting — into one figure with a forecast. How you get to that cross-provider number, whether by hand, through tooling, or read straight from each billing API, is its own decision; the ways to track AI costs across providers lay the options out side by side.

	GitHub’s billing page	CostCompass
Timing	Running estimate, settles at month-end	Running total, current when you Refresh
Forecast	Spending trends only; no burn-rate forecast	Month-end projection from your burn rate
Breakdown	Per-product and per-repo, buried a few clicks deep	Ranked by product and SKU, up front
Scope	GitHub only	GitHub beside every other provider

Getting started takes three steps:

1. In GitHub, create a fine-grained personal access token with read access to billing — the Plan permission for a personal account, or Administration for an organization.
2. Paste it into CostCompass. It’s encrypted in your browser before it’s stored, so the server only ever holds ciphertext.
3. Click Refresh. CostCompass reads your usage feed and, from there, your running total and forecast roll up, broken down by product, with GitHub folded into the whole-stack number.

Prefer not to manage a token, or running this for an organization that installs apps centrally? Connect with the GitHub App instead — the “Connect with GitHub” path authorizes CostCompass to read the same billing data without a token to paste or rotate.