> ## Documentation Index
> Fetch the complete documentation index at: https://docs.beta.b3os.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Same-host latency

Why B3OS runs tools on the node that serves its model, which setups keep the loop on one machine, and which numbers are dev baselines or targets.

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](/quickstart/sandbox-agent), model from [infer](/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](/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](/concepts/timing) explains each field.