disposable-exec
Python-only isolated execution

Python execution with a real safety boundary.

disposable-exec is a hosted isolated execution system for short-lived remote Python runs. It is built for agent-triggered code, workflow-triggered execution, and unknown Python that should not run on your app host.

Start with a Free API key. Then validate one real path through /me, optional /diagnose, /run, /status/{execution_id}, and /result/{execution_id}.

Get a Free API key Use the playground with a key
Live execution surface api ready
Request
POST /run {"script":"print(\"hello from disposable-exec\")"}
Optional /diagnose

Cheap preflight for payload, path, syntax, and local-import issues.

→
Execution /run

Submit short-lived Python to the hosted execution path.

Lifecycle
queued
running
completed
stdout
hello from disposable-exec
stderr
-
exit code
0
result
status, stdout, stderr, exit_code
Why this exists

Show the execution system first. Explain it second.

The product is intentionally narrow: Python-only, short-lived, inspectable, and designed to give generated or risky Python a separate execution surface before it touches core systems.

Hosted isolated execution for short-lived remote Python runs
Not a shell sandbox and not a multi-language platform
Inspectable outputs status, stdout, stderr, exit code, and result
Agent-triggered Python

When an agent needs Python, but the app host should not become the runtime.

Who it is for

Teams building agent tools, operator copilots, and assistants that need real Python execution to do useful work.

What goes wrong without it

Generated code lands directly on the app host or worker host, where simple mistakes become file writes, process sprawl, or harder-to-audit failures.

What disposable-exec changes

It gives the agent one hosted isolated Python execution path with inspectable status, stdout, stderr, exit code, and result.

Automation/workflow isolation

When a workflow needs Python execution, but the orchestrator should not become the runtime.

Who it is for

Teams wiring Python execution into schedulers, internal tools, integration layers, and operational workflows.

What goes wrong without it

The orchestration layer turns into a mixed-control runtime where dependencies, failures, and risky scripts blur into the main operational surface.

What disposable-exec changes

It keeps Python off the orchestrator and turns execution into a separate hosted dependency with one simple API flow.

Safety boundary for unknown Python

When generated or user-supplied Python should cross a real boundary before it reaches core systems.

Who it is for

Teams dealing with generated code, user-supplied snippets, or Python assembled from external input.

What goes wrong without it

Unknown Python runs on the same system that holds app state, workflow control logic, or user-facing infrastructure, increasing the blast radius of simple mistakes.

What disposable-exec changes

It makes the first decision obvious: route the code through a hosted isolated Python execution system before deciding what to trust.

Plan decision

Use Free to prove the path. Move up only when usage becomes recurring.

Free Prove the full path once.

Get the key, test /me, optionally use /diagnose, and finish one real execution without a paid commitment.

Starter Make it part of recurring work.

Move here when disposable-exec stops being a proof and starts becoming part of regular agent or workflow execution.

Pro / Scale Increase headroom, not complexity.

Use higher tiers when the same API flow is already working and the main need is more monthly credit capacity.

Execution playground

Try one short run after you have a key

This is for users who already have an API key and want a fast first proof. Python-only. Short-lived runs. Not a general shell sandbox.

Start Free View API flow

Get a Free or paid API key first, paste it here, then validate one short Python run before you wire the SDK.

1. Get a Free or paid API key 2. Paste it here 3. Run one short Python script
Playground limits

Runs short self-contained Python scripts only.

Local files and project modules are not available in the sandbox.

Packages that are not installed in the runtime will fail.

If browser access fails, continue with Quickstart and the direct API flow.

You will get status, stdout, stderr, exit code, and execution ID.

If this page cannot reach the API from your browser, open Quickstart and continue with the direct API flow.

Get a Free or paid API key first, paste it here, and try one short Python script.
Developer links

Move from first run to integration

Once you have a successful run, jump into the Python client, docs, or direct source.

PyPI Source Docs