A home for the work, and a runtime for the computation.

Start with the resource you are trying to manage

A workspace organizes the continuing job: its sources, instructions, conversations, reusable roles, and checked results. A sandbox supplies an execution resource with a particular identity, credentials, capabilities, and lifetime. An agent may need either or both, depending on whether the problem is retaining the work or running a computation.

In Clanker, the browser Workspace and standalone Sandbox API are distinct surfaces. Creating a Sandbox API resource does not create a Workspace Project or Session. A Project identifier is not a sandbox identifier, and a hosted MCP token is not a sandbox credential. Choose the intended resource before copying an example or issuing an action.

Compare the documented Clanker surfaces

Distinguish sleep, stopping, and deletion

The Sandbox API runbook distinguishes scratch /workspace from sandbox-scoped persistent /data. Use the returned expiry and inspect the resource’s actual status. /data survives compute sleep, but deleting the sandbox removes sandbox-scoped data. Export needed results before authorized cleanup and keep the export location with the task record.

Workspace Projects retain saved material under their account and retention rules; their existence does not prove a particular cloud computer remains active. BYOA registration and successfully saved private files can also outlive bounded compute. None of these statements guarantees that unsaved process memory survives an interruption.

Keep authentication attached to its interface

Hosted Workspace MCP uses browser authorization and explicit permissions. Its grant can cover the connected user’s accessible Workspace; the selected Project is task context. Workspace HTTP uses a separately supported authenticated route. Follow the current live instructions rather than interchanging account cookies, CSRF values, and MCP tokens.

The Sandbox API has its own account or anonymous execution contract and returned sandbox credentials. Retain those for the same sandbox and task. Do not substitute a new anonymous resource after a timeout when an existing one may already hold the result. First inspect the known resource and reconcile what happened.

Use a Project for the decision and a runtime for the dependency

A fictional operations team comparing supplier terms benefits from a Project with the proposals, criteria, evidence table, and decision note. If the same task needs a script to normalize a large supplied dataset, identify a supported execution path for that calculation and save its inspected result with the continuing work.

A developer building a service that creates, inspects, and cleans up hosted runtimes may need Sandbox API directly. Follow that API’s capabilities and lifecycle instead of treating a browser Project as a generic shell endpoint. A successful shell command does not establish document preview, recurring work, or agent publication behavior.

Evaluate the whole path to a retained result

For either route, define the output, a check against known evidence, the next task, and a stop condition. Inspect the actual result before claiming completion. Record which resource produced it and where it now lives. A temporary runtime output is not a completed handoff until the intended reviewer can open the retained copy.

Review usage on the active surface and stop resources you no longer need. Closing a viewer may leave an environment running. Check current pricing, account capabilities, and service boundaries before a larger deployment. This comparison explains resource selection; it does not claim a universal sandbox limit or performance advantage over another provider.

Try it with a small example.

Before you use the result.

• Workspace and sandbox identifiers and credentials are not mixed.
• The persistence claim names the resource and event it survives.
• Needed outputs are inspected before cleanup.
• The next reviewer can access the retained result.