For customersLive V1

Routing controls

Priority presets, model classes, and per-request constraints. Tell the auction what you value.

You never pick a provider on Omnious. You pick a model class and say what you value, and the auction picks whoever serves that class best on your terms right now. The controls ride in a routing block on the request body, and every one of them changes how the score is computed, not who is allowed to compete.

Priority presets

The auction scores each candidate's effective cost: its expected USDC cost for your request, marked up by its measured latency gap to the fastest candidate in the field. A priority preset sets the price and latency weights, and only their ratio matters: it is latency's exchange rate into price, the fractional cost markup per unit of latency gap.

PresetPrice weightLatency weightReads as
cheapest0.90.1a latency gap costs almost nothing; find the floor
balanced (default)0.70.3price-dominant, but speed can flip a close call
fastest0.30.7pay a real premium in ranking for measured speed

Latency here is measured by the router on real traffic, never self-reported, and the ranking premium a fast provider earns is fills, not price: the clear is capped at the cheapest live rival's expected cost, so fastestchanges who wins without letting the winner charge above the field's floor. The design doc also specs a quality weight in the score; in live V1 quality and reliability enter as a router-measured service markup on effective cost rather than a customer-set weight.

Model classes, not providers

The model field names a class, such as glm-4.7 or minimax-m3. Every provider quoting that class claims to serve exactly that model, and the verification pipeline polices the claim per provider. Within a class the auction is deliberately quality-blind: the competition is on price and measured latency. Across classes, the catalog publishes a pinned capability score per class on /v1/models, so a client comparing a flash-tier ask against a frontier ask can weigh what each can do against what it costs.

The catalog groups by issuer: the Z.ai GLM line (from glm-5.2 at the frontier down to the flash tier), the MiniMax line (minimax-m3 and the m2 family, including highspeed variants), and the OpenAI line (gpt-5.5 through the mini and nano tiers). Scores are ordinal judgment on a 0 to 1 scale: roughly 0.9 is frontier-tier, 0.7 a strong workhorse, 0.4 flash-tier. An uncataloged class sits at a neutral 0.5 and competes on price and latency until it is cataloged. The catalog also flags which classes accept image input, and the router refuses an image-bearing request on a text-only class before you pay, not after.

Per-request constraints

  • routing.max_price_usdc: a hard cap in decimal USD. The router refuses with a 400 rather than quote above it, so the cap binds before any payment exists.
  • max_tokens: bounds the worst case the 402 quotes, since the authorization assumes the reply runs to the cap.
  • routing.session_id and routing.session_budget_usdc: bind turns into a session with one budget authorization.
  • routing.lock_id: bill against a forward lock's frozen tariff instead of running the auction.
noteConstraints shape the auction; they never bypass it. Even cheapestwith a tight price cap clears second-score, so the winner is still paid by its rivals' asks, not by your cap.