What the mesh actually does.

All 12 routing calls returned a valid decision with a non-zero composite score, a selected execution path, and a persisted RoutingLog entry. No call fell through to a default or errored. The router evaluated between 1 and 3 eligible candidates per request and selected the highest-scoring route every time — the decision engine is live, deterministic, and auditable.

The benchmark exercised four physically distinct compute tiers: browser WebGPU (on-device GPU via WASM), desktop GPU (local VRAM), virtual GPU (rented Spheron H100 cloud node via mesh), and cloud API (proprietary model endpoint). Each tier has different hardware, a different network path, a different cost model, and a different latency profile — and the router correctly matched each workload to the tier its constraints allowed.

The measured latency spread — 120ms → 184ms → 600ms — and cost spread — $0 → $0.000003 → $0.000154 — across the four paths proves the router is not returning a static answer. If routing were hardcoded, every request would land on the same path with the same latency and cost. Instead, the router produced three different winning routes across four workloads, each with a distinct score, confirming the scoring function is evaluating real per-request factors (model size, privacy policy, device GPU, battery, partition weights, node load, heartbeat freshness).

The 70B model routed to the Spheron H100 vGPU mesh node at $0.000003 per inference and 184ms. The cloud baseline for the same request is $0.000154 at 600ms. For this eligible workload, mesh execution cost is ~98% lower than cloud and latency is 3.3× lower. This demonstrates the mechanism works — the mesh path can execute open-weight large-model inference at substantially lower cost than cloud-only execution by using rented GPU capacity directly rather than proprietary API endpoints.

The 1B and 7B models both routed to on-device execution at 120ms and $0.000000 — zero marginal cost, zero network round-trip, zero coordinator fee. The router achieved this by checking model size against the local hardware cap (≤7B with GPU) and selecting local when the model fit. For workloads that fit on user hardware, local execution eliminates per-inference cost entirely — the benchmark demonstrates the router can identify and select this path when eligible.

The gpt-4o request could not run locally (no GPU) or on the mesh (proprietary model, modelSizeB=null — the mesh only serves open-weight models). The router correctly identified cloud as the only eligible path and routed there at 600ms and $0.000154. This proves the fallback path works: when no cheaper tier can serve the request, the router does not fail — it delegates to the cloud API and still returns a valid decision.