Residencia y modelos

Las cabeceras de divulgación de la respuesta, los alias gestionados y el catálogo de modelos verificado en vivo.

Cabeceras de respuesta

Las llamadas a un alias sluis/* divulgan la ruta resuelta mediante las cabeceras de respuesta x-sluis-*; las llamadas provider/model normales no llevan cabeceras adicionales. La residencia en sí es política de la organización, aplicada en el despacho, nunca una cabecera de petición.

Alias gestionados

Los alias gestionados son nombres de modelo reservados sluis/.... sluis/auto elige por petición; los alias por caso de uso eligen desde snapshots diarios de benchmarks de Artificial Analysis curados por Sluis. Artificial AnalysisCada alias se resuelve primero dentro de la política de residencia del tenant, así que la regla de soberanía gana al ranking del benchmark.

Llame a un alias en cualquier lugar donde pasaría un id provider/model. Las cabeceras de respuesta muestran la ruta solicitada y el modelo concreto ejecutado.

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 es el alias gestionado o de tenant que resolvió la petición. x-sluis-model es el destino provider/model concreto después de política de residencia, shadowing y enrutamiento.

Modelos compatibles

Sluis expone proveedores integrados mediante claves gestionadas cuando hay una credencial de plataforma configurada; conecte su propia clave (BYOK) o añada un proveedor compatible con OpenAI personalizado en la Consola para anular o ampliar el catálogo. Cada id invocable lleva el prefijo del proveedor: pase provider/model (p. ej. mistral/mistral-large-latest) y Sluis lo enruta según su política de residencia. El catálogo tiene en cuenta las credenciales y la política, usa catálogos en vivo de los proveedores cuando están disponibles y puede recurrir a modelos declarados si falla un catálogo upstream. La disponibilidad en la UE de los candidatos de Vertex se verifica por separado.

# the public catalog behind the list above — sanitized, no auth, refreshed hourly
curl https://api.sluis.ai/public/catalog.json | jq '.operations[0].providers[].id'

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