Grain and agent sandboxes: Daytona, Blaxel, Modal

The relationship in one line

A sandbox is the disposable or session-bound room where code executes; Grain is the workspace where selected output becomes a maintained artifact. Daytona describes stateful elastic sandboxes for agents, Blaxel provides microVMs with a persistent Agent Drive filesystem, and Modal offers serverless compute with GPU-capable sandboxes. Those are execution choices. Grain does not replace their APIs or help you build an agent. It accepts files from the coding agent you already use, publishes them, and keeps the artifact connected to its data, access rules and reader comments.

What each layer owns

When you need both

You need both layers when agents must execute safely at scale and people must use the results afterward. Imagine an internal research service that launches one isolated job per customer brief. A sandbox provider runs the extraction and transformation code, contains failures and gives your orchestration service an execution boundary. The final deliverable is a report app with source files, a review queue and a weekly refresh. Grain can hold that app, its Postgres data, login boundary, schedule and share URL. Your system decides which sandbox output is ready to publish. Grain then makes that approved state the artifact people return to. This separation prevents a process identifier or expiring preview from becoming the team's accidental system of record.

When you need only one

Choose a sandbox provider alone when you are building infrastructure: an evaluation harness, a code interpreter, a fleet of autonomous workers or a product that must run arbitrary code behind its own interface. Daytona, Blaxel and Modal give you different execution models to evaluate; Grain does not expose a replacement for those product surfaces. Choose Grain alone when a human already runs a coding agent and the immediate problem is that its page or tool only exists on a laptop. A local Grain workspace can publish the files without you selecting a sandbox vendor. If the artifact later needs paid cloud execution, Grain's hosted cloud workspaces use E2B underneath. The decisive question is whether you are engineering the runner or delivering the result.

How it fits together

1. Define a useful deliverable. Give the agent a prompt such as: Build a review dashboard from the completed evaluation JSON. Add filters by model and failure type, a Postgres table for reviewer decisions, login access and a daily aggregation job. The prompt separates the artifact from the execution fleet that produced its input.
2. Run isolated work. Your orchestration system starts the appropriate Daytona sandbox, Blaxel microVM or Modal workload. It supplies inputs, runs the evaluator and collects the output files. Provider selection belongs here because this layer owns execution constraints and lifecycle.
3. Create the destination. In the dashboard project folder, run grain init. Grain creates the workspace and writes .mcp.json, .codex/config.toml and .cursor/mcp.json so a supported agent can work with it.
4. Have the agent assemble the artifact. The agent turns the collected JSON into the page, app and service files. It can add the Postgres-backed review flow and scheduled aggregation named in the prompt.
5. Publish an intentional state. Run grain push, then grain checkpoint -m "evaluation dashboard ready". Do not treat every transient sandbox filesystem as a release. The pushed files and checkpoint identify the state people should review.
6. Create the audience boundary. Run grain share --public for open access or grain share --password <pw> for a protected review. The returned URL belongs to the artifact rather than to one execution session.
7. Iterate from comments. Reviewers comment on the artifact. The coding agent reads that feedback, revises the files and publishes another checkpoint without changing which sandbox provider produced the underlying evaluations.

Frequently asked questions