Plimsoll is for running code an agent produces, not for hosting the whole agent. It puts a Go service between your application and an execution backend. Each request can demand a minimum isolation level; a weaker deployment must refuse before executing it. That makes the boundary an explicit part of the interface rather than an assumption buried in deployment settings.

The 0.21.0 release, published October 9, binds daemon responses to individual request IDs. This matters when a dropped or replayed response could otherwise make a client believe “nothing ran” and repeat a potentially side-effecting operation. It also tightens API-route matching and closes unused sessions after their idle timeout.

  • Execution choices: in-process JavaScript for development, ordinary Docker containers, Docker under gVisor on Linux, or hosted microVMs through E2B and Docker Cloud. Results report process, container, kernel, or vm; these labels describe the project’s configured boundary, not hardware-backed proof.
  • API access without handing over your token: code has no network by default. An optional grant permits specific API methods and routes through a broker outside the sandbox, which adds the real credential and enforces call budgets. An allowed route can still transmit data or cause side effects—grants need careful review.
  • Interface and setup: Go, Python, and TypeScript clients, with adapters for frameworks including Vercel AI SDK and Google ADK. Build the daemon with Go 1.26.9 or newer, create caller credentials, and configure a backend. The small go run ./examples/minimal example needs no Docker, but its in-process boundary is not suitable for hostile code. Stronger self-hosted isolation requires Docker images and a gVisor installation.
  • State and receipts: supported backends can keep a sandbox across calls, including interpreter state. Clients check request/result hashes, and a separate signing tool can verify linked run records. Neither a hash nor a signature proves the generated program is correct.
  • Cost: Apache-2.0 source, with your own build and hosting costs. E2B and Docker Cloud execution incurs provider charges; daily paid-time allowances can cap usage. This is not a claim that production execution is free.

The limits are substantial: pre-1.0, single-maintainer, and no independent security audit. Dependencies must be baked into sandbox images; arbitrary npm install during execution is not supported. Version 0.21 also changes the protocol: upgrade clients and daemon together, and preserve the documented response headers through proxies.

Useful as execution plumbing for a controlled agent service—not something to trust with sensitive workloads merely because the examples run. This capture reviews the release notes and documentation; it is not a hands-on test or security assessment.