docs: update agent sandbox competitor landscape

2026-07-27 03:44:41 +00:00
parent 74ec9843f0
commit a6e1aebda1
1 changed files with 293 additions and 8 deletions
@@ -32,9 +32,17 @@ not a principled scope exclusion: both are major hosted sandbox platforms and
 belong in this landscape even though they target platform builders rather than
 bot-bottle's local single-operator workflow.
 Updated 2026-07-27 after a scan of recent Show HN launches: **Black LLAB,
 Eve, CloudRouter, Nucleus, yolo-cage, and Sandbox Agent SDK** added as a
 dated entrant cohort. They sharpen the comparison on three axes the original
 table underweighted: the browser/preview loop, parallel-agent operator UX, and
 a provider-neutral automation/session API.
 ## Summary
-The main table compares bot-bottle against fifteen isolation/sandbox tools.
+The main table compares bot-bottle against fifteen canonical
 isolation/sandbox tools; a later section evaluates six recent HN entrants
 without widening an already unwieldy table.
 Governance/pre-action authorization and credential-only layers are covered
 separately because they don't provide VM or container isolation. None
 duplicate bot-bottle's combination of local
@@ -542,6 +550,199 @@ them.
  framework runtime is not compromised.
 - **Maturity**: Specification + reference implementation, 2026.
 ## Recent HN entrants (added 2026-07-27)
 These are grouped by launch date rather than promoted into the main table.
 Several are young or sparsely documented, and putting them beside mature
 runtime platforms with false precision would obscure the useful comparison.
 The HN launch posts are the evidence snapshot; feature claims should be
 rechecked against their repositories before relying on them for a security
 decision.
 ### Black LLAB
 - **Source**: https://github.com/isaacdear/black-llab ;
  HN launch https://news.ycombinator.com/item?id=47402394
 - **Isolation/locality**: Local Docker environment, with an isolated container
  created for each agent task. Shared host kernel; no stronger boundary is
  claimed.
 - **Agent integration**: General local/cloud model workspace. Its headline is
  dynamic routing of simple prompts to local models and complex prompts to
  hosted models, with code execution and web scraping inside the task
  container.
 - **Network/credentials**: No default-deny egress, payload inspection, or
  host-side credential injection documented in the launch.
 - **Competitive read**: Superficial overlap ("a container per agent task"),
  but not a direct security-policy competitor. Its useful challenge is the
  integrated model-selection UX, which bot-bottle intentionally leaves to the
  selected agent provider.
 - **Maturity**: Early solo project; HN launch received 1 point.
 ### Eve
 - **Source**: https://eve.new/ ;
  HN launch https://news.ycombinator.com/item?id=47721255
 - **Isolation/locality**: Managed, hosted Linux sandbox per user/session
  (claimed 2 vCPU, 4 GB RAM, 10 GB disk), with filesystem, code execution,
  headless Chromium, and service connectors.
 - **Agent integration**: End-user OpenClaw-style agent product. An orchestrator
  routes subtasks to specialist models and can run parallel subagents that
  coordinate through a shared filesystem. Web UI and iMessage are primary
  interaction surfaces.
 - **Network/credentials**: Broad connectors are a product feature; the launch
  does not document bot-bottle-style default-deny route policy, content DLP,
  or credentials held outside the sandbox.
 - **Competitive read**: Adjacent, not direct. Eve sells a managed colleague;
  bot-bottle lets an operator run existing coding-agent CLIs under local
  containment. Eve nevertheless demonstrates the appeal of background work,
  live progress, browser capability, and mobile notification.
 - **Maturity**: Commercial hosted product; HN launch received 71 points and
  39 comments.
 ### CloudRouter
 - **Source**: https://github.com/manaflow-ai/manaflow/tree/main/packages/cloudrouter ;
  HN launch https://news.ycombinator.com/item?id=47006393
 - **Isolation/locality**: Claude Code or Codex runs locally and provisions
  remote cloud VMs/GPUs for execution. Project files are uploaded to the VM;
  each machine exposes auth-protected VNC, VS Code, and Jupyter surfaces.
 - **Agent integration**: A skill plus CLI lets the coding agent itself start,
  command, inspect, and tear down machines. Browser automation is integrated,
  including snapshots and screenshots. Parallel disposable compute is the
  central workflow.
 - **Network/credentials**: The launch emphasizes remote resource isolation and
  authenticated UI endpoints, not default-deny guest egress, payload DLP, or
  proxy-held application credentials.
 - **Competitive read**: The closest recent workflow competitor. It directly
  addresses parallel coding agents, environmental conflict, and closing the
  browser/test loop, but trades local custody for elastic cloud compute.
  Cloud VMs and GPUs could be a future bot-bottle backend; they do not replace
  its manifest/policy layer.
 - **Maturity**: Active open-source monorepo project; HN launch received
  138 points and 36 comments.
 ### Nucleus
 - **Source**: https://github.com/coproduct-opensource/nucleus ;
  HN launch https://news.ycombinator.com/item?id=46855770
 - **Isolation/locality**: Firecracker microVM with an enforcing MCP tool proxy.
 - **Agent integration/config**: Compositional permission envelope for
  read/write/run actions. The envelope is non-escalating and can tighten or
  terminate, with scoped approval tokens for gated operations.
 - **Network/credentials**: Default-deny egress, DNS allowlist, iptables drift
  detection, time/budget caps, and hash-chained audit logging are claimed.
  Remote append-only audit storage and attestation were roadmap items at
  launch.
 - **Competitive read**: Direct on security architecture, especially
  non-escalating policy and tamper-evident audit. It is an early execution/tool
  proxy rather than a provider-neutral, one-command coding-agent product. Its
  tool-level action envelope is semantically finer than bot-bottle's network
  boundary; bot-bottle is stronger on turnkey agent/provider integration,
  credential custody, Git mediation, and long-running operator workflow.
 - **Maturity**: Early OSS experiment; HN launch received 3 points.
 ### yolo-cage
 - **Source**: https://github.com/borenstein/yolo-cage ;
  HN launch https://news.ycombinator.com/item?id=46706796
 - **Isolation/locality**: Local sandbox for running multiple coding agents in
  YOLO mode. The launch discussion describes a VM boundary.
 - **Agent integration**: Built around the native Claude Code experience and
  motivated by running many agents in parallel without permission-prompt
  fatigue.
 - **Network/Git/credentials**: Strict egress filtering, configurable HTTP
  middleware, and mediated `git`/`gh` dispatch are the main value. The launch
  discussion explicitly identifies provider credential handling as unfinished
  and difficult because Claude state spans multiple host paths.
 - **Competitive read**: The closest new threat-model competitor. It shares
  bot-bottle's premise that filesystem isolation alone is insufficient and
  that Git plus authorized HTTP channels need mediation. bot-bottle currently
  leads on cross-provider support, proxy-held Claude/Codex/forge credentials,
  typed per-role manifests, content DLP, and supervision. yolo-cage's simpler
  pitch and narrower Claude-first setup may be easier to explain.
 - **Maturity**: Early local tool; HN launch received 60 points and 76 comments.
 ### Sandbox Agent SDK
 - **Source**: https://github.com/rivet-dev/sandbox-agent ;
  HN launch https://news.ycombinator.com/item?id=46795584
 - **Isolation/locality**: Does not provide the isolation primitive. It runs
  inside E2B, Daytona, Modal, Cloudflare Containers, Agent Computer, BoxLite,
  Docker, or another sandbox provider. Embedded mode can also run locally
  without a sandbox.
 - **Agent integration**: Provider-neutral Rust server/SDK exposing a common
  HTTP/SSE/OpenAPI interface across Claude Code, Codex, OpenCode, Cursor, Amp,
  and Pi, plus a universal event/session schema for external storage and
  replay. It also exposes filesystem, managed-process, terminal, MCP, skills,
  custom-tool, and computer-use APIs. TypeScript is the primary SDK surface.
 - **Network/credentials**: Delegated to the chosen sandbox provider.
 - **Credential posture**: Its documented convenience command extracts real
  OpenAI/Anthropic credentials from local agent configuration and passes them
  as environment variables into the sandbox. That is materially weaker than
  bot-bottle's host-side credential custody, but it is an integration choice,
  not a structural limitation: a sandbox provider could put a credential
  proxy underneath the same SDK.
 - **Competitive read**: A serious architectural threat despite not supplying
  isolation. Sandbox Agent is trying to standardize the boundary *above* the
  sandbox: one client protocol, session model, and UI/control surface across
  every coding agent and runtime. If that boundary becomes the ecosystem
  standard, users and application builders may choose a sandbox provider plus
  Sandbox Agent rather than a vertically integrated launcher. bot-bottle's
  manifests would then be valuable chiefly as a local policy/backend
  implementation unless they expose an equally usable control contract.
 - **Maturity**: Apache 2.0, ~1.5k stars and 426 commits at the 2026-07-27
  check; HN launch received 41 points.
 #### Why the Sandbox Agent architecture is strategically different
 The manifest and the universal control protocol solve different layers:
 - A bot-bottle manifest is a **trusted launch-time policy composition**. It
  selects the agent role, isolation backend, image, skills, egress routes,
  credentials, Git mediation, and supervision policy. Crucially, identity and
  secret references live on the host side of the trust boundary.
 - Sandbox Agent is a **runtime control and observation protocol**. A remote
  client creates sessions, sends messages, handles permissions, configures
  skills/MCP, manipulates files/processes/desktops, and streams normalized
  events. It deliberately delegates sandbox lifecycle, Git management,
  storage, network policy, and credential security to other products.
 That makes it complementary in a component diagram but competitive in product
 architecture. The layer that becomes the stable integration point tends to own
 the ecosystem. Three plausible threat paths matter:
 1. **Standard control plane, interchangeable runtimes.** Applications integrate
   once with Sandbox Agent and treat E2B, Daytona, BoxLite, Docker, or a future
   local microVM as replaceable compute. A provider that bundles adequate
   egress and credential custody makes bot-bottle's end-to-end launcher less
   necessary.
 2. **Policy grows upward.** Sandbox Agent already configures permissions,
   skills, MCP, custom tools, filesystem/process access, and computer use. If
   it adds a declarative, host-verifiable policy document, the overlap with
   agent/bottle manifests becomes substantial even if enforcement remains
   delegated.
 3. **UI and session ownership.** Its universal transcript schema, Inspector,
   React components, event replay, and remote terminal/computer APIs can become
   the natural basis for desktop, web, and mobile agent managers. bot-bottle's
   security layer could remain stronger while losing the operator surface and
   distribution channel.
 The counter-position is not to claim that manifests and an API are mutually
 exclusive. The defensible split is:
 - bot-bottle owns the trusted policy and enforcement plane outside the agent;
 - a provider-neutral protocol owns agent process control and normalized
  events; and
 - the operator UI consumes both.
 This suggests an explicit compatibility decision rather than parallel,
 accidental protocol design: evaluate running Sandbox Agent inside a bottle and
 exposing it only through the authenticated bot-bottle control plane. If its
 schema is suitable, adopting it could turn a threat into an integration while
 keeping manifests as the higher-trust policy source. If it is unsuitable,
 bot-bottle should still publish a stable provider-neutral session/event API so
 frontends do not depend on Claude/Codex/Pi-specific process behavior.
 ## Comparison table
 *Isolation/sandbox tools only. AGT and OAP are governance layers — see their per-project notes above.*
