Skip to content
KitploitKITPLOIT
工具博客
提交
工具博客
提交

黑客、渗透测试和网络安全工具,武装您的安全武器库!

Kitploit 是一个黑客、网络安全和渗透测试工具的目录。发现最新的项目更新,查找漏洞、分析系统、自动化测试并加强你的安全。

··订阅源·联系·隐私·© 2026 Kitploit

工具目录

分类

查看所有分类
Loading categories
quill-router — TrustedRouter.com 仓库,用于安全的 LLM 代理 | Kitploit
工具/GitHubGitHub/lore-hex/quill-router
身份验证与授权加密/解密工具配置审计云安全DevSecOps隐私保护威胁情报API 安全日志分析
GitHublore-hex/quill-router

quill-router

TrustedRouter.com 仓库,用于安全的 LLM 代理

查看仓库
182915小时18分前Kitploit 审核通过

最受欢迎

查看全部 →

发现我们社区最常用的工具。

探索所有工具

浏览我们的工具集合

查看所有工具 →
分享

TrustedRouter

CI Deploy Prod smoke Status Verifiable trust JavaScript SDK Python SDK License: BUSL-1.1

端到端加密的 LLM。一个 API。可证明的隐私。

别再担心谁能看到你的提示词。告诉你的编码智能体把项目 迁移过来,选择你想要的隐私程度,选一个模型,放入一个 密钥——搞定。同一个 API,30+ 个模型,一个密钥。网关运行在硬件 安全飞地中,你可以通过密码学方式验证它绝不会记录你的信息。

一条提示词迁移你的项目

将这份内容粘贴到 Codex、Claude Code 或 Cursor 中——它会帮你完成迁移:```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.

root@kitploit:~
然后:

1. **选择你的隐私级别或区域** — 使用
   `{"provider": {"min_privacy": "zdr"}}` 作为严格的零留存底线,或使用
   `{"provider": {"min_privacy": "confidential"}}` 作为更强的严格机密计算 + E2EE 底线。便捷的 `trustedrouter/zdr` 和
   `trustedrouter/e2e`(`trustedrouter/confidential`)别名可选择这些池。使用 `trustedrouter/eu` 搭配
   `https://api-europe-west4.quillrouter.com/v1` 进行欧盟区域路由。
2. **选择一个模型** — 数百种模型任选,或使用 `trustedrouter/auto` 在提供商广度比最严格的隐私过滤器更重要时自动回退。
3. **注册、添加银行卡、获取密钥**,请访问 https://trustedrouter.com。
4. **上线** — 你的提示词现在运行的路径是可验证的。

<details>
<summary>更喜欢手动配置?</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-..."
root@kitploit:~
# Any OpenAI SDK
client = OpenAI(base_url="https://api.trustedrouter.com/v1", api_key="sk-tr-v1-...")
  • 获取密钥 / 掏钱吧: https://trustedrouter.com
  • 先试用(无需注册): https://trustedrouter.com/chat
  • 技术细节(给极客): https://trustedrouter.com/security
  • 我们构建它的原因: https://jperla.com/blog/attestation-is-all-you-need

给极客:隐私如何可证明

TrustedRouter 的网关运行在 GCP Confidential Space 中。该平台会签名 正在运行的二进制文件的度量值;你 可以将该哈希值与此仓库进行比较。如果匹配,你就知道 — 而非假设 — 处理你提示词的代码就是你可以在这里阅读的代码,并且它永远不会 将你的提示词写入磁盘。

在 60 秒内自行验证,无需账户:```bash NONCE=$(openssl rand -hex 16) curl -s "https://api.trustedrouter.com/attestation?nonce=$NONCE" | jq .

eat_nonce your nonce (replay-protected)

image_digest SHA-256 of the running container

pcrs boot-time platform measurements

Compare image_digest to the published artifact at

https://trustedrouter.com/security — match = the running code is this repo.

root@kitploit:~
| | 信任模型 |
|---|---|
| OpenRouter、托管提供商 | "我们不记录日志。" 这是一项你无法核查的政策。 |
| Portkey、Cloudflare AI Gateway | 记录一切以供可观测性。 |
| LiteLLM | 自行托管,但运行中的代理未经验证。 |
| **TrustedRouter** | **开源 + 硬件证明。验证代码路径;它不记录任何内容。** |

诚实的范围说明:证明能够证明运行中的二进制文件就是发布在硬件上的二进制文件,而你可以通过 nonce 对其提出挑战。它无法击败拥有物理主机访问权限的国家级对手,也不能证明开源二进制文件没有 bug。信任锚点是 Google Confidential Computing 的硬件支持证明链。上游提供商根据自己的政策处理提示词——每个提供商的立场都发布在模型页面上。

</details>

---

## 仓库布局

该仓库实现了控制面契约:路由覆盖、认证/密钥管理、账单账本语义、用量元数据、不存储提示词/输出、Sentry 清理器,以及提供商抽象。经过证明的网关实现位于 `quill-cloud-proxy` 中。

信任边界:`api.trustedrouter.com` 是经过证明的提示词路径,并且必须在 Confidential Space 内终止 TLS。`trustedrouter.com` 是控制面,绝不得提供生产推理回退服务。

`api.quillrouter.com` 仍然是一个永久可用的别名(相同的经过证明的网关和证书),因此现有集成无需迁移即可继续工作。

## 本地```bash
uv sync
uv run pytest
uv run uvicorn trusted_router.main:app --reload
下载工具

