Price limits & routing

The router solves one problem: serve this request from the cheapest qualifying capacity that satisfies your constraints, or refuse it. Understanding the order of those constraints is most of what you need to run Spot in production.

The matching engine still walks a per-model book from lowest ask to highest and takes the first ask at or under max_price with remaining capacity. Fills use the resting (maker) price. See How matching works.

Order of evaluation

1. Hard filters. Instrument, context window, region, and any account-level data terms. Venues that fail are removed, never priced.
2. Quality gate. Only venues currently inside the family's conformance tolerance remain eligible.
3. Price ceiling. Offers above max_price are dropped. An empty book after this step returns 402 no_fill_at_limit (ledger rejection of an insufficient balance is also 402 — see Errors).
4. Latency tiebreak. Among remaining offers within 2% of best price, the lowest expected time-to-first-token wins. Price-time priority still decides the resting ask.

Choosing a ceiling

Tighter ceilings save more and fill less. Observed fill rates for gpt-class-mid over the last 30 days, against a 0.4204 list price:

Recommended pattern

Run interactive traffic at a loose ceiling and batch work at an aggressive one. Catch the refusal and downgrade the instrument rather than paying up.

try:
    r = call(model="gpt-class-mid", max_price=0.22)
except spot.NoFillAtLimit:
    r = call(model="open-weights-70b", max_price=0.09)

Retry patterns for the live gateway live in Error handling.

Set max_price at roughly 0.65× list for chat families and 0.75× for reasoning. Below that, watch your refusal rate before you ship.