Skip to content
Latchkey

How to Weigh the Cost of Larger Runners

A bigger runner only saves money if the job speeds up more than the per-minute rate rises; otherwise you pay more for the same work.

Larger runners scale linearly in price with vCPU count. They pay off for parallelizable work (large test suites, native builds) and waste money on serial work.

Steps

  • Measure the job duration on the standard 2-core runner.
  • Run it on a larger runner and compare duration and per-minute rate.
  • Keep the larger runner only if total cost (minutes times rate) drops.

Target a larger runner by label

.github/workflows/ci.yml
jobs:
  build:
    # Custom larger-runner label defined in org runner settings
    runs-on: ubuntu-latest-8-cores
    steps:
      - uses: actions/checkout@v4
      - run: make -j8 build   # only faster if the work parallelizes

Gotchas

  • A single-threaded job runs no faster on more cores, so you just pay the higher rate.
  • The per-minute rate roughly scales with core count, so a 2x-faster job on a 4x runner costs more.
  • Measure real wall-clock, not CPU time; I/O-bound jobs rarely benefit from more cores.

Related guides

Run this faster and cheaper on Latchkey managed runners. Start free →