Smart Router
Send model="auto" eller en routeradresse, og Stav velger en modell per forespørsel – filtrert etter policyen din og forespørselens behov, skåret på kvalitet, forventet forbruk og målt svartid, med reserve til nestbeste alternativ.
Smart Router velger en modell for hver forespørsel. Du setter policyen én gang i arbeidsområdet ditt, og koden din sender auto eller en routeradresse i stedet for et modellnavn.
resp = client.chat.completions.create(
model="auto",
messages=[{"role": "user", "content": "Summarise this contract clause."}],
)
print(resp.model) # the model that actually served
Ruting fungerer på /v1/chat/completions, /v1/messages og /v1/responses.
Tre måter å adressere en modell på
model="auto" # standardrouteren i arbeidsområdet ditt
model="@acme/eu-only" # en router arbeidsområdet ditt har opprettet
model="anthropic/claude-sonnet-4-5" # en låst modell – ingen ruting
auto kjører standardrouteren i arbeidsområdet ditt. Endre standarden under arbeidsområdet ditt → Koble til → Routere, så følger alle auto-kall etter – uten ny utrulling.
En router adresseres som @workspace-slug/router-slug. Den løses bare opp innenfor ditt eget arbeidsområde:
| Tilfelle | Resultat |
|---|---|
| En annen arbeidsområde-slug | 404 router_not_found – aldri 403, så eksistensen lekker ikke |
| Ukjent eller arkivert router | 404 router_not_found |
| Ugyldig adresse | 400 invalid_router_ref |
| API-nøkkelen er begrenset til andre routere | router_not_allowed_for_key |
| API-nøkkelen er begrenset til en router, og forespørselen angir en modell | router_required_for_key |
En router som ikke er standardrouteren din, faller aldri tilbake til noe annet. Er poolen tom, får du en feil.
En låst modell hopper over ruting. Arbeidsområdets policy og suverenitetsgulv gjelder likevel. En nøkkel som er begrenset til en router, kan ikke låse en modell – den kan bare sende auto eller én av routerne sine.
Slik tas en beslutning
1. Bygg kandidatpoolen
Start fra modellene arbeidsområdet ditt kan bruke, og fjern deretter alle modeller som:
- er under suverenitetsgulvet ditt (se Suverenitet)
- er under kvalitetsgulvet, hvis et er satt (det strengeste av arbeidsområde, nøkkel og router vinner)
- ikke har et aktivt leverandørendepunkt
- ikke kan betjene en chat-forespørsel
- ikke oppfyller routerens egne filtre: tillatte eller blokkerte modeller, tillatte modellskapere, påkrevde egenskaper, blokkerte beregningsland for leverandøren, tillatte leverandørjurisdiksjoner, eget suverenitetsgulv (det kan bare stramme inn arbeidsområdets gulv) og BYOK-modus
- mangler en egenskap forespørselen krever (se nedenfor)
- har et kontekstvindu som er for lite for forespørselens estimerte inndata, inkludert verktøydefinisjoner
2. Skår det som overlever
| Begrep | Hva det måler |
|---|---|
| Kvalitet | Et kvalitetsindeks fra 0–100 per modell |
| Kostnad | Forventet kostnad for denne forespørselen: estimerte inndata- og utdatatoken mot prisen til hvert leverandørendepunkt |
| Hastighet | Målt tid til første token og gjennomstrømning per leverandørendepunkt. Modeller uten nok målinger får en konservativ standardverdi |
Standardvektene er kvalitet 40 / kostnad 30 / svartid 30. Hver router har sine egne vekter. Et arbeidsområde som er satt til å foretrekke suverene modeller, gir en bonus til suverene modeller med åpne vekter.
2a. Hva en router betaler for
En router kan sette to priser i stedet for tre vekter: hva et godt svar er verdt og hva ett sekunds ventetid koster, i arbeidsområdets valuta (egendefinert i routerens mål). Routeren velger da modellen med best verdi: sannsynligheten for et godt svar ganget med verdien, minus forventet kostnad, minus ventetiden. Forhåndsinnstillinger (Balansert, Lavest kostnad, Kortest svartid, Høyest kvalitet) er faste par av disse to prisene. Routere som bruker vekter, fortsetter å fungere.
2b. Velg resonneringsnivå
Hvis du ikke sendte noe resonneringsnivå, velger routeren ett for modellen den plukker, blant nivåene som modellens leverandørendepunkt godtar – aldri over modellens standard med mindre routeren tillater det, og aldri et nivå der tenkningen ikke ville fått plass under max_tokens når et lavere nivå passer. Routerens Resonnering-innstilling (Auto / Aldri / Høyst et nivå) setter grensen. Se Resonnering.
3. Betjen og behold reservekandidatene
Toppmodellen betjener forespørselen. De neste tre beholdes som reservekjede.
Snarveier
- Skår-buffer. Rangeringer bufres per policy og forespørselsform. Et treff spiller av den tidligere rangeringen og dens reservekjede.
X-Stav-Route-Reasonstarter medAuto-routed (cached). - Kontinuitetslås. I en agentløkke forblir en forespørsel som returnerer verktøyresultater for kall den forrige modellen gjorde – eller som bærer signert resonnering – på den modellen hvis den fortsatt er kvalifisert. Å bytte midt i løkken ville brutt den.
X-Stav-Route-Lockangir utløseren (tool_loop,signed_thinking) eller siernone.
Egenskapsfiltrering
Et hardt filter, brukt før skåring:
| Du sender | Påkrevd egenskap |
|---|---|
en tools-array | tool_use |
| en innholdblokk med bilde | vision |
response_format av typen json_schema eller grammar | structured_output |
reasoning_effort / reasoning / thinking med annen verdi enn none | extended_thinking |
De samme flaggene finnes i stav_capabilities på GET /v1/models. Hvis ingen modell kvalifiserer, mislykkes forespørselen med navn på egenskapen.
Klassifikatoren
For rutede forespørsler kjører Stav først en liten klassifikator over starten av instruksen. Den stopper ikke ved feil: ved tidsavbrudd eller feil fortsetter rutingen uten den. Forespørsler med låst modell hopper over den.
Hovedresultatet er et kompleksitetsbånd, som blir det forventede utdataomfanget. Det tallet styrer kostnads- og hastighetsestimatene – utdatatoken dominerer vanligvis regningen, så et svar på én linje og et fullt dokument kan ha ulike billigste modeller. Uten klassifikatoren faller forventet utdata tilbake til et multiplum av inndatastørrelsen. max_tokens begrenser alltid estimatet.
Resonnering skalerer estimatet opp: low ×2, medium ×4, high ×6, mer for xhigh og max.
Domene, sensitivitet og språk registreres i forespørselsloggen. De endrer ikke skåren i dag.
Når ingen policy gjelder
Hvis auto eller din standard-router ikke gir noen kvalifisert modell, skårer Stav på nytt på tvers av alle aktive chatmodeller. Suverenitetsgulvet, kvalitetsgulvet og egenskapsfilteret gjelder fortsatt. Årsaksheaderen lyder:
Auto-routed (fallback - no workspace model policy, scored across N active chat models): <slug>
En ikke-standard router gjør aldri dette. Hvis heller ikke reserverutingen finner noe, mislykkes forespørselen med 404 no_eligible_models.
Reservebetjening
På /v1/chat/completions prøver Stav neste kandidat fra den samme rangerte listen hvis den valgte modellen feiler. Listen ble bygget fra policyen din, så reservebetjeningen forlater den aldri. Låste modeller har ingen kjede; feilene deres når deg direkte.
Reservebetjening utløses ved:
5xxfra leverandøren429fra leverandøren (leverandørklienten har allerede prøvd på nytt og gitt opp)- at Stavs konto avvises av leverandøren
- tidsavbrudd ved tilkobling, lesing, skriving og tilkoblingspool
- en åpen kretsbryter for leverandøren
Andre 4xx-feil utløser ikke reservebetjening – en annen modell ville mislykkes på samme måte.
Strømming: reservebetjening skjer bare før den første datablokken er sendt. Én situasjon håndteres for deg: en resonneringsmodell som returnerer en tom strøm, erstattes lydløst, fordi ingenting har nådd deg ennå.
Hva du kan se
Svarhoder:
X-Stav-Request-Id: chatcmpl-8f3a…
X-Stav-Model: mistralai/mistral-small-4-119b-2603
X-Stav-Provider: mistral
X-Stav-Sovereignty-Level: L3
X-Stav-Route-Reason: Picked mistralai/mistral-small-4-119b-2603 for code work with the best score, 78.4; reasoning level none chosen by the router.
X-Stav-Reasoning-Chosen-By: router
X-Stav-Route-Time-Ms: 41.3
X-Stav-Route-Lock: none
X-Stav-Router: @acme/eu-only
response.model er modellen som betjente forespørselen, ikke strengen du sendte. Logg den.
Hele beslutningen – kandidater, hvilket filter fjernet hva, skårer, klassifisering, estimerte token – finner du på forespørselen under Arbeidsområdet ditt → Overvåk → Forespørselslogg. Siden Routere viser også hva den rutede trafikken ville ha kostet på én enkelt frontmodell, til katalogpris.
Hvorfor dette valget, i forespørselsloggen
Åpne en forespørsel under Arbeidsområdet ditt → Overvåk → Forespørselslogg og utvid Hvorfor den havnet her. Der ser du hvilken type arbeid routeren leste ut av forespørselen (kode, agentløkke, uttrekk, …), behovene den matchet (verktøykall, JSON-utdata, bilder som inndata, …), modellen og endepunktet som betjente den, resonneringsnivået og hvem som valgte det, om valget var et utforsket alternativ, og de neste kandidatene med kvalitet, forventet kostnad og forventet tid de ble skåret på. De samme dataene er tilgjengelige via GET /api/inference/logs/{request_id}/routing.
Routereksempler
- Etterlevelsessone. Et suverenitetsgulv og en liste over godkjente leverandørjurisdiksjoner. Regulert kode kaller
@acme/regulated. - Kostnadsone. Høy kostnadsvekt, et kvalitetsgulv, fem kvalifiserte modeller. Batchjobber kaller
@acme/bulk. - Svartidssone. Høy svartidsvekt. Autofullføring kaller
@acme/interactive.
Poenget er at koden din sier @acme/bulk, så å bytte modeller er en endring i arbeidsområdet ditt, ikke en release.
Når du bør låse i stedet
- Når du reproduserer en evaluering.
- Når en kontrakt navngir modellen.
- Når du er avhengig av én modells eksakte utdataformat.
Neste steg
- Rutingshint — økt-identitet per forespørsel og leverandørfiltre
- Suverenitet
- Resonnering
- Svarhoder