针对运行中的实例进行端到端冒烟测试:```bash TR_SMOKE_BASE_URL=http://127.0.0.1:18080/v1 uv run python scripts/smoke_e2e.py

root@kitploit:~
对于生产环境,设置 `TR_SMOKE_BASE_URL=https://api.trustedrouter.com/v1` 和
`TR_SMOKE_INTERNAL_TOKEN`(如果内部网关路由受令牌保护)。

在以下位置设置本地运营商/提供商密钥:```text
/Users/jperla/claude/.quill_cloud_keys.private

该文件永远不会被提交。它预期为 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=...

root@kitploit:~
The deploy script also accepts local aliases already used in some operator
files: `CLAUDE_API_KEY` for Anthropic, `CHATGPT_API_KEY` for OpenAI, and
`STRIPE_KEY` for `STRIPE_SECRET_KEY`.

部署脚本也接受一些运维文件中已使用的本地别名:`CLAUDE_API_KEY` 对应 Anthropic,`CHATGPT_API_KEY` 对应 OpenAI,`STRIPE_KEY` 对应 `STRIPE_SECRET_KEY`。

Vertex is different from the other provider platforms: production GCP deploys
use the Cloud Run or Confidential Space service account and short-lived Google
access tokens from metadata/ADC. Do not put a long-lived Vertex key in this
file for the first-party prepaid Vertex route; grant the runtime service
account Vertex permissions instead.

Vertex 与其他提供商平台不同:生产环境 GCP 部署使用 Cloud Run 或 Confidential Space 服务账号,以及来自 metadata/ADC 的短期 Google 访问令牌。对于第一方预付费 Vertex 路由,不要在此文件中放置长期有效的 Vertex 密钥;而是应为运行时服务账号授予 Vertex 权限。

## License

## 许可证

Business Source License 1.1. The source is public so anyone can read, build,
and verify the exact code behind TrustedRouter's privacy and attestation
claims (https://trust.trustedrouter.com) — that is what it is here for.
Non-production use (security review, audit, local evaluation) is free.
Production use requires a commercial license from Lore Hex Corp:
[email protected]. Each version converts to the Apache License 2.0
four years after publication. Code published before July 3, 2026 remains
Apache-2.0.

Business Source License 1.1。源代码是公开的,任何人都可以阅读、构建并验证 TrustedRouter 隐私与证明声明(https://trust.trustedrouter.com)背后的确切代码——这正是它放在这里的原因。非生产用途(安全审查、审计、本地评估)免费。生产使用需要获得 Lore Hex Corp 的商业许可证:[email protected]。每个版本在发布四年后转换为 Apache License 2.0。2026 年 7 月 3 日之前发布的代码保持 Apache-2.0。

## Security Defaults

## 安全默认值

- Prompt and output content are never stored.

- 提示词和输出内容永远不会被存储。

- Usage logs contain metadata only.

- 使用日志仅包含元数据。

- API keys are stored as salted SHA-256 hashes with opaque key IDs.

- API 密钥以加盐 SHA-256 哈希形式存储,并带有不透明的密钥 ID。

- User-submitted BYOK provider keys are stored as envelope-encrypted ciphertext
  rows, not one Secret Manager object per key. In production, Cloud KMS wraps
  the per-key DEK; external `env://...` references remain supported for
  operator-managed keys.

- 用户提交的 BYOK 提供商密钥以信封加密的密文行形式存储,而不是每个密钥一个 Secret Manager 对象。在生产环境中,Cloud KMS 包裹每个密钥的 DEK;外部 `env://...` 引用仍受支持,用于运维人员管理的密钥。

