What GitHub Actions Larger Runners Cost

GitHub Actions larger runners bill per minute at GitHub's published list rates: $0.012 for 4 vCPU Linux x64, $0.022 for 8 vCPU, $0.042 for 16 vCPU, $0.082 for 32 vCPU, and up to $0.252 for 96 vCPU, checked on 2026-08-13 against GitHub's per-minute rate reference. WarpBuild runs the same vCPU sizes for less per minute, from $0.008 at 4 vCPU Linux x64 to $0.064 at 32 vCPU. This guide lays out both rate ladders, the break-even arithmetic for moving up a size, and a worked monthly cost model you can rerun with your own job volume.

Diagnosis

Larger runners are the GitHub-hosted machines above the default 2 vCPU tier. GitHub bills them per minute of workflow execution and rounds each job up to the nearest whole minute. An idle larger runner pool costs nothing; the meter runs only while a job executes.

These are GitHub's list prices for hosted larger runners, checked on 2026-08-13 against the per-minute rate reference and the GitHub pricing page:

Four billing rules shape what these numbers turn into at the end of the month:

• Included minutes from your GitHub plan never apply to larger runners. Every larger runner minute is a paid minute, and that holds for public repositories too.
• Larger runners require a GitHub Team or GitHub Enterprise Cloud plan. Personal and Free organization accounts cannot create them.
• Each job rounds up to a whole minute. A 15 second job on a 32 vCPU Linux runner bills a full minute at $0.082.
• How many jobs run concurrently depends on your GitHub plan, so deep matrix builds can queue behind the cap.

The harder question is when a bigger machine pays for itself. The answer comes from two curves: the per-minute rate as vCPUs grow, and your job's wall clock time as vCPUs grow.

On the GitHub ladder, each step up multiplies the Linux x64 rate by 1.8 to 2.0. Moving from 4 to 8 vCPU multiplies the rate by 1.83 ($0.012 to $0.022), so cost per run breaks even when the job finishes in about 55 percent of its old duration. Moving from 8 to 16 vCPU multiplies the rate by 1.91, with break-even near 52 percent of the old duration. On the WarpBuild ladder the rate doubles exactly at each step, so break-even sits at half the old duration.

Whether your job clears that bar depends on which steps dominate. Compilation, sharded test suites, and multi-stage container builds spread across cores and often scale close to the core count. Checkout, dependency installs against a warm lockfile, single-threaded bundlers, and artifact uploads run at the same speed on 4 vCPUs as on 32. If those serial steps are most of the job, a bigger runner raises cost per run and buys little time.

Two quick signals before any resizing decision. A job whose peak CPU sits near full utilization for most of the run has headroom to convert cores into speed. A job that spends its time waiting on registries, package mirrors, or a database container will look identical on a bigger machine, at a higher rate.

Fix

There are two independent levers, and they compound.

The first lever changes the rate without touching the job: run the same vCPU count on a provider with a lower per-minute price. The runner images carry the same tooling as GitHub-hosted runners, and a job moves by editing one runs-on label. Pricing is purely usage based. There is no base subscription fee, no platform fee, and no seat fee. Signup includes $10 free credits.

Here is the same-size comparison, GitHub-hosted list price against the WarpBuild rate, both checked on 2026-08-13:

WarpBuild Linux runners at these sizes carry 4GB of memory per vCPU and 150GB of SSD storage; Windows runners carry 256GB. WarpBuild also keeps a 2 vCPU Linux tier at $0.004 per minute on x64 and $0.003 on ARM64 for jobs that were never CPU bound in the first place. Full ARM64 and Windows catalogs are on the Linux ARM64 runner page and the Windows runner page, and every rate is listed on the WarpBuild pricing page.

Concurrency behaves differently too. Run as many jobs as your workflows need. Generally available Linux and Windows runners do not have plan-level concurrency caps. For matrix-heavy workflows, that removes the queueing that plan-level concurrency caps impose on GitHub-hosted pools.

The second lever is right-sizing against measurements. Move a job up a size only when its measured CPU shows the parallel phases dominating, and move oversized jobs down when they do not. The two levers are independent: the rate change requires no scaling assumption at all, while the size change is a bet that your job parallelizes. The guide to reducing GitHub Actions costs covers the levers beyond runner choice, including caching and artifact retention.

Configuration

Moving a job between sizes is one line. This workflow moves a sharded Jest suite from a 2 vCPU runner to an 8 vCPU runner:

