Get This Tool
Hotcell
Summary
Run two AI coding agents against the same repo and you will spend the next hour untangling branch collisions, leaked API keys in logs, and a charge spike you did not authorize — Hotcell exists to make that the other team's problem.
Hotcell is a self-hosted sandbox daemon that provisions isolated containers for agents like Claude Code, Codex, or OpenCode. Each sandbox gets its own cloned workspace on its own branch, a scoped gateway token instead of your real provider key, and a hard spend cap — the actual API credential never enters the container. Five agents against one repo is a single command; teardown revokes every token and cleans every workspace in the same step. The ceiling appears at hardware: you get as many parallel sandboxes as your Mac Mini, Linux VM, or bare-metal box can carry, and no managed scaling layer ships with the open-source daemon.
Bottom line: Pick Hotcell when you are running three or more local coding agents against the same repo and need credential isolation that holds under prompt injection — skip it when you need elastic cloud capacity or a billing dashboard your finance team can read.
Community Performance Report Card
No community ratings yet. Be the first to rate this tool!
Pros
Sign in to edit- Real provider keys are held in the host keychain and never injected into the sandbox — so a prompt injection or leaked log inside the container cannot reach your OpenRouter or Anthropic account credentials.
- Per-sandbox spend caps enforced at the gateway layer, which means a runaway agent cannot charge past the limit you configured, eliminating the surprise billing spike that follows an unconstrained agent loop.
- One command provisions five isolated cells against the same repo on five separate auto-named branches, so parallel agent experiments on one codebase produce zero branch collisions and require zero manual worktree setup.
- Three isolation tiers — Docker, Firecracker, Apple VZ — so teams running untrusted third-party agent code can step up to VM-weight boundaries without switching tools.
- Apache-2.0 licensed with self-hosted deployment on any Mac, Linux VM, or bare-metal box, which means the isolation layer is fully auditable and carries no lock-in to a vendor's sandbox API.
Cons
Sign in to edit- No API surface ships with the daemon. Teams that need to provision sandboxes programmatically — from a CI job, a test harness, or an orchestration script — have nothing to call. The workaround is shelling out to the CLI, which breaks when the invocation context lacks a TTY or when output parsing becomes load-bearing.
- Parallelism is bounded by the host machine. When the number of simultaneous agents outgrows a single Mac Mini or VM, there is no multi-host fleet management documented. Teams reaching that ceiling move to a cloud-native sandbox provider that can schedule across machines — at which point Hotcell's local-first architecture is the reason they leave, not a bug they can fix.
- The Cloud option is waitlist-only. Teams that cannot or will not self-host have no production path available from what the page describes, which means Hotcell is not a candidate for organizations with a policy against running infrastructure daemons on developer machines.
About
- Platforms
- macOS, Linux
- API Available
- No
- Self-Hosted
- Yes
- Last Updated
- 2026-08-14T01:47:51.347Z
Best For
Who it's for
- Developers running Claude Code, Codex, or OpenCode locally
- Teams needing infrastructure-level agent containment
- Self-hosted environments requiring hard spend limits
What it does well
- Run multiple AI coding agents on the same repo without git conflicts
- Execute untrusted agent code with credential isolation
- Enforce per-sandbox spend caps and egress allowlists
Integrations
Add notes, reviews, and benchmarks so the next visitor gets a clearer picture.
Compare Hotcell
Spotted incorrect or missing data? Join our community of contributors.
Sign Up to ContributeFrequently Asked Questions
- Is Hotcell free?
- Hotcell has a permanent free tier alongside paid upgrades. You can keep using a baseline version indefinitely without paying.
- Is Hotcell open source?
- Yes. Hotcell is open source.
- Can I self-host Hotcell?
- Yes. Hotcell supports self-hosting on your own infrastructure.
- What platforms does Hotcell support?
- Hotcell is available on: macOS, Linux.
Curated lists that include this category
Credential exposure and uncapped spend are the two failure modes the page names explicitly — Hotcell addresses both by sitting between your agents and your provider. A single daemon runs on the host, holds your real API keys in the system keychain, and issues per-sandbox revocable gateway tokens to each container. The agent inside the cell sees a gateway URL and a scoped token; it cannot read the original key. Spend caps and egress allowlists are enforced at the gateway layer, so an agent that goes wrong cannot charge past the limit you set or phone data to an unwhitelisted destination. The guided CLI wizard — `hotcell create` — walks through repo cloning, branch naming, egress wiring, and agent preinstallation, then prints the equivalent one-liner so repeatable runs skip the prompts.
The differentiating detail is keyless egress combined with git isolation. When you spin up five cells against the same repo, each gets its own auto-named branch cloned into its own `/workspace`. `git push` routes through the gateway keylessly. There is no git-worktree juggling on the host. Teardown with `hotcell rm –all` drops all five cells and revokes all five tokens in one command — the source repo is untouched. The page lists three isolation tiers — Docker, Firecracker, and Apple VZ — giving teams a choice between container-weight and VM-weight boundaries depending on how untrusted the agent code is.
Hotcell fits a specific gap: developers who already own the hardware and want infrastructure-level containment without routing everything through a third-party cloud. The Apache-2.0 license and self-hosted model mean no vendor dependency on the core isolation path. The gap is on the other side — the project ships a Cloud waitlist, but the open-source daemon has no managed scaling, no multi-host fleet management documented on the page, and no API surface, which means teams that need to provision sandboxes programmatically from an orchestration layer have nothing to call. At the scale where a CI pipeline needs to spin up sandboxes dynamically, the daemon-on-one-box architecture becomes the constraint.