Introduction

An agent works in a loop: the model decides, a tool acts, and the result goes back to the model. When the tools and the model live in different places, every turn pays for the trip between them. B3OS puts the tools (browsers, sandboxes, screenshots and videos, durable workflows, marketplace actions) on a B3IQ node that serves models, behind one key, one SDK, one CLI and one MCP server.

Four layers on one machine

B3IQ owns the hardware and serves models on it. B3OS is the runtime and automation layer on top, running inside one daemon on each B3IQ node. The stack explains how a request travels through it.

What runs where

When your agent runs in a sandbox on the node and uses a model served there, the think-act-observe loop stays on one machine. Agents that run elsewhere call the same tools over the network. If you use a frontier model hosted somewhere else, only the act and observe steps are co-located with B3OS, not the model call.

The same-host latency page shows what that saves per tool call and where the numbers come from.

Products

One key, one SDK, one CLI, one MCP server

Every product sits behind the same API at https://beta-api.b3os.org. Create a key in the dashboard, export it as B3OS_API_KEY, and use whichever client fits:

• plain HTTP, documented in the API reference;
• the TypeScript SDK @b3os/sdk and the Python SDK;
• the CLI b3os;
• the MCP server, @b3os/mcp on your machine or https://beta-api.b3os.org/mcp.

Code inside a B3OS sandbox calls the same API at http://127.0.0.1:7700 without a key. The sandbox's grant decides what it may call.

Numbers on this site

B3OS publishes a latency figure only when raw benchmark data backs it. Every figure on these pages says what it is: a target from the build contract, a dev baseline measured on the beta node before the products existed, or a measured product result with its conditions and raw data. Benchmarks describes the method.

Start here