Local, Managed, Network
The three B3IQ operating modes and how they map to local inference, managed control-plane enrollment, and paid network routing.
B3IQ separates local usefulness from network participation. A machine can be valuable as a local inference host without being ready for paid routed work.
Mode Summary
| Mode | Default | What it enables | What it does not imply |
|---|---|---|---|
| Local Mode | Yes | Local setup, local auth, local API keys, local OpenAI-compatible inference | Cloud enrollment, paid routing, or approval |
| Managed Mode | Operator opt-in | Signed enrollment, heartbeats, command polling, support and fleet workflows | Earn eligibility by itself |
| Network Mode | Gated | Approved, route-ready, benchmarked supply that serves paid routing to its owning account | A shared public pool — a key routes only to that account's own approved machines |
Local Mode
Local Mode keeps the host useful even when the cloud or protocol surfaces are not involved. The wizard, local API keys, model installs, runtime probes, local playground, and local receipts all belong here.
Start in Local Mode unless you are intentionally testing B3IQ managed or paid network workflows.
Managed Mode
Managed Mode enrolls a node in the control plane. The host signs an enrollment challenge with its Ed25519 identity, posts signed heartbeats, and polls for commands over outbound HTTPS. This model works behind normal NAT and firewall setups.
Managed Mode can support:
- Public-safe node inventory and readiness.
- Remote command queues with signed results.
- Support grants that avoid exposing setup tokens or local secrets.
- Broker-managed public routes when explicitly configured.
- Receipt and billing evidence from managed or routed work.
Network Mode
Network Mode is a policy gate, not a toggle. A node and model profile need live evidence before B3IQ routes paid traffic to them. Routing is own-nodes-strict: a gateway key selects only among that account's own approved machines. There is no shared public pool that a customer key draws from.
Identity
Node enrolled and heartbeat is fresh.
Route
Broker route is healthy and inference is allowed.
Approval
Node is enrolled and an admin has approved it to earn.
Model
Profile is installed, network-eligible, benchmarked, and paid-route eligible.
Customer
Gateway key and model policy allow the request, and a machine on the caller’s account can serve it.
Own-Nodes-Strict Routing
There is no public pool to opt into or out of. A customer's key dispatches only to machines that customer's account owns, so your fleet serves your traffic and nothing else. Enrollment, readiness, and receipts work the same across your machines, and B3IQ never routes an outside caller's request onto your hardware.
For the step-by-step — minting a fleet key and calling your own machines — see Run a Private Fleet.
Consumer Edge
consumer_edge is explicit. It is a low-priority route tier for small
models or edge work when benchmark, persistence, queue, customer policy, and
incident gates allow it. Local-convenience profiles do not automatically become
paid routes.
What Claims Are Safe
Describe exact readiness
Say a node is local-ready, managed-enrolled, route-ready, benchmark-observed, or paid-route eligible when those gates are actually true.
Flatten all modes into earning
A local profile or an installed model does not prove billable network route eligibility.
Decision Guide
Install the host agent, complete setup, create a b3iq_local_ key, and use
the local API. You do not need managed enrollment.
Use Managed Mode. The node can publish heartbeats and receive narrow command workflows without opening inbound ports.
Treat that as Network Mode. You need route health, registration, admin approval, model install, benchmark evidence, paid-route policy, queue health, and customer policy.