Routing Modes

Every Qubax API key has a routing policy — a simple, explicit choice of how the marketplace should pick which seller serves each of your requests. You choose the mode when you create a key and can change it at any time from the API keys page.

ℹ️

Routing affects which seller serves your request — never your price. You always pay the same per-model Qubax price regardless of mode.

The four modes

Mode	Optimizes for	Seller pool	Trade-off
trusted	Lowest price	Trusted sellers only	None — recommended default. Best-effort model-identity attestation, cheapest-first routing.
lowest_price	Lowest price	All sellers, incl. unverified	Cheapest offers overall, but unverified sellers' model identity is not attested — a seller could proxy to a different model.
fastest	Latency	Trusted sellers only	May cost more per request than the cheapest seller — you pay the same Qubax price, but the seller chosen may not be the absolute cheapest offer.
best_reliability	Uptime	Trusted sellers only	Prefers sellers with the best failure/recovery track record. Potentially slower and never cheaper than price routing.

What "trusted" means

The upstream marketplace maintains a trusted allowlist of provider domains. Sellers on the allowlist have their provider identity verified. Sellers that are not on the list (shown as unverified in Qubax model pages) can be cheaper, but the marketplace does not attest that they serve the exact model they advertise. If that guarantee matters to you, keep your keys on trusted or fastest/best_reliability.

Setting the mode

Routing is a property of the API key, set in the dashboard (API keys → create/edit → Routing policy). New keys default to trusted.

Shell

# Change an existing key's routing mode (dashboard API)
curl https://api.qubax.ai/api-keys/key_123 \
  -X PATCH \
  -H "Authorization: Bearer *** \
  -H "Content-Type: application/json" \
  -d '{"routingMode": "fastest"}'

How it works under the hood

Qubax routes your request through the Surplus Intelligence marketplace. Two independent controls implement the policy:

Seller pool — lowest_price widens routing to unverified sellers; every other mode stays on the trusted pool.
Objective — fastest sends a lowest-latency routing objective upstream; best_reliability sends a reliability objective. Both are marketplace-native and change seller ranking, not your bill.

Failover is transparent in every mode: if the chosen seller fails, the request automatically retries the next-best seller under the same policy. You never see provider-level failures.

Which mode should I pick?

You care about…	Use
Production defaults, no surprises	trusted
Absolute lowest cost, tolerant of unverified sellers	lowest_price
Interactive apps, voice, agents where latency matters	fastest
Batch pipelines that must not fail	best_reliability

Minimum-discount floor

Marketplace discounts are not static — a seller offering 90% off today may disappear tomorrow, leaving the next-cheapest seller at 60% off. Without a floor, your request silently routes to the more expensive offer and you pay more (upstream cost goes up, though your Qubax price stays the same).

Set a minimum-discount floor on your API key (1-100%) to prevent this. When the best available discount drops below your floor, the request fails with 503 minimum_discount_not_met instead of silently routing to a pricier seller. The error message tells you the best available discount so you can decide whether to lower your floor or wait.

ℹ️

The floor is a minimum — requests still route to the cheapest seller, but only if that seller's discount is at least N%. Setting 50% means "never serve me an offer worse than 50% off." Leave it empty (or 0) to always route regardless of discount.

You can also override the floor per-request by passing "min_discount": N in the request body (chat) or as a form field (audio transcriptions). Explicit 0 disables the key-level floor for that one request.

Shell

# Per-request override (chat completions)
curl https://api.qubax.ai/v1/chat/completions   -H "Authorization: Bearer ***   -H "Content-Type: application/json"   -d '{
    "model": "glm-5.2",
    "messages": [{"role": "user", "content": "hi"}],
    "min_discount": 80
  }'

The floor works on all inference endpoints: chat, streaming, TTS, STT, and image generation.

←

Embeddings

Rate Limits

→