Route Readiness
How B3IQ explains why a machine or model is eligible or blocked for routed inference.
Route readiness is the public-safe diagnosis for whether a node can serve routed work. It combines node liveness, route health, protocol state, model profile policy, benchmark evidence, queue health, and customer gateway policy.
Public diagnosis
Route readiness is surfaced on your node's page in the explorer and in the node dashboard. It is backed by a public-safe readiness endpoint:
textGET /v1/public/nodes/:node_id/route-readiness?model=<model>
The response can include route blockers, model blockers, next actions, and
operator prompts. For consumer_edge profiles, model_profiles[].consumer_edge
reports model_class, a conservative concurrency_cap, benchmark age and
freshness, the uptime gates (online, tunnel ready, service persistent), recent
completions and errors with an error_rate_pct, the blockers, the next actions,
and an earning_status of earning_ready, paused, or blocked. It must not
include tunnel IDs, local URLs, runtime IDs, prompts, outputs, request IDs, API
keys, customer IDs, raw tokens, route secrets, or private tunnel details.
Gate order
Blockers and actions
| Blocker | Meaning | Operator action |
|---|---|---|
| Enrollment | Node is not fully enrolled | Complete managed enrollment |
| Heartbeat | Heartbeat is stale, missing, or offline | Bring host agent online and sync a fresh heartbeat |
| Runtime | Runtime is not ready or reachable | Start or configure runtime and rerun probe |
| Service persistence | The host agent is not installed as a persistent service, or does not report its persistence state | Install the host agent as a systemd service (or enable systemd linger) and let it publish a fresh heartbeat |
| Public route | The tunnel or the public inference route is missing, unhealthy, or not advertised to the router | Rotate or repair the broker-managed tunnel from the host menu, then re-publish the route in heartbeat metadata |
| Claim | Node is not linked to an owner account | Redeem the claim code from the node's setup screen in your dashboard |
| Route tier | The profile sits on a tier that never dispatches, or its route class is paused by an incident control | Serve the model through a runtime on a dispatchable tier, or resume the route-class incident control |
| Benchmark proof | Observed benchmark evidence is missing or stale | Keep the node online with a healthy runtime: B3IQ schedules a fresh benchmark automatically |
| Queue health | Queue is blocked or unhealthy | Clear runtime queue issue and publish heartbeat |
| Customer policy | The calling key rejects the model by allowlist or denylist, rejects the route tier, or the request asks for a modality, task, or capability the profile does not serve | Widen the key policy or send an allowed request |
A machine switched to Earn mode is excluded from every b3iq routing query at
the SQL loader. It never appears as a candidate, so route readiness reports it
as route_missing until you switch it back to Bare metal from the machine's
dashboard page.
The short answer
The operator-facing answer to "why is nothing routing to my machine?" should be direct:
Routing requires more than an installed model. The node must be enrolled, online, route-ready, claimed, runtime-ready, model-installed, network-eligible, benchmark-observed, on a dispatchable route tier, queue-healthy, and accepted by customer policy.
Clearing every gate on this page makes a machine routable. It does not make it earn: inference on B3IQ is free, so a served request pays no one. See Claiming and earnings for what a machine does earn from.
Stale benchmark prompts
benchmark.smoke is not an operator-runnable command. If an otherwise eligible
profile depends on stale observed benchmark evidence, keep the node online
with a healthy runtime after any runtime, driver, model artifact,
quantization, context, or queue-policy change. B3IQ re-benchmarks eligible
profiles that lack fresh observed evidence on its own schedule.