Residency & modellen

De responsheaders met routedisclosure, beheerde aliassen en de live modelcatalogus met toelichting op beschikbaarheid en fallback.

Responsheaders

Aanroepen van een sluis/*-alias tonen de opgeloste route via de x-sluis-*-responsheaders, en elke aanroep met een inline document onthult hoe dat document het model bereikte. Een gewone provider/model-aanroep zonder document draagt geen van beide. Residency zelf is organisatiebeleid, afgedwongen bij verzending, nooit een requestheader.

Beheerde aliassen

Beheerde aliassen zijn gereserveerde sluis/... modelnamen. sluis/auto kiest per verzoek uit de routes die je beleid toestaat: een classifier binnen de Sluis-deployment kan de reasoning-route kiezen zonder dat er tekst de deployment verlaat; anders leest een gehoste classifier na gegevensbescherming drie korte fragmenten van de prompt, en alleen op een model van een provider in Europese handen die in de EU verwerkt. De use-case aliassen kiezen uit dagelijkse Artificial Analysis benchmark-snapshots die Sluis cureert. Artificial AnalysisElke alias wordt eerst binnen het residency-beleid van de tenant opgelost, dus de soevereiniteitsregel wint van de benchmarkrang.

Roep een alias aan overal waar je een provider/model-id zou meegeven. De responseheaders tonen de gevraagde route en het concrete model dat draaide.

curl https://api.sluis.ai/v1/chat/completions \
  -H "Authorization: Bearer $SLUIS_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "model": "sluis/auto", "messages": [{ "role": "user", "content": "Plan a GDPR-safe rollout" }] }'

# response headers:
# x-sluis-route: sluis/auto
# x-sluis-model: mistral/mistral-large-latest

x-sluis-route is de beheerde of tenantalias die het verzoek oploste. x-sluis-model is het concrete provider/model-target na residency-beleid, shadowing en routing. Weigert de provider de credential voor het model van een beheerde route, dan gaat de aanroep door naar het volgende conforme model van die route; een concreet provider/model of een tenantalias wordt nooit vervangen.

Ondersteunde modellen

Sluis ontsluit ingebouwde providers via beheerde keys wanneer een platformcredential is ingesteld; verbind je eigen key (BYOK) of voeg in de Console een eigen OpenAI-compatibele provider toe om de catalogus te overschrijven of uit te breiden. Elk aanroepbaar id draagt de providerprefix: geef provider/model door (bijv. mistral/mistral-large-latest) en Sluis routeert het volgens je residency-beleid. De catalogus houdt rekening met credentials en beleid, gebruikt live providercatalogi waar beschikbaar en kan bij een storing in de upstreamcatalogus terugvallen op gedeclareerde modellen. Vertex-kandidaten worden afzonderlijk op EU-beschikbaarheid geverifieerd. Nebius Token Factory is in Europese handen, maar de publieke nebius/...-modellen hebben geen regiogarantie: ze tellen als GLOBAL en vereisen een expliciete GLOBAL-toestemming. Alleen nebius-eu, de toegewijde endpoints van de operator in een EU-regio, telt als EU.

tok/s is de uitvoerdoorvoer, gemeten aan echte verzoeken via Sluis over de laatste 7 dagen — niet aan een synthetische benchmark. Een getal zonder teken laat de wachttijd op het eerste token buiten beschouwing; een ‡ bevat die nog; een † markeert een cijfer dat de modelleverancier publiceert via Artificial Analysis en dat wij niet hebben gemeten. n/a betekent dat we nog geen verkeer voor dit model hebben en de leverancier niets publiceert.

# models callable through Sluis platform credentials — no auth
curl https://api.sluis.ai/public/models.json | jq '.models[] | "\(.provider)/\(.model)"'

# per key: the models your policy, credentials and allow-list actually reach
curl https://api.sluis.ai/v1/models -H "Authorization: Bearer $SLUIS_KEY"