---
title: "Introducing Adaptive Compute: up to 2.3x faster GitHub Actions"
description: "StarSling Runners with Adaptive Compute ran up to 2.32x faster than GitHub-hosted runners, boosting CPU up to 25% and RAM up to 50% at no extra cost."
date: 2026-10-14
url: https://starsling.dev/blog/adaptive-compute
canonicalUrl: https://starsling.dev/blog/adaptive-compute
---
# Introducing Adaptive Compute: up to 2.3x faster GitHub Actions
[Image: Wide buses of parallel blue circuit traces sweeping across a dark board with 45-degree jogs, and three gold traces fading in to run alongside one bus as it crosses the frame]
Your CI workload changes between jobs and even within individual steps. Its compute should too.
Introducing the next generation of [StarSling Runners](/products/runners) with two adaptive systems:
- [**Afterburner**](https://docs.starsling.dev/runners/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**](https://docs.starsling.dev/runners/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](/products/runners#ai-prs).
## The evolution of StarSling Runners
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](/blog/beyond-cold-starts-benchmarking-sandboxes-for-real-workloads), we exclusively use ephemeral sandboxes for agentic and CI workloads. This architecture is what unlocks adaptive compute.
## Afterburner
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.
An illustrative build-and-test job on a 4 vCPU, 16 GB StarSling Runners label, one bar per second. The four floor lanes are the label's vCPUs, and the raised lane is memory against a 16 GB wall. When CPU or memory pressure engages Afterburner, the outline of the board's Afterburner die glows gold and signals along a gold wire to add 25% more vCPU or 50% more memory. When pressure passes, both go away. Switch Afterburner off to see the same job on the label alone, with the steps that run short of CPU or memory marked in gold.
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](https://docs.starsling.dev/runners/afterburner) for how boosts are sized and when they engage.
## Sandbox Router
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](/hpc-sandbox-benchmarks).
Sandbox Router automatically routes CI jobs to the fastest available sandbox provider for each job. CI execution telemetry for each job updates the weights, so end-to-end time falls as the router learns. Switch on an outage and that provider's weights go to zero at once: jobs headed there turn back and run on the healthy providers.
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.
### More resilient
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.
### Faster queue time
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.
### Faster disk
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](https://docs.starsling.dev/runners/sandbox-router) for how job placement and failover work.
## Adaptive compute for agent-native CI
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.
| Metric | What moves it |
| --- | --- |
| Queue time | Sandbox Router's start-time-aware placement. Never billed. |
| Execution time | Sandbox Router's disk-aware placement, plus Afterburner's extra CPU and memory on intensive steps. |
| Total time to green | Queue time plus execution time. |
| Cost | Execution minutes at the label's price: $0.008 per minute for 4 vCPU / 16 GB. Afterburner minutes cost the same. |
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.
## Results
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:
[Image: Line chart of price per job against run time at 2, 4, and 8 vCPU. GitHub-hosted runners sit highest and slowest, at 4.6 to 9.3 cents a job. The older generation of StarSling Runners, in cyan, and StarSling Runners with Afterburner, in gold, sit below and to the left, with Afterburner fastest at every size. At 4 vCPU the points are 5.09 minutes and $0.071 a job for GitHub-hosted, 3.04 minutes and $0.028 for the older generation, and 2.61 minutes and $0.028 for Afterburner, marked 1.67x and 1.95x faster.]
Price per job against run time. Each point is the geometric mean, over a TypeScript install, lint, and build job and a Rust test and clippy job, of median run time and of price per job. Measured October 13, 2026, n=1 to 5 per point.
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](https://github.com/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](https://github.com/starslingdev/github-actions-benchmarks/actions/runs/38490164589) and [Rust (spotify-player) run](https://github.com/starslingdev/github-actions-benchmarks/actions/runs/38490167886)
- **Older generation of StarSling Runners:** [TypeScript (mastra) run](https://github.com/starslingdev/github-actions-benchmarks/actions/runs/38484877550) and [Rust (spotify-player) run](https://github.com/starslingdev/github-actions-benchmarks/actions/runs/38484883575)
GitHub-hosted prices come from GitHub's [Actions runner pricing](https://docs.github.com/en/billing/reference/actions-runner-pricing) docs.
## Enable adaptive compute today
Install the [StarSling GitHub App](https://github.com/apps/starslingdev) and set your label:
```yaml
jobs:
build:
runs-on: starsling-ubuntu-26.04
```
If you're using `ubuntu-latest` or `ubuntu-24.04`, check out [our post](/blog/ubuntu-26) 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](mailto:founders@starsling.dev?subject=Afterburner%20access) 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.