lore-hex/quill-routerDépôt TrustedRouter.com pour un proxying sécurisé des LLM.
# TrustedRouter
[](https://github.com/Lore-Hex/quill-router/actions/workflows/ci.yml)
[](https://github.com/Lore-Hex/quill-router/actions/workflows/deploy.yml)
[](https://github.com/Lore-Hex/quill-router/actions/workflows/prod-smoke.yml)
[](https://github.com/Lore-Hex/quill-router/actions/workflows/trust-drift.yml)
[](https://status.trustedrouter.com)
[](https://trust.trustedrouter.com)
[](https://www.npmjs.com/package/@lore-hex/trusted-router)
[](https://pypi.org/project/trusted-router-py/)
[](LICENSE)
# LLMs chiffrés de bout en bout. Une seule API. Confidentialité avec preuve.
Cessez de vous demander qui peut voir vos prompts. Demandez à votre agent de codage de migrer
votre projet, choisissez le niveau de confidentialité souhaité, choisissez un modèle, ajoutez une
clé — c'est fait. La même API, plus de 30 modèles, une seule clé. La passerelle s'exécute dans des
enclaves matérielles et vous pouvez vérifier cryptographiquement qu'elle ne journalise jamais vos données.
### Migrez votre projet en un seul prompt
Collez ceci dans Codex, Claude Code ou Cursor — la migration est effectuée pour vous :
```text
Migrate this project to TrustedRouter, a privacy-first LLM router
(https://trustedrouter.com). Repoint my LLM client to base_url
"https://api.trustedrouter.com/v1" (or "https://api.trustedrouter.com" for the
Anthropic SDK), read the key from the TRUSTEDROUTER_API_KEY env var, and keep
all my existing calls working.
For a hard provider-side confidential-compute and end-to-end-encryption
requirement, add {"provider": {"min_privacy": "confidential"}}. TrustedRouter
fails closed when the selected model or provider cannot satisfy both controls.
Then tell me to sign up at trustedrouter.com, add a card, and paste my sk-tr
key into TRUSTEDROUTER_API_KEY.
```
Ensuite :
1. **Choisissez votre niveau de confidentialité ou votre région** — utilisez
`{"provider": {"min_privacy": "zdr"}}` pour un plancher strict de zéro rétention, ou
`{"provider": {"min_privacy": "confidential"}}` pour le plancher renforcé de calcul
confidentiel + E2EE. Les alias pratiques `trustedrouter/zdr` et
`trustedrouter/e2e` (`trustedrouter/confidential`) sélectionnent ces
pools. Utilisez `trustedrouter/eu` avec
`https://api-europe-west4.quillrouter.com/v1` pour un routage orienté UE.
2. **Choisissez un modèle** — parmi des centaines, ou `trustedrouter/auto` pour un basculement
automatique lorsque l'étendue des fournisseurs compte plus que le filtre de confidentialité
le plus strict.
3. **Inscrivez-vous, ajoutez une carte, obtenez votre clé** sur https://trustedrouter.com.
4. **Déployez** — vos prompts passent désormais par un chemin que vous pouvez vérifier.
<details>
<summary>Vous préférez le configurer manuellement ?</summary>
```bash
# Codex
export OPENAI_BASE_URL="https://api.trustedrouter.com/v1"
export OPENAI_API_KEY="sk-tr-v1-..."
# Claude Code
export ANTHROPIC_BASE_URL="https://api.trustedrouter.com"
export ANTHROPIC_API_KEY="sk-tr-v1-..."
```
```python
# Any OpenAI SDK
client = OpenAI(base_url="https://api.trustedrouter.com/v1", api_key="sk-tr-v1-...")
```
</details>
- **Obtenir une clé / me soutenir financièrement :** https://trustedrouter.com
- **Essayez d'abord (sans inscription) :** https://trustedrouter.com/chat
- **Les détails techniques (pour les nerds) :** https://trustedrouter.com/security
- **Générer des images :** [docs/image-generation.md](https://github.com/lore-hex/quill-router/blob/main/docs/image-generation.md)
- **Générer des vidéos :** [docs/video-generation.md](https://github.com/lore-hex/quill-router/blob/main/docs/video-generation.md)
- **Pourquoi nous l'avons construit :** https://jperla.com/blog/attestation-is-all-you-need
---
<details>
<summary><strong>Pour les nerds : comment la confidentialité est prouvable</strong></summary>
La passerelle de TrustedRouter s'exécute dans GCP Confidential Space. La plateforme signe
une mesure du conteneur en cours d'exécution. Vérifiez ces preuves signées et comparez
leur digest d'image avec la mesure de la version publiée. La revue du code source et la
provenance du build de la version établissent ce que fait cette image mesurée ; un digest
correspondant seul ne prouve pas l'absence de bugs ou de journalisation.
Inspectez les preuves GCP, sans compte :
```bash
NONCE=$(openssl rand -hex 16)
curl --fail --silent --show-error \
"https://api-us-central1.quillrouter.com/attestation?nonce=$NONCE" \
--output attestation.jwt
# GCP returns a raw Google-signed JWT, not a JSON response.
# Decoded claims include eat_nonce and submods.container.image_digest.
# GCP evidence has no pcrs field; PCRs belong to AWS Nitro evidence.
```
L'enregistrement ou le décodage d'un JWT **ne constitue pas une vérification**. Utilisez le
[vérificateur d'attestation](https://github.com/Lore-Hex/quill-cloud-proxy/blob/main/tools/verify-attestation.py)
depuis une copie révisée de `quill-cloud-proxy` pour vérifier l'émetteur/la signature,
le nonce frais, la liaison certificat TLS/exporter, et la mesure de version attendue.
Pour un point de terminaison GCP, exécutez depuis cette copie :
```bash
DIGESTS=$(curl --fail --silent --show-error \
https://trust.trustedrouter.com/trust/accepted-image-digests-gcp.txt)
test -n "$DIGESTS" && uv run --script tools/verify-attestation.py \
--api-host api-us-central1.quillrouter.com --expect-digest "$DIGESTS"
```
Le vérificateur récupère des preuves fraîches sur la connexion TLS qu'il vérifie. Cette vérification n'atteste pas une connexion `curl` ou SDK ultérieure et distincte. Ces exemples utilisent le nom d'hôte GCP US Central publié pour sélectionner le format de preuve GCP. Le point de terminaison global peut sélectionner un autre cloud ; utilisez sa politique de vérification propre au cloud et les mesures depuis [le site de confiance](https://trust.trustedrouter.com/).
| | modèle de confiance |
|---|---|
| OpenRouter, fournisseurs hébergés | « Nous ne journalisons pas. » Une politique que vous ne pouvez pas vérifier. |
| Portkey, Cloudflare AI Gateway | Tout journaliser pour l'observabilité. |
| LiteLLM | Auto-hébergé, mais le proxy en cours d'exécution n'est pas vérifié. |
| **TrustedRouter** | **Open source + attestation matérielle. Vérifiez le chemin de code ; il ne journalise rien.** |
Portée honnête : l'attestation prouve que le binaire en cours d'exécution est le binaire publié sur un matériel que vous pouvez mettre au défi avec un nonce. Elle ne défait pas un État-nation disposant d'un accès physique à l'hôte, et elle ne prouve pas que le binaire open source est exempt de bugs. L'ancre de confiance est la chaîne d'attestation adossée au matériel de Google Confidential Computing. Les fournisseurs en amont traitent les prompts selon leurs propres politiques — la posture de chaque fournisseur est publiée sur les pages des modèles.
</details>
---
## Organisation du dépôt
Ce dépôt implémente le contrat du plan de contrôle : couverture des routes, gestion des authentifications/clés, sémantique du registre de facturation, métadonnées d'utilisation, interdictions de journalisation des prompts/sorties, filtres Sentry et abstractions de fournisseurs. L'implémentation de la passerelle attestée se trouve dans `quill-cloud-proxy`.
Frontière de confiance : `api.trustedrouter.com` est le chemin de prompts attesté et doit terminer le TLS à l'intérieur de Confidential Space. `trustedrouter.com` est le plan de contrôle et ne doit jamais servir de repli d'inférence en production.
`api.quillrouter.com` reste un alias permanent fonctionnel (même passerelle attestée et même certificat), afin que les intégrations existantes continuent de fonctionner sans migration.
## Local
```bash
uv sync
uv run pytest
uv run uvicorn trusted_router.main:app --reload
```
Test de fumée de bout en bout contre une instance en cours d'exécution :
```bash
TR_SMOKE_BASE_URL=http://127.0.0.1:18080/v1 uv run python scripts/smoke_e2e.py
```
Pour la production, définissez `TR_SMOKE_BASE_URL=https://api.trustedrouter.com/v1` et
`TR_SMOKE_INTERNAL_TOKEN` si les routes de la passerelle interne sont protégées par jeton.
Définissez les clés locales de l'opérateur/du fournisseur dans :
```text
/Users/jperla/claude/.quill_cloud_keys.private
```
Ce fichier n'est jamais commité. Il est censé être au format dotenv :
```text
ANTHROPIC_API_KEY=...
OPENAI_API_KEY=...
GEMINI_API_KEY=...
CEREBRAS_API_KEY=...
DEEPSEEK_API_KEY=...
MISTRAL_API_KEY=...
STRIPE_SECRET_KEY=...
STRIPE_WEBHOOK_SECRET=...
SENTRY_DSN=...
```
Le script de déploiement accepte également des alias locaux déjà utilisés dans certains fichiers d'opérateur : `CLAUDE_API_KEY` pour Anthropic, `CHATGPT_API_KEY` pour OpenAI, et `STRIPE_KEY` pour `STRIPE_SECRET_KEY`.
Vertex diffère des autres plateformes de fournisseurs : les déploiements GCP en production utilisent le compte de service Cloud Run ou Confidential Space et des jetons d'accès Google de courte durée issus des métadonnées/ADC. Ne placez pas de clé Vertex de longue durée dans ce fichier pour la route Vertex prépayée first-party ; accordez plutôt les permissions Vertex au compte de service d'exécution.
## Licence
Business Source License 1.1. Le code source est public afin que quiconque puisse lire, compiler et vérifier le code exact qui sous-tend les garanties de confidentialité et d'attestation de TrustedRouter (https://trust.trustedrouter.com) — c'est précisément sa raison d'être. L'utilisation hors production (revue de sécurité, audit, évaluation locale) est gratuite. L'utilisation en production nécessite une licence commerciale de Lore Hex Corp : [email protected]. Chaque version passe sous la licence Apache 2.0 quatre ans après sa publication. Le code publié avant le 3 juillet 2026 reste sous Apache-2.0.
## Valeurs par défaut de sécurité
- Le contenu des prompts et des sorties n'est jamais journalisé. L'inférence synchrone et en streaming ordinaire ne le conserve pas. L'API Batch, sur opt-in, conserve temporairement des artefacts chiffrés par l'enclave pendant 30 jours maximum.
- Les journaux d'utilisation ne contiennent que des métadonnées.
- Les clés d'API sont stockées sous forme de hachages SHA-256 salés avec des identifiants de clé opaques.
- Les clés de fournisseur BYOK soumises par les utilisateurs sont stockées sous forme de lignes de texte chiffré à enveloppe, et non sous forme d'un objet Secret Manager par clé. En production, Cloud KMS enveloppe la DEK par clé ; les références externes `env://...` restent prises en charge pour les clés gérées par l'opérateur.
- Les autorisations de la passerelle incluent une `byok_cache_key` non secrète pour les enveloppes BYOK chiffrées. Les passerelles attestées l'utilisent pour un cache de clés déchiffrées en mémoire uniquement, à courte durée de vie ; la rotation BYOK change la clé et la suppression cesse de renvoyer l'enveloppe.
- Les clés BYOK brutes ne sont acceptées qu'en entrée unique ; les réponses publiques/du plan de contrôle exposent un court indice du début/la fin de la clé et des métadonnées de référence chiffrées, jamais le texte en clair.
- La configuration de production échoue en mode fermé sans jeton de passerelle interne, sans secret de webhook Stripe signé et sans backend de stockage non-mémoire.
- Les applications du plan de contrôle en production n'enregistrent pas `/chat/completions`, `/messages`, `/responses` ou `/embeddings` ; ces routes appartiennent au plan d'API attesté.
- Sentry est réservé au plan de contrôle et purge les corps de requête, les en-têtes d'authentification, les clés d'API, les clés BYOK, les messages de prompt et le texte des sorties. Un limiteur anti-flood Sentry côté client plafonne les problèmes répétés par empreinte et le total d'événements par processus/fenêtre, afin qu'une seule intégration bruyante ne puisse plus consommer tout le budget d'erreurs.
- Aucune configuration Sentry ne doit se trouver dans l'enclave attestée.
## Observabilité Broadcast
Les propriétaires d'espace de travail peuvent configurer des destinations Broadcast sur `/v1/broadcast/destinations` ou dans la console sous Broadcast. Les destinations prises en charge sont PostHog et les webhooks OTLP JSON. Broadcast est par défaut limité aux métadonnées : modèle, fournisseur, nombre de tokens, latence, coût, type de route, région et métadonnées de trace personnalisées. Le contenu des prompts/sorties n'est exporté que lorsqu'une destination active explicitement `include_content` ; ces destinations chiffrées avec contenu activé ne sont renvoyées qu'à la passerelle attestée, et non aux réponses de gestion normales. Les livraisons limitées aux métadonnées sont d'abord écrites dans une outbox Broadcast persistante puis vidées de manière asynchrone par `/internal/broadcast/drain`, afin qu'une panne de PostHog/webhook ne bloque pas l'inférence ni ne perde les métadonnées déjà réglées lors d'un redémarrage du processus.
## Niveaux de routage fixes
Ces alias utilisent un pool de modèles explicitement ordonné : le premier membre est préféré et les autres sont des solutions de repli. Ils exécutent un modèle par tentative, sans synthèse, orchestration ni plancher de confidentialité implicite. Définissez `provider.min_privacy` explicitement si nécessaire. Le catalogue actif `/v1/models` publie chaque pool dans `auto_candidates`.
- `trustedrouter/frontier` : pool fixe de modèles frontier.
- `trustedrouter/advanced` : pool fixe de modèles avancés.
- `trustedrouter/professional` : pool fixe de modèles professionnels.
- `trustedrouter/efficient` : pool fixe de modèles efficaces.
## Surveillance synthétique
TrustedRouter dispose d'un plan de surveillance synthétique distinct pour la disponibilité publique.
Les workers synthétiques s'exécutent en dehors de l'enclave, envoient de minuscules requêtes réelles dans l'API publique attestée et ne stockent que des métadonnées. Les alias de modèles de surveillance sont :
- `trustedrouter/free` : pool gratuit de style OpenRouter. Utile pour les utilisateurs, mais pas un signal de SLA.
- `trustedrouter/cheap` : pool payant le moins cher avec diversité de fournisseurs.
- `trustedrouter/eu` : pool de fournisseurs axé sur l'UE. Il privilégie les fournisseurs européens, éligibles à une région UE et soucieux de la confidentialité, en particulier lorsqu'il est associé à `https://api-europe-west4.quillrouter.com/v1`. Il s'agit d'une politique de routage, et non d'une garantie générale de résidence des données.
- `trustedrouter/monitor` : pool de disponibilité interne pour les vérifications PONG et de repli. Il est visible dans le catalogue par souci de transparence, mais l'autorisation nécessite la variable `TR_SYNTHETIC_MONITOR_API_KEY` configurée ; les clés API normales reçoivent une erreur 403.
Les workers doivent s'exécuter depuis `us-central1` et `europe-west4`, en utilisant un espace de travail et une clé dédiés `trustedrouter-synthetic-monitoring` avec des plafonds de dépenses stricts et un réapprovisionnement automatique. Les échantillons bruts sont des lignes Bigtable en ajout seul ; les pages de statut publiques lisent des agrégats compacts exposés sur `/status`, `/status.json` et `/status/history?window=5m|24h|daily`. Les générations synthétiques utilisent le libellé d'application `TrustedRouter Synthetic` et sont exclues des analyses client/application.
Chaque invocation du moniteur effectue également une complétion de chat avec `stream: true` et échoue si elle ne reçoit pas un événement de données SSE, un chunk terminal et `[DONE]`. La tâche récurrente Stage D ajoute `--expect-stage-d`, puis recherche l'autorisation typée de cette requête et exige un `stage_d_boot_kid` lié ainsi que `heartbeat_seq > 0`. Son espace de travail est volontairement séparé : provisionnez-le avec `scripts/provision_stage_d_probe_workspace.py` et ajoutez son identifiant à `TR_STAGE_D_PILOT_WORKSPACE_IDS`. La clé doit être une clé locale typée compatible avec les heartbeats ; le déploiement la lit depuis `trustedrouter-stage-d-probe-api-key` et utilise `trustedrouter/cheap` afin qu'elle soit indépendante de la clé ordinaire réservée au moniteur. Le déploiement normal laisse l'éligibilité Stage D désactivée, donc la création de la clé seule n'active pas Stage D.
La mesure des fournisseurs utilise deux classes de sondes indépendantes :
- Les sondes PONG courtes couvrent aléatoirement l'ensemble du catalogue actif et mesurent la disponibilité, le TTFB, le TTFT et la dérive de l'API en amont.
- Un flux soutenu de 512 tokens couvre les 200 routes fournisseur/modèle les plus importantes en rotation déterministe depuis `us-central1`. Il mesure les tokens de sortie par seconde après le premier token. Il s'exécute dans une tâche Cloud Run distincte, afin que les flux lents ne puissent pas retarder les sondes de disponibilité. Les échecs des sondes longues ne sont jamais comptabilisés dans les alertes de disponibilité des fournisseurs ni de dérive de l'API.
La planification actuelle de deux minutes donne à chaque route soutenue environ 25 échantillons par semaine et 108 par 30 jours. La CI calcule une estimation des dépenses à capacité maximale à partir du catalogue en direct et échoue si elle dépasse le plafond mensuel validé.
Le statut sépare deux classes de SLO de service au lieu de les mélanger avec le comportement des fournisseurs en amont :
- `router_core` : API attestée joignable, autorisation de clé fonctionnelle, candidats de route/repli disponibles, et règlement/remboursement durable.
- `control_plane` : tableau de bord, interface de facturation, clés, crédits, documentation, confiance et surfaces de statut.
Les watchdogs de déploiement et les alertes internes de burn-rate utilisent par défaut `router_core`.
Les défaillances propres aux fournisseurs sont mesurées par fournisseur sur `/status` et `/leaderboard` ; elles ne consomment pas le budget d'erreur de router-core tant que le repli reste disponible.
## Positionnement public
- Tarification : l'usage prépayé et BYOK est suivi en microdollars entiers, et non en dollars à virgule flottante, afin que les coûts infimes par token restent auditables dans le registre.
- Objectif de disponibilité : `trustedrouter/auto` est un véritable alias de modèle de chat dans l'inférence du plan de contrôle local/test et bascule vers le fournisseur configuré suivant en cas de défaillance du fournisseur amont. `trustedrouter/eu` privilégie le pool de fournisseurs axé sur l'UE, `trustedrouter/zdr` impose un plancher de fournisseurs à rétention nulle avec Anthropic en premier, et `trustedrouter/e2e` impose des routes confidentielles + E2EE avec Tinfoil en premier. Les requêtes de chat respectent également les filtres de routage de type OpenRouter `models` et `provider` (`order`, `only`, `ignore`, `allow_fallbacks`, `min_privacy`, `data_collection`, `sort`, `max_price`, `require_parameters` et `zdr`), afin que les clients puissent demander des chaînes de repli explicites ou des préférences de fournisseur. `provider.order` est une préférence tant que les replis sont activés, et les fournisseurs non listés restent éligibles après la liste préférée. Avec `allow_fallbacks=false`, le routage est restreint à l'ensemble ordonné de fournisseurs et seule sa première route disponible est autorisée. `provider.only` est toujours une liste d'autorisation stricte de fournisseurs. Définir `allow_fallbacks=false` au niveau supérieur de la requête ou via `provider.allow_fallbacks` empêche également la substitution par un autre modèle. `min_privacy="confidential"` est une exigence stricte côté fournisseur de calcul confidentiel + E2EE et échoue en mode fermé ; les alias de valeur de requête `e2e` et `e2ee` sélectionnent le même niveau au lieu de se rabattre sur une route plus faible. Les options de requête ou de fournisseur inconnues renvoient `400` avec le nom exact du champ. Les contrôles OpenRouter reconnus mais non implémentés renvoient un `501 not_supported_in_alpha` stable ; ils ne sont jamais acceptés comme des no-ops du routeur.
- Facturation : crédits prépayés et BYOK en priorité ; aucun abonnement n'est requis.
- Confiance : open source hébergé, avec le commit source de l'API en cours d'exécution, la référence d'image, le digest d'image et la politique d'attestation publiés sur `trust.trustedrouter.com`.
- Inscription : l'inscription par e-mail crée une clé de gestion à usage unique pour l'espace de travail.
- Portefeuille/crypto : le paiement en stablecoin est raccordé au moyen de paiement Crypto de Stripe Checkout lorsqu'il est demandé. Le paiement par carte/Checkout par défaut reste le chemin par défaut.
## Cible d'échelle
L'objectif est de prendre en charge une échelle de classe OpenRouter :
- 1 billion de tokens/jour, soit environ 11,6 millions de tokens/seconde en moyenne sur une journée.
- 1 à 4 millions de comptes développeurs.
- Plus de 300 modèles activement routables.
- Plus de 60 fournisseurs.
- Une surcharge de routage globale compétitive avec les routeurs déployés en périphérie.
Le déploiement de production actuel **n'atteint pas encore** cette cible. Il exécute le plan de contrôle dans quatre régions GCP derrière un LB global avec des Serverless NEG par région et quatre régions d'API attestées actives. La capacité s'étend horizontalement à mesure que davantage de pools attestés sont mis en ligne ; la correction, la confiance, la facturation et la compatibilité SDK sont en régime stable.
Le volume de requêtes dépend fortement de la taille moyenne de génération. À 1 billion de tokens/jour :
| Tokens moyens/requête | Requêtes/jour | Taux moyen de requêtes |
| ---: | ---: | ---: |
| 1 000 | 1,0 Md | 11,6k rps |
| 2 500 | 400 M | 4,6k rps |
| 10 000 | 100 M | 1,2k rps |
L'architecture peut évoluer vers cette échelle, mais uniquement si le chemin critique évite les goulots d'étranglement globaux par requête. Cela implique des flottes de passerelles régionales sans état, des pools de fournisseurs régionaux, des baux de quota partitionnés, des écritures de métadonnées en ajout seul et une agrégation asynchrone.
## Latence actuelle
Mesurée depuis cette machine de développement vers l'API attestée GCP `us-central1` centralisée le 2 mai 2026 :
| Sonde | p50 | p95 | Notes |
| --- | ---: | ---: | --- |
| Rejet de `/v1/chat/completions` non authentifié | 174 ms | 184 ms | Inclut DNS, TCP, TLS public, traitement de la requête dans l'enclave. |
| Connexion TCP | 55 ms | 59 ms | Chemin réseau vers `us-central1` depuis cette machine. |
| Poignée de main TLS terminée | 112 ms | 124 ms | Le certificat ACME public se termine à l'intérieur de l'enclave. |
| `/attestation` | 1,06 s | 1,12 s | Inclut la génération du token d'attestation GCP, donc non représentatif de la surcharge de routage normale. |
La surcharge réseau centralisée est bien plus élevée que la surcharge en périphérie rapportée par OpenRouter, mais la latence du modèle domine généralement les requêtes interactives. La première étape de mise à l'échelle en production devrait être le multi-région plutôt que la construction immédiate d'une périphérie mondiale personnalisée.
## Forme de la mise à l'échelle horizontale
Le chemin de production est conçu pour évoluer en gardant la passerelle de prompts sans état :
- Les instances `api.trustedrouter.com` peuvent être répliquées derrière un passthrough TCP. Elles autorisent, réservent et règlent via le plan de contrôle, mais les octets du prompt ne quittent jamais le chemin attesté.
- Spanner stocke l'état du plan de contrôle et de facturation à cohérence forte : utilisateurs, espaces de travail, clés, métadonnées BYOK, idempotence des événements de paiement, soldes, agrégats, réservations actives et une fenêtre d'audit des requêtes terminales de 30 jours.
- Bigtable stocke des métadonnées d'activité à volume élevé et bornées, indexées par espace de travail et par date. L'activité et les benchmarks des fournisseurs sont conservés 30 jours, les échantillons synthétiques bruts 14 jours, et les rollups d'état compacts 24 mois. Les prompts, les sorties et les arguments d'appel d'outils ne sont pas stockés.
- La vérification des clés API utilise un hash de recherche à haute entropie pour les lectures ponctuelles ; elle ne scanne pas les clés.
- Les limites de débit sont appliquées avant les gestionnaires de routes et utilisent le store configuré, de sorte que les compteurs de production sont partagés entre les instances Cloud Run.
À un trafic de l'ordre d'OpenRouter, le prochain goulot d'étranglement n'est pas le binaire de l'enclave ; c'est le chemin synchrone de facturation/autorisation. L'architecture nécessite des réservations partitionnées, des clusters Bigtable régionaux, des limites en périphérie Cloud Armor et plusieurs réplicas de passerelle avant que le trafic public ne soit autorisé à monter en charge.
## Plan multi-région
Le multi-région est réalisable tout en préservant la frontière de confiance, mais il doit être fait avec soin :
São Paulo (`southamerica-east1`) reste un plan de contrôle Cloud Run actif : `trusted-router` continue de se déployer et de servir via l'équilibreur de charge global. Seul son MIG de passerelle d'enclave a été retiré (quill-cloud-proxy #309) ; son enregistrement DNS de passerelle régionale obsolète a été supprimé. Les régions de déploiement du plan de contrôle restent `us-central1`, `us-east4`, `europe-west4` et `southamerica-east1`.
L'Oregon (`us-west1`) est le cas inverse : une région de passerelle uniquement. Elle exécute un pool de passerelles attestées à `api-us-west1.quillrouter.com` et n'a pas de plan de contrôle Cloud Run. Sa passerelle atteint le plan de contrôle via l'équilibreur de charge global, qui l'achemine vers la région de plan de contrôle la plus proche (`us-central1`). Rien dans `scripts/deploy` n'y crée de service Cloud Run, de tâche planifiée ou de NEG, et elle n'a aucune entrée dans les valeurs par défaut de région chaude ou d'instances minimales.
- Exécuter des pools de passerelles attestées à chaud indépendants dans `us-central1`, `us-east4`, `europe-west4` et `us-west1`. L'inventaire des enclaves se trouve dans `src/trusted_router/enclave_regions.py`, partagé par les sondes synthétiques, les vérifications de fumée des fournisseurs, les valeurs par défaut du watchdog et les valeurs par défaut de déploiement `TR_REGIONS`. Le même module nomme les régions de passerelle qui n'ont pas de plan de contrôle local (`ENCLAVE_REGIONS_WITHOUT_LOCAL_CONTROL_PLANE`).
- Conserver les clés privées TLS à l'intérieur de chaque charge de travail Confidential Space régionale.
- Conserver l'émission de certificats à l'intérieur de la charge de travail attestée. Les certificats sont partagés entre les réplicas via le cache chiffré. Un premier nom d'hôte régional n'est exposé à un seul nœud qu'après que chaque nœud a passé l'attestation canonique et un PONG stabilisé ; il n'est étendu qu'après que le certificat régional et les mêmes conditions ont été validés sur chaque nœud.
- Conserver les noms d'hôte régionaux tels que `api-us-central1.quillrouter.com`, `api-us-east4.quillrouter.com`, `api-europe-west4.quillrouter.com` et `api-us-west1.quillrouter.com` pour une attestation déterministe, des tests de fumée et le basculement du SDK.
- Placer `api.trustedrouter.com` derrière un DNS de latence/géo ou un passthrough TCP qui ne termine pas TLS. Le proxy orange-cloud de Cloudflare reste incompatible avec l'affirmation de confiance du chemin de prompt.
- Autoriser via des lignes de facturation partitionnées, et non via une mutation unique d'un compteur Spanner global pour chaque requête. Les nouveaux espaces de travail et clés démarrent avec 16 partitions de facturation exactes. Les baux de quota régionaux restent des travaux futurs : les pilotes de quota régional et de bail de dépenses de 2026-09 ont été supprimés.
- Écrire les métadonnées de génération dans des clusters Bigtable régionaux, puis les agréger de manière asynchrone dans des vues d'activité globales.
- Conserver le routage des fournisseurs au niveau régional, avec des disjoncteurs spécifiques à chaque fournisseur, une politique de repli et des limites de débit par fournisseur.
La règle de conception clé : une panne régionale peut échouer en mode fermé ou router vers une autre région attestée, mais elle ne doit jamais se dégrader silencieusement vers un gestionnaire de prompt non attesté.
## Objectif de quatre neuf pour le cœur du routeur
L'objectif est un SLO interne, et non un SLA contractuel. 99,99 % autorise environ 52 minutes et 36 secondes d'indisponibilité par an. Le statut public étiquette ce chiffre comme un objectif tant qu'au moins 30 à 60 jours de disponibilité mesurée du cœur du routeur à 99,99 % n'existent pas.
La disponibilité du cœur du routeur signifie :
- le TLS attesté est joignable ;
- la validation de la clé API et l'autorisation de la passerelle fonctionnent ;
- les candidats de route sont renvoyés et le repli peut choisir un fournisseur sain ;
- le règlement/remboursement est durable ou réparable en toute sécurité ;
- aucune requête de prompt ne bascule jamais vers un chemin non attesté.
Les chemins de code qui soutiennent cette feuille de route aujourd'hui sont :
- `/status.json` exporte `slo_classes.router_core`, `slo_classes.control_plane` et des alertes de taux de consommation pour des fenêtres de 5 min, 1 h, 6 h et 24 h.
- Le watchdog de déploiement lit `router_core` par défaut, de sorte que les pannes propres aux fournisseurs ne provoquent pas automatiquement le retour arrière d'un déploiement du plan de contrôle.
- Les SDK sont censés réessayer les échecs de connexion et les 502/503/504 sur les points de terminaison attestés régionaux avant de signaler l'échec.
- Les écritures d'activité Bigtable sont réparables à partir de la boîte d'envoi de règlement durable. Le règlement utilise des ID de génération déterministes, de sorte que les nouvelles tentatives écrasent les mêmes lignes d'index et ne peuvent ni facturer deux fois ni dupliquer l'activité.
Avant de décrire quatre neuf comme une disponibilité mesurée plutôt qu'un objectif, exiger trois régions GCP attestées à chaud, une pagination testée, des tests de chaos du cœur du routeur, des déploiements régionaux par étapes avec des conditions de retour arrière, et au moins 30 jours de disponibilité mesurée du cœur du routeur égale ou supérieure à 99,99 %.
## Contrat de passerelle interne
Le plan d'API attesté peut réserver et régler l'utilisation sans envoyer le contenu du prompt ou de la sortie au plan de contrôle :
- `POST /v1/internal/gateway/authorize` : valide le hachage de la clé API, réserve les crédits/limites de clé et renvoie les métadonnées de routage du fournisseur/BYOK, les candidats de route dérivés des filtres de requête `model`, `models` et `provider`, ainsi que les points de terminaison régionaux configurés.
- `POST /v1/internal/gateway/settle` : règle l'utilisation réussie et ajoute des lignes d'activité contenant uniquement des métadonnées.
---
[Read more](https://github.com/lore-hex/quill-router)