AI Gateway

L'AI Gateway est un endpoint unique qu'un administrateur remet aux développeurs. Leur outil de développement existant pointe vers lui au lieu d'une API de fournisseur, et rien ne change dans leur façon de travailler. Ce qui change, c'est que chaque tour passe désormais par le même pipeline gouverné que tout autre appel de capacité Scrydon — politique de modèles, DLP, modération, audit et comptage — et qu'il est attribuable au développeur qui l'a effectué.

Il n'existe pas de second chemin d'exécution. Le routeur est un traducteur de protocole placé devant le pipeline que votre plateforme exécute déjà.

Choisissez le parcours correspondant à votre identité : une application d'IA connectée depuis le navigateur, votre compte Scrydon, un compte de service dans Claude Code ou un pipeline de CI.

Connecter vos applications IA

Utilisez les outils que votre organisation a connectés à Scrydon (e-mail, documents, tickets) depuis Claude Desktop, Codex, Cursor ou Claude Code. Rien n'est à installer au préalable. Cette connexion porte uniquement sur les outils : l'application conserve sa propre connexion et ses propres modèles. Pour faire aussi passer le trafic de modèles de l'application par la passerelle, suivez Pour les développeurs.

Ouvrez Paramètres → Compte → AI Gateway et choisissez l'onglet de votre application. Chaque onglet comporte les mêmes trois étapes.

echo 'export SCRYDON_API_KEY="scry_…"' >> ~/.zshrc
codex mcp add scrydon --url 'https://auth.your-company.com/api/mcp/v1' --bearer-token-env-var SCRYDON_API_KEY

L'onglet Outils pour développeurs contient les URL de base et les lignes de shell pour router le trafic de modèles. Ce sont les mêmes lignes que celles qu'affiche scrydon router env.

L'onglet Vos clés liste toutes les clés que vous avez créées pour une application d'IA dans cette organisation, de la plus récente à la plus ancienne, y compris celles créées par scrydon router setup : leur environnement, leur dernière utilisation par une application et leur date d'expiration. Révoquez-y une clé lorsque vous n'utilisez plus l'application, ou si quelqu'un d'autre a pu la voir. L'application est refusée dès son appel suivant.

Pour les développeurs

bunx scrydon login https://auth.your-company.com

bunx scrydon router setup

export ANTHROPIC_BASE_URL="https://auth.your-company.com/api/router"
export ENABLE_TOOL_SEARCH="true"
export OPENAI_BASE_URL="https://auth.your-company.com/api/router/v1"
export GOOGLE_GEMINI_BASE_URL="https://auth.your-company.com/api/router"
export ANTHROPIC_API_KEY="scry_…"
export OPENAI_API_KEY="scry_…"
export GEMINI_API_KEY="scry_…"

