Sentry 希望每个人都能试验 AI，这样人们可以按自己认为合适的方式使用它。几个月后，账单不断攀升，而且没有人能说清谁在为什么付费、用在了哪些模型上，或者这些模型是否合适。2026 年 7 月，Sentry 将其内部 AI 使用迁移到 OpenRouter，在三周内清理了大约 500 个 Anthropic 和 OpenAI 密钥，并在 8 月关闭了对两者的直接访问。这次迁移让 Sentry 同时获得了更严格的控制和更广泛的模型访问。他们现在可以追溯每一笔支出背后的个人或工作区，工程师无需供应商审批即可试用任何新模型。
成果
| 结果 | 详情 |
|---|---|
| ~93% | 降低失控账单的上限 |
| 约 3 周 | 用于迁移 Sentry 的内部 AI 使用 |
| ~500 | 被淘汰的直接 Anthropic 和 OpenAI 密钥 |
| 45+ 个应用 | 通过单一账户运行推理 |
- 行业： 开发者工具与可观测性
- 总部： 美国加利福尼亚州旧金山
- 员工人数： ~400
Sentry 是数百万开发者用来查找并修复损坏代码的应用监控平台。其客户采用 AI 编码工具的速度几乎超过任何人，而 Sentry 的每个人都以同样的方式工作。他们在新模型发布的当天就试用，并构建自己的 agent，AI 访问对所有人开放。
如今，Sentry 每个需要模型 API 密钥的内部工具都通过 OpenRouter 运行，包括 Sentry 用于代码和安全审查的 agent Warden。客户连接的官方 Sentry MCP 服务器也是如此。
没人能说清钱花在了哪里
在 Sentry 工作十年、从维也纳管理其遥测团队的 Daniel Griesser 领导了公司向 OpenRouter 的迁移。他将公司早期对 AI 工具的态度描述为“狂野西部”。Sentry 持有 Anthropic 和 OpenAI 的企业账户，任何人都可以创建 API 密钥，而且没有任何流程。这是刻意为之。领导层希望人们进行试验，在几个月里这种安排运转良好。
麻烦始于可见性。Sentry 联合创始人 David Cramer 在供应商自己的 API 之上构建了一个支出仪表板，这是几天的工作量，Sentry 后来将其发布在 GitHub 上，名为 abacus。它一直运行良好，直到 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 批准的预算总额上限，目前没有任何工作区达到其上限。
迁移一个工具过来是很快的部分。Griesser 说，由于 OpenRouter 提供 Anthropic 兼容和 OpenAI 兼容的端点，这意味着只需修改三个变量，并保留该工具已经在使用的 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 将 Grok 4.5 与 Warden 和 Junior 的评估套件进行了基准测试，它在价格和延迟方面的表现良好。在该账户上，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 大约每两周浏览一次仪表板。在9月下旬，他发现 Sentry 的 Tools 工作区中一个密钥产生了8,000美元的使用量。该密钥的归属人设置错误：一位工程师为别人拥有的工具创建了它。Griesser 重新命名了它并将其转为工作区密钥。密钥可以在工作区之间移动，或从个人转到工作区，而无需重新生成 token，因此无需重新部署任何内容。
Sentry 现在在其默认工作区中为每人设置每周1,500美元的预算，每个工作区都有自己的上限。这些限制是它防止支出异常的保障措施。当密钥达到其限额时，它会停止。要么当事人询问原因，要么触发通知，问题随之被上报。
“以前，一个工程师或一个用户很容易就能让我们的整体 AI 账单爆掉，因为没有任何控制、没有保障措施、也没有兜底机制。”
Daniel Griesser，Sentry 工程高级总监
管理层不再为意外而严阵以待
对 Sentry 的工程管理层来说，这些限制为意外账单设置了上限。当被问及他会如何建议另一位考虑同样举措的工程负责人时，Griesser 的回答很简短。
“采用它，不要回头。它恰好解决了那些你根本不想花时间去处理的问题。”
Daniel Griesser，Sentry 工程高级总监