- Gateway authorizations include a non-secret `byok_cache_key` for encrypted
  BYOK envelopes. Attested gateways use it for short TTL, memory-only decrypted
  key caching; BYOK rotation changes the key and delete stops returning the
  envelope.

- 网关授权包含一个非机密的 `byok_cache_key`,用于加密的 BYOK 信封。经证明的网关使用它进行短 TTL、仅内存的解密密钥缓存;BYOK 轮换会更换密钥,删除操作会停止返回信封。

- BYOK raw keys are one-time input only; public/control-plane responses expose
  a short first/last key hint and encrypted reference metadata, never plaintext.

- BYOK 原始密钥仅限一次性输入;公共/控制平面响应只暴露简短的首/尾密钥提示和加密的引用元数据,绝不暴露明文。

- Production config fails closed without an internal gateway token, signed
  Stripe webhook secret, and a non-memory storage backend.

- 生产环境配置在缺少内部网关令牌、已签名的 Stripe webhook 机密以及非内存存储后端时会默认失败关闭。

- Production control-plane apps do not register `/chat/completions`,
  `/messages`, `/responses`, or `/embeddings`; those belong on the attested API
  plane.

- 生产环境控制平面应用不注册 `/chat/completions`、`/messages`、`/responses` 或 `/embeddings`;这些属于经证明的 API 平面。

- Sentry is control-plane-only and scrubs request bodies, auth headers, API
  keys, BYOK keys, prompt messages, and output text. A client-side Sentry flood
  gate caps repeated issues per fingerprint and total events per process/window
  so a single noisy integration cannot consume the whole error budget again.

- Sentry 仅用于控制平面,并会清除请求体、认证头、API 密钥、BYOK 密钥、提示消息和输出文本。客户端 Sentry 洪泛闸门会限制每个指纹的重复问题以及每个进程/窗口的事件总数,因此单个嘈杂的集成无法再次消耗整个错误预算。

- No Sentry configuration belongs in the attested enclave.

- 经证明的 enclave 中不应包含任何 Sentry 配置。

## Broadcast Observability

## Broadcast 可观测性

Workspace owners can configure Broadcast destinations at
`/v1/broadcast/destinations` or in the console under Broadcast. Supported
destinations are PostHog and OTLP JSON webhooks. Broadcast is metadata-only by
default: model, provider, token counts, latency, cost, route type, region, and
custom trace metadata. Prompt/output content is exported only when a destination
explicitly enables `include_content`; those content-enabled encrypted
destinations are returned only to the attested gateway, not normal management
responses. Metadata-only deliveries are written to a persistent Broadcast
outbox first and drained asynchronously by `/internal/broadcast/drain`, so a
PostHog/webhook outage does not block inference or lose already-settled
metadata on process restart.

工作区所有者可以在 `/v1/broadcast/destinations` 或控制台的 Broadcast 下配置 Broadcast 目标。支持的目标是 PostHog 和 OTLP JSON webhook。Broadcast 默认仅包含元数据:模型、提供商、令牌数量、延迟、成本、路由类型、区域以及自定义追踪元数据。仅当目标显式启用 `include_content` 时,提示词/输出内容才会被导出;这些启用内容加密的目标仅返回给经证明的网关,而不是普通管理响应。仅元数据的投递会先写入持久的 Broadcast 发件箱,并由 `/internal/broadcast/drain` 异步排空,因此 PostHog/webhook 中断不会阻塞推理,也不会在进程重启时丢失已结算的元数据。

## Synthetic Monitoring

## 合成监控

TrustedRouter has a separate synthetic monitoring plane for public uptime.
Synthetic workers run outside the enclave, send tiny real requests into the
public attested API, and store only metadata. The monitor model aliases are:

TrustedRouter 有一个独立的合成监控平面,用于公共正常运行时间。合成工作器在 enclave 之外运行,向公共经证明的 API 发送微小的真实请求,并且只存储元数据。监控模型别名如下:

- `trustedrouter/free`: OpenRouter-style free pool. Useful for users, not an
  SLA signal.
- `trustedrouter/cheap`: cheapest paid pool with provider diversity.
- `trustedrouter/eu`: EU-focused provider pool. It prefers European,
  EU-regionable, and privacy-forward providers, especially when paired with
  `https://api-europe-west4.quillrouter.com/v1`. This is a routing policy, not
  a blanket data-residency guarantee.
