Model Readiness
Check installed models, runtime health, account scope, and current route readiness before calling your own machines.
Model profiles describe what a machine can install and serve. For hosted inference, your gateway key reaches eligible machines on your own account. An installed model still needs a healthy runtime and route, and the request must pass account and key policy.
Choose the runtime from the machine, the workload shape, and the serving model.
llama.cpp and any OpenAI-compatible endpoint you run yourself land on the
portable_local tier; vLLM lands on network_beta. Ollama profiles use
local_convenience. These labels describe serving classes; they do not
establish current availability for your key.
The model guides help you compare model requirements. For installed profiles and serving state, sign in to your machines and open the machine's Models tab. A research listing does not establish that a model is installed or routable.
Dispatch checklist
Use the OpenAI SDK quickstart to list models with the same gateway key your application will use, then make a small request. Discovery reflects current eligibility; a route can become unavailable before the request arrives.
The node must be online with recent signed control-plane state.
The runtime and managed tunnel must be reachable, with the supported authentication mode and valid route configuration.
The machine was onboarded to the fleet by B3IQ and is linked to an owner account. There is no separate admin approval step beyond onboarding.
The profile status is installed, and its model, modality and capabilities
match the request. A hardware qualification fault can still stop serving.
The machine belongs to your account and is within the key's machine scope. Earn-mode machines are excluded. The key's model restrictions, incident controls, and any requested privacy requirements still apply.
Owner use and retained promotion fields
Owner-scoped inference does not require the marketplace promotion flags
network_eligible, benchmark_verified, or paid_route_eligible, or an
observed benchmark. The current owner path also skips the profile's economic
route-tier and queue-health gates. An installed Ollama model can therefore
serve its owner when the requirements above pass.
This does not bypass machine health, connectivity, installed-model matching, or the key's machine and model scope. Gateway route-tier filters affect model discovery; they are not an access boundary for owner chat requests. Use machine and model scopes to restrict a key, and verify a request as well as discovery. A runtime can still fail a live request. Use Route readiness to investigate the reported blockers; do not reinstall a working model solely to change a promotion flag.
The fields below remain in model profiles and diagnostics for other routing policies and operational history. They are not proof of paid capacity, earnings, or a public shared inference pool.
Key fields
| Field | Meaning |
|---|---|
| status | Local install and readiness state such as installed, ready_to_install, runtime_missing, or hardware_unsupported |
| runtime_kind | Runtime family such as llama-cpp, ollama, localai, openai, xinference, or vllm |
| route_tier | Serving-policy class such as local_convenience, consumer_edge, portable_local, network_beta, datacenter_optimized, or fleet_orchestrated |
| network_eligible | Retained network promotion flag; not required for owner-scoped inference |
| benchmark_verified | Host/profile benchmark claim; not required for owner-scoped inference |
| observed_benchmark | Control-plane-observed benchmark evidence; informative for owner use, required only by policies that enforce that gate |
| paid_route_eligible | Retained paid-route promotion flag; does not establish owner serving state or earnings |
| queue_health | Reported runtime queue posture; inspect runtime health and request results even where the profile gate is skipped |
Route tiers
| Route tier | Serving class |
|---|---|
| local_convenience | Ollama-class serving; can serve owner requests when live readiness and key policy permit |
| consumer_edge | Consumer and edge profiles; the tier alone does not establish availability |
| portable_local | llama.cpp and self-hosted OpenAI-compatible endpoints |
| network_beta | vLLM and Xinference profiles |
| datacenter_optimized | Datacenter-class serving profiles |
| fleet_orchestrated | Orchestrated fleet profiles |
| unknown | Unrecognized tier metadata; inspect the profile and runtime before using it |
Common blockers
Install the approved model profile and publish a fresh heartbeat after the runtime reports it is available.
Missing benchmark evidence alone does not block owner-scoped inference. Check discovery with your own gateway key and inspect the machine's current health. Benchmark and paid-route promotion state belong to separate policy checks; a static profile flag is not observed performance evidence.
Check whether the finding comes from model discovery, a promotion policy,
or an incident control. Discovery applies gateway route-tier filters.
Owner chat skips the economic promotion gate, including Ollama's
local_convenience classification; key machine/model scope and incident
controls still apply.
Clear queue state, runtime overload, or backend health issues, then publish a fresh heartbeat.
The key's model allowlist or denylist can reject a request. Discovery also applies gateway model and route-tier filters. Check the same key and model your application uses.
Public claims
Browser GPU preflight, static model fit, and installed model counts are not dispatch proof. Public UI should only claim route readiness when the live model profile and the router gates agree.