✓ Claude MCP configured (https://auth.your-company.com/api/mcp/v1)
✓ Codex MCP configured (https://auth.your-company.com/api/mcp/v1)

claude mcp add-json --scope user scrydon \
  '{"type":"http","url":"https://auth.your-company.com/api/mcp/v1","headers":{"Authorization":"Bearer ${ANTHROPIC_API_KEY}"}}'

codex mcp add scrydon --url 'https://auth.your-company.com/api/mcp/v1' --bearer-token-env-var OPENAI_API_KEY

bunx scrydon router doctor

Checking https://auth.your-company.com

  ✓ credential accepted
  ✓ 4 models available
      anthropic/claude-opus-5
      anthropic/claude-sonnet-5
      openai/gpt-5
      openai/gpt-5-mini
  ✓ completion succeeded (claude-opus-5 via anthropic)
  ✓ Claude MCP registered and connected
      https://auth.your-company.com/api/mcp/v1
  ✓ Codex MCP registered
      https://auth.your-company.com/api/mcp/v1
  ✓ 61 organization tools published by Scrydon MCP

Everything checks out. Models route, Claude Code and Codex are registered, and organization tools are published.
Personal OAuth account readiness is checked when each tool is called.

Commandes

En cas d'échec

Le routeur répond dans le dialecte d'erreur de votre propre outil, de sorte que le message vous parvient au lieu d'être englouti. Signification des erreurs courantes :

Appels d'outils refusés par Scrydon. Quand Scrydon refuse un appel d'outil MCP — aucun compte connecté, un garde-fou, un plafond de dépenses, un fournisseur indisponible — l'appel renvoie un résultat d'outil marqué comme erreur (isError: true) dont le texte est la phrase du tableau ci-dessus : votre application d'IA peut la lire et vous dire quoi faire. Le code Scrydon et le statut HTTP se trouvent dans _meta["scrydon/error"]. Seule une requête que Scrydon ne peut pas accepter du tout — un nom d'outil inconnu, des paramètres mal formés ou une clé d'accès non reconnue — est une erreur JSON-RPC.

Erreurs après le début d'un flux. Un tour en streaming qui échoue en cours de route reste un HTTP 200 : le flux se termine par un événement d'erreur dans le dialecte de votre outil, après le texte déjà livré. Cet événement porte le même code Scrydon et les mêmes détails qu'une erreur hors streaming, si bien qu'un refus de politique en cours de réponse nomme toujours son policyCode. Ils figurent sous scrydon au niveau supérieur des corps d'erreur Anthropic et Ollama, sous error.scrydon pour OpenAI Chat Completions, sur l'événement error lui-même pour OpenAI Responses, et dans error.details[] pour Gemini. Un flux que le fournisseur a arrêté sans le terminer se clôt avec le code INTERNAL_ERROR et details.reason STREAM_ENDED_WITHOUT_TERMINAL. Considérez cette réponse comme tronquée, et non comme complète. Elle est enregistrée comme un tour en échec, et non comme un tour réussi.

Ce qui n'est pas pris en charge

Le routeur refuse ces éléments au lieu de les ignorer, car un paramètre abandonné silencieusement vous donne un résultat erroné sans aucun moyen de le découvrir :

• n, logprobs, top_logprobs, seed, logit_bias, presence_penalty, frequency_penalty (et leurs graphies Gemini / Ollama)
• les champs obsolètes functions / function_call — utilisez tools / tool_choice
• l'état de conversation côté serveur : previous_response_id, item_reference, background de Responses ; cachedContent de Gemini. Envoyez l'entrée complète à chaque tour — votre outil le fait déjà.
• les outils hébergés d'un fournisseur (web_search, file_search, googleSearch, codeExecution, …). Les outils de l'organisation vous parviennent à la place via le serveur MCP Scrydon, de manière gouvernée.
• une entrée d'embedding pré-tokenisée (tableaux d'entiers) — le routeur ne dispose d'aucun tokenizer pour le modèle cible.
• une partie de texte unique dépassant 1 000 000 de caractères (environ 250k jetons) ; la requête dans son ensemble est limitée à 16 Mio.
• count_tokens d'Anthropic, /api/generate, /api/embed d'Ollama et la gestion des modèles.

L'envoi de l'un d'eux renvoie un 400 nommant le champ. Les envoyer avec la valeur null (ce que font certains SDK pour les options non définies) ne pose pas de problème. Les champs qui ne portent aucune sémantique de requête pour un modèle hébergé — store, include, safetySettings, num_ctx, keep_alive, user — sont acceptés et ignorés.

L'endpoint /chat/completions compatible OpenAI transporte le raisonnement du fournisseur dans le champ facultatif reasoning_content, y compris dans les deltas de streaming et dans l'historique de l'assistant pour les suites d'appels d'outils. Le raisonnement reste séparé du content visible ; les fournisseurs qui n'exposent pas leur raisonnement ne produisent pas ce champ. La forme Anthropic /v1/messages transporte les blocs thinking en intégralité, signatures comprises.

Utiliser Claude Code avec un compte de service

Suivez ce parcours pour envoyer un message depuis votre terminal en tant que compte de service appartenant à l'organisation. Vous avez besoin de Bun, curl, jq et Claude Code installés. Votre déploiement Scrydon et votre CLI doivent prendre en charge la connexion par jeton machine d'un compte de service. Pour les jobs de CI disposant d'un fournisseur OIDC, utilisez la fédération sans secret.

Préparer le compte de service

En tant qu'administrateur de l'organisation, ouvrez Paramètres → Membres → Comptes de service et créez un compte avec capabilities:write. Rattachez-le à un environnement disposant d'une connexion fournisseur Claude configurée et d'un modèle Claude activé. Copiez son identifiant client et le secret affiché une seule fois à la création ; effectuez une rotation du secret si vous ne l'avez plus.

Cette connexion utilise l'identifiant client ordinaire du compte, et non son identifiant client fédéré. Le secret authentifie le compte auprès de Scrydon ; Claude reçoit le jeton bearer de courte durée émis par cette connexion. Vous n'avez pas besoin de scrydon router setup pour cette identité. bunx scrydon router doctor vérifie actuellement la clé de routeur distincte enregistrée par la configuration du compte personnel ; utilisez la requête de liste des modèles avec le bearer et le message Claude ci-dessous pour vérifier ce compte de service.

Se connecter depuis votre terminal

Exécutez ces commandes dans Bash ou Zsh. Remplacez l'URL par l'origine de votre plateforme, sans barre oblique finale, et remplacez l'identifiant client. L'invite lit le secret sans l'afficher ni placer sa valeur dans l'historique du shell.

export SCRYDON_PLATFORM_URL="https://auth.your-company.com"
export SCRYDON_CLIENT_ID="YOUR_SERVICE_ACCOUNT_CLIENT_ID"

printf 'Client secret: '
IFS= read -rs SCRYDON_CLIENT_SECRET
printf '\n'

bunx scrydon login "$SCRYDON_PLATFORM_URL" \
  --service-account "$SCRYDON_CLIENT_ID" \
  --service-account-secret "$SCRYDON_CLIENT_SECRET" \
  --ttl 2h

unset SCRYDON_CLIENT_SECRET

Ne poursuivez qu'une fois la connexion réussie. Si la CLI vous redirige d'une URL d'application vers son URL de plateforme, remplacez SCRYDON_PLATFORM_URL par l'URL de plateforme qu'elle affiche avant l'étape suivante. Le fichier d'identifiants est indexé par cette URL canonique. --ttl 2h demande deux heures ; la politique de l'organisation et le plafond du déploiement peuvent raccourcir cette durée, et la CLI indique la durée de vie accordée.

Configurer Claude et choisir un modèle

Dans le même terminal, chargez le bearer enregistré par la connexion et configurez la passerelle de Claude :

TOKEN="$(jq -er --arg url "$SCRYDON_PLATFORM_URL" \
  '.[$url].token' \
  "${SCRYDON_CREDENTIALS_DIR:-$HOME/.scrydon}/credentials.json")"

unset ANTHROPIC_API_KEY CLAUDE_CODE_OAUTH_TOKEN
export ANTHROPIC_BASE_URL="$SCRYDON_PLATFORM_URL/api/router"
export ANTHROPIC_AUTH_TOKEN="$TOKEN"
export ENABLE_TOOL_SEARCH=true
unset TOKEN

curl --fail --silent --show-error \
  "$ANTHROPIC_BASE_URL/v1/models" \
  -H "Authorization: Bearer $ANTHROPIC_AUTH_TOKEN" \
  | jq -r '.data[].id'

L'URL de base se termine par /api/router : Claude ajoute /v1/messages. ANTHROPIC_AUTH_TOKEN envoie le bearer Scrydon dans l'en-tête Authorization. Ces exports configurent ce terminal et le processus Claude lancé depuis celui-ci. Consultez la configuration de la passerelle de Claude si des paramètres Claude existants remplacent la configuration de votre shell.

Copiez dans la commande ci-dessous un identifiant de modèle Claude activé figurant dans la liste, préfixe de fournisseur compris. Une liste vide signifie qu'un administrateur doit vérifier la configuration du fournisseur et des modèles pour l'environnement du compte.

Envoyer votre premier message

export SCRYDON_CLAUDE_MODEL="PASTE_AN_ENABLED_CLAUDE_MODEL_ID"

claude --model "$SCRYDON_CLAUDE_MODEL" \
  -p "Reply with one sentence confirming you received this message."

-p affiche la réponse puis quitte. Pour une conversation interactive, exécutez :

claude --model "$SCRYDON_CLAUDE_MODEL"

Dans la session interactive, /status doit afficher l'URL de base de votre passerelle et le jeton d'environnement comme source d'identifiants. Consultez Paramètres → Gouvernance → Cost Insights → Utilisation, sélectionnez AI Gateway et la ventilation Principal : la requête appartient au compte de service, affiché sous son nom, et non à votre compte personnel. Le simple fait de lister les modèles ne démontre pas une dépense de complétion.

Lorsque le bearer expire, quittez Claude, répétez la connexion et l'export du jeton, puis relancez Claude. Ne conservez pas le bearer dans le profil de votre shell et ne le validez pas dans les paramètres de Claude. La désactivation du compte de service rejette son bearer à la requête authentifiée suivante ; la rotation de son secret client ne modifie que les connexions futures. Consultez le cycle de vie des identifiants.

Pour les pipelines

Un pipeline de CI n'est pas un développeur devant un terminal — il n'y a pas de navigateur pour approuver une connexion par flux d'appareil, et l'identifiant qu'il détient doit pouvoir être révoqué et limité dans le temps selon ses propres termes, et non emprunté à la session d'une personne. Un compte de service est l'identité propre du pipeline.

Créer le compte

Paramètres → Membres → Comptes de service → Nouveau compte de service. Accordez-lui la portée capabilities:write — la même portée que déclare chaque appel au routeur — et rattachez-le à son environnement.

L'environnement est une propriété du compte, et non d'un indicateur ou du jeton : un pipeline dev et un pipeline prd sont deux comptes de service distincts, chacun rattaché à son propre environnement, et non un seul compte basculé de l'un à l'autre à l'exécution. Consultez Comptes de service pour savoir ce que fait ce rattachement et comment le modifier ultérieurement.

Stocker les identifiants

Pour les fournisseurs de CI qui émettent des jetons OIDC, utilisez la fédération sans secret. Cette recette enregistre l'émetteur, associe un sujet de pipeline exact et échange une assertion récente, avec l'identifiant client fédéré du compte, contre un bearer AI Gateway. Elle ne nécessite aucun secret client Scrydon stocké. Les instructions de connexion par secret via la CLI ci-dessous constituent l'alternative lorsque votre pipeline ne peut pas utiliser la fédération.

Enregistrez l'identifiant client et le secret comme secrets de dépôt de votre pipeline — par exemple SCRYDON_CLIENT_ID et SCRYDON_CLIENT_SECRET dans GitHub Actions.

Contrairement au bearer contre lequel il est échangé, le secret n'est pas destiné à être émis à chaque exécution — mais il expire. Votre organisation fixe une durée de vie maximale pour celui-ci (180 jours par défaut, jusqu'à un plafond strict de 365 jours) ; Comptes de service explique d'où vient ce nombre et comment fonctionne la rotation. La rotation remplace le secret immédiatement — il n'y a pas de fenêtre de chevauchement — mettez donc à jour le secret stocké du pipeline dans la même modification que celle qui effectue la rotation.

S'authentifier

La connexion et l'export doivent se trouver dans la même étape. Chaque étape - run: est un nouveau shell : exporter une variable dans une étape et la lire dans la suivante n'aboutit à rien — l'export disparaît avec le shell qui l'a créé. Une étape distincte invoquant votre outil de développement a besoin que les variables soient écrites à un endroit dont les étapes suivantes héritent réellement : sur GitHub Actions, il s'agit de $GITHUB_ENV ; les autres systèmes de CI ont leur propre équivalent (un fichier d'environnement partagé, une API de variables de pipeline — vérifiez le vôtre avant de supposer que export seul suffit).

- run: |
    scrydon login https://auth.your-company.com \
      --service-account "$SCRYDON_CLIENT_ID" \
      --service-account-secret "$SCRYDON_CLIENT_SECRET" \
      --ttl 2h

    TOKEN="$(jq -r '."https://auth.your-company.com".token' ~/.scrydon/credentials.json)"
    {
      echo "ANTHROPIC_BASE_URL=https://auth.your-company.com/api/router"
      echo "OPENAI_BASE_URL=https://auth.your-company.com/api/router/v1"
      echo "ANTHROPIC_API_KEY=$TOKEN"
      echo "OPENAI_API_KEY=$TOKEN"
    } >> "$GITHUB_ENV"

Utilisez votre URL de plateforme — la même que celle utilisée sur toute cette page, expliquée ci-dessous dans Vers quelle URL pointer ?. La connexion d'un pipeline la résout exactement comme celle d'un développeur : saisissez l'une ou l'autre URL et la CLI demande au déploiement quelle origine possède son authentification. Si vous avez saisi l'URL de l'application à la place, scrydon login affiche "<the url you typed> is the application URL; its platform URL is <the one it found>. Logging in there instead." et poursuit — c'est la CLI qui corrige une URL que vous n'aviez pas à saisir exactement, et non un échec.

--ttl est une demande, pas une garantie. La politique d'identifiants de votre organisation — et, en dessous, un plafond strict que votre opérateur fixe pour l'ensemble du déploiement — peut la raccourcir, et le serveur réduit la durée plutôt que de refuser. Demandez 2h (7200 s) sur un déploiement dont le plafond est inférieur et la commande affiche, par exemple, "Requested 7200s; this organization's policy caps it at 3600s. The token is valid for the shorter time." — la connexion a tout de même réussi. Ne demandez rien et vous obtenez la valeur par défaut de l'organisation (une heure, tant qu'un administrateur n'en a pas défini une). Un administrateur de l'organisation définit ce maximum, cette valeur par défaut et la durée de vie du secret client dans Paramètres → Gouvernance → Identifiants → Politique — le plafond du déploiement lui-même y est également affiché, en lecture seule, puisque seul votre opérateur peut le modifier.

Le jeton est enregistré dans ~/.scrydon/credentials.json, le même fichier que celui qu'utilise la connexion d'un développeur. Il n'y a pas d'étape distincte d'émission de clé de routeur pour un compte de service, comme c'est le cas avec le router setup d'une personne — le bearer renvoyé par la connexion est lui-même un identifiant de routeur valide, c'est pourquoi l'extrait ci-dessus le relit directement au lieu d'émettre quoi que ce soit de nouveau.

Reconnectez-vous au début de chaque job plutôt que de mettre en cache la clé exportée d'un job à l'autre — voir le mode de défaillance lié à l'expiration ci-dessous.

Choisir un modèle

GET /api/router/v1/models, envoyé avec le bearer ci-dessus, liste ce que votre organisation a activé — la même liste d'autorisation que celle à laquelle est soumise la clé d'un développeur :

curl -H "authorization: Bearer $ANTHROPIC_API_KEY" https://auth.your-company.com/api/router/v1/models

En cas d'échec

Le changement de rattachement d'environnement d'un compte prend effet à sa prochaine requête, y compris pour un bearer déjà émis — l'environnement est lu sur le compte à chaque requête, et non inscrit dans le jeton ; il n'y a donc rien à réémettre.

Connecter une application qui n'accepte qu'une clé d'API

Certaines applications ne savent ni se connecter ni rafraîchir un jeton. Leurs paramètres d'IA demandent une URL de base et une clé d'API, les stockent toutes deux et envoient la même clé à chaque appel : Twenty CRM, Open WebUI, n8n, LibreChat. Donnez à une telle application une clé de routeur émise pour un compte de service. Ses appels sont alors gouvernés, facturés et audités au nom de ce compte — pas au vôtre, ni à celui de la personne qui a configuré l'application.

Préparer le compte de service pour l'application

Créez un compte de service pour l'application et nommez-le d'après elle, par exemple « Twenty CRM », afin de retrouver facilement ses dépenses. Accordez-lui capabilities:write et limitez-le à un seul environnement avec les modèles que l'application doit utiliser. Une clé de routeur agit dans l'environnement de son compte et ne porte aucune autre portée. Consultez Clés de routeur pour toutes les exigences.

Émettre la clé

Sur le compte, sélectionnez Ajouter une clé de routeur, nommez-la d'après l'application et choisissez une durée de vie. Copiez la clé — elle n'est affichée qu'une seule fois — puis sélectionnez Tester la clé pour confirmer que Scrydon l'accepte.

Configurer l'application

Utilisez l'URL de base de l'API que parle l'application :

L'AI Gateway accepte la clé dans l'un ou l'autre en-tête ; vous n'avez donc pas à choisir. Le panneau qui affiche la clé liste les deux URL de base de votre déploiement. Comme pour une clé de développeur, elles diffèrent d'un segment de chemin, et c'est voulu : chaque SDK ajoute son propre chemin.

Pour Twenty CRM, ajoutez à sa configuration AI_PROVIDERS un fournisseur qui utilise le SDK compatible OpenAI (@ai-sdk/openai-compatible), avec baseUrl défini sur l'URL de base OpenAI ci-dessus et apiKey sur la clé de routeur. Conservez la clé dans le secret que votre déploiement monte déjà pour Twenty plutôt que dans une configuration en clair.

Avant de configurer l'application, vous pouvez confirmer que la clé atteint un modèle :

curl -H "authorization: Bearer $ROUTER_KEY" https://auth.your-company.com/api/router/v1/models

La liste affiche les modèles activés pour l'environnement du compte — la même liste d'autorisation à laquelle sont soumis les appels de l'application.

Maintenir la connexion

• Effectuez une rotation avant l'expiration. Le créateur du compte est prévenu six jours avant l'expiration de la clé. Effectuer une rotation de la clé maintient l'ancienne clé active pendant un jour ou une semaine ; mettez donc à jour l'application dans ce délai.
• Une modification du compte atteint la clé immédiatement. Désactiver le compte, retirer capabilities:write ou le configurer pour agir dans tous les environnements arrête la clé dès son prochain appel.
• Révoquez-la depuis le compte ou depuis le registre des identifiants lorsque l'application n'en a plus besoin.

Pour les administrateurs

Activer des modèles

Paramètres → Plateforme → Extensions → le fournisseur → Inclus. Ce que vous y sélectionnez est ce à quoi les développeurs peuvent accéder.

Trois états, et la différence compte :

Voir ce que cela coûte

Paramètres → Gouvernance → Cost Insights → Utilisation, avec la source définie sur AI Gateway.

Le trafic du routeur est comptabilisé avec sa propre source, distincte du trafic d'API applicatif, de sorte que le tableau par principal répond à la question « qui l'utilise et combien cela me coûte-t-il » — une personne ou un compte de service — sans que la charge de travail d'une application ne brouille les chiffres. Chaque ligne indique les appels, les jetons, la dépense indicative et le CO₂ modélisé.