- `trustedrouter/monitor`: internal uptime pool for PONG and fallback checks.
  It is visible in the catalog for transparency, but authorization requires
  the configured `TR_SYNTHETIC_MONITOR_API_KEY`; normal API keys receive 403.

- `trustedrouter/free`:OpenRouter 风格的免费池。对用户有用,但不是 SLA 信号。
- `trustedrouter/cheap`:具有提供商多样性的最便宜付费池。
- `trustedrouter/eu`:面向欧盟的提供商池。它优先选择欧洲、可在欧盟区域化以及注重隐私的提供商,尤其是与 `https://api-europe-west4.quillrouter.com/v1` 搭配使用时。这是一项路由策略,而不是全面的数据驻留保证。
- `trustedrouter/monitor`:用于 PONG 和回退检查的内部正常运行时间池。为保持透明,它在目录中可见,但授权需要配置的 `TR_SYNTHETIC_MONITOR_API_KEY`;普通 API 密钥会收到 403。

Workers should run from `us-central1` and `europe-west4`, using a dedicated
`trustedrouter-synthetic-monitoring` workspace/key with hard spend caps and
auto-refill. Raw samples are append-only Bigtable rows; public status pages
read compact rollups exposed at `/status`, `/status.json`, and
`/status/history?window=5m|24h|daily`. Synthetic generations use the
`TrustedRouter Synthetic` app label and are excluded from customer/app
analytics.

工作器应从 `us-central1` 和 `europe-west4` 运行,使用专用的 `trustedrouter-synthetic-monitoring` 工作区/密钥,并设置硬性支出上限和自动充值。原始样本是仅追加的 Bigtable 行;公共状态页面读取在 `/status`、`/status.json` 和 `/status/history?window=5m|24h|daily` 公开的紧凑汇总。合成生成使用 `TrustedRouter Synthetic` 应用标签,并排除在客户/应用分析之外。

Provider measurement uses two independent probe classes:

提供商测量使用两个独立的探测类别:

- Short PONG probes randomly cover the full active catalog and measure uptime,
  TTFB, TTFT, and upstream API drift.
- A sustained 512-token stream covers the 200 most important provider/model
  routes in deterministic rotation from `us-central1`. It measures output
  tokens per second after the first token. It runs in a separate Cloud Run Job,
  so slow streams cannot delay uptime probes. Long-probe failures never count
  against provider uptime or API-drift alerts.

- 短 PONG 探测随机覆盖完整的活动目录,并测量正常运行时间、TTFB、TTFT 和上游 API 漂移。
- 持续 512 令牌流以确定性轮换方式覆盖来自 `us-central1` 的 200 条最重要的提供商/模型路由。它测量第一个令牌之后的每秒输出令牌数。它运行在单独的 Cloud Run Job 中,因此慢速流不会延迟正常运行时间探测。长探测失败永远不会计入提供商正常运行时间或 API 漂移警报。

The current two-minute schedule gives each sustained route about 25 samples per
week and 108 per 30 days. CI calculates a full-cap spend estimate from the live
catalog and fails if it exceeds the reviewed monthly ceiling.

当前的两分钟调度使每条持续路由每周获得约 25 个样本,每 30 天获得 108 个样本。CI 根据实时目录计算满容量支出估算,如果超过已审阅的每月上限则失败。

Status separates two service SLO classes instead of blending them with
upstream-provider behavior:

状态服务将两个服务 SLO 类别分开,而不是将它们与上游提供商行为混在一起:

- `router_core`: attested API reachable, key authorization works, route
  candidates/fallback are available, and settle/refund is durable.
- `control_plane`: dashboard, billing UI, keys, credits, docs, trust, and
  status surfaces.

- `router_core`:经证明的 API 可访问,密钥授权正常,路由候选/回退可用,结算/退款是持久的。
- `control_plane`:仪表板、计费 UI、密钥、积分、文档、信任和状态页面。

Deploy watchdogs and internal burn-rate alerts default to `router_core`.
Provider-only failures are measured per provider on `/status` and
`/leaderboard`; they do not consume the router-core error budget when fallback
remains available.

部署看门狗和内部燃烧率警报默认使用 `router_core`。仅提供商故障会在 `/status` 和 `/leaderboard` 上按提供商衡量;当回退仍然可用时,它们不会消耗 router-core 错误预算。

## Public Positioning

## 公开定位

- Pricing: prepaid and BYOK usage is tracked as integer microdollars, not
  floating point dollars, so tiny token costs remain auditable in the ledger.
