Same-host latency

Every turn of an agent is a model call followed by tool calls. When the model, the tools and the agent sit in different places, every hop between them crosses a network. B3OS runs the tools on the node that serves its model, which removes those hops for an agent that runs on that node too and uses that model.

Where the loop runs

There are three ways to use B3OS, and they differ in how much of the loop stays on one machine:

Your setup	Model call	Tool calls
Agent in a B3OS sandbox, model from infer	On the node	On the node, over vsock
Agent elsewhere, model from infer	Over the internet to the edge	Over the internet to the edge
Agent elsewhere, a frontier model from another provider	At that provider	Over the internet to the edge

Only the first keeps the whole think-act-observe loop on one machine. The second still gets the warm pools (browsers already running, microVMs already restored) but pays a network round trip per call. The third gets co-located acting and observing only; the model call happens wherever that model runs.

Tools that reach outside still cross the internet for that part: a scrape of a public site fetches it from the site, and an action that calls GitHub calls GitHub. What stays local is the hop between your agent, the model and B3OS.

What a local call costs

The numbers below are dev baselines: measured on the beta node before any product code existed, to decide how to build the products. They are floors under the products, not product results. Each was a dev run without the benchmark lock, server side, on the node, between 2026-10-25 and 2026-10-26; the raw data is in bench/baseline/ in the B3OS beta repository.

What	p50	n	Design consequence
Unix socket round trip, 64 B, C, within one CPU complex (CCD) / across sockets	3.5 µs / 12.1 µs	3 runs of 100,000	Products on the node talk over local sockets, not the network
HTTP/1.1 over a Unix socket, Go client and server pinned to one CCD	12.0 µs	3 runs of 20,000	HTTP/1.1 keep-alive is the default local transport; HTTP/2 without TLS measured slower
The same Go round trip with threads left unpinned	50.1 µs	3 runs of 20,000	Latency-critical threads are pinned to one CCD per NUMA node
Host to microVM over vsock, ping	17.6 µs	10,000	Sandbox exec and the in-sandbox API ride vsock
Run /bin/true in a microVM over vsock	162 µs	2,000
Restore a microVM from a warm snapshot to first reply	3.26 ms	100	Sandboxes are claimed from restored slots, never booted on request (cold boot: 58.1 ms, n=100)
Usable browser tab on a warm Chrome headless shell	8.9 ms	100	Scrape contexts and tabs are created ahead of time and claimed from a pool
HTML to Markdown in Rust, readability plus htmd, per page	2.7 ms	33 pages	Extraction runs in Rust inside the daemon; the Node and jsdom pipeline was 64x slower
4 KiB durable write with FUA	213 µs	240,000	A durable routine step is designed to cost about one such commit

n is the number of samples behind each p50; for the "3 runs of" rows the p50 is the median of the three runs' p50s. Sources: bench/baseline/platform/summary.md, bench/baseline/cells/summary.md (the sandboxes baselines) and bench/baseline/vision/summary.md, with every row's conditions and raw data. Those files are in the B3OS beta repository; the raw data does not have a public home yet.

What B3OS commits to

These are targets from the build contract, server side and p50 unless noted. Each will be published only with a measured result next to it.

Operation	Target
Claim a sandbox and run its first command	5 ms, at idle and under 100-claim bursts
Claim a browser context from the scrape pool	5 ms (p99 15 ms)
Overhead per browser action in a session	1 ms
Dispatch a pure routine step, 1 KB	20 µs
Call an action from a routine on the same node, 1 KB	60 µs
Declarative HTTP action overhead, excluding the upstream	150 µs
Styled screenshot at 1600x900, quiet window included	150 ms

Benchmarks lists every target and how it will be measured.

See it in your own requests

Every response carries Server-Timing with the node's phases, plus edge_auth and edge_upstream when it came through the edge. The request log records the connection each request arrived on:

bash
curl -s "https://beta-api.b3os.org/v1/requests?limit=20" \  -H "Authorization: Bearer $B3OS_API_KEY" | jq '.data[] | {path, connection, duration_ms}'

Compare connection: sandbox calls with connection: edge calls for the same operation to see the transport difference on your own workload. Timing explains each field.