Subchapter 25.4
RUNNERS.mdMarkdown9 KBView on GitHub
Surveyed 2026-10, and not guaranteed to be up to date. Use it to get oriented, then research the current options yourself: products, prices, limits and betas change fast.
A runner is disposable: every run starts on a fresh machine and leaves nothing behind. Five types fill the slot. They differ mostly in who owns the agent loop and who owns the machine:
| Type | Agent loop | Machine | Also fills |
|---|---|---|---|
| CI runner | yours, inside the CI job | CI vendor’s, or yours | orchestrator, observability platform |
| MicroVM API | yours, in the orchestrator or on the runner | provider’s | nothing |
| Bundled agent platform | vendor’s | vendor’s | part of orchestrator, observability platform |
| Bring-your-own worker |
| vendor’s |
| yours |
| part of orchestrator, observability platform |
| Own VPS or containers | yours | yours | nothing |
Runner choice is per run: a cheap CI runner for review runs and a microVM for implementer runs is a normal design.
A fresh VM or pod per CI job, started by the git host’s own workflow engine; the agent CLI is one step in the job. The orchestrator starts a run with a workflow trigger (issue, PR, schedule, manual dispatch), and a concurrency group keeps two runs off the same ticket. Hosted runners are disposable by construction; self-hosted runners get there through an ephemeral mode, one pod per job, deleted after. Cost is per minute.
Pick it when the git host is GitHub or GitLab and every trigger is a git host event or a clock: the workflow file is the orchestrator and the run page is the observability platform, so one product fills three slots.
Starting points:
An SDK call creates an isolated microVM (vendors say “sandbox”) in about a second; the orchestrator execs commands into it, or starts an agent CLI inside it. Cost is per second of vCPU and RAM. The orchestrator creates one per run, kills it at the end, and sets a timeout as the backstop. Providers also sell persistence (pause/resume, snapshots, drives); a factory uses it as a cache, and keeps memory between runs in the ticket tracker, git host and orchestrator.
Pick it when the factory has its own orchestrator (a server, a queue) and wants many short-lived, parallel runs with no machines to manage. Compare on max run length, concurrency cap, and whether time spent waiting on the model is billed: as of 2026-10, Vercel bills only active CPU, so model-wait time is nearly free there.
Starting points: E2B (opens in a new tab), Daytona (opens in a new tab), Modal Sandboxes (opens in a new tab), Vercel Sandbox (opens in a new tab).
A hosted coding agent with its runner included: the vendor provisions a fresh VM or container per run, runs its own agent loop there, and pushes a branch or PR. Only the branch survives. Runs start from an @-mention or assignment in the git host or ticket tracker, a chat message, a schedule, or an HTTP call, so the platform fills much of the orchestrator; its transcript view fills the observability platform. Cost is folded into a seat or subscription, or charged per run.
Pick it when the user wants the fewest moving parts and is happy with that vendor’s agent. Confirm its triggers cover the user’s ticket tracker.
Starting points:
The bundled platform keeps its agent loop and its queue of runs, but tool calls execute on a worker the user hosts. The worker polls the vendor outbound, claims a run, executes it, and exits: the same shape as a self-hosted CI runner. Disposability is the user’s job: run the worker under Kubernetes or a microVM API so each run gets a fresh disk. Cost is the vendor’s seat or usage plus the user’s machines.
Pick it when the user wants a bundled agent but runs must reach a private network, keep data on the user’s machines, or use custom hardware.
Starting points: Claude Code self-hosted environments (opens in a new tab), Cursor self-hosted pool (opens in a new tab), Copilot coding agent on ARC (opens in a new tab).
A machine the user rents or runs, with a fresh container (or machine) per run: the machine may live for months, the container lives for one run. Max run length is whatever deadline the orchestrator sets. Disposability comes from docker run --rm, a Kubernetes Job with ttlSecondsAfterFinished: 0, or a machine destroyed at the end; every cache sits on a path the next run treats as optional. Cost is flat monthly, or per second while running.
Pick it when runs are long, steady or heavy, cost per hour dominates, or a server already hosts the orchestrator.
Starting points: Fly Machines (opens in a new tab) (pricing (opens in a new tab)), Hetzner Cloud (opens in a new tab) plus Docker, Kubernetes Jobs (opens in a new tab).
Check each candidate against these, with the factory’s runs in hand:
The type traits above (who owns the loop, who owns the machine, which slots it fills) change slowly; trust them over any number here.