
TrustedRouter.com Repo für sicheres LLM-Proxying
Hör auf, dir Sorgen darüber zu machen, wer deine Prompts sehen kann. Sag deinem Coding-Agenten, er soll dein Projekt umziehen, wähle, wie privat du sein möchtest, wähle ein Modell, füge einen Schlüssel ein – fertig. Gleiche API, 30+ Modelle, ein Schlüssel. Das Gateway läuft in Hardware-Enklaven und du kannst kryptographisch verifizieren, dass es dich niemals protokolliert.
Füge das in Codex, Claude Code oder Cursor ein – es übernimmt die Migration für dich:```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 Zero-Retention-Untergrenze, oder
`{"provider": {"min_privacy": "confidential"}}` für die stärkere harte
Confidential-Compute- + E2EE-Untergrenze. Die praktischen Aliase `trustedrouter/zdr` und
`trustedrouter/e2e` (`trustedrouter/confidential`) 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 automatisches
Fallback, wenn die Anbieterbreite wichtiger ist als der strengste Datenschutzfilter.
3. **Registriere dich, füge eine Karte hinzu, erhalte deinen Schlüssel** unter https://trustedrouter.com.
4. **Live gehen** — deine Prompts laufen jetzt über einen Pfad, den du überprüfen kannst.
<details>
<summary>Lieber von Hand verdrahten?</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-..."
# Any OpenAI SDK
client = OpenAI(base_url="https://api.trustedrouter.com/v1", api_key="sk-tr-v1-...")
Das Gateway von TrustedRouter läuft in GCP Confidential Space. Die Plattform signiert eine Messung der laufenden Binärdatei; du vergleichst diesen Hash mit diesem Repo. Wenn sie übereinstimmen, weißt du — nicht vermutest —, dass der Code, der deine Eingaben verarbeitet, der Code ist, den du hier lesen kannst, und dass er deine Eingaben nie auf die Festplatte schreibt.
Überprüfe es selbst in 60 Sekunden, ohne Konto:```bash NONCE=$(openssl rand -hex 16) curl -s "https://api.trustedrouter.com/attestation?nonce=$NONCE" | jq .
| | Vertrauensmodell |
|---|---|
| OpenRouter, gehostete Anbieter | "Wir protokollieren nicht." Eine Richtlinie, die man nicht überprüfen kann. |
| Portkey, Cloudflare AI Gateway | Protokolliert alles für Observability. |
| LiteLLM | Selbst hosten, aber der laufende Proxy ist unverifiziert. |
| **TrustedRouter** | **Open Source + Hardware-Attestierung. Verifiziere den Codepfad; es protokolliert nichts.** |
Ehrlicher Umfang: Die Attestierung beweist, dass die laufende Binärdatei die veröffentlichte Binärdatei auf Hardware ist, die du mit einer Nonce herausfordern kannst. Sie besiegt keinen Nationalstaat mit physischem Hostzugriff und beweist nicht, dass die Open-Source-Binärdatei fehlerfrei ist. Der Vertrauensanker ist die hardwaregestützte Attestierungskette von Google Confidential Computing. Upstream-Anbieter behandeln Prompts gemäß ihren eigenen Richtlinien – die Haltung jedes Anbieters wird auf den Modellseiten veröffentlicht.
</details>
---
## Repository-Struktur
Dieses Repository implementiert den Control-Plane-Vertrag: Routenabdeckung, Auth-/Schlüsselverwaltung, Abrechnungs-Ledger-Semantik, Nutzungsmetadaten, keine Speicherung von Prompts/Ausgaben, 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 dauerhafter funktionierender Alias (gleiches attestiertes 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.
Setzen Sie lokale Operator-/Provider-Schlüssel in:```text
/Users/jperla/claude/.quill_cloud_keys.private
Diese Datei wird nie committet. Es wird erwartet, dass sie im dotenv-Stil ist:```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 auch 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: Produktive GCP-Deploys verwenden das Cloud Run- oder Confidential-Space-Dienstkonto sowie kurzlebige Google-Zugriffstokens von Metadata/ADC. Für die First-Party-Prepaid-Vertex-Route keine langlebigen Vertex-Schlüssel in diese Datei eintragen; stattdessen dem Laufzeit-Dienstkonto Vertex-Berechtigungen erteilen.
## Lizenz
Business Source License 1.1. Der Quellcode ist öffentlich, sodass jeder den genauen Code hinter TrustedRouters Datenschutz- und Attestierungsaussagen (https://trust.trustedrouter.com) lesen, bauen und verifizieren kann – genau 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 zur Apache License 2.0. Code, der vor dem 3. Juli 2026 veröffentlicht wurde, bleibt Apache-2.0.
## Sicherheitsstandards
- Prompt- und Ausgabeinhalte werden nie gespeichert.
- Nutzungslogs enthalten nur Metadaten.
- API-Schlüssel werden als gesalzene SHA-256-Hashes mit undurchsichtigen Schlüssel-IDs gespeichert.
- Vom Benutzer übermittelte BYOK-Provider-Schlüssel werden als envelope-verschlüsselte Chiffrat-Zeilen gespeichert, nicht als ein Secret-Manager-Objekt pro Schlüssel. In der Produktion umhüllt Cloud KMS den schlüsselbezogenen DEK; externe `env://...`-Referenzen bleiben für operator-verwaltete Schlüssel unterstützt.
- Gateway-Autorisierungen enthalten einen nicht-geheimen `byok_cache_key` für verschlüsselte BYOK-Envelopes. Attestierte Gateways verwenden ihn für kurzlebiges, rein speicherbasiertes entschlüsseltes Schlüssel-Caching; BYOK-Rotation ändert den Schlüssel und Delete beendet die Rückgabe des Envelopes.
- Rohe BYOK-Schlüssel sind nur einmalige Eingaben; öffentliche/Control-Plane-Antworten geben einen kurzen Hinweis auf ersten/letzten Schlüsselteil und verschlüsselte Referenzmetadaten preis, niemals Klartext.
- Produktionskonfiguration schließt ohne internes Gateway-Token, signiertes Stripe-Webhook-Secret und Nicht-Speicher-Backend ab (Fail-closed).
- Produktions-Control-Plane-Apps registrieren `/chat/completions`, `/messages`, `/responses` oder `/embeddings` nicht; diese gehören zur attestierten API-Ebene.
- Sentry ist nur Control-Plane und bereinigt Request-Bodies, Auth-Header, API-Schlüssel, BYOK-Schlüssel, Prompt-Nachrichten und Ausgabetext. Ein clientseitiges Sentry-Flood-Gate begrenzt wiederholte Issues pro Fingerprint und Gesamtereignisse pro Prozess/Fenster, sodass eine einzelne laute Integration nicht erneut das gesamte Fehlerbudget verbrauchen kann.
- Keine Sentry-Konfiguration gehört in die attestierte Enklave.
## Broadcast-Observability
Workspace-Inhaber 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 Metadaten: Modell, Provider, Token-Anzahl, 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 Management-Antworten. Nur-Metadaten-Zustellungen werden zuerst in ein persistentes Broadcast-Outbox geschrieben und asynchron von `/internal/broadcast/drain` verarbeitet, sodass ein PostHog/Webhook-Ausfall weder Inferenz blockiert noch bereits abgerechnete Metadaten bei Prozessneustart verliert.
## Synthetisches Monitoring
TrustedRouter hat eine separate synthetische Monitoring-Ebene für öffentliche Verfügbarkeit. Synthetische Worker laufen außerhalb der Enklave, senden kleine echte Anfragen an die öffentliche attestierte API und speichern nur Metadaten. Die Monitor-Modell-Aliase sind:
- `trustedrouter/free`: OpenRouter-artiger Free-Pool. Nützlich für Benutzer, kein SLA-Signal.
- `trustedrouter/cheap`: günstigster kostenpflichtiger Pool mit Provider-Diversität.
- `trustedrouter/eu`: EU-fokussierter Provider-Pool. Bevorzugt europäische, EU-regionierbare und datenschutzorientierte Provider, besonders in Kombination mit `https://api-europe-west4.quillrouter.com/v1`. Dies ist eine Routing-Richtlinie, keine pauschale Datenresidenz-Garantie.
- `trustedrouter/monitor`: interner Verfügbarkeits-Pool für PONG- und Fallback-Checks. Er ist im Katalog aus Transparenzgründen 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, mit einem dedizierten `trustedrouter-synthetic-monitoring`-Workspace/-Schlüssel mit harten Ausgabenobergrenzen und automatischer Aufladung. Rohe Samples 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 Generationen verwenden das App-Label `TrustedRouter Synthetic` und sind von Kunden-/App-Analysen ausgeschlossen.
Die Provider-Messung verwendet zwei unabhängige Probe-Klassen:
- Kurze PONG-Probes decken zufällig den gesamten aktiven Katalog ab und messen Verfügbarkeit, TTFB, TTFT und Upstream-API-Drift.
- Ein kontinuierlicher 512-Token-Stream deckt die 200 wichtigsten Provider-/Modell-Routen in deterministischer Rotation von `us-central1` ab. Er misst Ausgabe-Tokens pro Sekunde nach dem ersten Token. Er läuft in einem separaten Cloud Run Job, sodass langsame Streams Verfügbarkeits-Probes nicht verzögern. Fehler bei langen Probes zählen nie gegen Provider-Verfügbarkeit oder API-Drift-Alarme.
Der aktuelle Zwei-Minuten-Zeitplan ergibt für jede kontinuierliche Route etwa 25 Samples pro Woche und 108 pro 30 Tage. CI berechnet eine Vollkosten-Schätzung aus dem Live-Katalog und schlägt fehl, wenn sie das überprüfte monatliche Limit überschreitet.
Der Status trennt zwei Service-SLO-Klassen, anstatt sie mit dem Verhalten der Upstream-Provider zu vermischen:
- `router_core`: attestierte API erreichbar, Schlüsselautorisierung funktioniert, Routenkandidaten/Fallback verfügbar, und Settlement/Refund ist dauerhaft.
- `control_plane`: Dashboard, Abrechnungs-UI, Schlüssel, Credits, Doku, Trust und Status-Oberflächen.
Deploy-Watchdogs und interne Burn-Rate-Alarme verwenden standardmäßig `router_core`. Nur-Provider-Fehler werden pro Provider unter `/status` und `/leaderboard` gemessen; sie verbrauchen das Router-Core-Fehlerbudget nicht, wenn Fallback verfügbar bleibt.
## Öffentliche Positionierung
- Preisgestaltung: Prepaid- und BYOK-Nutzung wird als ganzzahlige Mikrodollar erfasst, nicht als Gleitkomma-Dollar, sodass winzige Token-Kosten im Ledger prüfbar bleiben.
- Verfügbarkeitsziel: `trustedrouter/auto` ist ein echtes Chat-Modell-Alias in lokaler/Test-Control-Plane-Inferenz und wechselt bei Upstream-Provider-Fehlern zum nächsten konfigurierten Provider. `trustedrouter/eu` bevorzugt den EU-fokussierten Provider-Pool, `trustedrouter/zdr` erzwingt eine Zero-Retention-Provider-Stufe mit Anthropic an erster Stelle, und `trustedrouter/e2e` erzwingt vertrauliche + E2EE-Routen mit Tinfoil an erster Stelle. Chat-Anfragen berücksichtigen auch OpenRouter-artige `models`- und `provider`-Routing-Filter (`order`, `only`, `ignore`, `allow_fallbacks`, `min_privacy`, `data_collection` und `sort`), sodass Clients explizite Fallback-Ketten oder Provider-Präferenzen anfordern können. `min_privacy="confidential"` ist eine harte, provider-seitige Anforderung an vertrauliches Computing + E2EE und schließt fail-closed; die Request-Value-Aliase `e2e` und `e2ee` wählen dieselbe Stufe, anstatt auf eine schwächere Route zurückzufallen.
- Abrechnung: Prepaid-Credits und BYOK zuerst; kein Abonnement erforderlich.
- Vertrauen: gehosteter Open Source, wobei der Quell-Commit der laufenden API, die Image-Referenz, der Image-Digest und die Attestierungsrichtlinie unter `trust.trustedrouter.com` veröffentlicht werden.
- Anmeldung: E-Mail-Anmeldung erstellt einen einmaligen Management-Schlüssel für den Workspace.
- Wallet/Krypto: Stablecoin-Checkout wird über die Crypto-Zahlungsmethode von Stripe Checkout abgewickelt, wenn angefordert. Karten-/Standard-Checkout bleibt der Standardpfad.
## Skalierungsziel
Das Ziel ist die Unterstützung von OpenRouter-artigem Maßstab:
- 1 Billion Tokens/Tag, also 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-bereitgestellten Routern.
Die aktuelle Produktionsbereitstellung erreicht dieses Ziel **noch nicht**. Sie läuft mit der Control Plane in vier GCP-Regionen hinter einem globalen LB mit pro Region Serverless NEGs, mit drei live attestierten API-Regionen, bis zusätzliche attestierte regionale Pools bereitgestellt werden. Die Kapazität skaliert horizontal, wenn weitere attestierte Pools online kommen; Korrektheit, Vertrauen, Abrechnung und SDK-Kompatibilität befinden sich im Dauerzustand.
Das Anfragevolumen hängt stark von der durchschnittlichen Generierungsgröße ab. Bei 1 Billion Tokens/Tag:
| Durchschnittliche Tokens/Anfrage | Anfragen/Tag | Durchschnittliche Anfragelast |
| ---: | ---: | ---: |
| 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 diesen Maßstab weiterentwickelt werden, aber nur, wenn der Hot Path globale Engpässe pro Anfrage vermeidet. Das bedeutet regionale zustandslose Gateway-Flotten, regionale Provider-Pools, shardierte 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 |
| --- | ---: | ---: | --- |
| Abgelehnte nicht authentifizierte `/v1/chat/completions`-Anfrage | 174 ms | 184 ms | Enthält DNS, TCP, öffentliches TLS, Enklaven-Request-Handling. |
| TCP-Verbindung | 55 ms | 59 ms | Netzwerkpfad zu `us-central1` von dieser Maschine. |
| TLS-Handshake abgeschlossen | 112 ms | 124 ms | Public-ACME-Zertifikat endet innerhalb der Enklave. |
| `/attestation` | 1,06 s | 1,12 s | Enthält GCP-Attestierungs-Token-Generierung, daher nicht repräsentativ für normalen Routing-Overhead. |
Der zentralisierte Netzwerk-Overhead ist deutlich höher als der von OpenRouter berichtete Edge-Overhead, aber Modell-Latenz dominiert normalerweise interaktive Anfragen. Der erste Produktionsskalierungsschritt sollte Multi-Region sein, anstatt sofort ein benutzerdefiniertes globales Edge zu bauen.
## Form der horizontalen Skalierung
Der Produktionspfad ist so ausgelegt, dass er skaliert, indem der Prompt-Gateway zustandslos bleibt:
- `api.trustedrouter.com`-Instanzen können hinter TCP-Passthrough repliziert werden. Sie autorisieren, reservieren und wickeln Settlement über die Control Plane ab, aber Prompt-Bytes verlassen nie den attestierten Pfad.
- Spanner speichert stark konsistenten Control-Plane- und Abrechnungszustand: Benutzer, Workspaces, Schlüssel, BYOK-Metadaten, Zahlungsereignis-Idempotenz, Salden, Aggregate, aktive Reservierungen und ein 30-tägiges terminales Request-Audit-Fenster.
- Bigtable speichert begrenzte, hochvolumige Aktivitätsmetadaten, verschlüsselt nach Workspace und Datum. Aktivität und Provider-Benchmarks behalten 30 Tage, rohe synthetische Samples 14 Tage und kompakte Status-Rollups 24 Monate. Prompt, Ausgabe und Tool-Call-Argumente werden nicht gespeichert.
- API-Schlüsselüberprüfung verwendet einen High-Entropy-Lookup-Hash für Punktlesevorgänge; sie scannt keine Schlüssel.
- Rate Limits werden vor Routen-Handlern durchgesetzt und verwenden den konfigurierten Store, sodass Produktionszähler über Cloud-Run-Instanzen hinweg gemeinsam genutzt werden.
Bei OpenRouter-Scale-Traffic ist der nächste Engpass nicht die Enklaven-Binärdatei; es ist der synchrone Abrechnungs-/Autorisierungspfad. Die Architektur benötigt shardierte Reservierungen, regionale Bigtable-Cluster, Cloud-Armor-Edge-Limits und mehrere Gateway-Replikate, bevor öffentlicher Traffic hochgefahren werden darf.
## Multi-Region-Plan
Multi-Region ist machbar, während die Vertrauensgrenze erhalten bleibt, aber es muss sorgfältig umgesetzt werden:
- Unabhängige warme attestierte Gateway-Pools in mindestens `us-central1`, `us-east4` und `europe-west4` betreiben, dann Asien, sobald die ersten drei Regionen langweilig laufen.
- TLS-Private-Key in jeder regionalen Confidential-Space-Workload behalten.
- ACME von TLS-ALPN-01 auf DNS-01 oder einen anderen Challenge-Flow umstellen, der mit mehreren regionalen Endpunkten für denselben Hostnamen funktioniert. Der aktuelle TLS-ALPN-01-Flow ist für eine Region in Ordnung, aber ein globaler DNS-Eintrag kann Challenges an das falsche Replikat leiten.
- Regionale Hostnamen wie `api-us-central1.quillrouter.com`, `api-us-east4.quillrouter.com` und `api-europe-west4.quillrouter.com` für deterministische Attestierung, Smoke-Tests und SDK-Failover beibehalten.
- `api.trustedrouter.com` hinter Latenz-/Geo-DNS oder TCP-Passthrough platzieren, das TLS nicht terminiert. Cloudflare-Orange-Cloud-Proxying bleibt mit dem Vertrauensanspruch des Prompt-Pfads inkompatibel.
- Über regionale Quota-Leases autorisieren, nicht über eine synchrone globale Spanner-Transaktion für jede Anfrage.
- Generierungsmetadaten in regionale Bigtable-Cluster schreiben und dann asynchron in globale Aktivitätsansichten aggregieren.
- Provider-Routing regional halten, mit provider-spezifischen Circuit Breakern, Fallback-Richtlinie und Pro-Provider-Rate-Limits.
Die zentrale Designregel: Ein regionaler Ausfall kann fail-closed sein oder zu einer anderen attestierten Region routen, aber er darf niemals stillschweigend auf einen nicht-attestierten Prompt-Handler degradieren.
## Router-Core-Vier-Neunen-Ziel
Das Ziel ist ein internes SLO, kein vertragliches SLA. 99,99 % erlauben etwa 52 Minuten 36 Sekunden Ausfall pro Jahr. Öffentliche Statusseiten kennzeichnen diese Zahl als Ziel, bis mindestens 30–60 Tage gemessener 99,99 % Router-Core-Verfügbarkeit vorliegen.
Router-Core-Verfügbarkeit bedeutet:
- attestiertes TLS ist erreichbar;
- API-Schlüsselvalidierung und Gateway-Autorisierung funktionieren;
- Routenkandidaten 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 diesen Fahrplan heute unterstützen:
- `/status.json` exportiert `slo_classes.router_core`, `slo_classes.control_plane` und Burn-Rate-Alarme für 5m-, 1h-, 6h- und 24h-Fenster.
- Der Deploy-Watchdog liest standardmäßig `router_core`, sodass Nur-Provider-Ausfälle ein Control-Plane-Deploy nicht automatisch zurückrollen.
- SDKs sollen Verbindungsfehler und 502/503/504 über regionale attestierte Endpunkte hinweg erneut versuchen, bevor sie einen Fehler anzeigen.
- Bigtable-Aktivitätsschreibvorgänge sind aus dem dauerhaften Settlement-Outbox reparierbar. Settlement verwendet deterministische Generierungs-IDs, sodass Wiederholungen dieselben Indexzeilen überschreiben und weder doppelt belasten noch Aktivität duplizieren können.
Bevor vier Neunen als gemessene Verfügbarkeit statt als Ziel beschrieben werden, sind drei warme GCP-attestierte Regionen, getestetes Paging, Router-Core-Chaos-Tests, gestaffelte regionale Deploys mit Rollback-Gates und mindestens 30 Tage gemessener 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-Schlüssel-Hash, reserviert Credits/Schlüssellimits und gibt Provider-/BYOK-Routing-Metadaten, aus `model`, `models`- und `provider`-Request-Filtern abgeleitete Routenkandidaten sowie konfigurierte regionale Endpunkte zurück.
- `POST /v1/internal/gateway/settle`: wickelt erfolgreiche Nutzung ab und hängt Zeilen nur mit Metadaten-Aktivität an.
- `POST /v1/internal/gateway/refund`: gibt Reservierungen nach Provider-Fehlern oder Client-Trennungen frei.
`TR_INTERNAL_GATEWAY_TOKEN` außerhalb der lokalen Entwicklung setzen.
## Produktionsspeicher
Die Produktion verwendet:```text
TR_STORAGE_BACKEND=spanner-bigtable
TR_SPANNER_INSTANCE_ID=trusted-router
TR_SPANNER_DATABASE_ID=trusted-router
TR_BIGTABLE_INSTANCE_ID=trusted-router-logs
TR_BIGTABLE_GENERATION_TABLE=trustedrouter-generations
scripts/deploy-gcp.sh aktiviert die APIs, erstellt die Spanner-Tabelle
tr_entities, erstellt die Bigtable-Generationstabelle, stellt Cloud Run bereit und
bindet die aktuellen GCP-Trust-Metadaten in die Trust-Seite ein.
POST /v1/billing/checkout erstellt eine Stripe-Checkout-Sitzung, wenn
TR_STRIPE_SECRET_KEY konfiguriert ist, und gibt andernfalls eine deterministische lokale
Mock-Antwort zurück. Stripe-Webhooks schreiben Workspaces idempotent gut, wobei die
Workspace-ID in den Checkout-Metadaten verwendet wird. 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
verarbeitet wird, gewährt niemals Gutschriften. POST /v1/billing/portal folgt demselben
Stripe-oder-Mock-Muster für die Abrechnungsverwaltung.
Für Stablecoin-Checkout senden Sie {"payment_method":"stablecoin"}. Wenn
TR_STABLECOIN_CHECKOUT_ENABLED=true ist, wird die Checkout-Sitzung mit
Stripes crypto-Zahlungsmethode erstellt und schreibt dem Workspace dennoch über den signierten
checkout.session.completed-Webhook gut.
ACH verwendet die us_bank_account-Zahlungsmethode von Stripe Checkout. Der Standard-
Verarbeitungsplan beträgt 0,8 % mit einer Obergrenze von 5 $ und kann überschrieben werden mit
TR_STRIPE_ACH_FEE_BASIS_POINTS, TR_STRIPE_ACH_FEE_FIXED_CENTS und
TR_STRIPE_ACH_FEE_MAX_CENTS. Die automatische Aufladung mit gespeicherter Karte bleibt reine Kartenzahlung.