On this page

External Compute Providers

Available providers: Orgo Orgo live E2B soon Daytona soon

MIOSA runs computers on three substrates behind one API:

SourceWhere it runs
miosa-cloudMIOSA-managed cloud computers
opencomputersthe user’s own hardware (BYOC) over an outbound WebSocket
externala 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

ExternalComputerOrgo
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/scrollPOST /computers/{id}/{action}
read_file/write_filevia bash (Orgo’s /files API is workspace-scoped multipart)
preview_url(port)Provider-dependent. Use a MIOSA tunnel when direct ingress is unavailable.
stop/destroyPOST /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:

user-alice orgo
running
live screenshot renders here
fed from computer.screenshot()
GOALOpen a terminal and report the OS
  • exec uname -sm Linux x86_64
  • screenshot captured 1280×720
  • left_click x=640 y=360 ok
  • exec echo done done

Set it up

Orgo Connect Orgo
  1. Get a provider API key from the provider dashboard.
  2. Store it per user, server-side, encrypted. Never ship it to the browser.
  3. Scope a MIOSA workspace per user so external boxes roll up to the right tenant for usage and billing.
  4. 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)

metricorgonotes
boot - warm pool272 msfromPool instance
boot - cold3.13 sfresh metal instance
desktop-ready (first command accepted)2.09 s
exec round-trip (bash) p50 / p95100 ms / 116 ms
python exec p50206 ms
file write p50100 msvia bash
click (computer-use) p50200 ms
screenshot p50290 ms - 1.19 svaries with capture path
clone404not available on this plan tier
reported specs1 vCPU / 4 GB / 1280×720nproc 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:

examples/external-compute-orgo →

Provider contract, provider implementations, driver examples, an end-to-end demo, and a comparison benchmark.

View on GitHub →

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

Was this helpful?