Sentry 如何用 OpenRouter 管住失控的 AI 账单而不限制使用

Sentry 希望人人都在 AI 上做实验，这样大家可以按自己认为合适的方式使用它。几个月后，账单不断攀升，却没人说得清谁在花钱、花在哪些模型上，以及这些模型是否合适。2026 年 7 月，Sentry 将其内部 AI 使用迁移到了 OpenRouter，在三周内清理了约 500 个 Anthropic 和 OpenAI 密钥，并于 8 月关闭了对两者的直接访问。这次迁移让 Sentry 同时获得了更严格的控制和更广泛的模型访问。现在他们可以将支出追溯到具体的人或工作区，工程师无需供应商审批就能试用任何新模型。

成果

• 行业：开发者工具与可观测性
• 总部：美国加利福尼亚州旧金山
• 员工人数：约 400

Sentry 是一个应用监控平台，数百万开发者用它来查找和修复有问题的代码。它的客户几乎比任何人都更快地采用 AI 编码工具，而 Sentry 内部每个人的工作方式也是如此。他们会在新模型发布的当天就试用，并构建自己的智能体，AI 访问对所有人开放。

如今，Sentry 内部所有需要模型 API 密钥的工具都通过 OpenRouter 运行，包括 Warden——Sentry 用于代码和安全审查的智能体。客户连接的官方 Sentry MCP 服务器也是如此。

没人说得清钱花到哪里去了

在 Sentry 工作了十年、从维也纳领导其遥测团队的 Daniel Griesser 主导了公司向 OpenRouter 的迁移。他将公司早期对 AI 工具的做法形容为狂野西部。Sentry 拥有 Anthropic 和 OpenAI 的企业账户，任何人都可以创建 API 密钥，而且没有任何流程。这是有意为之。管理层希望大家多做实验，在几个月里这种安排运行良好。

麻烦始于可见性。Sentry 联合创始人 David Cramer 基于提供商自身的 API 构建了一个支出仪表盘，这项花了几天的工程后来被 Sentry 以 abacus 之名发布在 GitHub 上。在 Sentry 迁移到企业账户类型之前，它一直够用。一些报告只送来一份 CSV 格式的总支出，没有按人员或模型细分，也没有缓存命中的数据。与此同时，支出持续攀升。

一个案例显示了这些报告能隐藏多少问题。一位工程师的用量达到了每天 $3,000，因为他编码工具上的一个自定义扩展在每次请求时都破坏了提示词缓存，本应从缓存提供的 token 被按全价计费。这种情况持续了几天 Griesser 才发现，而他之所以能发现，是因为那位工程师用的是自己创建的 API 密钥。他说，如果这笔用量混在企业登录里，恐怕永远不会浮出水面。缓存恢复正常后，这位工程师的用量降到了原来的一小部分。

“我们需要做出改变，因为这样下去不可持续。我们完全不知道钱花到哪里去了，也不知道谁在花什么。”

Daniel Griesser，Sentry 工程高级总监

第二个问题是选择。在 OpenRouter 之前，Sentry 的工程师手里只有来自两家供应商的少数几个模型。想用其他任何模型，就意味着要走一遍新的供应商审批流程，而对于只想花一个下午测试某个开放权重模型的人来说，这样的流程根本不值得启动。想尝试那些模型的工程师只好使用自己的个人账户，这让使用情况完全脱离了 Sentry 的可见范围。

“通过任何其他供应商采用或随便试用任何其他模型，这种事基本上根本谈不起来。”

Daniel Griesser，Sentry 工程高级总监

人人都有一个密钥和一份预算

在选择供应商之前，Griesser 考虑过运行 LiteLLM 来管理团队访问。这是可行的，但 Sentry 得自己托管和维护它。对于管理全公司员工日常使用 AI 的方式，他们想要一个无需自己运维的方案。

Griesser 在自己的工作中早已熟悉 OpenRouter，加上有 Cramer 为这一举措撑腰，法律审查和审批进展很快。

“我们可以在 UI 里把各种东西点点设置好，然后由别人负责让它持续运行。”

Daniel Griesser，Sentry 工程高级总监

零数据留存是一项硬性要求，因此 Sentry 默认启用了该功能，另外还通过自带密钥（BYOK）的方式把路由限制在自己的供应商密钥上。各编码工具链和大多数工作区都以这种方式运行在 Sentry 现有的 Anthropic 和 OpenAI 密钥上，由 OpenRouter 负责用量归因和限额。

推广从 2026 年 7 月初开始。第一天所有人都获得了访问权限，包括工程以外的团队，而且每个人可以创建任意数量的密钥。默认情况下，每个密钥都绑定到创建它的用户。每个工作区都有一个总额上限，由 Sentry 的 CFO 批准设定，目前没有任何工作区达到上限。

