Health & compatibility
Clients don't take your node on faith. They continuously probe every registered node to learn whether it's reachable, what it currently serves, and whether it speaks a compatible protocol version. A node that probes cleanly is routable; one that doesn't is flagged and skipped. This page covers what's checked and how to stay in rotation.
What clients probe
Probing reads your node's public details document — an unauthenticated, unencrypted endpoint that returns your live catalog and capabilities (see Serving models & pricing). From it, and from your on-chain record, a client determines:
- Reachability — does the endpoint respond?
- Protocol version — is your wire-protocol version compatible with the client's?
- Your catalog — which models, at which prices, with which capabilities.
When both reachability and a compatible protocol version hold, the client marks your node OK and ready to route. A separate check — a valid, signed encryption recipient (your current sealing key, unexpired and signed by your on-chain key; see Encryption & keys) — is verified at probe time and again just before sealing. It doesn't change the OK/reachable state, but a missing, expired, or unsigned recipient makes the client fail over to another node at send time, so in practice you still need a valid one advertised to actually receive traffic (see Probe states below).
Probe states
A client classifies each node into one of a few states:
| State | Meaning | Routable? |
|---|---|---|
| Probing | The client hasn't finished its first probe yet. | Not yet |
| OK | Reachable and on a compatible protocol version. | Yes (subject to the send-time recipient check below) |
| Incompatible | Reachable, but the protocol version doesn't match. | No — flagged in the picker, never chosen by Auto |
| Failing | The probe errored, or (in privacy mode) no relay could reach it. | No |
The decision flow, including the separate send-time recipient check:
An incompatible node is the most common avoidable problem: it's up and serving, but on a protocol version the client can't speak, so it's dropped from selection. Keep your node software current.
The encryption recipient is checked slightly later than reachability and version: a node can show as reachable and still be skipped at send time if its advertised recipient is missing, expired, or unsigned — the client verifies it just before sealing and fails over to another node rather than downgrade. The practical rule is the same either way: keep a valid, signed, unexpired recipient advertised or you won't be routed to.
How often you're probed
Clients re-discover registered nodes on a short background cadence, designed to pick up your changes quickly without hammering your endpoint:
- Config changes and outage recoveries propagate to active clients on the order of tens of seconds to a couple of minutes — a price change, a newly-served model, or a fixed outage shows up the next time clients refresh.
- A node found unreachable is re-checked less aggressively until it recovers, so a node that's genuinely down isn't spammed.
The practical implication: after you change config or recover from an outage, expect active users to notice within roughly that window — you don't need to do anything to announce it. (The exact intervals are client/proxy-side and may change; don't tune your operations to a specific number here.)
Performance is measured, not claimed
Beyond up/down, the network measures two performance signals per node and keeps them on-chain as rolling averages:
| Signal | What it measures |
|---|---|
| Time to first token | How quickly you start responding (a latency and hardware-readiness signal). |
| Decode throughput | Tokens per second once you're streaming. |
These feed target selection — including users' Auto mode — so genuinely faster nodes get picked to serve more often. (Relay selection, the separate privacy hop, is weighted by network round-trip time only, not by these two signals.) You can't game them by advertising; they come from real served requests.
Staging nodes
You can register a node as staging. A staging node is held out of normal routing: ordinary clients won't dispatch to it, even though it's registered and reachable. This lets you:
- Bring up a new machine or a new model and exercise it end-to-end before it takes production traffic.
- Test a software upgrade against real protocol behavior without risking paying users.
Users can opt in to staging nodes with an Allow staging toggle, so you can point a cooperating tester at your staging node deliberately. Clear the staging flag when the node is ready, and it joins normal rotation on the next probe.
Keeping your node routable — checklist
- Stay reachable at your advertised endpoint over HTTPS.
- Keep your protocol version current so you never land in Incompatible.
- Keep a valid, signed, unexpired encryption recipient advertised — rotate before it lapses.
- Serve what your details document advertises — if you stop serving a model, drop it from the catalog so clients don't route to a model you no longer have.
- Let performance speak — fast first tokens and steady throughput earn more traffic than any self-reported number.