Health & Routing
Minimum-discount routing: The /min{N}/ URL segment adds a minimum estimated-discount filter on marketplace seller offers, applied after health and trust filters and before the provider call. It never filters buyer-owned priority/fallback providers. See Minimum-Discount Routing.
Overriding this default: every step below can be steered per request - optimise for latency or reliability instead of price, name a provider order, refuse providers outright, and read back which offers failed. See Routing Controls.
Failure detection is passive, driven by live buyer traffic. Recovery is active: an unhealthy offer is never routed, so it cannot heal on buyer traffic, and a sweep re-probes due offers every three minutes. For a text offer that probe is a small real request (output capped at 16 tokens) and does consume a little of the seller's upstream quota; for a media offer it is a free GET check.
Routing Logic
1. Resolve model name (canonical, alias, provider-specific, or display name)
2. Check buyer's priority provider → try first if configured
3. Get all active marketplace offers for the requested model
4. If a request includes a provider hint (one provider or an allow-list array), keep only offers from the matching provider host(s)
5. Skip unhealthy offers (in backoff period)
6. Skip offers that have hit spending caps
7. Apply the minimum-discount floor (the key's `min_discount_pct`, the `X-Min-Discount` header, or a `/min{N}` URL — strictest wins)
8. Estimate per-request cost using the buyer's input tokens + max_tokens
9. Sort by estimated total cost (not just unit price — accounts for input/output ratio)
10. Try cheapest first
11. If seller uses Anthropic API format → auto-translate request/response
12. On failure → mark unhealthy, try next seller
13. If all sellers fail → try the buyer's catch-all fallback provider (a provider registered with `model: null` via `/v1/buyer/providers`)
14. Buyer never sees provider failures — failover is transparentRouting order: Priority provider → marketplace sellers (cheapest first) → catch-all fallback provider (model: null) → universal fallback.
Cross-provider translation: Requests are always accepted in OpenAI format. OpenAI-compatible sellers receive normalized OpenAI requests. Native Anthropic sellers use the OpenAI ⇄ Anthropic translator described in Models & Providers. Current active Claude liquidity is mainly OpenAI-compatible providers, not native Anthropic offers.
Provider Pinning
The normal buyer path is provider-agnostic: request a model and let the marketplace route to the cheapest healthy eligible offer. Advanced clients can optionally pin routing by passing provider (a single provider or an array of providers - an allow-list), provider_url, or provider_base_url in a chat completion request.
Pinning does not select a specific seller offer. It narrows the eligible order book to offers from the matching provider host(s), then the router still chooses the cheapest healthy offer within that filtered set. With an array, an offer is eligible if its provider matches any entry, and providers you didn't list are excluded even if cheaper. If no matching provider offer is active and healthy, the request can fail even if another (unlisted) provider has liquidity for the same model.
Each pinned entry is checked against the supported provider list. Unrecognized entries are dropped; if every entry is unrecognized the request fails with 400 unsupported_provider. A supported provider that simply has no offer for the model returns 404 no_sellers_for_model instead - the two cases are distinct.
See POST /v1/chat/completions for request examples.
Health States
active = seller intent only (create/cancel). The health system never touches it.
healthy = system-managed, self-healing via exponential backoff.
Each consecutive failure climbs the ladder before the next probe is attempted:
- 1st failure1 min
- 2nd2 min
- 3rd5 min
- 4th10 min
- 5th30 min
- 6th and on60 mincapped
Only a successful recovery probe returns an offer to service. consecutiveFailures is preserved across a
probe recovery, so a chronic flapper keeps climbing the backoff; only a real served request resets it.
Offers with dead keys (permanently revoked, closed account) will cycle through hourly retries indefinitely. This is an intentional tradeoff - one wasted attempt per hour per dead offer vs. the risk of permanently losing offers that could recover (e.g. DIEM credit resets at midnight UTC).
Failure Categories
| Category | Examples | Backoff | Self-heals? |
|---|---|---|---|
| Server error | 5xx, connection refused | 30s → 60s → 120s → 10min cap | Usually |
| Timeout | Request timeout | 30s → 60s → 120s → 10min cap | Usually |
| Auth/config | 401, 402, 403 | 10min → 20min → 40min → 1hr cap | Often (DIEM resets, key renewals) |
| Rate limited | 429 | 10-30s | Yes |
| Bad response | Malformed body | 60s → 120s → 10min cap | Maybe |
Health Log
All health events are logged with:
- Error category and HTTP status
- Truncated error message
- Action taken (backoff duration)
Sellers can view their health log via GET /v1/seller/health-log.
Seller Quality and Model Authenticity
Health routing measures operational health: provider errors, auth failures, timeouts, backoff, and recovery after successful requests. It does not prove model identity.
Today SI does not cryptographically or semantically verify that a seller advertising claude-opus-4.6 is serving that exact model rather than proxying to another model. Trusted provider domains and health stats reduce risk but are not model attestation. Trusted-only routing is the default for new accounts; allowing untrusted providers requires an explicit opt-in via Routing preferences on /buy (account-level) or per-API-key in Key Management. Buyers who need stronger guarantees should keep the default or use a BYOK priority provider until reputation/model-quality scoring ships.
For the full list of what is checked at listing time and in flight, what those checks establish, and how to report a suspected mismatch, see Provider & Model Verification.