Per-request residency headers, the response provenance set, and the live-verified model catalog.
Residency headers
Sluis reads these on the request and returns the x-sluis-* set on the response.
Header
Description
X-Sluis-Residency
Override the key's policy for this call. Stricter only, e.g. eu-only, eu-uk.
X-Sluis-Class
Force a data class instead of letting the classifier decide: phi, pii, secrets.
x-sluis-region
Response · the region the request actually ran in.
x-sluis-decision
Response · in-region, fallback, or blocked.
x-sluis-seal
Response · this entry's hash in the audit chain.
x-sluis-route
Response · the managed or tenant alias that resolved the request, e.g. sluis/auto.
x-sluis-model
Response · the concrete provider/model target selected after policy and routing.
Managed aliases
Managed aliases are reserved sluis/... model names. sluis/auto chooses per request; 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.
Alias
Use case
sluis/auto
Per-request routing. Sluis picks the best compliant target for the prompt.
sluis/code
Coding and code review.
sluis/chat
General conversation.
sluis/support
Customer-support answers.
sluis/fast
Low latency.
sluis/cheap
Best value for bulk work.
sluis/agents
Tool use and agentic workflows.
sluis/extract
Structured extraction.
sluis/docs
Document extraction and parsing.
sluis/longcontext
Long-context analysis.
sluis/vision
Image input.
sluis/translate
Multilingual translation.
sluis/sovereign
Open-weights only.
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.
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.
Tenant aliases shadow managed names. If your organisation creates sluis/code, that route wins for your tenant. Key allow-lists may include reserved aliases such as sluis/auto; the allow-list is checked before the alias resolves.
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.
Live catalog. This list is generated from the platform's model catalog and refreshed every hour, so it always matches what Sluis offers right now. The same data is public at api.sluis.ai/public/catalog.json; per key, GET /v1/models returns what your policy and credentials can actually reach.
# the public catalog behind the list above — sanitized, no auth, refreshed hourlycurl https://api.sluis.ai/public/catalog.json | jq '.operations[0].providers[].id'# per key: the models your policy, credentials and allow-list actually reachcurl https://api.sluis.ai/v1/models -H "Authorization: Bearer $SLUIS_KEY"