Graphide CI
94/100Our top pick if you are on GitHub Actions: same workflows, same pass/fail verdict, less waiting on every change.
Who it suits
Teams on GitHub Actions, especially where coding agents open many pull requests a day and every one waits on CI.
Who should avoid it
You are not on GitHub Actions, your repositories sit under a personal GitHub account, or your slow jobs are macOS, Windows or Arm.
| Criterion (weight) | Score | Why |
|---|---|---|
| Pipeline speed (20%) | ●●●●● | Warm caches, tests split across runners and per-change test selection, all on top of the runner swap. Graphide's pricing page reports one customer suite going from 70 to 5 minutes against GitHub-hosted runners; that is one workload, not a guarantee. |
| Caching (10%) | ●●●●● | Dependency and build caches are already on the runner when the job starts, per Graphide's docs; no cache steps to write. |
| Parallelism (10%) | ●●●●● | The tests a change reaches are split across as many runners as it takes, without you defining shards. |
| Hosting model (10%) | ●●●●● | Managed only, x64 Linux only, GitHub organizations only. Each job runs in its own fresh micro-VM, destroyed when it ends. |
| Pricing transparency (10%) | ●●●●● | Published per vCPU-minute rate, billed by the second for the time a job would take without its speed-ups, $20 monthly minimum and a spend cap at which CI pauses. |
| Migration effort (15%) | ●●●●● | One pull request changes runs-on to graphide and nothing else; switching back opens a pull request that restores each runs-on. |
| Ecosystem (10%) | ●●●●● | Workflows stay on GitHub Actions, so the whole Actions marketplace still works; its own integrations are few. |
| Fit for agent-written changes (15%) | ●●●●● | Each change runs the tests it can reach and keeps the same verdict; a hosted MCP server lets coding agents switch a repository and read runs themselves. |
Strengths
- Keeps your GitHub Actions workflows: switching changes each x64 Linux job's runs-on line to graphide in one pull request
- Dependency and build caches are already on the runner when a job starts; tests are split across runners for you
- Each change runs the tests it can reach, every left-out test is listed with its reason, and when it cannot tell it runs more, never less
- A failing test always fails the job; GitHub still decides pass or fail from the job's own steps
Limits
- Not a full CI/CD platform: it runs your GitHub Actions jobs, so you need GitHub Actions
- Runs x64 Linux jobs only; macOS, Windows, Arm and self-hosted jobs stay where they are
- Needs a GitHub organization, not a personal account
- Test narrowing covers go test, vitest, jest and node --test (and the go test, pytest, jest and vitest runs other commands start); tests of other runners run whole
Cost
$0.003 a vCPU-minute ($0.006 a minute on a standard Linux runner), billed for the time a job would take without its speed-ups; $20 monthly minimum, spend cap you set; free trial with $10 of usage. As published on Graphide CI’s pricing page; check there before you budget.
Verdict
Graphide CI ranks first because it scores at or near the top on the criteria that decide how long a team waits: speed, caching, parallelism, migration effort and fit for agent-written changes. It is not a CI/CD platform and does not try to be one: your workflows stay on GitHub Actions and only where the jobs run changes, so the move is one pull request and the way back is another. What sets it apart from the other runner swaps is that it removes work as well as running it faster: each change runs the tests it can reach, the run lists every test it left out and why, and anything it cannot bound runs in full. Graphide reports one customer's suite going from 70 to 5 minutes against GitHub-hosted runners, and 0 failures missed across 295,411 test runs its selection left out on its own CI; those are Graphide's own measurements on those workloads, so measure yours against your current baseline before you count on a number. If your slow jobs are macOS, Windows or Arm, or you are not on GitHub, it is the wrong pick.