Residency-Header pro Request, die Provenienz-Header der Antwort und der live verifizierte Modellkatalog.
Residency-Header
Sluis liest diese Header auf der Anfrage und liefert das x-sluis-*-Set auf der Antwort zurück.
Header
Beschreibung
X-Sluis-Residency
Überschreibt die Policy des Keys für diesen Aufruf. Nur strenger, z. B. eu-only, eu-uk.
X-Sluis-Class
Erzwingt eine Datenklasse, statt den Klassifizierer entscheiden zu lassen: phi, pii, secrets.
x-sluis-region
Antwort · die Region, in der die Anfrage tatsächlich lief.
x-sluis-decision
Antwort · in-region, fallback oder blocked.
x-sluis-seal
Antwort · der Hash dieses Eintrags in der Audit-Kette.
x-sluis-route
Antwort · der verwaltete oder Tenant-Alias, der die Anfrage aufgelöst hat, z. B. sluis/auto.
x-sluis-model
Antwort · das konkrete provider/model-Ziel nach Policy und Routing.
Verwaltete Aliasse
Verwaltete Aliasse sind reservierte sluis/... Modellnamen. sluis/auto wählt pro Anfrage; die Use-Case-Aliasse wählen aus täglichen Artificial Analysis Benchmark-Snapshots, die Sluis kuratiert. Artificial AnalysisJeder Alias wird zuerst innerhalb der Residency-Policy des Tenants aufgelöst, deshalb schlägt die Souveränitätsregel den Benchmark-Rang.
Alias
Use Case
sluis/auto
Routing pro Anfrage. Sluis wählt das beste konforme Ziel für den Prompt.
sluis/code
Coding und Code Review.
sluis/chat
Allgemeine Konversation.
sluis/support
Antworten für Kundensupport.
sluis/fast
Niedrige Latenz.
sluis/cheap
Bester Wert für Batch-Arbeit.
sluis/agents
Tool-Nutzung und agentische Workflows.
sluis/extract
Strukturierte Extraktion.
sluis/docs
Dokumentextraktion und Parsing.
sluis/longcontext
Long-Context-Analyse.
sluis/vision
Bildeingabe.
sluis/translate
Mehrsprachige Übersetzung.
sluis/sovereign
Nur Open Weights.
Rufen Sie einen Alias überall dort auf, wo Sie sonst eine provider/model-ID übergeben. Die Response-Header zeigen die angefragte Route und das konkrete Modell, das lief.
x-sluis-route ist der verwaltete oder Tenant-Alias, der die Anfrage aufgelöst hat. x-sluis-model ist das konkrete provider/model-Ziel nach Residency-Policy, Shadowing und Routing.
Tenant-Aliasse überdecken verwaltete Namen. Wenn Ihre Organisation sluis/code erstellt, gewinnt diese Route für Ihren Tenant. Key-Allow-Lists dürfen reservierte Aliasse wie sluis/auto enthalten; die Allow-List wird geprüft, bevor der Alias aufgelöst wird.
Unterstützte Modelle
Sluis stellt integrierte Anbieter über verwaltete Keys bereit, wenn ein Plattform-Credential konfiguriert ist; verbinden Sie Ihren eigenen Key (BYOK) oder fügen Sie in der Console einen eigenen OpenAI-kompatiblen Anbieter hinzu, um den Katalog zu überschreiben oder zu erweitern. Jede aufrufbare Modell-ID trägt das Provider-Präfix: übergeben Sie provider/model (z. B. mistral/mistral-large-latest), und Sluis routet sie gemäß Ihrer Residency-Policy. Der Katalog berücksichtigt Credentials und Policy, nutzt verfügbare Live-Kataloge der Anbieter und kann bei einem Ausfall des Upstream-Katalogs auf deklarierte Modelle zurückfallen. Vertex-Kandidaten werden separat auf EU-Verfügbarkeit geprüft.
Live-Katalog. Diese Liste wird aus dem Modellkatalog der Plattform generiert und stündlich aktualisiert; sie entspricht also immer dem, was Sluis gerade anbietet. Dieselben Daten sind öffentlich unter api.sluis.ai/public/catalog.json; pro Key liefert GET /v1/models, was Ihre Policy und Credentials tatsächlich erreichen können.
# 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"