@@ -616,6 +817,70 @@ would be a *backend* bot-bottle could call, not a competitor to its
 manifest layer. endo-familiar is in a different paradigm entirely:
 capability passing rather than kernel boundaries.
 **Recent entrants change two parts of this read.** yolo-cage is closer to the
 actual threat model than agent-safehouse or litterbox: it combines a VM-style
 boundary with mediated Git and filtered HTTP specifically for parallel coding
 agents. Sandbox Agent SDK is the more important strategic entrant even though
 it supplies no isolation. It can become the standard agent-control layer above
 all of these runtimes, including a future bot-bottle backend. CloudRouter is
 the clearest workflow challenge because its browser/desktop/GPU loop makes
 parallel agents visibly more capable, not merely safer.
 ## Gap evaluation after the 2026-07-27 entrant scan
 ### Material gaps
 1. **A stable provider-neutral control and event protocol.** This is the
   largest newly visible gap. bot-bottle normalizes launch/provisioning across
   providers, but an external UI or orchestrator still lacks one documented
   contract for creating a Claude/Codex/Pi session, sending input, handling
   permission/supervision events, streaming normalized output, reconnecting,
   and replaying history. Sandbox Agent SDK addresses exactly this layer and
   is already portable across many sandbox providers.
 2. **Browser/preview closure.** CloudRouter and Eve make a browser or desktop
   part of the standard agent environment and expose screenshots/live viewing
   to the operator. bot-bottle can run dev servers and supports nested
   containers, but it does not present a first-class browser/computer-use
   primitive or an auth-protected preview surface. For coding agents expected
   to verify UI work, this is a real product gap.
 3. **Unified parallel-session operator UX.** Named persistent bottles and
   supervision provide the substrate, but the recent products make task
   switching, live progress, notifications, terminal attach, diffs, and
   session history the product. Security depth will not compensate for a
   visibly rougher daily loop.
 4. **Normalized transcript persistence and replay.** bot-bottle preserves
   provider-specific state for resume; it does not expose a provider-neutral
   event record suitable for audit, replay, analytics, or a web/mobile client.
   This is both a UX gap and an audit gap.
 ### Important, but not necessarily bot-bottle features
 - **Cloud VM/GPU provisioning.** Valuable for elastic workloads and could be a
  backend, but it conflicts with the local-custody default and should not
  displace core policy work.
 - **Automatic model routing.** Black LLAB and Eve sell task-to-model routing.
  bot-bottle's provider-template boundary can host that choice without making
  it part of the trusted sandbox policy.
 - **A thousand SaaS connectors.** This broadens capability and blast radius.
  The bot-bottle-native answer should remain explicit, scoped forge/egress
  associations rather than connector count as a goal.
 - **SDK-driven sandbox lifecycle as the primary configuration model.** Useful
  for platform builders, but not a replacement for reviewable, host-owned
  manifests. A control API and a declarative policy source are compatible;
  neither should silently become the other.
 ### Areas where bot-bottle remains ahead
 - real provider and forge credentials remain outside the agent process rather
  than being extracted into its environment;
 - authorized HTTP payloads are scanned, not merely destination-filtered;
 - Git writes traverse a distinct gate with secret scanning and host-held
  upstream credentials;
 - role policy is host-owned, composable, and separate from untrusted repo
  content; and
 - local Firecracker/Apple Container execution preserves operator custody
  without requiring a hosted sandbox platform.
 ## Borrowable ideas
 ### Already shipped or otherwise addressed
