Introducing Adaptive Compute: up to 2.3x faster GitHub Actions

Your CI workload changes between jobs and even within individual steps. Its compute should too.

Introducing the next generation of StarSling Runners with two adaptive systems:

• Afterburner, which resizes a running job every second, adding up to 25% more CPU and up to 50% more RAM at no extra cost
• Sandbox Router, which intelligently routes every job to the most performant sandbox

Together, Adaptive Compute makes StarSling Runners up to 2.32x faster than GitHub-hosted runners, without a single code change in your repo.

Meanwhile, StarSling AI agents continue to optimize your workflows to make your CI even faster over time by opening up PRs autonomously.

Every CI job is an intensive sequence of different computational workloads. Installing dependencies is often bound by I/O (disk and network). A build for a compiled language often saturates every core. Running tests fans out workers that drive memory up and saturates every core.

Most CI providers buy expensive hardware and lock you into a specific hardware shape from the first step to the last step in a CI job. As a customer, that leaves you with two options:

1. Size the runner for the peak, and pay for capacity every step that sits idle.
2. Size it for the median, and live with slow compiles or even test flakes that run out of memory.

StarSling went the opposite direction. As I shared in Benchmarking Sandboxes for Real Workloads, we exclusively use ephemeral sandboxes for agentic and CI workloads. This architecture is what unlocks adaptive compute.

Afterburner resizes a running job every second, based on the CPU and memory pressure of the current step. When a step heats up, it adds up to 25% more CPU and up to 50% more RAM, at no extra cost.

Afterburner is a temporary boost. It engages only while a step is under pressure, holds the extra resources for as long as that pressure lasts, and hands them back as soon as the step eases.

A starsling-ubuntu-26.04 runner is 4 vCPU and 16 GB. When a compile saturates all four vCPUs, Afterburner brings a fifth online for that step. When a test suite pushes memory toward 16 GB, it raises the ceiling to as much as 24 GB until the spike passes. Then the job is back on 4 vCPU and 16 GB, on the same label at the same per-minute price. A single job can boost several times within each step that needs it. If a workload needs more on every run, our agents open a PR recommending the right label.

See the Afterburner docs for how boosts are sized and when they engage.

Every StarSling Runners job runs in its own sandbox. Sandbox Router decides which provider and region hosts it.

Two sandboxes with the same resource shape can deliver different end-to-end time (the time from when you push a branch to a green CI check). The differences come from many dimensions: how fast the sandbox starts, how the disk performs on small-file metadata operations, noisy neighbors on the same bare-metal host, internet backbone cuts, regional GitHub outages, and more. We have seen it all running 3M+ sandbox jobs in production and with rigorous benchmarking sandbox providers on real CI workloads.

Every completed job updates the preferred provider for its workflow and the routing weights for its organization. The more you run, the sharper the placement gets.

You choose the runner size. StarSling chooses the environment.

StarSling Runners are more distributed, durable and resilient than CI that lives in one place. Most CI providers promise to be more reliable than GitHub's own runners and aren't. A regional power or cooling failure at a single-operator datacenter can take down every runner hosted there.

StarSling distributes jobs across several high-performance sandbox providers and regions, with fast failover. Sandbox Router constantly watches every one of them through our telemetry streams. In the rare event that a sandbox provider stops starting sandboxes, its weights drop to zero and your CI jobs move to a healthy provider in under a second, so your workflows keep running while one provider recovers.

In a GitHub Actions workflow with a three-job needs: chain of 30-second jobs with 15-second handoffs, a third of the end-to-end wall clock is waiting for GitHub to queue a job and a sandbox provider to start our optimized runner image. Sandbox Router learns that the workflow is queue-sensitive and shifts weight toward sandbox providers that start fastest.

Another example is that a disk-bound job like Docker builds, package installs or massive cache restores can take 3 minutes on one provider and 5 on another. Sandbox Router learns to send those disk-heavy jobs to sandboxes with a RAM-backed filesystem (the ultra-low latency of memory is faster than any NVMe disk for small files and metadata operations).

See the Sandbox Router docs for how job placement and failover work.

Sandbox Router intelligently routes jobs to the fastest sandbox provider and makes execution more resilient. Afterburner adaptively resizes resources for what a CI step needs at any given moment. Both use the same telemetry stream as the StarSling AI agents that open optimization PRs against your workflows.

Faster hardware is a one-time win. Cheaper minutes are a one-time win. A system that learns from every run, acts on it at placement time and at run time, and opens optimization PRs into your repo keeps compounding.

Adaptive compute is our new system for CI infrastructure that achieves frontier-level CI performance and value, with the same runs-on label and the same GitHub Actions files that you already use. Here are results from real CI jobs we benchmarked:

Across 2, 4, and 8 vCPU, StarSling Runners with Sandbox Router and Afterburner ran between 1.53x and 2.32x faster than GitHub-hosted runners.

Every measurement comes from public GitHub Actions runs in starslingdev/github-actions-benchmarks on October 13, 2026, with up to five fresh runners per label. Each run's summary page reports the p50 and p90 of every phase for every runner.

• StarSling Runners and GitHub-hosted: TypeScript (mastra) run and Rust (spotify-player) run
• Older generation of StarSling Runners: TypeScript (mastra) run and Rust (spotify-player) run

GitHub-hosted prices come from GitHub's Actions runner pricing docs.

Install the StarSling GitHub App and set your label:

jobs:
  build:
    runs-on: starsling-ubuntu-26.04

If you're using ubuntu-latest or ubuntu-24.04, check out our post on the upcoming GitHub Actions migration.

Sandbox Router is on by default for every StarSling Runners label, so existing StarSling workflows are already being intelligently routed. Afterburner is in early access: contact us to have it enabled for your org.

Change one line in your GitHub Actions workflows to switch to StarSling and get CI compute that adapts.