- Uptime target: `trustedrouter/auto` is a real chat model alias in local/test
  control-plane inference and rolls to the next configured provider on upstream
  provider failures. `trustedrouter/eu` prefers the EU-focused provider pool,
  `trustedrouter/zdr` forces a zero-retention provider floor with Anthropic
  first, and `trustedrouter/e2e` forces confidential + E2EE routes with
  Tinfoil first. Chat requests also honor OpenRouter-style `models` and
  `provider` routing filters (`order`, `only`, `ignore`, `allow_fallbacks`,
  `min_privacy`, `data_collection`, and `sort`) so clients can request explicit
  fallback chains or provider preferences. `min_privacy="confidential"` is a
  hard provider-side confidential-compute + E2EE requirement and fails closed;
  the request-value aliases `e2e` and `e2ee` select the same tier
  rather than falling back to a weaker route.
- Billing: prepaid credits and BYOK first; no subscription is required.
- Trust: hosted open source, with the running API's source commit, image
  reference, image digest, and attestation policy published at
  `trust.trustedrouter.com`.
- Signup: email signup creates a one-time management key for the workspace.
- Wallet/crypto: stablecoin checkout is wired through Stripe Checkout's Crypto
  payment method when requested. Card/default Checkout remains the default path.

- 定价:预付费和 BYOK 使用量以整数微美元跟踪,而不是浮点美元,因此微小的令牌成本在账本中仍然可审计。
- 正常运行时间目标:`trustedrouter/auto` 是本地/测试控制平面推理中的真实聊天模型别名,在上游提供商故障时会滚动到下一个配置的提供商。`trustedrouter/eu` 优先选择面向欧盟的提供商池,`trustedrouter/zdr` 强制使用零保留提供商下限并优先 Anthropic,`trustedrouter/e2e` 强制使用机密 + E2EE 路由并优先 Tinfoil。聊天请求还遵循 OpenRouter 风格的 `models` 和 `provider` 路由过滤器(`order`、`only`、`ignore`、`allow_fallbacks`、`min_privacy`、`data_collection` 和 `sort`),因此客户端可以请求显式回退链或提供商偏好。`min_privacy="confidential"` 是提供商端的硬性机密计算 + E2EE 要求,并默认失败关闭;请求值别名 `e2e` 和 `e2ee` 选择相同层级,而不会回退到较弱的路由。
- 计费:预付费积分和 BYOK 优先;无需订阅。
- 信任:托管开源,运行中 API 的源代码提交、镜像引用、镜像摘要和证明策略发布在 `trust.trustedrouter.com`。
- 注册:电子邮件注册会为工作区创建一个一次性管理密钥。
- 钱包/加密货币:在请求时,稳定币结账通过 Stripe Checkout 的 Crypto 支付方式接通。卡片/默认 Checkout 仍然是默认路径。

## Scale Target

## 规模目标

The goal is to support OpenRouter-class scale:

目标是支持 OpenRouter 级别的规模:

- 1 trillion tokens/day, or about 11.6 million tokens/second averaged over a
  day.
- 1-4 million developer accounts.
- 300+ actively routable models.
- 60+ providers.
- Global routing overhead competitive with edge-deployed routers.

- 每天 1 万亿令牌,或按一天平均约每秒 1160 万令牌。
- 100 万到 400 万开发者账号。
- 300+ 个可主动路由的模型。
- 60+ 个提供商。
- 全球路由开销与边缘部署的路由器相比具有竞争力。

The current production deployment does **not** meet that target yet. It runs
the control plane in four GCP regions behind a global LB with per-region
Serverless NEGs, with three live attested API regions until additional
attested regional pools are deployed. Capacity scales horizontally as more
attested pools come online; correctness, trust, billing, and SDK compatibility
are in steady-state.

当前的生产部署**尚未**达到该目标。它在全球 LB 后面的四个 GCP 区域运行控制平面,每个区域使用 Serverless NEG,在部署额外的经证明区域池之前,有三个活跃的经证明 API 区域。随着更多经证明的池上线,容量水平扩展;正确性、信任、计费和 SDK 兼容性处于稳定状态。

Request volume depends heavily on average generation size. At 1 trillion
tokens/day:

请求量在很大程度上取决于平均生成大小。在每天 1 万亿令牌的情况下:

| Average tokens/request | Requests/day | Average request rate |
| ---: | ---: | ---: |
| 1,000 | 1.0B | 11.6k rps |
| 2,500 | 400M | 4.6k rps |
| 10,000 | 100M | 1.2k rps |

| 平均每请求令牌数 | 每日请求数 | 平均请求速率 |
| ---: | ---: | ---: |
| 1,000 | 1.0B | 11.6k rps |
| 2,500 | 400M | 4.6k rps |
| 10,000 | 100M | 1.2k rps |

The architecture can be evolved to this scale, but only if the hot path avoids
per-request global bottlenecks. That means regional stateless gateway fleets,
regional provider pools, sharded quota leases, append-only metadata writes, and
asynchronous aggregation.

架构可以演进到这一规模,但前提是热路径避免每请求的全局瓶颈。这意味着区域无状态网关集群、区域提供商池、分片配额租约、仅追加元数据写入以及异步聚合。

## Current Latency

## 当前延迟

Measured from this development machine to the centralized GCP `us-central1`
attested API on May 2, 2026:

于 2026 年 5 月 2 日从这台开发机器到集中式 GCP `us-central1` 经证明 API 测量:

| Probe | p50 | p95 | Notes |
| --- | ---: | ---: | --- |
| Unauthenticated `/v1/chat/completions` rejection | 174 ms | 184 ms | Includes DNS, TCP, public TLS, enclave request handling. |
| TCP connect | 55 ms | 59 ms | Network path to `us-central1` from this machine. |
| TLS handshake complete | 112 ms | 124 ms | Public ACME cert terminates inside the enclave. |
| `/attestation` | 1.06 s | 1.12 s | Includes GCP attestation token generation, so not representative of normal routing overhead. |

| 探测 | p50 | p95 | 备注 |
| --- | ---: | ---: | --- |
| 未经认证的 `/v1/chat/completions` 拒绝 | 174 ms | 184 ms | 包括 DNS、TCP、公共 TLS、enclave 请求处理。 |
| TCP 连接 | 55 ms | 59 ms | 从本机到 `us-central1` 的网络路径。 |
| TLS 握手完成 | 112 ms | 124 ms | 公共 ACME 证书在 enclave 内终止。 |
| `/attestation` | 1.06 s | 1.12 s | 包括 GCP 证明令牌生成,因此不代表正常路由开销。 |

The centralized network overhead is much higher than OpenRouter's reported
edge overhead, but model latency usually dominates interactive requests. The
first production scaling step should be multi-region rather than building a
custom global edge immediately.

集中式网络开销远高于 OpenRouter 报告的边缘开销,但模型延迟通常主导交互请求。第一个生产扩展步骤应该是多区域,而不是立即构建自定义全局边缘。

## Horizontal Scale Shape

## 水平扩展形态

The production path is designed to scale by keeping the prompt gateway
stateless:

生产路径旨在通过保持提示网关无状态来实现扩展:

- `api.trustedrouter.com` instances can be replicated behind TCP passthrough.
  They authorize, reserve, and settle through the control plane, but prompt
  bytes never leave the attested path.
- Spanner stores strongly consistent control-plane and billing state: users,
  workspaces, keys, BYOK metadata, payment event idempotency, balances,
  aggregates, active reservations, and a 30-day terminal request audit window.
- Bigtable stores bounded high-volume activity metadata keyed by workspace and
  date. Activity and provider benchmarks retain 30 days, raw synthetic samples
  retain 14 days, and compact status rollups retain 24 months. Prompt, output,
  and tool-call arguments are not stored.
- API-key verification uses a high-entropy lookup hash for point reads; it does
  not scan keys.
- Rate limits are enforced before route handlers and use the configured store,
  so production counters are shared across Cloud Run instances.

- `api.trustedrouter.com` 实例可以复制到 TCP 透传之后。它们通过控制平面进行授权、预留和结算,但提示字节永远不会离开经证明的路径。
- Spanner 存储强一致的控制平面和计费状态:用户、工作区、密钥、BYOK 元数据、支付事件幂等性、余额、聚合、活动预留以及 30 天的终端请求审计窗口。
- Bigtable 存储以工作区和日期为键的有界高容量活动元数据。活动和提供商基准保留 30 天,原始合成样本保留 14 天,紧凑状态汇总保留 24 个月。提示、输出和工具调用参数不会被存储。
- API 密钥验证使用高熵查找哈希进行点读取;它不扫描密钥。
- 速率限制在路由处理程序之前强制执行,并使用配置的存储,因此生产计数器在 Cloud Run 实例之间共享。

