lore-hex/quill-routerRepositorio de TrustedRouter.com para proxy seguro de 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 cifrados de extremo a extremo. Una API. Privacidad con pruebas.
Deja de preocuparte por quién puede ver tus prompts. Dile a tu agente de programación que migre
tu proyecto, elige cuánta privacidad quieres, elige un modelo, introduce una
clave — listo. La misma API, más de 30 modelos, una sola clave. La pasarela se ejecuta en enclaves
de hardware y puedes verificar criptográficamente que nunca registra tus datos.
### Migra tu proyecto con un solo prompt
Pega esto en Codex, Claude Code o Cursor — hace la migración por ti:
```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.
```
Luego:
1. **Elige tu nivel de privacidad o región** — usa
`{"provider": {"min_privacy": "zdr"}}` para un límite estricto de retención cero, o
`{"provider": {"min_privacy": "confidential"}}` para el límite más estricto de
computación confidencial + E2EE. Los prácticos alias `trustedrouter/zdr` y
`trustedrouter/e2e` (`trustedrouter/confidential`) seleccionan esos
grupos. Usa `trustedrouter/eu` con
`https://api-europe-west4.quillrouter.com/v1` para un enrutamiento centrado en la UE.
2. **Elige un modelo** — cualquiera de los cientos disponibles, o `trustedrouter/auto` para un respaldo
automático cuando la amplitud de proveedores importa más que el filtro de privacidad
más estricto.
3. **Regístrate, añade una tarjeta y obtén tu clave** en https://trustedrouter.com.
4. **Despliega** — tus prompts ahora se ejecutan a través de una ruta que puedes verificar.
<details>
<summary>¿Prefieres configurarlo manualmente?</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>
- **Obtener una clave / darme tu dinero:** https://trustedrouter.com
- **Pruébalo primero (sin registro):** https://trustedrouter.com/chat
- **Los detalles técnicos (para los nerds):** https://trustedrouter.com/security
- **Generar imágenes:** [docs/image-generation.md](https://github.com/lore-hex/quill-router/blob/main/docs/image-generation.md)
- **Generar video:** [docs/video-generation.md](https://github.com/lore-hex/quill-router/blob/main/docs/video-generation.md)
- **Por qué lo construimos:** https://jperla.com/blog/attestation-is-all-you-need
---
<details>
<summary><strong>Para los nerds: cómo la privacidad es demostrable</strong></summary>
La puerta de enlace de TrustedRouter se ejecuta dentro de GCP Confidential Space. La plataforma firma
una medición del contenedor en ejecución. Verifica esa evidencia firmada y compara
su digest de imagen con la medición de la versión publicada. La revisión del código fuente y la
procedencia de la compilación de la versión establecen qué hace esa imagen medida; un digest
coincidente por sí solo no demuestra la ausencia de errores ni de registro.
Inspecciona la evidencia de GCP, sin cuenta:
```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.
```
Guardar o decodificar un JWT **no es verificación**. Utiliza el
[verificador de atestación](https://github.com/Lore-Hex/quill-cloud-proxy/blob/main/tools/verify-attestation.py)
desde una copia revisada de `quill-cloud-proxy` para verificar el emisor/firma,
el nonce fresco, el certificado TLS/vinculación del exportador y la medición de versión esperada.
Para un endpoint de GCP, ejecuta desde esa copia:
```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"
```
El verificador obtiene evidencia fresca sobre la conexión TLS que verifica. Esa comprobación no certifica una conexión `curl` o SDK posterior y separada. Estos ejemplos usan el nombre de host publicado de GCP US Central para seleccionar el formato de evidencia de GCP. El endpoint global puede seleccionar otra nube; use su política de verificación específica de la nube y las mediciones de [el sitio de confianza](https://trust.trustedrouter.com/).
| | modelo de confianza |
|---|---|
| OpenRouter, proveedores alojados | "No registramos." Una política que no puedes comprobar. |
| Portkey, Cloudflare AI Gateway | Registrarlo todo para observabilidad. |
| LiteLLM | Autoalojado, pero el proxy en ejecución no está verificado. |
| **TrustedRouter** | **Código abierto + atestación de hardware. Verifica la ruta del código; no registra nada.** |
Alcance honesto: la atestación demuestra que el binario en ejecución es el binario publicado sobre hardware que puedes desafiar con un nonce. No derrota a un estado-nación con acceso físico al host, y no demuestra que el binario de código abierto esté libre de errores. El ancla de confianza es la cadena de atestación respaldada por hardware de Google Confidential Computing. Los proveedores upstream gestionan los prompts según sus propias políticas — la postura de cada proveedor se publica en las páginas de los modelos.
</details>
---
## Estructura del repositorio
Este repositorio implementa el contrato del plano de control: cobertura de rutas, gestión de auth/keys, semántica del libro mayor de facturación, metadatos de uso, prohibiciones de registro de prompts/salidas, depuradores de Sentry y abstracciones de proveedores. La implementación del gateway atestado reside en `quill-cloud-proxy`.
Límite de confianza: `api.trustedrouter.com` es la ruta de prompts atestada y debe terminar TLS dentro de Confidential Space. `trustedrouter.com` es el plano de control y nunca debe servir un fallback de inferencia de producción.
`api.quillrouter.com` sigue siendo un alias permanente funcional (mismo gateway atestado y certificado), por lo que las integraciones existentes siguen funcionando sin migración.
## Local
```bash
uv sync
uv run pytest
uv run uvicorn trusted_router.main:app --reload
```
Prueba de humo de extremo a extremo contra una instancia en ejecución:
```bash
TR_SMOKE_BASE_URL=http://127.0.0.1:18080/v1 uv run python scripts/smoke_e2e.py
```
Para producción, establezca `TR_SMOKE_BASE_URL=https://api.trustedrouter.com/v1` y
`TR_SMOKE_INTERNAL_TOKEN` si las rutas internas del gateway están protegidas por token.
Establezca las claves locales de operador/proveedor en:
```text
/Users/jperla/claude/.quill_cloud_keys.private
```
Ese archivo nunca se confirma. Se espera que tenga el estilo 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=...
```
El script de despliegue también acepta alias locales ya usados en algunos archivos de operador: `CLAUDE_API_KEY` para Anthropic, `CHATGPT_API_KEY` para OpenAI y `STRIPE_KEY` para `STRIPE_SECRET_KEY`.
Vertex es diferente de las otras plataformas de proveedores: los despliegues de GCP en producción usan la cuenta de servicio de Cloud Run o Confidential Space y tokens de acceso de Google de corta duración desde metadata/ADC. No coloques una clave de Vertex de larga duración en este archivo para la ruta de Vertex prepago de primera parte; en su lugar, otorga permisos de Vertex a la cuenta de servicio en tiempo de ejecución.
## Licencia
Business Source License 1.1. El código fuente es público para que cualquiera pueda leer, compilar y verificar el código exacto detrás de las afirmaciones de privacidad y atestación de TrustedRouter (https://trust.trustedrouter.com) — para eso está aquí. El uso no productivo (revisión de seguridad, auditoría, evaluación local) es gratuito. El uso productivo requiere una licencia comercial de Lore Hex Corp: [email protected]. Cada versión se convierte a la Apache License 2.0 cuatro años después de su publicación. El código publicado antes del 3 de julio de 2026 permanece bajo Apache-2.0.
## Valores predeterminados de seguridad
- El contenido de prompts y salidas nunca se registra. La inferencia síncrona y en streaming ordinaria no lo retiene. La API Batch opcional retiene temporalmente artefactos cifrados por el enclave durante un máximo de 30 días.
- Los registros de uso contienen únicamente metadatos.
- Las claves de API se almacenan como hashes SHA-256 con sal e IDs de clave opacos.
- Las claves de proveedor BYOK enviadas por el usuario se almacenan como filas de texto cifrado con cifrado de sobre, no como un objeto de Secret Manager por clave. En producción, Cloud KMS envuelve la DEK por clave; las referencias externas `env://...` siguen siendo compatibles para claves gestionadas por el operador.
- Las autorizaciones de la puerta de enlace incluyen un `byok_cache_key` no secreto para sobres BYOK cifrados. Las puertas de enlace atestadas lo usan para el almacenamiento en caché de claves descifradas solo en memoria con TTL corto; la rotación de BYOK cambia la clave y la eliminación deja de devolver el sobre.
- Las claves BYOK sin procesar son solo de entrada única; las respuestas públicas/del plano de control exponen una breve pista de la primera/última clave y metadatos de referencia cifrados, nunca texto plano.
- La configuración de producción falla de forma cerrada sin un token de puerta de enlace interno, un secreto de webhook de Stripe firmado y un backend de almacenamiento no en memoria.
- Las aplicaciones del plano de control de producción no registran `/chat/completions`, `/messages`, `/responses` ni `/embeddings`; esos pertenecen al plano de API atestado.
- Sentry es exclusivo del plano de control y depura los cuerpos de las solicitudes, las cabeceras de autenticación, las claves de API, las claves BYOK, los mensajes de prompt y el texto de salida. Una puerta de inundación de Sentry del lado del cliente limita los problemas repetidos por huella y el total de eventos por proceso/ventana para que una única integración ruidosa no pueda consumir de nuevo todo el presupuesto de errores.
- Ninguna configuración de Sentry pertenece al enclave atestado.
## Observabilidad de Broadcast
Los propietarios de espacios de trabajo pueden configurar destinos de Broadcast en `/v1/broadcast/destinations` o en la consola bajo Broadcast. Los destinos compatibles son PostHog y webhooks OTLP JSON. Broadcast es solo de metadatos por defecto: modelo, proveedor, recuentos de tokens, latencia, coste, tipo de ruta, región y metadatos de traza personalizados. El contenido de prompts/salidas se exporta solo cuando un destino habilita explícitamente `include_content`; esos destinos cifrados con contenido habilitado se devuelven únicamente a la puerta de enlace atestada, no a las respuestas de gestión normales. Las entregas solo de metadatos se escriben primero en una bandeja de salida persistente de Broadcast y se drenan de forma asíncrona mediante `/internal/broadcast/drain`, de modo que una caída de PostHog/webhook no bloquea la inferencia ni pierde metadatos ya liquidados al reiniciarse el proceso.
## Niveles de enrutamiento fijos
Estos alias usan un grupo de modelos con orden explícito: el primer miembro es el preferido y el resto son alternativas. Ejecutan un modelo por intento, sin síntesis, orquestación ni umbral de privacidad implícito. Establece `provider.min_privacy` explícitamente cuando sea necesario. El catálogo activo `/v1/models` publica cada grupo en `auto_candidates`.
- `trustedrouter/frontier`: grupo fijo de modelos frontier.
- `trustedrouter/advanced`: grupo fijo de modelos advanced.
- `trustedrouter/professional`: grupo fijo de modelos professional.
- `trustedrouter/efficient`: grupo fijo de modelos efficient.
## Monitoreo sintético
TrustedRouter dispone de un plano de monitoreo sintético independiente para la disponibilidad pública.
Los workers sintéticos se ejecutan fuera del enclave, envían pequeñas peticiones reales a la
API pública atestiguada y almacenan únicamente metadatos. Los alias de modelo del monitor son:
- `trustedrouter/free`: grupo gratuito al estilo de OpenRouter. Útil para usuarios, no es una
señal de SLA.
- `trustedrouter/cheap`: grupo de pago más económico con diversidad de proveedores.
- `trustedrouter/eu`: grupo de proveedores centrado en la UE. Prefiere proveedores europeos,
con capacidad de región UE y orientados a la privacidad, especialmente cuando se combina con
`https://api-europe-west4.quillrouter.com/v1`. Se trata de una política de enrutamiento, no
de una garantía general de residencia de datos.
- `trustedrouter/monitor`: grupo interno de disponibilidad para comprobaciones PONG y de fallback.
Es visible en el catálogo por transparencia, pero la autorización requiere la
`TR_SYNTHETIC_MONITOR_API_KEY` configurada; las claves de API normales reciben 403.
Los workers deben ejecutarse desde `us-central1` y `europe-west4`, usando un workspace/clave
dedicado `trustedrouter-synthetic-monitoring` con límites de gasto estrictos y
recarga automática. Las muestras en bruto son filas de Bigtable de solo anexado; las páginas de estado públicas
leen rollups compactos expuestos en `/status`, `/status.json` y
`/status/history?window=5m|24h|daily`. Las generaciones sintéticas usan la
etiqueta de aplicación `TrustedRouter Synthetic` y se excluyen de las analíticas de
clientes/aplicaciones.
Cada invocación del monitor también realiza una finalización de chat con `stream: true` y falla
a menos que reciba un evento de datos SSE, un chunk terminal y `[DONE]`. El
trabajo recurrente Stage D añade `--expect-stage-d`, luego consulta la autorización tipada de esa petición
y requiere un `stage_d_boot_kid` vinculado más
`heartbeat_seq > 0`. Su workspace es intencionalmente separado: aprovisiónalo
con `scripts/provision_stage_d_probe_workspace.py` y añade su id a
`TR_STAGE_D_PILOT_WORKSPACE_IDS`. La clave debe ser una
clave local tipada con capacidad de heartbeat; el despliegue la lee de
`trustedrouter-stage-d-probe-api-key` y usa `trustedrouter/cheap` para que sea
independiente de la clave ordinaria de solo monitor. El despliegue normal deja la elegibilidad de Stage D
deshabilitada, por lo que crear la clave por sí sola no habilita Stage D.
La medición de proveedores utiliza dos clases de sondeo independientes:
- Las sondas PONG cortas cubren aleatoriamente el catálogo activo completo y miden disponibilidad,
TTFB, TTFT y deriva de la API upstream.
- Un flujo sostenido de 512 tokens cubre las 200 rutas proveedor/modelo más importantes
en rotación determinista desde `us-central1`. Mide los tokens de salida
por segundo tras el primer token. Se ejecuta en un Cloud Run Job separado,
de modo que los flujos lentos no pueden retrasar las sondas de disponibilidad. Los fallos de sondas largas nunca cuentan
contra la disponibilidad del proveedor ni las alertas de deriva de la API.
La programación actual de dos minutos da a cada ruta sostenida unas 25 muestras por
semana y 108 por 30 días. CI calcula una estimación de gasto a plena capacidad a partir del catálogo
en vivo y falla si supera el techo mensual revisado.
El estado separa dos clases de SLO de servicio en lugar de mezclarlas con
el comportamiento de los proveedores upstream:
- `router_core`: API atestiguada accesible, la autorización de claves funciona, los candidatos de ruta/fallback están disponibles y la liquidación/reembolso es duradera.
- `control_plane`: panel de control, interfaz de facturación, claves, créditos, documentación, confianza y
superficies de estado.
Los watchdogs de despliegue y las alertas internas de burn-rate usan `router_core` por defecto.
Los fallos exclusivos de proveedor se miden por proveedor en `/status` y
`/leaderboard`; no consumen el presupuesto de errores de router-core cuando el fallback
sigue disponible.
## Posicionamiento público
- Precios: el uso de prepago y BYOK se registra como microdólares enteros, no
como dólares en punto flotante, de modo que los costes mínimos de tokens sigan siendo auditables en el libro mayor.
- Objetivo de disponibilidad: `trustedrouter/auto` es un alias real de modelo de chat en la inferencia del plano de control local/de prueba y pasa al siguiente proveedor configurado ante fallos del proveedor upstream. `trustedrouter/eu` prefiere el grupo de proveedores centrado en la UE, `trustedrouter/zdr` fuerza un nivel mínimo de proveedores de retención cero con Anthropic en primer lugar, y `trustedrouter/e2e` fuerza rutas confidenciales + E2EE con Tinfoil en primer lugar. Las solicitudes de chat también respetan los filtros de enrutamiento `models` y `provider` al estilo OpenRouter (`order`, `only`, `ignore`, `allow_fallbacks`, `min_privacy`, `data_collection`, `sort`, `max_price`, `require_parameters` y `zdr`) para que los clientes puedan solicitar cadenas de fallback explícitas o preferencias de proveedor. `provider.order` es una preferencia mientras los fallbacks estén habilitados, y los proveedores no listados siguen siendo elegibles después de la lista preferida. Con `allow_fallbacks=false`, el enrutamiento se restringe al conjunto ordenado de proveedores y solo se autoriza su primera ruta disponible. `provider.only` es siempre una lista de permitidos de proveedores estricta. Establecer `allow_fallbacks=false` ya sea en el nivel superior de la solicitud o como `provider.allow_fallbacks` también impide sustituir por otro modelo. `min_privacy="confidential"` es un requisito estricto de computación confidencial + E2EE del lado del proveedor y falla de forma cerrada; los alias de valor de solicitud `e2e` y `e2ee` seleccionan el mismo nivel en lugar de recurrir a una ruta más débil. Las opciones de solicitud o de proveedor desconocidas devuelven `400` con el nombre exacto del campo. Los controles de OpenRouter reconocidos que no están implementados devuelven un `501 not_supported_in_alpha` estable; nunca se aceptan como no-ops del enrutador.
- Facturación: créditos de prepago y BYOK primero; no se requiere suscripción.
- Confianza: código abierto alojado, con el commit de origen de la API en ejecución, la referencia de imagen, el digest de imagen y la política de atestación publicados en `trust.trustedrouter.com`.
- Registro: el registro por correo electrónico crea una clave de gestión de un solo uso para el espacio de trabajo.
- Cartera/cripto: el pago con stablecoin se canaliza a través del método de pago Crypto de Stripe Checkout cuando se solicita. El Checkout con tarjeta/por defecto sigue siendo la ruta predeterminada.
## Objetivo de escala
El objetivo es soportar una escala de clase OpenRouter:
- 1 billón de tokens/día, o aproximadamente 11,6 millones de tokens/segundo en promedio durante un
día.
- 1-4 millones de cuentas de desarrolladores.
- Más de 300 modelos enrutables activamente.
- Más de 60 proveedores.
- Sobrecarga de enrutamiento global competitiva con enrutadores desplegados en el edge.
El despliegue de producción actual **no** cumple todavía ese objetivo. Ejecuta
el plano de control en cuatro regiones de GCP detrás de un LB global con Serverless NEGs por región y cuatro regiones de API atestadas activas. La capacidad escala
horizontalmente a medida que se ponen en línea más grupos atestados; la corrección, la confianza, la facturación
y la compatibilidad con SDK están en estado estacionario.
El volumen de solicitudes depende en gran medida del tamaño medio de generación. A 1 billón de
tokens/día:
| Tokens medios/solicitud | Solicitudes/día | Tasa media de solicitudes |
| ---: | ---: | ---: |
| 1.000 | 1,0B | 11,6k rps |
| 2.500 | 400M | 4,6k rps |
| 10.000 | 100M | 1,2k rps |
La arquitectura puede evolucionar a esta escala, pero solo si la ruta crítica evita
cuellos de botella globales por solicitud. Eso significa flotas de gateways sin estado regionales,
grupos de proveedores regionales, leases de cuota fragmentados, escrituras de metadatos de solo adición y
agregación asíncrona.
## Latencia actual
Medida desde esta máquina de desarrollo hasta la API atestada centralizada de GCP `us-central1` el 2 de mayo de 2026:
| Sonda | p50 | p95 | Notas |
| --- | ---: | ---: | --- |
| Rechazo de `/v1/chat/completions` sin autenticar | 174 ms | 184 ms | Incluye DNS, TCP, TLS público, manejo de solicitudes del enclave. |
| Conexión TCP | 55 ms | 59 ms | Ruta de red a `us-central1` desde esta máquina. |
| Handshake TLS completado | 112 ms | 124 ms | El certificado ACME público termina dentro del enclave. |
| `/attestation` | 1,06 s | 1,12 s | Incluye la generación del token de atestación de GCP, por lo que no es representativo de la sobrecarga de enrutamiento normal. |
La sobrecarga de red centralizada es mucho mayor que la sobrecarga de borde reportada por OpenRouter, pero la latencia del modelo suele dominar las solicitudes interactivas. El primer paso de escalado en producción debería ser multirregión en lugar de construir un borde global personalizado de inmediato.
## Forma de escalado horizontal
La ruta de producción está diseñada para escalar manteniendo la pasarela de prompts sin estado:
- Las instancias de `api.trustedrouter.com` pueden replicarse detrás de un passthrough TCP. Autorizan, reservan y liquidan a través del plano de control, pero los bytes del prompt nunca abandonan la ruta atestiguada.
- Spanner almacena el estado del plano de control y de facturación con consistencia fuerte: usuarios, espacios de trabajo, claves, metadatos de BYOK, idempotencia de eventos de pago, saldos, agregados, reservas activas y una ventana de auditoría de solicitudes terminales de 30 días.
- Bigtable almacena metadatos de actividad de alto volumen y acotados, indexados por espacio de trabajo y fecha. La actividad y los benchmarks de proveedores conservan 30 días, las muestras sintéticas sin procesar conservan 14 días y los resúmenes de estado compactos conservan 24 meses. No se almacenan el prompt, la salida ni los argumentos de llamadas a herramientas.
- La verificación de claves de API utiliza un hash de búsqueda de alta entropía para lecturas puntuales; no escanea claves.
- Los límites de tasa se aplican antes de los manejadores de rutas y utilizan el almacén configurado, por lo que los contadores de producción se comparten entre las instancias de Cloud Run.
Con un tráfico a escala de OpenRouter, el siguiente cuello de botella no es el binario del enclave; es la ruta síncrona de facturación/autorización. La arquitectura necesita reservas fragmentadas, clústeres regionales de Bigtable, límites de borde de Cloud Armor y múltiples réplicas de pasarela antes de que se permita aumentar el tráfico público.
## Plan multirregión
El multirregión es viable preservando el límite de confianza, pero debe hacerse con cuidado:
São Paulo (`southamerica-east1`) sigue siendo un plano de control de Cloud Run activo: `trusted-router` continúa desplegándose y sirviendo a través del balanceador de carga global. Solo se retiró su MIG de pasarela de enclave (quill-cloud-proxy #309); su registro DNS regional de pasarela obsoleto ha sido eliminado. Las regiones de despliegue del plano de control siguen siendo `us-central1`, `us-east4`, `europe-west4` y `southamerica-east1`.
Oregón (`us-west1`) es el caso opuesto: una región solo de pasarela. Ejecuta un grupo de pasarelas atestiguadas en `api-us-west1.quillrouter.com` y no tiene plano de control de Cloud Run. Su pasarela llega al plano de control a través del balanceador de carga global, que la envía a la región del plano de control más cercana (`us-central1`). Nada en `scripts/deploy` crea un servicio de Cloud Run, un trabajo del programador ni un NEG allí, y no tiene entrada en los valores predeterminados de región cálida ni de instancias mínimas.
- Ejecutar pools de gateway atestiguados en caliente independientes en `us-central1`, `us-east4`, `europe-west4` y `us-west1`. El inventario de enclaves es `src/trusted_router/enclave_regions.py`, compartido por las sondas sintéticas, las comprobaciones de humo de proveedores, los valores predeterminados del watchdog y los valores predeterminados de despliegue de `TR_REGIONS`. El mismo módulo nombra las regiones de gateway que no tienen plano de control local (`ENCLAVE_REGIONS_WITHOUT_LOCAL_CONTROL_PLANE`).
- Mantener las claves privadas TLS dentro de cada carga de trabajo regional de Confidential Space.
- Mantener la emisión de certificados dentro de la carga de trabajo atestiguada. Los certificados se comparten entre réplicas a través de la caché cifrada. Un nombre de host regional se expone a un solo nodo únicamente después de que cada nodo supere la atestación canónica y un PONG confirmado; se expande solo después de que el certificado regional y las mismas compuertas se superen en cada nodo.
- Mantener nombres de host regionales como `api-us-central1.quillrouter.com`, `api-us-east4.quillrouter.com`, `api-europe-west4.quillrouter.com` y `api-us-west1.quillrouter.com` para atestación determinista, pruebas de humo y failover del SDK.
- Colocar `api.trustedrouter.com` detrás de DNS por latencia/geo o TCP passthrough que no termine TLS. El proxy orange-cloud de Cloudflare sigue siendo incompatible con la afirmación de confianza de la ruta de prompts.
- Autorizar mediante filas de facturación fragmentadas, no mediante una única mutación de contador global de Spanner para cada solicitud. Los nuevos espacios de trabajo y claves comienzan con 16 fragmentos de facturación exactos. Los arrendamientos de cuota regional siguen siendo trabajo futuro: los pilotos de cuota regional y arrendamiento de gasto de 2026-09 fueron eliminados.
- Escribir los metadatos de generación en clústeres regionales de Bigtable y luego agregarlos en vistas de actividad global de forma asíncrona.
- Mantener el enrutamiento de proveedores a nivel regional, con interruptores de circuito específicos por proveedor, política de fallback y límites de tasa por proveedor.
La regla de diseño clave: una interrupción regional puede fallar de forma cerrada o enrutar a otra región atestiguada, pero nunca debe degradarse silenciosamente a un manejador de prompts no atestiguado.
## Objetivo de cuatro nueves de Router-Core
El objetivo es un SLO interno, no un SLA contractual. El 99,99 % permite aproximadamente 52 minutos y 36 segundos de inactividad al año. El estado público etiqueta este número como un objetivo hasta que existan al menos 30-60 días de tiempo de actividad medido del router-core del 99,99 %.
La disponibilidad del router-core significa:
- el TLS atestiguado es accesible;
- la validación de la clave de API y la autorización del gateway funcionan;
- se devuelven candidatos de ruta y el fallback puede elegir un proveedor saludable;
- la liquidación/reembolso es duradera o reparable de forma segura;
- ninguna solicitud de prompt recurre jamás a una ruta no atestiguada.
Las rutas de código que respaldan esta hoja de ruta hoy son:
- `/status.json` exporta `slo_classes.router_core`, `slo_classes.control_plane` y alertas de tasa de consumo para ventanas de 5m, 1h, 6h y 24h.
- El watchdog de despliegue lee `router_core` de forma predeterminada, por lo que las interrupciones solo de proveedores no revierten automáticamente un despliegue del plano de control.
- Se espera que los SDK reintenten fallos de conexión y 502/503/504 en puntos de conexión atestiguados regionales antes de exponer el fallo.
- Las escrituras de actividad de Bigtable son reparables desde la bandeja de salida de liquidación duradera. La liquidación utiliza IDs de generación deterministas, por lo que los reintentos sobrescriben las mismas filas de índice y no pueden duplicar cargos ni duplicar actividad.
Antes de describir cuatro nueves como disponibilidad medida en lugar de un objetivo, se requieren tres regiones atestiguadas de GCP en caliente, paginación probada, pruebas de caos del router-core, despliegues regionales por etapas con compuertas de reversión y al menos 30 días de tiempo de actividad medido del router-core igual o superior al 99,99 %.
## Contrato interno del gateway
El plano de API atestiguado puede reservar y liquidar el uso sin enviar contenido de prompt o salida al plano de control:
- `POST /v1/internal/gateway/authorize`: valida el hash de la clave de API, reserva
créditos/límites de clave y devuelve metadatos de enrutamiento de proveedor/BYOK, candidatos
de ruta derivados de los filtros de solicitud `model`, `models` y `provider`,
y endpoints regionales configurados.
- `POST /v1/internal/gateway/settle`: liquida el uso exitoso y añade
filas de actividad solo con metadatos.
- `POST /v1/internal/gateway/refund`: libera las reservas tras fallos del proveedor
o desconexiones del cliente.
Establezca `TR_INTERNAL_GATEWAY_TOKEN` fuera del desarrollo local.
## Almacenamiento en producción
Producción utiliza:
```text
TR_STORAGE_BACKEND=spanner-clickhouse
TR_SPANNER_INSTANCE_ID=trusted-router-nam6
TR_SPANNER_DATABASE_ID=trusted-router
TR_OPERATIONAL_ANALYTICS_CLICKHOUSE_URL=http://<clickhouse-ilb>:8123
TR_OPERATIONAL_ANALYTICS_CLICKHOUSE_PASSWORD=<control-read secret>
```
`scripts/deploy-gcp.sh` habilita las APIs, crea la tabla de Spanner
`tr_entities`, despliega Cloud Run y
conecta los metadatos de confianza actuales de GCP en la página de confianza.
## Facturación
`POST /v1/billing/checkout` crea una sesión de Stripe Checkout cuando
`TR_STRIPE_SECRET_KEY` está configurado y, de lo contrario, devuelve una respuesta
simulada local determinista. Los webhooks de Stripe acreditan los espacios de trabajo de forma idempotente usando el
ID del espacio de trabajo en los metadatos de Checkout. Los pagos con tarjeta se liquidan de inmediato. Los pagos
ACH usan `{"payment_method":"ach"}` y se acreditan solo después de que Stripe envíe
`checkout.session.async_payment_succeeded`; la finalización de Checkout mientras el débito
está en proceso nunca otorga créditos. `POST /v1/billing/portal` sigue el mismo
patrón de Stripe o simulado para la gestión de facturación.
Para el checkout con stablecoin, envíe `{"payment_method":"stablecoin"}`. Cuando
`TR_STABLECOIN_CHECKOUT_ENABLED=true`, la sesión de Checkout se crea con
---
[Read more](https://github.com/lore-hex/quill-router)