name: ci
on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: warp-ubuntu-latest-x64-8x # was: warp-ubuntu-latest-x64-2x
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run build
      - run: npx jest --maxWorkers=8

The sizing rationale, with the arithmetic: on warp-ubuntu-latest-x64-2x this suite ran 28 minutes with both vCPUs pinned, which costs 28 x $0.004 = $0.112 per run. Jest shards across workers, so on warp-ubuntu-latest-x64-8x with --maxWorkers=8 the run drops to 6 minutes, which costs 6 x $0.016 = $0.096 per run. The bigger runner is cheaper per run here and returns 22 minutes per pull request. The move pays because the test phase, the dominant step, spreads across all 8 cores; the npm ci step stays serial but is a small share of the total.

Label mechanics worth knowing before you edit runs-on:

• The full catalog lives in the cloud runners documentation. Linux x64 and ARM64 come in 2x, 4x, 8x, 16x, and 32x sizes. Windows comes in 4x through 32x; the 2 vCPU Windows tier was removed on June 8, 2026.
• The latest labels track Ubuntu 24.04. To pin an OS version, use the versioned labels such as warp-ubuntu-2404-x64-8x or warp-ubuntu-2604-x64-8x.
• On ARM64, Ubuntu 24.04 runners set the work dir to /runner/_work, unlike GitHub's /home/runner/work/. Scripts with hardcoded paths need that update when you switch architecture.

Verify the resize with numbers rather than impressions. The Reports page documentation covers per-job duration at P75 and P90, queue time, and billed cost per run, filterable by runner label, so the before and after comparison is one filter change. CPU and memory percentiles come from CI observability, which correlates system metrics from the runner agent with GitHub Actions job logs; enable it before the experiment so the P90 CPU column can confirm whether the job actually saturated the smaller machine.

Cost or Time Model

Take a concrete volume: a team runs 1,500 GitHub Actions jobs per month on 8 vCPU Linux x64 runners, averaging 10 billed minutes per job. That is 15,000 runner minutes per month. Rates below are the GitHub list prices from the per-minute rate reference, checked on 2026-08-13, and the WarpBuild rates from the pricing page.

Same size, both providers:

The label change alone moves the bill from $330.00 to $240.00, a difference of $90.00 per month or $1,080.00 per year, with identical vCPU count and no assumption about the job speeding up.

Now add the sizing lever. Suppose Reports shows the job pinning all 8 vCPUs through its compile and test phases, and a trial run on 16 vCPU brings wall clock from 10 minutes to 6.5:

At $312.00 the doubled size stays under the original $330.00 GitHub-hosted baseline while finishing every run 3.5 minutes sooner. Across 1,500 monthly runs that removes 5,250 pipeline minutes, about 87 hours of waiting spread over the team's pull requests.

The break-even line for that upgrade: the 16x rate is double the 8x rate, so cost per run matches when duration falls to 10 x ($0.016 / $0.032) = 5.0 minutes. Between 5.0 and 10 minutes, the bigger runner costs more per run and buys speed; below 5.0 minutes it wins on both cost and time. Whether 6.5 minutes is worth $72.00 more per month than the 8x figure is a judgment about how much a faster feedback loop is worth to the team, and the model above gives you the exact price of that choice.

Both tables hold job duration constant across providers, so they compare list prices rather than predict a fleet's total. Substitute your measured job duration, and use the pricing page for current rates.

To rerun this model with your own numbers, pull monthly job counts and billed minutes from your GitHub usage report, multiply by the list rate at your size, and set that against the WarpBuild rate at the same vCPU count. macOS runs on a separate ladder on both sides; the macOS runner cost guide works through it with the same method.

FAQ

Do included GitHub Actions minutes cover larger runners?

No. GitHub excludes larger runners from included minutes, so every larger runner minute bills at the published per-minute rate, on public and private repositories alike (checked on 2026-08-13).

Which GitHub plan do larger runners require?

GitHub restricts larger runners to organizations on GitHub Team or GitHub Enterprise Cloud. WarpBuild runners attach through a runs-on label and work with any plan that allows self-hosted runner registration.

Is a bigger runner ever cheaper per run than a smaller one?

Yes, when wall clock time falls faster than the per-minute rate rises. A job that finishes in under half its old duration after moving from 4 vCPU to 8 vCPU costs less per run and ships sooner.

Can I run larger runners inside my own cloud account?

Yes. BYOC runs on AWS, GCP, and Azure. Jobs keep their warp- labels, compute runs in your cloud account, and the WarpBuild BYOC rate for Linux runners is $0.002 per minute.