Skip to content

Add Sandboxes documentation page - #24

Open
mmilutinovic371 wants to merge 5 commits into
mainfrom
docs/sandboxes
Open

Add Sandboxes documentation page#24
mmilutinovic371 wants to merge 5 commits into
mainfrom
docs/sandboxes

Conversation

@mmilutinovic371

Copy link
Copy Markdown

Summary

New docs page for the DeepSands sandbox service (isolated microVMs for running untrusted code), added ahead of general release per mentor feedback that pre-release docs matter — especially the non-obvious details (lifespan, /workspace-only persistence, isolation boundaries).

  • New page: sandboxes/overview.mdx, added to nav between GPU Instances and Hosted Agents
  • Content verified directly against the backend implementation (deep-sands service) and the deepinfra-python SDK source, not just the marketing blog post — plans/pricing table, lifecycle states, three independent timeout clocks (idle / 24h hard age / 7-day stopped retention), filesystem persistence model, isolation/networking, quotas, typed errors, Python SDK usage, and raw HTTP API examples
  • Note: docs use /workspace (not /work) for all paths — the backend only accepts /workspace; the SDK's own README/examples currently use /work, which is a separate bug worth fixing in that repo

Test plan

  • Validated docs.json is well-formed JSON
  • Ran npx mint broken-links — no broken links
  • Visual check with mint dev (not run in this environment)

mmilutinovic371 and others added 3 commits August 14, 2026 12:37
Documents the DeepSands sandbox service ahead of release: plans/pricing,
lifecycle and timeouts, filesystem persistence (only /workspace survives
stop/start), isolation/networking, quotas, errors, Python SDK, and HTTP API.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Exact specs and hourly rates can change; link to the dashboard and
catalog endpoint/SDK method instead of a table that will go stale.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The backend branch merged main since the page was first written, and
fixed the fs-path-outside-/workspace bug from a 500 to a proper 400 --
update the docs to match instead of describing a bug that's gone.
Also: drop the unreachable 403 row from the errors table, add the 400
row that's now common (bad path, empty command, timeout out of range),
note the read-side 100 MiB cap symmetric to writes, and mention the
fail_reason field GET/list now returns for a failed sandbox.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Comment thread sandboxes/overview.mdx Outdated
A sandbox is subject to three independent clocks:

- **Idle timeout** — configurable per sandbox with `timeout` at creation (an hour, by default, if you don't pass one, and there's currently no way to disable it). Idle time is measured from when your **last call finished**, not when it started, so a single command that runs longer than the idle timeout can have its sandbox stopped out from under it mid-execution. If a job might take a while, set `timeout` generously (up to the 30-minute per-command cap) rather than relying on the default.
- **24-hour hard age limit** — a sandbox auto-stops 24 hours after **creation**, and that clock is never reset by `stop()`/`start()`. Create a sandbox, stop it after ten minutes, come back the next day, and it can auto-stop again shortly after you restart it — simply because it's more than a day old by wall-clock time. If you need something to outlive a day of calendar time, `terminate()` and recreate it rather than stop/start-ing the same one indefinitely.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be honest, this flow doesn't seem right to me. Let's refactor the logic to: a sb can be in running state max 24h at a time, then it becomes stopped. Also, a stopped sb is deleted after 7 days of inactivity. In theory someone might start and stop his sb forever, but that's not a problem for us and he will be paying for the time it's running.

Comment thread sandboxes/overview.mdx
Comment thread sandboxes/overview.mdx
Comment thread sandboxes/overview.mdx
mmilutinovic371 and others added 2 commits August 19, 2026 16:18
…examples

- backend#4450 (merged) changes the 24h sandbox lifetime cap to measure
  continuous running time instead of wall-clock age since creation, so
  stop()/start() now resets it -- update both mentions and drop the
  now-misleading terminate()-and-recreate guidance.
- Add an ephemeral-by-design paragraph to the intro per PR review
  feedback from ats3v.
- Make the async SDK example actually runnable (bare `await` outside a
  function is a SyntaxError) and annotate fs.read()'s bytes return type
  on the context-manager example, both prompted by user confusion.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
stop() and terminate() don't check suspension (sandbox_routes.py) --
only create/start/exec/fs calls do. The old text implied stop was
blocked too, which would have stopped suspended users from cutting
off their own billing.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants