SSH is the API

Every sandbox product ships with a Python SDK. Some also ship TypeScript. A few have Go bindings. Everyone races to wrap their execution runtime in language-idiomatic helpers, because that's what developers expect.

boxd doesn't have an SDK. We don't plan to ship one. SSH is the API.

Why not an SDK

SDKs are convenient. They're also a commitment.

Every SDK has to be maintained across language ecosystems, kept in sync with the backend, updated for every API change, documented for every method. That's real engineering work — and it's work that steers your API design toward what fits cleanly in a Python decorator, not what fits cleanly in an agent's shell.

Worse: SDKs bind your users to the languages you support. A JS-shop team can use your JS SDK. A Python shop uses your Python SDK. A Rust shop waits. An agent whose runtime is a prompt-to-shell loop can't use an SDK at all — not without a bespoke integration layer that translates prompt intent into SDK method calls.

SSH has none of these problems.

What SSH gives you

Every language has an SSH client. Bash does. Python does. Rust does. An agent with shell access does — in fact, an agent with shell access is an SSH client, because that's what agents fundamentally know how to do: run commands.

When SSH is the API:

• Any language works. curl, Python, Node, Go, Rust, Bash, Fish, your grandmother's Tcl. If it can open an SSH connection, it can drive boxd.
• Agents work natively. An agent that can run shell commands can use boxd without a wrapper. No SDK, no tool definition, no "teach the agent how our API works" step.
• The documentation is self-describing. ssh boxd.sh --help works. So does every flag's help output. There's no doc site to keep in sync because the tool documents itself.
• Shell ecosystem comes free. Tab completion, shell history, piping, grep, jq on JSON output. Nothing else has that ecosystem.

What about ergonomics

This is the objection we hear most: "Python users expect Python-idiomatic wrappers."

We get it. Wrap SSH in a thin Python helper if you want — it's fifteen lines. Wrap it in a Go library. Wrap it in whatever your team uses. We shipped the primitive; you pick the ergonomics.

The inverse doesn't work. You can always wrap SSH. You can't unwrap an SDK.

For agents specifically

An agent is a model that types commands and reads output. That's not a metaphor — it's what the runtime actually does. Model generates a tool call, harness executes, output returns, model generates next tool call. In that shape, "ssh into the box and run something" is the simplest possible tool: it's just shell, and the model already knows shell.

Every sandbox SDK we've looked at is a layer of translation between prompt and execution. The agent decides what to do. The harness converts to an SDK call. The SDK calls the runtime. The runtime runs it. The result comes back through the same layers. Every layer is a place bugs hide and a place latency accumulates.

An agent inside a boxd machine skips the layers. It runs a shell command. It reads the output. That's the entire tool interface. The machine is the API surface; SSH is the protocol.

A primitive, not a framework

We're not anti-SDK. Other tools ship great SDKs for different primitives — Modal's Python decorators, E2B's agent helpers. If your shape matches those primitives, those tools will beat us.

But a computer is not a framework. You don't need a Python wrapper to log into a computer; you just log in. The primitive we ship is a real Linux machine. The interface is the one that's been running computers for forty years.

SSH. That's it. That's the API.

For the operational consequence — what an agent harness gets when SSH is the only interface — read on. For how this stacks against the closest competitor by stated positioning: boxd vs exe.dev.