lore-hex/quill-routerTrustedRouter.com Repo für sicheres LLM-Proxying
# 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)
# Ende-zu-Ende-verschlüsselte LLMs. Eine API. Privatsphäre mit Beweis.
Schluss damit, sich Sorgen zu machen, wer deine Prompts sehen kann. Sag deinem Coding-Agenten, er soll dein Projekt umstellen, wähle, wie privat du sein möchtest, wähle ein Modell, füge einen Schlüssel ein — fertig. Dieselbe API, 30+ Modelle, ein Schlüssel. Das Gateway läuft in Hardware-Enclaves und du kannst kryptografisch verifizieren, dass es dich niemals protokolliert.
### Stelle dein Projekt mit einem einzigen Prompt um
Füge dies in Codex, Claude Code oder Cursor ein — die Migration wird für dich erledigt:
```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.
```
Dann:
1. **Wähle deine Datenschutzstufe oder Region** — verwende
`{"provider": {"min_privacy": "zdr"}}` für eine harte Null-Aufbewahrungs-Untergrenze oder
`{"provider": {"min_privacy": "confidential"}}` für die strengere harte
Confidential-Compute- + E2EE-Untergrenze. Die praktischen `trustedrouter/zdr`- und
`trustedrouter/e2e`- (`trustedrouter/confidential`)-Aliase wählen diese
Pools aus. Verwende `trustedrouter/eu` mit
`https://api-europe-west4.quillrouter.com/v1` für EU-fokussiertes Routing.
2. **Wähle ein Modell** — eines von Hunderten oder `trustedrouter/auto` für automatischen
Fallback, wenn die Anbieterbreite wichtiger ist als der strengste Datenschutz-
Filter.
3. **Registriere dich, füge eine Karte hinzu, erhalte deinen Schlüssel** unter https://trustedrouter.com.
4. **Loslegen** — deine Prompts laufen jetzt über einen Pfad, den du verifizieren kannst.
<details>
<summary>Lieber manuell einrichten?</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>
- **Einen Schlüssel erhalten / mich unterstützen:** https://trustedrouter.com
- **Erst ausprobieren (ohne Anmeldung):** https://trustedrouter.com/chat
- **Die technischen Details (für die Nerds):** https://trustedrouter.com/security
- **Bilder generieren:** [docs/image-generation.md](https://github.com/lore-hex/quill-router/blob/main/docs/image-generation.md)
- **Videos generieren:** [docs/video-generation.md](https://github.com/lore-hex/quill-router/blob/main/docs/video-generation.md)
- **Warum wir es gebaut haben:** https://jperla.com/blog/attestation-is-all-you-need
---
<details>
<summary><strong>Für die Nerds: wie die Privatsphäre nachweisbar ist</strong></summary>
Das Gateway von TrustedRouter läuft in einer GCP Confidential Space. Die Plattform signiert
eine Messung des laufenden Containers. Verifiziere diese signierten Nachweise und vergleiche
ihren Image-Digest mit der veröffentlichten Release-Messung. Die Quellcode-Prüfung und die
Provenienz des Release-Builds belegen, was dieses gemessene Image tut; ein übereinstimmender
Digest allein beweist nicht die Abwesenheit von Fehlern oder Protokollierung.
Prüfe die GCP-Nachweise, ohne Konto:
```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.
```
Das Speichern oder Dekodieren eines JWT ist **keine Verifikation**. Verwenden Sie den
[Attestation-Verifier](https://github.com/Lore-Hex/quill-cloud-proxy/blob/main/tools/verify-attestation.py)
aus einem geprüften Checkout von `quill-cloud-proxy`, um Aussteller/Signatur,
frische Nonce, TLS-Zertifikat/Exporter-Bindung und die erwartete Release-Messung zu verifizieren.
Für einen GCP-Endpunkt führen Sie aus diesem Checkout aus:
```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"
```
Der Verifier ruft frische Nachweise über die TLS-Verbindung ab, die er verifiziert. Diese Prüfung bescheinigt keine spätere, separate `curl`- oder SDK-Verbindung. Diese Beispiele verwenden den veröffentlichten US-Central-GCP-Hostnamen, um das GCP-Nachweisformat auszuwählen. Der globale Endpoint kann eine andere Cloud auswählen; verwenden Sie dessen cloud-spezifische Verifikationsrichtlinie und Messungen von [der Trust-Seite](https://trust.trustedrouter.com/).
| | Vertrauensmodell |
|---|---|
| OpenRouter, gehostete Anbieter | „Wir loggen nicht." Eine Richtlinie, die Sie nicht überprüfen können. |
| Portkey, Cloudflare AI Gateway | Alles für Observability loggen. |
| LiteLLM | Selbst gehostet, aber der laufende Proxy ist unverifiziert. |
| **TrustedRouter** | **Open Source + Hardware-Attestierung. Verifizieren Sie den Codepfad; er loggt nichts.** |
Ehrlicher Geltungsbereich: Attestierung beweist, dass die laufende Binärdatei die veröffentlichte Binärdatei auf Hardware ist, die Sie mit einer Nonce herausfordern können. Sie schützt nicht vor einem Nationalstaat mit physischem Host-Zugriff und beweist nicht, dass die Open-Source-Binärdatei fehlerfrei ist. Der Vertrauensanker ist die hardwaregestützte Attestierungskette von Google Confidential Computing. Upstream-Anbieter verarbeiten Prompts gemäß ihren eigenen Richtlinien — die Haltung jedes Anbieters ist auf den Modellseiten veröffentlicht.
</details>
---
## Repository-Layout
Dieses Repo implementiert den Control-Plane-Vertrag: Routenabdeckung, Auth-/Key-Verwaltung, Billing-Ledger-Semantik, Nutzungsmetadaten, Verbote für Prompt-/Output-Logging, Sentry-Scrubber und Provider-Abstraktionen. Die attestierte Gateway-Implementierung befindet sich in `quill-cloud-proxy`.
Vertrauensgrenze: `api.trustedrouter.com` ist der attestierte Prompt-Pfad und muss TLS innerhalb von Confidential Space terminieren. `trustedrouter.com` ist die Control Plane und darf niemals einen Produktions-Inferenz-Fallback bereitstellen.
`api.quillrouter.com` bleibt ein dauerhaft funktionierender Alias (dasselbe attestierte Gateway und Zertifikat), sodass bestehende Integrationen ohne Migration weiter funktionieren.
## Lokal
```bash
uv sync
uv run pytest
uv run uvicorn trusted_router.main:app --reload
```
End-to-End-Smoke-Test gegen eine laufende Instanz:
```bash
TR_SMOKE_BASE_URL=http://127.0.0.1:18080/v1 uv run python scripts/smoke_e2e.py
```
Für die Produktion setzen Sie `TR_SMOKE_BASE_URL=https://api.trustedrouter.com/v1` und
`TR_SMOKE_INTERNAL_TOKEN`, falls die internen Gateway-Routen token-geschützt sind.
Lokale Operator-/Provider-Schlüssel setzen Sie in:
```text
/Users/jperla/claude/.quill_cloud_keys.private
```
Diese Datei wird niemals committet. Es wird erwartet, dass sie im dotenv-Stil vorliegt:
```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=...
```
Das Deploy-Skript akzeptiert außerdem lokale Aliase, die bereits in einigen Operator-Dateien verwendet werden: `CLAUDE_API_KEY` für Anthropic, `CHATGPT_API_KEY` für OpenAI und `STRIPE_KEY` für `STRIPE_SECRET_KEY`.
Vertex unterscheidet sich von den anderen Provider-Plattformen: Produktions-GCP-Deployments verwenden das Cloud Run- oder Confidential Space-Servicekonto und kurzlebige Google-Zugriffstoken aus Metadaten/ADC. Legen Sie für die First-Party-Prepaid-Vertex-Route keinen langlebigen Vertex-Schlüssel in dieser Datei ab; erteilen Sie stattdessen dem Laufzeit-Servicekonto Vertex-Berechtigungen.
## Lizenz
Business Source License 1.1. Der Quellcode ist öffentlich, damit jeder den exakten Code hinter den Datenschutz- und Attestierungsversprechen von TrustedRouter lesen, bauen und verifizieren kann (https://trust.trustedrouter.com) — dafür ist er hier. Nicht-produktive Nutzung (Sicherheitsüberprüfung, Audit, lokale Evaluierung) ist kostenlos. Produktive Nutzung erfordert eine kommerzielle Lizenz von Lore Hex Corp: [email protected]. Jede Version wird vier Jahre nach Veröffentlichung in die Apache License 2.0 überführt. Code, der vor dem 3. Juli 2026 veröffentlicht wurde, bleibt unter Apache-2.0.
## Sicherheitsstandards
- Prompt- und Ausgabeinhalte werden niemals protokolliert. Gewöhnliche synchrone und Streaming-Inferenz speichert sie nicht. Die optionale Batch-API speichert Enclave-verschlüsselte Artefakte vorübergehend für bis zu 30 Tage.
- Nutzungsprotokolle enthalten nur Metadaten.
- API-Schlüssel werden als gesalzene SHA-256-Hashes mit undurchsichtigen Schlüssel-IDs gespeichert.
- Von Benutzern übermittelte BYOK-Provider-Schlüssel werden als envelope-verschlüsselte Chiffretext-Zeilen gespeichert, nicht als ein Secret-Manager-Objekt pro Schlüssel. In der Produktion umhüllt Cloud KMS den DEK pro Schlüssel; externe `env://...`-Referenzen bleiben für operatorverwaltete Schlüssel unterstützt.
- Gateway-Autorisierungen enthalten einen nicht-geheimen `byok_cache_key` für verschlüsselte BYOK-Envelopes. Attestierte Gateways nutzen ihn für kurzlebige, nur im Speicher befindliche Entschlüsselungs-Caches von Schlüsseln; BYOK-Rotation ändert den Schlüssel und Löschen beendet die Rückgabe des Envelopes.
- BYOK-Rohschlüssel sind nur einmalige Eingabe; öffentliche/Control-Plane-Antworten geben einen kurzen Hinweis auf den ersten/letzten Schlüssel und verschlüsselte Referenzmetadaten preis, niemals Klartext.
- Die Produktionskonfiguration schlägt geschlossen fehl ohne internes Gateway-Token, signiertes Stripe-Webhook-Secret und ein Nicht-Speicher-Backend.
- Produktions-Control-Plane-Apps registrieren nicht `/chat/completions`, `/messages`, `/responses` oder `/embeddings`; diese gehören auf die attestierte API-Ebene.
- Sentry ist ausschließlich auf der Control Plane aktiv und bereinigt Request-Bodies, Auth-Header, API-Schlüssel, BYOK-Schlüssel, Prompt-Nachrichten und Ausgabetext. Ein clientseitiges Sentry-Flood-Gate begrenzt wiederholte Vorfälle pro Fingerprint und Gesamtereignisse pro Prozess/Fenster, damit eine einzelne laute Integration nicht erneut das gesamte Fehlerbudget aufbrauchen kann.
- Keine Sentry-Konfiguration gehört in die attestierte Enclave.
## Broadcast-Observability
Workspace-Eigentümer können Broadcast-Ziele unter `/v1/broadcast/destinations` oder in der Konsole unter Broadcast konfigurieren. Unterstützte Ziele sind PostHog und OTLP-JSON-Webhooks. Broadcast ist standardmäßig nur auf Metadaten beschränkt: Modell, Provider, Token-Anzahlen, Latenz, Kosten, Routentyp, Region und benutzerdefinierte Trace-Metadaten. Prompt-/Ausgabeinhalte werden nur exportiert, wenn ein Ziel explizit `include_content` aktiviert; diese inhaltsaktivierten verschlüsselten Ziele werden nur an das attestierte Gateway zurückgegeben, nicht an normale Verwaltungsantworten. Metadaten-only-Zustellungen werden zuerst in eine persistente Broadcast-Outbox geschrieben und asynchron durch `/internal/broadcast/drain` abgearbeitet, sodass ein PostHog-/Webhook-Ausfall die Inferenz nicht blockiert und bereits abgerechnete Metadaten bei einem Prozessneustart nicht verloren gehen.
## Feste Routing-Stufen
Diese Aliase verwenden einen explizit geordneten Modell-Pool: Das erste Mitglied wird bevorzugt, die übrigen sind Fallbacks. Sie führen ein Modell pro Versuch aus, ohne Synthese, Orchestrierung oder implizite Datenschutz-Untergrenze. Setzen Sie `provider.min_privacy` bei Bedarf explizit. Der Live-Katalog unter `/v1/models` veröffentlicht jeden Pool in `auto_candidates`.
- `trustedrouter/frontier`: fester Frontier-Modellpool.
- `trustedrouter/advanced`: fester Advanced-Modellpool.
- `trustedrouter/professional`: fester Professional-Modellpool.
- `trustedrouter/efficient`: fester Efficient-Modellpool.
## Synthetisches Monitoring
TrustedRouter verfügt über eine separate synthetische Monitoring-Ebene für öffentliche Verfügbarkeit.
Synthetische Worker laufen außerhalb der Enklave, senden winzige echte Anfragen an die
öffentliche attestierte API und speichern nur Metadaten. Die Monitor-Modell-Aliase sind:
- `trustedrouter/free`: kostenloser Pool im OpenRouter-Stil. Nützlich für Benutzer, kein
SLA-Signal.
- `trustedrouter/cheap`: günstigster kostenpflichtiger Pool mit Anbieter-Vielfalt.
- `trustedrouter/eu`: EU-fokussierter Anbieter-Pool. Er bevorzugt europäische,
EU-regionierbare und datenschutzorientierte Anbieter, insbesondere in Kombination mit
`https://api-europe-west4.quillrouter.com/v1`. Dies ist eine Routing-Richtlinie, keine
pauschale Garantie für Datenresidenz.
- `trustedrouter/monitor`: interner Verfügbarkeits-Pool für PONG- und Fallback-Prüfungen.
Er ist aus Transparenzgründen im Katalog sichtbar, aber die Autorisierung erfordert
den konfigurierten `TR_SYNTHETIC_MONITOR_API_KEY`; normale API-Schlüssel erhalten 403.
Worker sollten von `us-central1` und `europe-west4` aus laufen und einen dedizierten
`trustedrouter-synthetic-monitoring`-Workspace/Schlüssel mit harten Ausgabenobergrenzen und
automatischer Wiederauffüllung verwenden. Rohproben sind append-only Bigtable-Zeilen; öffentliche Statusseiten
lesen kompakte Rollups, die unter `/status`, `/status.json` und
`/status/history?window=5m|24h|daily` bereitgestellt werden. Synthetische Generierungen verwenden das
App-Label `TrustedRouter Synthetic` und sind von Kunden-/App-
Analysen ausgeschlossen.
Jeder Monitor-Aufruf führt außerdem eine `stream: true`-Chat-Completion aus und schlägt fehl,
wenn er kein SSE-Datenereignis, keinen terminalen Chunk und kein `[DONE]` erhält. Der
wiederkehrende Stage-D-Job fügt `--expect-stage-d` hinzu, schlägt dann die typisierte Autorisierung dieser Anfrage nach und verlangt eine gebundene `stage_d_boot_kid` plus
`heartbeat_seq > 0`. Sein Workspace ist bewusst separat: Provisioniere ihn
mit `scripts/provision_stage_d_probe_workspace.py` und füge seine ID zu
`TR_STAGE_D_PILOT_WORKSPACE_IDS` hinzu. Der Schlüssel muss ein
heartbeat-fähiger lokal typisierter Schlüssel sein; das Deployment liest ihn aus
`trustedrouter-stage-d-probe-api-key` und verwendet `trustedrouter/cheap`, sodass er
unabhängig vom gewöhnlichen Monitor-only-Schlüssel ist. Der normale Rollout lässt die Stage-D-
Berechtigung deaktiviert, sodass das alleinige Erstellen des Schlüssels Stage D nicht aktiviert.
Die Anbieter-Messung verwendet zwei unabhängige Probe-Klassen:
- Kurze PONG-Proben decken zufällig den gesamten aktiven Katalog ab und messen Verfügbarkeit,
TTFB, TTFT und Upstream-API-Drift.
- Ein anhaltender 512-Token-Stream deckt die 200 wichtigsten Anbieter-/Modell-
Routen in deterministischer Rotation von `us-central1` ab. Er misst Ausgabe-
Token pro Sekunde nach dem ersten Token. Er läuft in einem separaten Cloud Run Job,
sodass langsame Streams Verfügbarkeitsproben nicht verzögern können. Fehler bei Langproben zählen niemals
gegen die Anbieter-Verfügbarkeit oder API-Drift-Warnungen.
Der aktuelle Zwei-Minuten-Zeitplan ergibt für jede anhaltende Route etwa 25 Proben pro
Woche und 108 pro 30 Tage. CI berechnet eine Vollauslastungs-Kostenschätzung aus dem Live-
Katalog und schlägt fehl, wenn sie die geprüfte monatliche Obergrenze überschreitet.
Der Status trennt zwei SLO-Klassen für Dienste, anstatt sie mit dem Verhalten der Upstream-Anbieter zu vermischen:
- `router_core`: attestierte API erreichbar, Schlüsselautorisierung funktioniert, Routen-
Kandidaten/Fallback sind verfügbar und Settle/Refund ist dauerhaft.
- `control_plane`: Dashboard, Abrechnungs-UI, Schlüssel, Guthaben, Dokumentation, Vertrauen und
Status-Oberflächen.
Deploy-Watchdogs und interne Burn-Rate-Warnungen verwenden standardmäßig `router_core`.
Reine Anbieter-Fehler werden pro Anbieter auf `/status` und
`/leaderboard` gemessen; sie verbrauchen das Fehlerbudget von router-core nicht, solange Fallback
verfügbar bleibt.
## Öffentliche Positionierung
- Preisgestaltung: Prepaid- und BYOK-Nutzung wird als ganzzahlige Mikrodollar statt als Gleitkomma-Dollar erfasst, damit kleinste Token-Kosten im Ledger nachvollziehbar bleiben.
- Uptime-Ziel: `trustedrouter/auto` ist ein echtes Chat-Modell-Alias in der lokalen/Test-Control-Plane-Inferenz und wechselt bei Upstream-Provider-Ausfällen zum nächsten konfigurierten Provider. `trustedrouter/eu` bevorzugt den EU-fokussierten Provider-Pool, `trustedrouter/zdr` erzwingt eine Zero-Retention-Provider-Untergrenze mit Anthropic an erster Stelle, und `trustedrouter/e2e` erzwingt vertrauliche + E2EE-Routen mit Tinfoil an erster Stelle. Chat-Anfragen berücksichtigen außerdem OpenRouter-konforme `models`- und `provider`-Routing-Filter (`order`, `only`, `ignore`, `allow_fallbacks`, `min_privacy`, `data_collection`, `sort`, `max_price`, `require_parameters` und `zdr`), sodass Clients explizite Fallback-Ketten oder Provider-Präferenzen anfordern können. `provider.order` ist eine Präferenz, solange Fallbacks aktiviert sind, und nicht gelistete Provider bleiben nach der bevorzugten Liste zulässig. Mit `allow_fallbacks=false` ist das Routing auf die geordnete Provider-Menge beschränkt, und nur deren erste verfügbare Route wird autorisiert. `provider.only` ist immer eine harte Provider-Allowlist. Das Setzen von `allow_fallbacks=false` entweder auf Anfrage-Ebene oder als `provider.allow_fallbacks` verhindert außerdem die Substitution durch ein anderes Modell. `min_privacy="confidential"` ist eine harte provider-seitige Anforderung an Confidential Compute + E2EE und schlägt fehlgeschlossen fehl; die Anfragewert-Aliase `e2e` und `e2ee` wählen dieselbe Stufe, statt auf eine schwächere Route zurückzufallen. Unbekannte Anfrage- oder Provider-Optionen geben `400` mit dem exakten Feldnamen zurück. Erkannte OpenRouter-Steuerungen, die nicht implementiert sind, geben ein stabiles `501 not_supported_in_alpha` zurück; sie werden niemals als Router-No-Ops akzeptiert.
- Abrechnung: Prepaid-Guthaben und BYOK zuerst; kein Abonnement erforderlich.
- Vertrauen: gehostetes Open Source, wobei der Quell-Commit der laufenden API, die Image-Referenz, der Image-Digest und die Attestation-Richtlinie unter `trust.trustedrouter.com` veröffentlicht werden.
- Registrierung: Die E-Mail-Registrierung erstellt einen einmaligen Management-Schlüssel für den Workspace.
- Wallet/Krypto: Stablecoin-Checkout wird auf Anfrage über die Crypto-Zahlungsmethode von Stripe Checkout abgewickelt. Karten-/Standard-Checkout bleibt der Standardpfad.
## Skalierungsziel
Das Ziel ist es, Skalierung auf OpenRouter-Niveau zu unterstützen:
- 1 Billion Tokens/Tag, oder etwa 11,6 Millionen Tokens/Sekunde im Tagesdurchschnitt.
- 1-4 Millionen Entwicklerkonten.
- 300+ aktiv routbare Modelle.
- 60+ Provider.
- Globaler Routing-Overhead, wettbewerbsfähig mit edge-deployten Routern.
Das aktuelle Produktions-Deployment erreicht dieses Ziel noch **nicht**. Es betreibt die Control Plane in vier GCP-Regionen hinter einem globalen LB mit regionalen Serverless NEGs und vier aktiven attestierten API-Regionen. Die Kapazität skaliert horizontal, sobald weitere attestierte Pools online gehen; Korrektheit, Vertrauen, Abrechnung und SDK-Kompatibilität befinden sich im Steady-State.
Das Anfragevolumen hängt stark von der durchschnittlichen Generierungsgröße ab. Bei 1 Billion Tokens/Tag:
| Durchschnittliche Tokens/Anfrage | Anfragen/Tag | Durchschnittliche Anfrage-Rate |
| ---: | ---: | ---: |
| 1.000 | 1,0 Mrd. | 11,6k rps |
| 2.500 | 400 Mio. | 4,6k rps |
| 10.000 | 100 Mio. | 1,2k rps |
Die Architektur kann auf diese Skalierung weiterentwickelt werden, aber nur, wenn der Hot Path globale Engpässe pro Anfrage vermeidet. Das bedeutet regionale zustandslose Gateway-Flotten, regionale Provider-Pools, geshardete Quota-Leases, Append-only-Metadaten-Schreibvorgänge und asynchrone Aggregation.
## Aktuelle Latenz
Gemessen von dieser Entwicklungsmaschine zur zentralisierten attestierten GCP-API in `us-central1` am 2. Mai 2026:
| Probe | p50 | p95 | Hinweise |
| --- | ---: | ---: | --- |
| Ablehnung nicht authentifizierter `/v1/chat/completions` | 174 ms | 184 ms | Umfasst DNS, TCP, öffentliches TLS, Enclave-Anfrageverarbeitung. |
| TCP-Verbindung | 55 ms | 59 ms | Netzwerkpfad zu `us-central1` von dieser Maschine. |
| TLS-Handshake abgeschlossen | 112 ms | 124 ms | Öffentliches ACME-Zertifikat terminiert innerhalb der Enclave. |
| `/attestation` | 1,06 s | 1,12 s | Umfasst die Generierung des GCP-Attestation-Tokens und ist daher nicht repräsentativ für den normalen Routing-Overhead. |
Der zentralisierte Netzwerk-Overhead ist deutlich höher als der von OpenRouter
angegebene Edge-Overhead, aber die Modelllatenz dominiert bei interaktiven
Anfragen in der Regel. Der erste Skalierungsschritt für die Produktion sollte
Multi-Region sein, statt sofort einen eigenen globalen Edge aufzubauen.
## Form der horizontalen Skalierung
Der Produktionspfad ist darauf ausgelegt, durch einen zustandslosen
Prompt-Gateway zu skalieren:
- `api.trustedrouter.com`-Instanzen können hinter TCP-Passthrough repliziert
werden. Sie autorisieren, reservieren und verrechnen über die Control Plane,
aber die Prompt-Bytes verlassen niemals den attestierten Pfad.
- Spanner speichert stark konsistenten Control-Plane- und Abrechnungszustand:
Benutzer, Workspaces, Schlüssel, BYOK-Metadaten, Idempotenz von
Zahlungsereignissen, Salden, Aggregate, aktive Reservierungen und ein
30-tägiges Auditfenster für abgeschlossene Anfragen.
- Bigtable speichert begrenzte, hochvolumige Aktivitätsmetadaten, indiziert nach
Workspace und Datum. Aktivitäts- und Provider-Benchmarks werden 30 Tage
aufbewahrt, rohe synthetische Samples 14 Tage und kompakte Status-Rollups
24 Monate. Prompt, Ausgabe und Tool-Call-Argumente werden nicht gespeichert.
- Die API-Schlüsselprüfung verwendet einen Lookup-Hash mit hoher Entropie für
Punktlesevorgänge; sie durchsucht keine Schlüssel.
- Ratenbegrenzungen werden vor den Route-Handlern durchgesetzt und nutzen den
konfigurierten Store, sodass Produktionszähler über Cloud Run-Instanzen
hinweg geteilt werden.
Bei Traffic im OpenRouter-Maßstab ist der nächste Engpass nicht die
Enclave-Binary, sondern der synchrone Abrechnungs-/Autorisierungspfad. Die
Architektur benötigt geshardete Reservierungen, regionale Bigtable-Cluster,
Cloud Armor-Edge-Limits und mehrere Gateway-Replikate, bevor öffentlicher
Traffic hochgefahren werden darf.
## Multi-Region-Plan
Multi-Region ist unter Beibehaltung der Vertrauensgrenze machbar, muss aber
sorgfältig umgesetzt werden:
São Paulo (`southamerica-east1`) bleibt eine aktive Cloud Run Control Plane:
`trusted-router` wird weiterhin über den globalen Load Balancer bereitgestellt
und bedient. Nur seine Enclave-Gateway-MIG wurde außer Betrieb genommen
(quill-cloud-proxy #309); sein veralteter regionaler Gateway-DNS-Eintrag wurde
gelöscht. Die Deployment-Regionen der Control Plane bleiben `us-central1`,
`us-east4`, `europe-west4` und `southamerica-east1`.
Oregon (`us-west1`) ist der umgekehrte Fall: eine reine Gateway-Region. Sie
betreibt einen attestierten Gateway-Pool unter `api-us-west1.quillrouter.com`
und hat keine Cloud Run Control Plane. Ihr Gateway erreicht die Control Plane
über den globalen Load Balancer, der es an die nächstgelegene
Control-Plane-Region (`us-central1`) weiterleitet. Nichts in
`scripts/deploy` erstellt dort einen Cloud Run-Service, Scheduler-Job oder NEG,
und es gibt keinen Eintrag in den Standardwerten für Warm-Region oder
Min-Instances.
- Betreiben Sie unabhängige warme, attestierte Gateway-Pools in `us-central1`, `us-east4`, `europe-west4` und `us-west1`. Das Enclave-Inventar ist `src/trusted_router/enclave_regions.py`, das von synthetischen Probes, Provider-Smoke-Checks, den Watchdog-Standardwerten und den `TR_REGIONS`-Deploy-Standardwerten gemeinsam genutzt wird. Dasselbe Modul benennt die Gateway-Regionen, die keine lokale Control Plane haben (`ENCLAVE_REGIONS_WITHOUT_LOCAL_CONTROL_PLANE`).
- Bewahren Sie TLS-Privatschlüssel innerhalb jeder regionalen Confidential-Space-Workload auf.
- Halten Sie die Zertifikatsausstellung innerhalb der attestierten Workload. Zertifikate werden zwischen Replikaten über den verschlüsselten Cache geteilt. Ein erster regionaler Hostname wird für einen Knoten erst dann freigegeben, wenn jeder Knoten die kanonische Attestierung und ein abgeschlossenes PONG besteht; er wird erst dann erweitert, wenn das regionale Zertifikat und dieselben Gates auf jedem Knoten bestehen.
- Behalten Sie regionale Hostnamen wie `api-us-central1.quillrouter.com`, `api-us-east4.quillrouter.com`, `api-europe-west4.quillrouter.com` und `api-us-west1.quillrouter.com` für deterministische Attestierung, Smoke-Tests und SDK-Failover bei.
- Platzieren Sie `api.trustedrouter.com` hinter Latenz-/Geo-DNS oder TCP-Passthrough, das TLS nicht terminiert. Cloudflare-Orange-Cloud-Proxying bleibt mit der Trust-Behauptung des Prompt-Pfads unvereinbar.
- Autorisieren Sie über geshardete Billing-Zeilen, nicht über eine einzelne globale Spanner-Counter-Mutation für jede Anfrage. Neue Workspaces und Schlüssel beginnen mit 16 exakten Billing-Shards. Regionale Quota-Leases bleiben zukünftige Arbeit: Die regionalen Quota- und Spend-Lease-Piloten von 2026-09 wurden entfernt.
- Schreiben Sie Generierungs-Metadaten in regionale Bigtable-Cluster und aggregieren Sie sie anschließend asynchron in globale Aktivitätsansichten.
- Halten Sie das Provider-Routing regional, mit providerspezifischen Circuit Breakern, Fallback-Richtlinie und Ratenlimits pro Provider.
Die zentrale Designregel: Ein regionaler Ausfall kann fail-closed sein oder auf eine andere attestierte Region routen, aber er darf niemals stillschweigend auf einen nicht attestierten Prompt-Handler degradieren.
## Router-Core-Ziel von vier Neunen
Das Ziel ist ein internes SLO, kein vertragliches SLA. 99,99 % erlauben etwa 52 Minuten und 36 Sekunden Ausfallzeit pro Jahr. Der öffentliche Status kennzeichnet diese Zahl als Ziel, bis mindestens 30–60 Tage gemessene Router-Core-Verfügbarkeit von 99,99 % vorliegen.
Router-Core-Verfügbarkeit bedeutet:
- attestiertes TLS ist erreichbar;
- API-Key-Validierung und Gateway-Autorisierung funktionieren;
- Route-Kandidaten werden zurückgegeben und Fallback kann einen gesunden Provider wählen;
- Settlement/Refund ist dauerhaft oder sicher reparierbar;
- keine Prompt-Anfrage fällt jemals auf einen nicht attestierten Pfad zurück.
Die Codepfade, die diese Roadmap heute unterstützen, sind:
- `/status.json` exportiert `slo_classes.router_core`, `slo_classes.control_plane` und Burn-Rate-Alarme für Fenster von 5m, 1h, 6h und 24h.
- Der Deploy-Watchdog liest standardmäßig `router_core`, sodass reine Provider-Ausfälle nicht automatisch ein Control-Plane-Deploy zurückrollen.
- Von SDKs wird erwartet, dass sie Verbindungsfehler und 502/503/504 über regionale attestierte Endpunkte hinweg wiederholen, bevor sie einen Fehler melden.
- Bigtable-Aktivitätsschreibvorgänge sind aus der dauerhaften Settlement-Outbox reparierbar. Settlement verwendet deterministische Generierungs-IDs, sodass Wiederholungen dieselben Indexzeilen überschreiben und weder doppelt berechnen noch Aktivitäten duplizieren können.
Bevor vier Neunen als gemessene Verfügbarkeit statt als Ziel beschrieben werden, sind drei warme attestierte GCP-Regionen, getestetes Paging, Router-Core-Chaos-Tests, gestaffelte regionale Deploys mit Rollback-Gates und mindestens 30 Tage gemessene Router-Core-Verfügbarkeit von mindestens 99,99 % erforderlich.
## Interner Gateway-Vertrag
Die attestierte API-Ebene kann Nutzung reservieren und abrechnen, ohne Prompt- oder Ausgabeinhalte an die Control Plane zu senden:
- `POST /v1/internal/gateway/authorize`: validiert den API-Key-Hash, reserviert
Credits/Key-Limits und gibt Provider-/BYOK-Routing-Metadaten, aus den
Request-Filtern `model`, `models` und `provider` abgeleitete Routen-
Kandidaten sowie konfigurierte regionale Endpunkte zurück.
- `POST /v1/internal/gateway/settle`: rechnet erfolgreiche Nutzung ab und hängt
reine Metadaten-Aktivitätszeilen an.
- `POST /v1/internal/gateway/refund`: gibt Reservierungen nach Provider-
Fehlern oder Client-Trennungen frei.
Legen Sie `TR_INTERNAL_GATEWAY_TOKEN` außerhalb der lokalen Entwicklung fest.
## Produktionsspeicher
Die Produktion verwendet:
```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` aktiviert die APIs, erstellt die Spanner-Tabelle
`tr_entities`, stellt Cloud Run bereit und
bindet die aktuellen GCP-Trust-Metadaten in die Trust-Seite ein.
## Abrechnung
`POST /v1/billing/checkout` erstellt eine Stripe-Checkout-Session, wenn
`TR_STRIPE_SECRET_KEY` konfiguriert ist, und gibt andernfalls eine deterministische lokale
Mock-Antwort zurück. Stripe-Webhooks schreiben Workspaces idempotent unter Verwendung der
Workspace-ID in den Checkout-Metadaten gut. Kartenzahlungen werden sofort abgerechnet. ACH-
Zahlungen verwenden `{"payment_method":"ach"}` und werden erst gutgeschrieben, nachdem Stripe
`checkout.session.async_payment_succeeded` sendet; der Abschluss des Checkouts, während die Lastschrift
in Bearbeitung ist, gewährt niemals Gutschriften. `POST /v1/billing/portal` folgt demselben
Stripe-oder-Mock-Muster für die Abrechnungsverwaltung.
Für den Stablecoin-Checkout senden Sie `{"payment_method":"stablecoin"}`. Wenn
`TR_STABLECOIN_CHECKOUT_ENABLED=true` gesetzt ist, wird die Checkout-Session mit
Stripes `crypto`-Zahlungsmethode erstellt und schreibt den Workspace weiterhin über den signierten
`checkout.session.completed`-Webhook gut.
ACH verwendet die Zahlungsmethode `us_bank_account` von Stripe Checkout. Der standardmäßige
Abrechnungsplan beträgt 0,8 % mit einer Obergrenze von 5 $ und kann mit
`TR_STRIPE_ACH_FEE_BASIS_POINTS`, `TR_STRIPE_ACH_FEE_FIXED_CENTS` und
`TR_STRIPE_ACH_FEE_MAX_CENTS` überschrieben werden. Die automatische Nachladung mit gespeicherter Karte bleibt nur für Karten möglich.