Residency & models

The response disclosure headers, managed aliases, and the live model catalog with availability and fallback notes.

Response headers

Calls to a sluis/* alias disclose the resolved route via x-sluis-* response headers, and any call that carried an inline document discloses how that document reached the model. A plain provider/model call with no document carries neither. Residency itself is organisation policy, enforced at dispatch, never a request header.

Managed aliases

Managed aliases are reserved sluis/... model names. sluis/auto chooses per request among the routes your policy allows: a classifier inside the Sluis deployment can pick the reasoning route without any text leaving it; otherwise a hosted classifier reads three short excerpts of the prompt after data protection, and only ever on a model from an EU-owned provider processing in the EU. The use-case aliases choose from daily Artificial Analysis benchmark snapshots curated by Sluis. Artificial AnalysisEvery alias resolves inside the tenant's residency policy first, so the sovereignty rule beats the benchmark rank.

Call an alias anywhere you would pass a provider/model id. The response headers show both the route you asked for and the concrete model that ran.

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 the managed or tenant alias that resolved the request. x-sluis-model is the concrete provider/model target after residency policy, shadowing and routing. If the provider refuses the credential for a managed route's model, the call moves on to the route's next compliant model; a concrete provider/model or a tenant alias is never swapped.

Supported models

Sluis exposes built-in providers through managed keys when a platform credential is configured; connect your own key (BYOK) or add a custom OpenAI-compatible provider in the Console to override or extend the catalog. Every callable id is provider-prefixed, so pass provider/model (e.g. mistral/mistral-large-latest) and Sluis routes it per your residency policy. The catalog is credential- and policy-aware, uses live provider catalogs where available, and can fall back to declared models during an upstream catalog failure. Vertex candidates are separately probe-verified for EU availability. Nebius Token Factory is EU-owned, but its public nebius/... models have no region guarantee: they count as GLOBAL and need an explicit GLOBAL opt-in. Only nebius-eu, the operator's dedicated endpoints in an EU region, counts as EU.

tok/s is output throughput, measured from real requests through Sluis over the last 7 days — not from a synthetic benchmark. A plain number excludes the wait for the first token; a ‡ still includes it; a † marks a figure published by the model vendor via Artificial Analysis, which we did not measure. n/a means we have no traffic for this model yet and the vendor publishes nothing.

# 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"