Your sandboxes now speak Python, TypeScript, and Rust

Until now, driving a Watasu sandbox meant talking to our REST and WebSocket API yourself. That works — the API was always the product — but you shouldn’t have to hand-roll HTTP calls and socket plumbing just to give an agent a computer. So today we’re shipping official SDKs for Python, TypeScript, and Rust.

Same EU-resident sandboxes, same per-second billing — now a few lines of code away.

Hello, sandbox

Set WATASU_API_KEY, install the package for your language, and you’re running code inside an isolated Linux machine.

Python — pip install watasu

from watasu import Sandbox

sbx = Sandbox()
sbx.files.write("/home/user/a.py", "print(2 + 2)")
result = sbx.commands.run("python /home/user/a.py")
print(result.stdout)
sbx.kill()

TypeScript — npm install @watasu/sdk

import { Sandbox } from '@watasu/sdk'

const sbx = await Sandbox.create()
await sbx.filesystem.write('/home/user/a.js', 'console.log(2 + 2)')
const result = await sbx.process.startAndWait('node /home/user/a.js')
console.log(result.stdout)
await sbx.kill()

Rust — watasu = "0.1"

use watasu::{CreateOptions, Sandbox};

#[tokio::main]
async fn main() -> watasu::Result<()> {
    let sbx = Sandbox::create(CreateOptions::default()).await?;
    sbx.files.write("/home/user/a.py", "print(2 + 2)").await?;
    let result = sbx.commands.run("python /home/user/a.py").await?;
    println!("{}", result.stdout);
    sbx.kill().await?;
    Ok(())
}

No polling. Ready means ready.

A small thing we care about a lot: Sandbox.create and Sandbox.connect return only when there’s a usable session waiting for you. The control plane tracks the runtime lifecycle internally, so the SDK never makes you write a while not ready: sleep() loop, and it never silently falls back to client-side polling. When the call returns, you can run code.

The whole sandbox, not a thin wrapper

These aren’t just create and run. Each SDK covers the full surface:

• Processes & PTYs — stream stdout/stderr from long commands, or open an interactive terminal.
• Filesystem — read, write, list, and watch directories for changes; batch writes of text or bytes.
• Git — clone, branch, add, commit, push, pull, configure identity, manage remotes — straight from the sandbox.
• Signed URLs — hand out scoped upload and download links without proxying bytes through your app.
• Checkpoints & snapshots — snapshot a disk mid-task and restore it into a fresh sandbox to pause, branch, or recover a session.
• Templates — build a reusable environment from a package spec or an existing Dockerfile, tag it, and start every sandbox ready.
• Lifecycle & volumes — auto-pause on timeout, resume on demand, and mount named persistent volumes across runs.
• Network policy — set egress allow/deny rules at create time, or tighten them live while a sandbox runs.
• MCP gateway — expose tools to your agent over MCP, straight from the sandbox.

Python and Rust are async-first (Python ships a sync API too — AsyncSandbox when you want it); the TypeScript SDK is ESM-first and ships type declarations.

Code interpreter, built in

If you just want to run model-written code and get structured results back, there’s a dedicated entry point — persistent execution contexts that return results, logs, and error for every run:

from watasu_code_interpreter import Sandbox

with Sandbox.create() as sbx:
    execution = sbx.run_code("print('hello')\n2 + 3")
    print(execution.text)

The same lives at @watasu/sdk/code-interpreter for TypeScript.

Get started

The SDKs are open source under MIT/Apache-2.0 and available today:

• Python — pip install watasu
• TypeScript — npm install @watasu/sdk
• Rust — add watasu to your Cargo.toml

Grab an API key in the dashboard, read the sandbox overview to build your first template, and see the sandboxes page for the full picture. Building something with them? We’d love to hear about it — info@watasu.io.