The stack
How B3OS sits on B3IQ, which hosts serve what, and the paths a request takes from your agent to the node and back.
B3OS is the runtime and automation half of a four-layer stack. B3IQ runs the bottom two layers: the GPU machines and the models on them. B3OS runs the top two inside one daemon, b3osd, on each B3IQ node, so the tools and the model share a machine.
| Layer | Owner | Products |
|---|---|---|
| L4 Automation | B3OS | Routines, actions and triggers |
| L3 Runtime | B3OS | Sandboxes, vision, render |
| L2 Inference | B3IQ | Models, reached through infer |
| L1 Compute | B3IQ | GPU machines |
The beta runs on one node, n1, at one site in Eugene, Oregon.
Hosts
| Host | What it serves |
|---|---|
beta.b3os.org | The site and the dashboard (/app). The dashboard calls the same /v1 paths with a session cookie. |
beta-api.b3os.org | The API (/v1/*), the compatibility paths (/compat/*), the MCP server (/mcp), /openapi.json and the CLI's device login. |
usercontent.b3os.org | Bytes you control and nothing else: render artifacts behind signed URLs, and sandbox port previews. It never sets or reads cookies. |
docs.beta.b3os.org | These docs and the canonical llms.txt. |
api.b3os.org and docs.b3os.org belong to the production B3OS app, not to this beta.
Three ways in
mermaidflowchart LR A[Agent anywhere] -- HTTPS + API key --> E[beta-api.b3os.org edge] E -- 60-second node token --> N[b3osd on node n1] S[Agent in a sandbox] -- vsock, no key --> N N --> M[Model on the same node]
Through the edge. Your request reaches beta-api.b3os.org, a Cloudflare Worker that checks your key, scopes and limits. It mints a single-use node token that lives 60 seconds and forwards the request to the node over B3OS's own tunnel. The node never sees your API key. Operations about your account (keys, usage, limits, organizations, projects, sign-in and the pack registry) are answered by the edge itself.
From inside a sandbox. Code in a sandbox calls http://127.0.0.1:7700. A proxy in the microVM carries the call over vsock straight to b3osd, with no network in between. Whatever credentials the code sends are discarded: the call runs as the sandbox's own principal, with only the scopes its grant names. Account operations are not on the node, so they answer 421 edge_only there; call beta-api.b3os.org for those.
On the node itself. B3OS's own tools on the host use a Unix socket. Customers do not reach the host directly.
Inside the node
b3osd hosts every product in one process and dispatches between them in memory, so a routine step that calls vision or a sandbox does not go back out to the network. Browsers, the video recorder and the speech model run as separate services the daemon talks to over local sockets.
Some properties every product shares:
- Warm pools. Requests claim things that already exist: pre-started browsers and browser contexts, restored microVM slots, compiled plans. Nothing heavy starts on the request path.
- One egress guard. Every outbound request you can steer (scrapes, browser navigation, routine HTTP steps, action calls, webhook deliveries, sandbox traffic) resolves the address once, connects to that address, and refuses loopback, private networks, the node's own addresses and cloud metadata. Redirects are checked at every hop.
- Fenced from B3IQ. B3OS runs on its own set of CPU cores with its own memory, disk and network budgets, so tool work and model serving do not compete for the same cores.
- Every request recorded. The node logs each request with its phase timings, whichever way it arrived.
GET /v1/requests/{request_id}returns the record.
Next
- Same-host latency for what this layout saves.
- Keys, scopes and principals for who may call what.