The free-minutes number on a CI pricing page is the least useful figure for predicting your bill. GitHub Actions bills wall-clock minutes with per-OS multipliers, CircleCI bills credits tied to machine size, and Buildkite mostly doesn't bill minutes at all — it charges per user and lets you bring your own compute. Pick wrong and a "generous free tier" turns into a surprise invoice the first time someone adds a macOS job or bumps a runner to 8 vCPUs.
I've run all three on real projects. Below is how each one actually meters your work, where the hidden multipliers live, and which model fits which team as of mid-2026.
Why don't "free minutes" tell you what you'll pay?
Because a minute is not a minute. Every provider prices against some unit of compute, and the marketing headline collapses that unit into a flat count that only holds for the cheapest possible job.
The three models are genuinely different:
- GitHub Actions meters wall-clock minutes, then multiplies by an OS factor. Linux is the baseline; Windows and macOS cost several times more per minute. Public repositories run for free on GitHub-hosted runners; private repos get a monthly included allotment tied to your plan, and overage is per-minute pay-as-you-go.
- CircleCI meters credits, and credits are consumed at a rate set by the resource class (the machine size) you pick per job. A small container burns credits slowly; a large machine or a GPU class burns them fast. The free plan includes a monthly credit bucket.
- Buildkite mostly doesn't meter your build compute at all on the self-hosted model. You run agents on your own infrastructure, and Buildkite charges per active user for the orchestration layer. It has a hosted-compute offering too, but the default mental model is "we sell the control plane, you rent the machines."
The takeaway: compare pricing models, not free-tier numbers, or you're comparing a Linux minute to a macOS minute to a per-seat fee.
How does each one bill in practice?
Here's the same question — "what am I actually paying for?" — answered per provider.
| Provider | Billing unit | Free/included allowance | Biggest cost multiplier |
|---|---|---|---|
| GitHub Actions | Wall-clock minute × OS factor | Unlimited for public repos; monthly minute allotment for private repos by plan | macOS and Windows runners cost multiples of a Linux minute |
| CircleCI | Credits consumed per resource class | Monthly credit bucket on the free plan | Large/GPU resource classes drain credits far faster |
| Buildkite | Per active user (self-hosted agents) | Small free tier of users | Your own cloud bill for the agents you run |
Two things to notice. First, GitHub and CircleCI both scale cost with how heavy each job is, but they expose that differently — GitHub through the OS multiplier, CircleCI through the resource class. Second, Buildkite moves the compute cost off its invoice and onto your cloud provider, which is cheaper at scale but only if you already know how to run and secure your own runners.
The unit you're billed in decides which optimization actually lowers your bill.
When does GitHub Actions get expensive?
Actions is the default because it's already in the repo, and for public open-source projects it's effectively free. The pain shows up in three places.
The OS multiplier is the classic trap. A test suite that costs a handful of Linux minutes costs the same wall time on macOS but bills at a much higher rate — macOS is the most expensive tier by a wide margin, which matters the moment you build iOS or run cross-platform matrices. If your matrix fans out to Linux + Windows + macOS on every push, your minute count and your bill diverge hard.
The second trap is matrix sprawl. Actions makes it trivial to add another axis to a build matrix, and each cell is billed independently. A 3-OS × 4-version matrix is 12 parallel jobs, and the included allotment evaporates.
The third is that self-hosted runners are free on minutes but not free on effort. You stop paying GitHub per minute, but you now own runner provisioning, security patching, and the real risk that a self-hosted runner on a public repo can be abused by malicious pull requests if you don't lock down when it runs.
GitHub Actions is cheapest when your workload is Linux-first and your matrix is disciplined; it punishes macOS-heavy and matrix-happy pipelines.
How do CircleCI credits change the math?
CircleCI's credit model is the most honest about the thing that actually drives cost: machine size. You choose a resource class per job, and a beefier class consumes credits at a higher rate per minute. This is good and bad.
It's good because it makes waste visible. If a job doesn't need a large container, dropping it to a smaller class directly and predictably lowers credit burn — the lever is right there in your config. CircleCI also has features like test splitting and Docker layer caching that cut the minutes you run in the first place.
It's less good because credits are an abstraction you have to keep converting in your head. "How many builds do we have left this month?" has no clean answer without knowing the mix of resource classes your jobs used. Teams routinely underestimate spend because a few large-class or GPU jobs quietly dominate the bucket while everyone watches the job count.
A concrete config lever — pin the resource class explicitly so nobody silently upgrades it:
version: 2.1
jobs:
test:
resource_class: medium # be deliberate; 'large' can multiply credit burn
docker:
- image: cimg/node:20.11
steps:
- checkout
- run: npm ci
- run: npm test
CircleCI rewards teams that treat resource class as a budget knob and audit it; it quietly overcharges teams that leave everything on a large default.
Is Buildkite's per-user model actually cheaper?
Buildkite bets that at a certain scale, paying per minute to a vendor is the expensive part, and orchestration is what you should pay for. You run the agents on your own EC2 / GKE / bare metal, and Buildkite coordinates the pipeline and charges per active user.
The economics flip based on two variables: how much compute you burn and how many humans touch CI. A small team running enormous, parallel build fleets is Buildkite's ideal customer — the compute would be brutally expensive as vendor minutes, but on your own spot instances it's cheap, and you're only paying for a handful of seats. Flip it — a large team with light, occasional builds — and per-seat pricing plus the operational burden of running agents can cost more than just buying managed minutes.
The real cost of Buildkite isn't on the invoice; it's the engineering time to run, autoscale, and secure your own agent fleet. That's a genuine line item, not a footnote. Buildkite does now offer hosted compute for teams that want the model without the ops, which narrows this gap but changes the pricing back toward metered compute.
Buildkite is cheapest for compute-heavy pipelines owned by a team that already runs its own infrastructure competently; it's a poor fit if "just add a runner" is not something your team wants to own.
A quick decision guide
Ask three questions before optimizing anything:
- What OS mix do you build on? Heavy macOS/Windows on GitHub Actions is where minute counts lie the most — price it before committing.
- Who controls machine size? On CircleCI, an unaudited default resource class is your most likely source of overspend.
- Do you want to own runners? Self-hosted GitHub runners and Buildkite agents both trade a vendor bill for operational responsibility, including real security exposure on public repos.
The cheapest CI is the one whose billing unit matches how you actually run jobs — not the one with the biggest free number.
Bottom line
Choose GitHub Actions if your pipeline is Linux-first, your team already lives in GitHub, and you keep matrices disciplined — just budget carefully the moment macOS enters the picture. Choose CircleCI if you want granular control over machine size as an explicit cost lever and you're willing to audit resource classes; its credit model rewards that discipline. Choose Buildkite if you run heavy, highly parallel builds, have a small-to-mid team, and already operate your own cloud infrastructure competently — the per-seat model gets cheaper the more compute you burn on your own hardware. In every case, the free-minutes headline is marketing; the billing unit is the number to plan around.
Top comments (0)