La ventilation bascule entre Principal et Modèle, le tableau des outils liste ce qui a été atteint via l'endpoint MCP, et la ligne de budget en haut de la page affiche le plafond de l'organisation. Les mêmes données sont disponibles via billing.summary avec filters: { source: "router" }.

Définir des plafonds de dépenses

Cost Insights → Limites. Chaque plafond figure à côté de la dépense du périmètre depuis le début de la période, avec l'équipe ou le développeur le plus élevé nommé. Un plafond peut être défini sur un développeur, une équipe ou l'ensemble de l'organisation, mesuré sur un jour ou un mois glissant, en fonction soit de la dépense indicative, soit du nombre d'appels.

• Les plafonds sont évalués à partir du registre d'utilisation ; ils s'appliquent donc sur toutes les répliques.
• Appliquer refuse les appels suivants ; Auditer enregistre le dépassement et laisse passer l'appel.
• Un champ vide signifie sans plafond. 0 signifie plafonné à zéro — cette distinction est réelle.
• Lorsqu'un plafond est atteint, le développeur reçoit un 429 dont le Retry-After est le temps réel jusqu'à la réinitialisation de la période, de sorte qu'un client bien conçu temporise correctement au lieu de marteler le service.

Choisir une posture DLP

Cost Insights → Limites, sous Garde-fous du routeur.

La DLP s'exécute sur chaque prompt, et pour un message de chat c'est tout simplement ce qu'il faut. Le prompt d'un agent de développement a une autre forme : il transporte l'ensemble de travail d'un dépôt, renvoyé à chaque tour, et le code source est une entrée adverse pour des règles réglées sur de la prose — un motif d'identifiant correspond à des fixtures de test, à .env.example et à du base64 dans un fichier de verrouillage.

La posture du routeur est donc une décision que vous prenez plutôt qu'une décision dont vous héritez :

Auditer ne signifie pas « DLP désactivée ». Chaque règle s'exécute toujours dans les mêmes limites qu'en mode Appliquer : les détecteurs intégrés s'exécutent toujours, et chaque règle personnalisée s'exécute dans sa limite de champ et dans le budget de temps par champ, la compilation des règles de la politique étant limitée à 1 seconde par requête (voir les limites DLP). Une règle personnalisée que ces limites arrêtent n'est pas ignorée en silence : elle échoue de manière sûre sur ce champ — ce qui, en audit, signifie que la détection est signalée — et la ligne d'analyse la nomme. Chaque détection est toujours comptée dans le journal d'audit, et chaque type de dlp.violation que lit un auditeur est toujours produit — une ligne par règle, type de détection et canal par requête, avec le nombre d'occurrences. La seule chose qui change est de savoir si une détection refuse le tour. Ce réglage n'affecte que le routeur ; le chat, les workflows et toutes les surfaces applicatives conservent la politique de l'organisation.

Le mode Appliquer fonctionne aussi en streaming. Une réponse diffusée en flux sous une posture Appliquer est gouvernée par fenêtres : la DLP analyse environ tous les 512 caractères, retient les 256 derniers jusqu'à ce que la fenêtre suivante les confirme, et libère le reste — le texte s'écoule donc pendant que le modèle écrit encore, au lieu d'arriver d'un bloc quand il a terminé. Une détection plus loin dans la réponse l'arrête quand même : le flux se termine par une erreur policy après la livraison du préfixe sain, et le texte qui portait la détection n'est jamais envoyé. La modération en mode Appliquer juge toujours la réponse entière avant de la libérer, car son juge est un appel de modèle.

Définir des routes — des modèles virtuels qui en choisissent un réel

Une route est un identifiant de modèle que vous définissez. Un développeur la nomme (ANTHROPIC_MODEL=team/agent, ou --model team/agent) et un algorithme choisit, pour chaque tour, le modèle réel, activé et figurant dans la liste d'autorisation. Rien n'est substitué à moins que le développeur n'ait demandé la route par son nom, et le modèle choisi par une route doit toujours passer votre liste d'autorisation — une route ne peut pas atteindre un modèle que vous n'avez pas activé.

Les routes se trouvent dans la politique d'organisation platform.llm_router.routes, écrite via l'API de politique d'organisation (organization.policy.set). Trois types de routes :

{
  "version": 1,
  "routes": {
    "team/fast": { "type": "passthrough", "target": "anthropic/claude-sonnet-5" },
    "team/ab": {
      "type": "random",
      "targets": [
        { "model": "anthropic/claude-opus-5", "weight": 1 },
        { "model": "openai/gpt-5", "weight": 3 }
      ]
    },
    "team/agent": {
      "type": "stage_router",
      "capable": "anthropic/claude-opus-5",
      "efficient": "anthropic/claude-sonnet-5",
      "picker": "efficient_first",
      "confidenceThreshold": 0.5,
      "recentTurnWindow": 3
    }
  }
}

