B3IQ separates local usefulness from network participation. A machine can be valuable as a local inference host without being ready to take routed work. Routing readiness is a routing gate, not a payment gate: serving a request is metered and receipted, but it is not what pays a machine's owner.

Mode summary

ModeDefaultWhat it enablesWhat it does not imply
Local ModeYesLocal setup, local auth, local API keys, local OpenAI-compatible inferenceCloud enrollment or network routing
Managed ModeOperator opt-inSigned enrollment, heartbeats, command polling, support and fleet workflowsEarn eligibility by itself
Network ModeGatedClaimed, route-ready, benchmarked supply that serves routed inference to its owning accountA shared public pool. A key routes only to that account's own 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.

Tip

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 traffic to them; the profile field that records it is paid_route_eligible. Routing is own-nodes-strict: a gateway key selects only among that account's own machines. There is no shared public pool that a customer key draws from.

1

Identity

Node enrolled and heartbeat is fresh.

2

Route

Broker route and tunnel are healthy and inference is allowed.

3

Onboarding

The machine was onboarded with a B3IQ-issued code and claimed to an account.

4

Model

Profile is installed, network-eligible, benchmarked, and paid-route eligible.

5

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 routes.

What claims are safe

Do

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.

Decision guide

Your B3IQ machine arrives with the host agent installed and set up. 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 and tunnel health, a claimed node, model install, benchmark evidence, paid-route policy, queue health, and customer policy. There is no separate admin approval step.

Ask a question... ⌘I