runners
a runner is an always-on worker that executes your agents. think of it as the muscle. when you run an agent, it runs on a runner. when your laptop is closed and the scheduler fires, it runs on a runner.
seats
you buy runners by the seat. a seat is a persistent compute unit thats yours. it has:
- cpu + ram + disk
- network access (configurable per agent)
- your project drive mounted
- its own queue
one seat handles many agents — they share it serially by default, or in parallel if you set concurrency.
tiers
| tier | cpu | ram | gpu | price | |------|-----|-----|-----|-------| | free | shared (2h/day) | 1 gb | — | $0 | | cpu | 2 vcpu | 4 gb | — | bundled | | cpu-big | 4 vcpu | 16 gb | — | +$15/mo | | gpu-on-demand | 4 vcpu | 32 gb | 1x a10 | per-minute | | gpu-dedicated | 8 vcpu | 64 gb | 1x a100 | team only |
cpu seats are bundled into your plan (see pricing). gpu is add-on.
what runs where
- lightweight agents (fs + llm + web) — cpu seats
- heavy agents (shell exec, local model inference, cad sims) — gpu seats
- training jobs (vibeSIM surrogate training, policy training) — gpu-dedicated only
the runner field in the agent frontmatter picks:
runner: gpu-on-demand
omit it and we auto-pick based on tool usage.
lifecycle
a cpu seat is a warm process — starts on agent invoke, idles for 60s after the last tool call, suspends. gpu seats suspend faster to save you money.
if a run needs a seat and none is available, it queues. you can see queue depth in /runners.
sandboxing
every run gets an isolated container. the drive is mounted read-only by default and writes go through the vfs api, which enforces your agent's permissions. network egress is allowlist-based per agent.
logs
every seat's stdout/stderr is captured and streamed to the run log in real time. click a run to see it — its just a file in /runs/<id>/stdout.log.