At OpenRouter-scale traffic, the next bottleneck is not the enclave binary; it
is the synchronous billing/authorization path. The architecture needs sharded
reservations, regional Bigtable clusters, Cloud Armor edge limits, and multiple
gateway replicas before public traffic is allowed to ramp.

在 OpenRouter 级别的流量下,下一个瓶颈不是 enclave 二进制文件,而是同步计费/授权路径。在允许公共流量增长之前,架构需要分片预留、区域 Bigtable 集群、Cloud Armor 边缘限制以及多个网关副本。

## Multi-Region Plan

## 多区域计划

Multi-region is feasible while preserving the trust boundary, but it has to be
done carefully:

在保留信任边界的同时实现多区域是可行的,但必须谨慎进行:

- Run independent warm attested gateway pools in at least `us-central1`,
  `us-east4`, and `europe-west4`, then Asia once the first three regions are
  boring.
- Keep TLS private keys inside each regional Confidential Space workload.
- Move ACME from TLS-ALPN-01 to DNS-01 or another challenge flow that works
  with multiple regional endpoints for the same hostname. The current
  TLS-ALPN-01 flow is fine for one region, but a global DNS record can route
  challenges to the wrong replica.
- Keep regional hostnames such as `api-us-central1.quillrouter.com`,
  `api-us-east4.quillrouter.com`, and `api-europe-west4.quillrouter.com` for
  deterministic attestation, smoke tests, and SDK failover.
- Put `api.trustedrouter.com` behind latency/geo DNS or TCP passthrough that does
  not terminate TLS. Cloudflare orange-cloud proxying remains incompatible
  with the prompt-path trust claim.
- Authorize through regional quota leases, not a synchronous global Spanner
  transaction for every request.
- Write generation metadata to regional Bigtable clusters, then aggregate into
  global activity views asynchronously.
- Keep provider routing regional, with provider-specific circuit breakers,
  fallback policy, and per-provider rate limits.

- 至少在 `us-central1`、`us-east4` 和 `europe-west4` 运行独立的预热经证明网关池,当前三个区域稳定后再加入亚洲。
- 将 TLS 私钥保留在每个区域 Confidential Space 工作负载内部。
- 将 ACME 从 TLS-ALPN-01 迁移到 DNS-01 或其他支持同一主机名多个区域端点的挑战流程。当前的 TLS-ALPN-01 流程适用于单一区域,但全局 DNS 记录可能会将挑战路由到错误的副本。
- 保留诸如 `api-us-central1.quillrouter.com`、`api-us-east4.quillrouter.com` 和 `api-europe-west4.quillrouter.com` 之类的区域主机名,用于确定性证明、冒烟测试和 SDK 故障转移。
- 将 `api.trustedrouter.com` 放在延迟/地理 DNS 或 TCP 透传之后,不终止 TLS。Cloudflare 橙色云代理仍然与提示路径信任声明不兼容。
- 通过区域配额租约进行授权,而不是对每个请求执行同步的全局 Spanner 事务。
- 将生成元数据写入区域 Bigtable 集群,然后异步聚合成全局活动视图。
- 保持提供商路由的区域性,使用特定于提供商的断路器、回退策略和每提供商速率限制。

The key design rule: a regional outage can fail closed or route to another
attested region, but it must never silently degrade to a non-attested prompt
handler.

关键设计规则:区域中断可以失败关闭或路由到另一个经证明的区域,但绝不能静默降级到未经证明的提示处理程序。

## Router-Core Four-Nines Target

## Router-Core 四个九目标

The target is an internal SLO, not a contractual SLA. 99.99% allows about
52 minutes 36 seconds of downtime per year. Public status labels this number
as a target until at least 30-60 days of measured 99.99% router-core uptime
exists.

该目标是内部 SLO,而不是合同 SLA。99.99% 允许每年约 52 分 36 秒的停机时间。公共状态将此数字标记为目标,直到至少存在 30-60 天实测 99.99% router-core 正常运行时间。

Router-core availability means:

Router-core 可用性意味着:

- attested TLS is reachable;
- API-key validation and gateway authorization work;
- route candidates are returned and fallback can choose a healthy provider;
- settlement/refund is durable or safely repairable;
- no prompt request ever falls back to a non-attested path.

- 经证明的 TLS 可访问;
- API 密钥验证和网关授权正常工作;
- 返回路由候选,回退可以选择健康的提供商;
- 结算/退款是持久的或可安全修复的;
- 任何提示请求都不会回退到未经证明的路径。

The code paths that support this roadmap today are:

当前支持此路线图的代码路径包括:

- `/status.json` exports `slo_classes.router_core`,
  `slo_classes.control_plane`, and burn-rate alerts for 5m, 1h, 6h, and 24h
  windows.
- The deploy watchdog reads `router_core` by default, so provider-only outages
  do not automatically roll back a control-plane deploy.
- SDKs are expected to retry connection failures and 502/503/504 across
  regional attested endpoints before surfacing failure.
- Bigtable activity writes are repairable from the durable settlement outbox.
  Settlement uses deterministic generation IDs, so retries overwrite the same
  index rows and cannot double charge or duplicate activity.

- `/status.json` 导出 `slo_classes.router_core`、`slo_classes.control_plane` 以及 5m、1h、6h 和 24h 窗口的燃烧率警报。
- 部署看门狗默认读取 `router_core`,因此仅提供商中断不会自动回滚控制平面部署。
- SDK 应在表面故障之前跨区域经证明端点重试连接失败和 502/503/504。
- Bigtable 活动写入可从持久的结算发件箱修复。结算使用确定性生成 ID,因此重试会覆盖相同的索引行,不会双重收费或重复活动。

Before describing four nines as measured availability rather than a target,
require three warm GCP attested regions, tested paging, router-core chaos
tests, staged regional deploys with rollback gates, and at least 30 days of
measured router-core uptime at or above 99.99%.

在将四个九描述为实测可用性而非目标之前,需要三个热备 GCP 经证明区域、经过测试的分页、router-core 混沌测试、带有回滚门的分阶段区域部署,以及至少 30 天达到或超过 99.99% 的实测 router-core 正常运行时间。

## Internal Gateway Contract

## 内部网关契约

The attested API plane can reserve and settle usage without sending prompt or
output content to the control plane:

经证明的 API 平面可以预留和结算使用量,而无需将提示或输出内容发送到控制平面:

- `POST /v1/internal/gateway/authorize`: validates the API key hash, reserves
  credits/key limits, and returns provider/BYOK routing metadata, route
  candidates derived from `model`, `models`, and `provider` request filters,
  and configured regional endpoints.
- `POST /v1/internal/gateway/settle`: settles successful usage and appends
  metadata-only activity rows.
- `POST /v1/internal/gateway/refund`: releases reservations after provider
  failures or client disconnects.

- `POST /v1/internal/gateway/authorize`:验证 API 密钥哈希,预留积分/密钥限制,并返回提供商/BYOK 路由元数据、从 `model`、`models` 和 `provider` 请求过滤器衍生的路由候选,以及配置的区域端点。
- `POST /v1/internal/gateway/settle`:结算成功的使用量并追加仅元数据的活动行。
- `POST /v1/internal/gateway/refund`:在提供商故障或客户端断开连接后释放预留。

Set `TR_INTERNAL_GATEWAY_TOKEN` outside local development.

在本地开发之外设置 `TR_INTERNAL_GATEWAY_TOKEN`。

## Production Storage

## 生产存储

Production uses:

生产环境使用:```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 启用所需 API,创建 Spanner 表 tr_entities,创建 Bigtable 生成表,部署 Cloud Run,并将当前 GCP 信任元数据接入信任页面。

计费

当配置了 TR_STRIPE_SECRET_KEY 时,POST /v1/billing/checkout 会创建一个 Stripe Checkout 会话;否则返回确定性的本地 mock 响应。Stripe Webhook 使用 Checkout 元数据中的工作区 ID 对工作区进行幂等入账。银行卡支付立即结算。ACH 支付使用 {"payment_method":"ach"},并且仅在 Stripe 发送 checkout.session.async_payment_succeeded 后才入账;在借记处理期间完成 Checkout 不会授予任何额度。POST /v1/billing/portal 遵循相同的 Stripe 或 mock 模式进行计费管理。

对于稳定币结账,发送 {"payment_method":"stablecoin"}。当 TR_STABLECOIN_CHECKOUT_ENABLED=true 时,Checkout 会话会使用 Stripe 的 crypto 支付方式创建,并且仍然会根据已签名的 checkout.session.completed Webhook 为工作区入账。

ACH 使用 Stripe Checkout 的 us_bank_account 支付方式。默认处理费率为 0.8%,上限为 5 美元,可通过 TR_STRIPE_ACH_FEE_BASIS_POINTS、TR_STRIPE_ACH_FEE_FIXED_CENTS 和 TR_STRIPE_ACH_FEE_MAX_CENTS 覆盖。已保存卡片的自动充值仍然仅限卡片支付。