@@ -642,6 +907,19 @@ capability passing rather than kernel boundaries.
 ### Still worth considering
 - **Sandbox Agent compatibility or an equivalent stable protocol (highest
  priority):** spike running its server inside a bottle behind bot-bottle's
  authenticated control plane. Compare its session/event schema, permission
  model, restore semantics, and provider coverage with current provider
  adapters. Adopt compatibility if it preserves the host-owned trust boundary;
  otherwise specify bot-bottle's own stable API before building another UI.
 - **First-class browser/preview loop** (from CloudRouter and Eve): give a
  bottle an optional browser/computer-use capability plus an operator-visible,
  authenticated preview/screenshot surface. Treat its network access as part
  of the bottle policy, not an implicit bypass.
 - **Provider-neutral transcript/event persistence** (from Sandbox Agent SDK):
  retain enough normalized structure for replay and audit while preserving the
  provider-native state needed for exact resume.
 - **Live network activity in the supervisor TUI** (from Docker sbx): show
  allowed and blocked connections and let the operator propose policy changes
  from the existing supervision surface.
@@ -652,10 +930,11 @@ capability passing rather than kernel boundaries.
  closer review. This needs a carefully specified trust model before it can be
  more than a heuristic.
-Not worth borrowing: the SDK-first programmatic API style of boxlite /
+Not worth borrowing: SDK-first *policy configuration* as used by boxlite /
-microsandbox (cuts against the declarative-manifest stance), and the
+microsandbox (cuts against the reviewable declarative-manifest stance), and
-hosted-SaaS dashboard model of tilde.run (cuts against the
+the hosted-SaaS custody model of tilde.run (cuts against the "infrastructure I
-"infrastructure I control" goal).
+control" goal). A provider-neutral runtime-control API is a separate concern
 and is worth borrowing.
 ## Publishing and positioning verdict
@@ -679,9 +958,15 @@ bot-bottle remains unusual in combining:
 The practical wedge is “as easy as native yolo, with declarative role policy
 and self-hosted custody,” including scoped access to private LAN/Tailnet
 services that cloud-first runtimes cannot provide without additional network
-plumbing. The main competitive risks are a local wrapper such as claudebox or
+plumbing. The main competitive risks are now:
-Docker sbx growing a role-manifest layer, and GUI products such as SuperHQ
+
-adding equivalent policy and audit depth.
+- a local wrapper such as yolo-cage, claudebox, or Docker sbx growing a
  role-manifest and credential-custody layer;
 - Sandbox Agent SDK becoming the standard control/session boundary and making
  the runtime beneath it interchangeable; and
 - GUI products such as SuperHQ or CloudRouter adding equivalent policy and
  audit depth before bot-bottle closes the browser/preview and
  parallel-session UX gaps.
 ## Caveats