Ce qui est enregistré : l'événement d'utilisation et la ligne d'audit portent le modèle qui a réellement servi le tour et la route qui l'a choisi (route.id, route.type, la source et le tier de la décision), et la trame Anthropic message_start nomme le modèle servi ; Cost Insights montre donc la répartition réelle et un auditeur peut demander « quels tours team/agent a-t-il envoyés au niveau capable ». Les routes ne sont pas listées dans /v1/models — nommez-les directement. Une politique qui échoue à la validation désactive toutes les routes et est journalisée ; le développeur obtient alors la réponse ordinaire « modèle non activé ».

Révoquer l'accès d'un développeur

Paramètres → Gouvernance → Identifiants liste les clés de tous les membres, clés de routeur comprises, sous le nom que le développeur leur a donné. La révocation de l'une d'elles prend effet à l'appel suivant. Un développeur révoque les siennes dans Paramètres → Compte → AI Gateway → Vos clés.

Supprimer la copie locale avec scrydon router forget ne révoque pas la clé. Si une clé a pu fuiter, révoquez-la ici.

Ce que fait le routeur d'une requête

1. Authentifier. La clé de routeur porte sa propre organisation et son propre environnement — la requête n'affirme jamais de tenant, et le routeur supprime tout en-tête qui tente de le faire.
2. Admettre. Portée, échéance, classification des données, habilitation et vos plafonds de dépenses.
3. Résoudre une cible. Votre fournisseur activé, votre liste d'autorisation, la connexion liée à cet environnement et son identifiant. L'outil d'un développeur ne voit jamais un identifiant de fournisseur.
4. Appliquer les garde-fous. La DLP, puis la modération, selon la posture que vous avez choisie.
5. Répartir. Via le même runtime que tout autre appel de capacité.
6. Enregistrer. Un événement d'audit et un événement d'utilisation, attribués à la personne ou au compte de service.

Les étapes 2 à 6 ne relèvent pas du code du routeur. Elles constituent le pipeline que votre plateforme exécute déjà ; le travail propre du routeur se limite à l'étape 1 et à la traduction de part et d'autre.

Capacité et contre-pression

Chaque pod API Platform accepte un nombre limité d'appels ouverts simultanément — un budget unique partagé par les tours du routeur, les appels directs à l'API de la plateforme et les appels d'outils MCP (la valeur de chart auth.maxInFlight, 64 par défaut ; variable d'environnement PLATFORM_MAX_IN_FLIGHT ; les anciennes auth.llmRouter.maxInFlight / LLM_ROUTER_MAX_IN_FLIGHT restent valables en repli). Lorsque le pod est plus qu'à moitié plein et qu'une autre organisation l'utilise, aucune organisation ne peut en prendre plus d'un quart (platform_org_in_flight_share) : un locataire très actif ne peut pas refuser tous les autres. Une organisation seule sur le pod peut tout utiliser sauf quatre emplacements (un quart, sur un petit pod), gardés libres pour un nouvel arrivant. Les appels encore en cours d'autorisation puisent dans une réserve distincte de même taille : les nouvelles tentatives d'une organisation ne peuvent donc pas occuper ces quatre emplacements. Un nouvel arrivant entre, sauf si un locataire maintient autant d'appels en cours d'autorisation au même moment. Si le pod se remplit pendant l'autorisation d'un appel, cet appel est refusé après l'autorisation avec le même 429. Un tour en streaming est compté jusqu'à la fin de son flux ou jusqu'à votre déconnexion ; un tour hors streaming est compté jusqu'au renvoi de sa réponse. La liste des modèles (/models) en est exemptée : c'est une courte lecture du catalogue qui n'occupe jamais d'emplacement. Au-delà de cette limite, le routeur répond 429 avec un en-tête Retry-After — rate_limit_error dans le dialecte Anthropic, rate_limit_error / rate_limit_exceeded dans le dialecte OpenAI — et ne touche pas à la base de données et ne démarre aucun travail pour la requête refusée. Les SDK Anthropic et OpenAI respectent tous deux Retry-After automatiquement.

Il s'agit d'une protection contre la surcharge par pod, et non d'un quota par développeur : elle existe pour qu'un pod saturé déleste de la charge au lieu de ralentir tous les flux puis de manquer de mémoire. Des 429 persistants en régime stable signifient que le déploiement a besoin d'une autre réplique ou d'une limite CPU plus élevée, et non de nouvelles tentatives côté client. Les limites par développeur et par organisation sont les plafonds de dépenses décrits plus haut.

