Troubleshooting

No inference engine is running or installed, so the node cannot serve any model.

Run b3iq-host runtimes to see what is installed and reachable. If the list is empty or every engine shows offline, install one from the setup wizard — it picks an engine that suits your hardware and starts it for you. Re-run b3iq-host runtimes afterward to confirm the engine reports ready.

A runtime is up, but the model the router would dispatch is not installed, is still downloading, or has not finished its first load.

Pick a model profile your machine can actually serve, then watch the install job to completion. The wizard surfaces install progress; you can also tail b3iq-host logs -f while the download and first load run. To see install status (installed, downloading, ready) for every profile, list GET /v1/model-profiles; GET /v1/models lists only the models that can answer right now. A model only counts as ready once it has loaded and can answer — "downloaded" is not the same as "ready". See model readiness for the full profile fields.

A machine switched to Earn mode serves no B3IQ inference by design — it is offered to external GPU marketplaces instead, and SSH and health telemetry are turned off along with it. This is the first thing to check when a machine you expect to be serving looks unreachable or idle.

Switch the machine back to Bare metal from its page in the dashboard to resume serving your own inference and restore SSH.

The node is online but not receiving routed work. Routing requires more than an installed model — several independent gates must all pass:

• Route — tunnel and public inference are healthy.
• Protocol — the node is registered and active.
• Model — the profile is installed and ready.
• Benchmark — fresh benchmark evidence has been observed for the profile.
• Customer policy — the caller's key accepts the model (key scoping).

To see exactly which gate is blocking you, open your node's page in the explorer or read route readiness, which lists every blocker and the matching operator action.

The dashboard warns when your running daemon is below the minimum supported version, and prompts you to update so the node stays current with protocol and readiness changes.

Update the host agent, then confirm with b3iq-host version and b3iq-host doctor. See updates for the per-OS update procedure.

Claim codes are short-lived — roughly 15 minutes — so a code left open in a browser tab will often have expired by the time you use it. If the dashboard is stuck on step 1 or rejects the code, regenerate a fresh one and claim again promptly.

An unclaimed node can be re-claimed safely, so regenerating does not strand the machine. If the node already shows as enrolled in b3iq-host status, you do not need a new claim code.

The host agent listens on loopback only by default:

text
http://127.0.0.1:8831

From the machine itself, curl --fail http://127.0.0.1:8831/health should succeed. If it does not, the daemon is not running — check b3iq-host status and b3iq-host logs -f. If you are trying to reach the listener from another device on your LAN, note that LAN exposure is opt-in and requires explicit configuration plus network controls; loopback will not answer remote requests by design.

Routed inference — requests sent through your account's API keys — reaches your node through a Cloudflare tunnel. If the route shows disconnected, you have two options from the host menu:

• Rotate the tunnel to issue fresh credentials while keeping the same route — use this for a transient or stuck connection.
• Revoke the tunnel to tear down public inference entirely — use this when you are taking the node offline or suspect the credential is compromised.

Prefer rotate for recovery; reserve revoke for intentional teardown. After rotating, re-run b3iq-host doctor and confirm the route gate clears in route readiness.