Cloud agents and sandboxes: what exists
Is the agent swarm real? Three different things get called that, and only some are something you use. This page says which is which, so you know what to rely on today.
Three things, three statuses
| What | What it is | Status | Do you use it? |
|---|---|---|---|
| Check sandboxes | Every pre-land check runs in a container sandbox leased for that bean. It runs the suite on the merged tree, and an idle sandbox goes to sleep. | live | No. They are internal; you never manage them. |
| Race harness | A benchmark that drives many agents at Gitstalk and at a GitHub merge queue and records who ships sooner. Its pages are admin-only. | research | No. It is how the published numbers were measured. |
| Cloud agents for users | Agents that run in the cloud next to your local ones, on your own model keys. | planned | Not yet. Design only. |
What you can use today
Your own local agent live
Run Claude Code or Codex on your machine, on the plan you already pay for. It pushes beans as you.
Automations live
A file in your repository defines an agent that Gitstalk runs in a container on a Workers AI model, when something happens or on a schedule.
Where each one runs
Your machine:
- Your agentClaude Code or Codex, your plan
- git pusha bean, as you
- Check sandboxGitstalk's container
- Sproutlanded
Hosted by Gitstalk, an automation:
- Event or schedulea bean went red, Monday 9:00
- Automation containerWorkers AI model, no model key inside
-
Beanpushed as
name[automation] - Same checksas anyone's bean
Planned, cloud agents with your own keys:
- Your model keysstored for you
- Cloud agent sessionruns next to your local ones
- Beanas you
- Same checksas anyone's bean
Whoever runs the agent, the rule is the same: it pushes a bean, the bean passes the pre-land check, and only the engine lands it.
Check sandboxes in a sentence
A repository is always granted a small floor of sandboxes (two) so its checks are never starved, and leases one sandbox per bean in check up to its own cap. A sandbox that is idle for two minutes sleeps and leaves the pool. While another repository waits for a sandbox, a busy one gets no more than an equal share. This is capacity plumbing, not a feature you configure unless you self-host.
The race harness
Real Claude Code and Codex agents, or replay agents, work a backlog against a merge queue and against Gitstalk, and every run is recorded. The results, with their caveats, are on Architecture and in the repository's research README. It is research tooling for the people who build Gitstalk, with its pages behind the admin area. It is not a feature for your repositories.
Cloud agents and your own keys planned
The plan is agents that run in the cloud next to your local ones, with your own model keys (Anthropic, OpenAI, Google, xAI) held encrypted and sent to the model through the AI gateway with spend caps. Nothing of this exists in the product: there is no screen to add a key, and no way to start a hosted session. Sharing one ChatGPT login across containers was ruled out before building (see what did not work). We give no dates.
Sources
- docs/claude-opus/17-cloud-agent-swarm.md (the benchmark design), 16-product-backlog.md (cloud sessions, phase 5)