Les opérateurs peuvent surveiller scrydon_llm_router_streams_in_flight, scrydon_llm_router_admission_rejections_total ainsi que les histogrammes de TTFT / durée sur le tableau de bord SigNoz AI Gateway livré avec le chart d'opérations. Deux histogrammes distinguent la plateforme du fournisseur : scrydon_llm_router_overhead_ms est le temps réel d'un tour moins le temps passé dans l'appel au fournisseur (attente en file, garde-fous et règlement de l'audit inclus), et scrydon_llm_router_provider_ttfb_ms est le temps propre du fournisseur jusqu'au premier événement. scrydon_llm_router_turns_total porte une response_class (success, retryable_error, other_error) et chaque tentative auprès du fournisseur, nouvelles tentatives comprises, est comptée dans scrydon_extension_outbound_attempts_total avec les mêmes classes — la différence entre les deux taux d'erreur correspond à ce qu'apportent les nouvelles tentatives du routeur.

Couverture des protocoles

Chaque dialecte est une traduction placée devant le même pipeline ; GET /api/router/v1/health liste ceux que parle votre déploiement.

Vers quelle URL pointer ?

Votre URL de plateforme — celle qui sert /api/router, généralement auth.<your-company>. Pas l'URL de l'application à laquelle vous vous connectez tous les jours.

Cette distinction compte plus qu'elle ne le devrait, car l'origine de l'application sert de proxy pour /api/auth. Une connexion sur celle-ci réussit donc, et rien ne semble anormal jusqu'à ce que votre éditeur signale un simple 404 provenant d'un endpoint qui ne sait rien de Scrydon.

La CLI gère cela pour vous : saisissez l'une ou l'autre URL et scrydon login demande au déploiement quelle origine possède son authentification, vous indique s'il y a eu redirection et enregistre la bonne. Chaque sous-commande scrydon router accepte aussi l'une ou l'autre URL — lorsque celle que vous avez saisie n'a pas d'identifiants enregistrés, elle suit la même redirection, indique quelle URL elle a utilisée et poursuit. scrydon router setup sonde ensuite /api/router avant d'émettre une clé, de sorte qu'une incohérence échoue immédiatement en nommant la cause plutôt que silencieusement plus tard.

Si vous configurez un client à la main, utilisez l'URL de plateforme.

Voir aussi

• Facturation et comptage de l'utilisation — l'API billing.* derrière Cost Insights
• Vue d'ensemble de la DLP — ce que recherchent les garde-fous
• Utilisation de la gouvernance — la surface Cost Insights plus large

Modèles gérés par le client

Connectez un serveur d'inférence hébergé ou sur site via OpenAI Compatible, puis découvrez ses modèles ou saisissez les identifiants de déploiement dans les paramètres de la connexion. Utilisez l'identifiant de modèle publié par la passerelle ; aucune nouvelle extension first-party ni entrée de catalogue n'est requise pour chaque modèle. Les noms de modèles peuvent inclure des préfixes d'organisation/de chemin.

Le profil de compatibilité Chat de la connexion sélectionne le comportement de l'API en amont. Laissez-le vide pour les Chat Completions standard. Utilisez reasoning-content pour les serveurs compatibles qui exigent le contenu de raisonnement dans l'historique des outils, ou glm, mimo, qwen ou deepseek lorsque l'endpoint implémente ce dialecte. Faites votre choix en fonction de l'API du serveur, et non de la marque du modèle : Qwen hébergé par vLLM peut exposer un contrat différent de celui de l'endpoint hébergé par Alibaba.

Les requêtes Chat Completions, Responses et Anthropic Messages de la passerelle sont normalisées avant d'atteindre la connexion en amont sélectionnée, qui choisit ensuite l'API OpenAI en amont pour ce modèle : Chat Completions ou /responses, défini par le champ OpenAI API de la connexion (vide signifie automatique). Un client Responses n'exige pas que le serveur en amont implémente /responses, et un client Chat Completions peut atteindre un modèle qui ne fonctionne que via celle-ci. Les limites existantes de la passerelle s'appliquent toujours, y compris le rejet des outils hébergés non pris en charge et de l'état de conversation côté serveur.

L'exécuteur doit disposer d'une route réseau vers l'endpoint privé. Les paramètres de connexion n'établissent ni VPN ni tunnel. Les contrôles de sortie existants de l'organisation s'appliquent toujours. Consultez Endpoints compatibles OpenAI pour la configuration de la connexion et le détail des profils.