External Compute Providers
MIOSA runs computers on three substrates behind one API:
| Source | Where it runs |
|---|---|
miosa-cloud | MIOSA-managed cloud computers |
opencomputers | the user’s own hardware (BYOC) over an outbound WebSocket |
external | a third-party provider such as Orgo, E2B, Daytona, and similar services |
This page covers the third option. A user connects a provider key, provider-backed
computers show up inside your MIOSA application, and your product drives them
through the same computers.* surface as a native MIOSA Computer. The provider
supplies capacity. MIOSA keeps the product surface, attribution, routing, and
user experience consistent.
The adapter contract
Every provider maps into a normalized computer shape. Your application depends on the MIOSA Computer API and does not need to branch on each vendor for common actions.
class ExternalComputer(abc.ABC):
@property
def info(self) -> ComputerInfo: ...
def exec(self, command, *, timeout=None) -> ExecResult: ...
def shell_endpoint(self) -> ShellEndpoint: ... # interactive shell/PTY
def screenshot(self) -> bytes: ... # optional
def left_click(self, x, y): ... # optional
def write_file(self, path, content): ... # optional
def preview_url(self, port, path="/") -> str: ... # optional (port ingress)
def stop(self): ...
def destroy(self): ... Provider mapping example
ExternalComputer | Orgo |
|---|---|
exec() | POST /computers/{id}/bash → {output, exit_code} |
python() | POST /computers/{id}/exec |
shell_endpoint() | WebSocket terminal endpoint |
screenshot() | GET /computers/{id}/screenshot |
left_click/type/key/scroll | POST /computers/{id}/{action} |
read_file/write_file | via bash (Orgo’s /files API is workspace-scoped multipart) |
preview_url(port) | Provider-dependent. Use a MIOSA tunnel when direct ingress is unavailable. |
stop/destroy | POST /stop, DELETE /computers/{id} |
Orchestrate it with your driver
The computer handle is provider-neutral, so your backend, hosted agent, or custom loop can drive it:
Bring your own harness
Building your own agent on your own platform? You don’t need our loop — you need
the controls. tools.py (and tools.ts) expose the computer as standard
tool/function schemas plus a dispatcher, so you drop external-computer control
straight into your own agent:
from external_compute import OrgoProvider
from tools import TOOL_SCHEMAS, dispatch
computer = OrgoProvider().create(name="agent-box")
# advertise the tools to your model (OpenAI-style; tools.anthropic_tools() for Anthropic)
resp = your_llm.create(model=..., tools=TOOL_SCHEMAS, messages=[...])
for call in resp.tool_calls:
result = dispatch(computer, call.name, call.arguments) # runs on the box Tools provided: exec, screenshot, left_click, type, key, write_file, read_file — the same primitives the built-in harnesses use. A ClaudeComputerUseHarness (Anthropic computer-use loop) ships in harness.py.
Display it in your UI
Render the computer and the agent’s actions back to your users. The ExternalComputerPanel shows status, the latest screenshot, and the tool-call
log — feed it live data from your platform_server:
fed from
computer.screenshot()execuname -sm→ Linux x86_64screenshot→ captured 1280×720left_clickx=640 y=360→ okexececho done→ done
Set it up
- Get a provider API key from the provider dashboard.
- Store it per user, server-side, encrypted. Never ship it to the browser.
- Scope a MIOSA workspace per user so external boxes roll up to the right tenant for usage and billing.
- Instantiate the provider and hand the computer to your driver:
from external_compute import OrgoProvider
provider = OrgoProvider(api_key=user.orgo_key) # or ORGO_API_KEY env
computer = provider.create(name=f"user-{user.id}-box")
result = computer.exec("uname -a") # drives the Orgo box
print(result.output, result.exit_code)
computer.destroy() Benchmarks
MIOSA ships a like-for-like benchmark that drives providers through the same interface: provision/boot, desktop-ready (first command accepted), exec round-trip, and screenshot latency.
Example provider run (2026-06-09, US client, real API calls)
| metric | orgo | notes |
|---|---|---|
| boot - warm pool | 272 ms | fromPool instance |
| boot - cold | 3.13 s | fresh metal instance |
| desktop-ready (first command accepted) | 2.09 s | |
exec round-trip (bash) p50 / p95 | 100 ms / 116 ms | |
| python exec p50 | 206 ms | |
| file write p50 | 100 ms | via bash |
| click (computer-use) p50 | 200 ms | |
| screenshot p50 | 290 ms - 1.19 s | varies with capture path |
| clone | ❌ 404 | not available on this plan tier |
| reported specs | 1 vCPU / 4 GB / 1280×720 | nproc reports 8 cores |
For reference, MIOSA sandbox snapshot restore boots about 166 ms p50 in the
current published benchmark (see Benchmarks). Run the adapter with a MIOSA_API_KEY to
print both columns side by side:
MIOSA_API_KEY=msk_... python benchmark.py --runs 12 --json Get the code
The full, runnable adapter examples and benchmark live in the repo:
Provider contract, provider implementations, driver examples, an end-to-end demo, and a comparison benchmark.
examples/external-compute-orgo/
external_compute/
provider.py # the contract: ComputeProvider + ExternalComputer
orgo_provider.py # Orgo implementation (verified against the live API)
miosa_provider.py # MIOSA implementation for like-for-like comparison
drivers.py # probe, model-backed driver, and custom driver examples
demo.py # connect -> drive -> teardown
benchmark.py # Orgo vs MIOSA on boot/exec/screenshot See also
- BYOC / OpenComputers - the other “bring your own” path (your hardware)
- Computers / Overview - the unified computer surface
- Benchmarks - MIOSA’s own boot/exec numbers