把工具迁移过来是快的部分。由于 OpenRouter 提供 Anthropic 兼容和 OpenAI 兼容的端点，Griesser 说这意味着只需改三个变量，并保留工具已在用的 SDK。清理工作则花了更长时间。在大约 500 个 Anthropic 和 OpenAI 密钥中，只有约 50 个还在日常使用，Sentry 得把它们的主人逐一找出来。大部分追查工作是 Griesser 自己做的，他给每个密钥的所有者一周时间创建 OpenRouter 密钥，之后旧密钥就会被停用。整个迁移大约花了三周时间，到了 8 月，Sentry 关闭了工程师对这两个平台的直接访问，他们再也无法在那里创建密钥。

现在试用一个新模型只需改一处配置

在使用 OpenRouter 的头三个月里，Sentry 的账户用到了 147 个模型。这个计数把每个版本都算作一个独立模型，所以 Claude 和 GPT 的多个系列出现了不止一次。每当有新模型发布，比如某个 Grok 或 Gemini 3.7 版本，工程师只需把一个密钥指向它并跑一遍评估。

“过去要让一个新模型获得批准得花些时间。现在这已经不成问题了。”

Daniel Griesser，Sentry 工程高级总监

在 7 月发布于 X 的一篇帖子中，Cramer 写道，Sentry 用 Warden 和 Junior 的评估套件对 Grok 4.5 进行了基准测试，它在价格和延迟方面表现出色。在该账户上，按支出计算，Grok 4.5 成了用量最大的模型之一。

前沿模型仍然承担着 Sentry 的大部分使用量。开放权重模型占到了约 12% 的 token，其中大部分来自 Kimi K2.6，用于为 Sentry 的内部工具（包括 Warden）运行评估套件。

“人们确实试用过这些开放权重模型，在某些用例中会使用它们，因为在完成任务时它们更具成本效益。”

Daniel Griesser，Sentry 工程高级总监

GPT-5.6 Luna 是官方 Sentry MCP 服务器这类高流量工具的默认模型，它承载了该账户 30.8% 的 token，却只占模型支出的 5.2%。

团队自带工具

按 token 量计算，Sentry 账户上第二大常用编码工具是 Pi，这是 Earendil 开发的一个极简开源终端智能体，用量几乎与 Claude Code 相当。紧随其后的是 OpenCode、Codex、Cursor，以及一长串 Sentry 工程师自建的智能体，它们全都运行在同一个账户上。

“如果你使用自己的智能体框架，或者自己构建智能体，体验会非常棒。你只有一个密钥，就可以配置想使用的模型。”

Daniel Griesser，Sentry 工程高级总监

现在有 113 人拥有账户，使用范围已经超出了工程部门。Sentry 营销副总裁 Rahul Chhabria 构建了一个生产服务来运营 Sentry 的初创企业计划，该服务现在运行在 OpenRouter 上。支持团队也在同一个账户上构建了自己的评估。总共有 45+ 个应用通过它发送流量。

每个请求都有归属人

Griesser 表示，迁移到 OpenRouter 并没有改变 Sentry 的支出总额。由于密钥绑定到用户或工作区，每个请求都关联到一个归属人和一个模型，通常还关联到发送它的工具。任何工程师都可以点击自己的用户名，查看自己的花费。

异常支出在仪表盘中一目了然

Griesser 大约每两周浏览一次仪表盘。九月下旬，他发现 Sentry 的 Tools 工作区中有一个密钥产生了 8,000 美元的使用量。这个密钥的归属人不对——是一名工程师为别人拥有的工具创建的。Griesser 将其重命名并改成了工作区密钥。密钥可以在工作区之间转移，或从个人转移到工作区，无需重新生成 token，因此不需要重新部署任何东西。

Sentry 现在为默认工作区中的每个人设置了每周 1,500 美元的预算，每个工作区也有各自的上限。这些限制就是它防范支出异常的护栏。当密钥达到限额时就会停止。要么本人会来询问原因，要么触发通知，问题随之被上报。

“以前，一名工程师或一个用户很容易就把我们的整体 AI 账单搞爆，因为没有任何控制、没有护栏，也没有兜底机制。”

Daniel Griesser，Sentry 工程高级总监

管理层不再为意外支出提心吊胆

对 Sentry 的工程管理层来说，这些限制为意外账单设了上限。当被问到会对同样考虑这一举措的其他工程负责人说些什么时，Griesser 的回答很简短。

“采用它，然后别再回头。它解决的都是你根本不想花时间去操心的问题。”

Daniel Griesser，Sentry 工程高级总监