跳到正文
Hacker News· mordras·· 5 天前AI 评分48

三人团队用 Claude 和 Codex 写代码后,我们停掉了哪些付费服务

What we stopped paying for after agents started writing our code

AI 导读

amaiko 三人工程团队四周合并 708 个 PR,基础设施与 AI 订阅按标价约每月 €1,500,Kubernetes 升级、CI、日志排查和代码审查大多交给 Claude 和 Codex。

正文 · AI 翻译

我们的工程团队只有三个人,而在过去四周里我们合并了 708 个拉取请求。基础设施和工具,包括 AI 订阅,按标价每月花费我们约 1,500 欧元。这些数字背后的大部分运维工作,从 Kubernetes 升级和 CI 运行器到日志分诊和代码审查,现在都由 Claude 和 Codex 完成,我们中的一个人负责指挥。这改变了哪些服务仍然值得购买。

我是 Stefan Kirsch,amaiko 的 CTO 和联合创始人。我在物理学习期间第一次接触 AI,从那时起就一直是个信徒。我已经写了 40 年代码,而且我很乐意再也不打一个分号。我曾在小型初创公司和大型企业担任 CTO,在我领导过的所有团队中,这个团队是最小也是最高效的。另外两位是 Markus Heigl,一位拥有数十年经验的资深开发者,以及 Florian Schauer,我们的资深 SRE。

价格是 2026 年 10 月的欧元标价,必要时按 1.10 的汇率从美元换算。估算值已标注。

服务器

我们在德国和芬兰租用了 16 台 Hetzner Cloud 服务器。其中 11 台在 Talos Linux 上组成三个 Kubernetes 集群:生产、用于我们工具的内部集群,以及一个小型开发集群。预发布环境是生产环境中的一个 vcluster。另外五台运行 CI。OpenTofu 负责配置服务器,ArgoCD 从 git 部署其他所有内容。

在集群内部,我们运行了许多在云账单上本来会单独列项的东西:通过 CloudNativePG 运行的 Postgres、Keycloak、NetBird VPN、用于正常运行时间检查的 Gatus、Renovate、使用 k8up 的备份,以及我们的监控。

Florian 负责所有这些,Claude 完成大部分实际操作工作,从 Talos 升级到弄清楚为什么某个发布无法进入健康状态。Claude 还通过 Hetzner API 创建服务器。它通过 shell 环境获取令牌,因此没有人需要把密钥粘贴到对话中。生产变更通过 git 和 ArgoCD 进行,任何想要在生产环境中重启、删除或同步内容的代理都需要我们其中一人的明确许可。

按今天的标价,集群部分(11 个节点、11 个负载均衡器、大约 1.5 TB 块存储和一些对象存储)每月花费约 480 欧元。

作为对比,我按相同规模在法兰克福的 AWS 上估了价:三个 EKS 控制平面、按 vCPU 和内存匹配的 Graviton 实例、11 个应用负载均衡器、NAT 网关、gp3 卷,以及假设每月 2 TB 的出站流量。按需价格约为每月 3,700 欧元,一年期 Savings Plan 为 3,100 欧元,三年期为 2,400 欧元,或者使用 x86 实例按需约 4,500 欧元。Hetzner 按需价格大约便宜八倍,与三年承诺相比大约便宜五倍。

有两个注意事项。Hetzner 的 CX 服务器使用共享 vCPU,而 Graviton vCPU 是一个完整的物理核心。我们的工作负载在共享核心上运行良好,但这一比较并非同类对比。而且 Hetzner 今年两次涨价:4 月上涨约 30%,包括现有服务器;6 月其 CPX 和 CCX 系列的新订单上涨 113% 至 176%。

我们的 Windows CI 机器运行在更昂贵的服务器类型上,因为更便宜的那种缺货,而我们最近的一笔订单收到的是 resource_unavailable。Hetzner 最便宜的产品线目前完全无法订购。我不确定 Hetzner 下周能否将我们的容量扩大三倍。

我们已经是 OVHcloud 的客户,用于备份以及我们最初的自托管模型实验。这两项都不计入本文的总数。我们的整个设置都是代码,我认为我们可以在一天左右迁移到另一家提供商。提供商只需给我们一台带 SSH shell 的服务器。Talos 和其他一切都在那之后。

监控

指标发送到 Prometheus 和 Mimir,日志通过 fluent-bit 发送到 Loki,追踪通过 OpenTelemetry collector 发送到 Tempo,Grafana 位于最上层。所有这些都运行在内部集群上,长期存储放在 Hetzner 的对象存储中。这套技术栈在六月取代了 SigNoz。SigNoz 有很多 bug 且用起来很繁琐,我们还不得不为它编写自己的 MCP 服务器。最重要的是,Claude 与 Grafana 配合得好得多。我猜这是因为 Grafana 使用和文档如此广泛,模型在训练中见过大量相关内容。

在过去七天里,这套技术栈每天摄入约 5 GB 日志和 7 GB 追踪数据,并维持约一百万个活跃指标序列。它与 ArgoCD、Forgejo 和 VPN 共享的内部集群每月服务器费用为 48 欧元。加上卷和存储桶,监控的份额远低于每月 100 欧元;这是一个估算值,因为账单上没有任何项目按工作负载拆分。

在这些数据量下,具有 30 天保留期的托管服务将花费:

每月按现状(约 100 万序列)序列削减至 10 万
Grafana Cloud Pro~€6,200~€660
Datadog~€48,000~€5,500

按我们当前的数据量,一个月的 Datadog 费用大约可以覆盖我们三个 Kubernetes 集群八年的开销。其中几乎全部都是指标序列:Grafana Cloud 每千个活跃序列收费约 5.90 欧元,而 Datadog 将 Prometheus 序列作为自定义指标计费,每百个约 4.50 欧元。日志和追踪约占 Grafana 数字中的 110 欧元。10 万那一列假设我们在迁移到托管服务之前会削减基数。我们从未开过会讨论哪些指标是我们负担得起保留的。

我们的 agent 自己读取所有这些数据。Grafana 的 MCP 服务器将 Loki、Mimir 和 Tempo 作为工具提供给 Claude,因此调试通常从 Claude 查询日志和追踪开始,而不是由我们中的某个人把摘录粘贴到聊天中。一个定时任务会遍历生产和预发布日志,按指纹对错误进行分组,并为每个新错误创建一个 issue。上面的数据量数字就是我在起草本文时通过同一连接得到的。

托管供应商也有 MCP 服务器。对我们来说,区别在于成本和数据所在位置。一个 agent 追查一个 bug 很容易运行五十次探索性查询,而我们不按查询付费。日志存储在我们的服务器上,只有查询结果会进入模型的提示中。

代码审查

CodeRabbit 的支持人员曾将我们的使用情况描述为“不正常”。我们当时使用的是 Pro+,即其当时最大的自助服务计划。在一个典型的早晨,它会审查前两三个 PR。然后我们触达了速率限制,未审查的 PR 就堆积起来。我们不合并未经审查的代码,所以它们等待,我们也等待。实际上,大约每五个 PR 中只有一个能在我们需要时得到审查。

CodeRabbit 的限制按开发者和每小时计算。三个人各自带着多个 agent,产生的 PR 和修复轮次远超其允许量。钱从来不是问题:当今最高公开计划上的三个席位每月花费略低于 200 欧元。

在 PR 打开之后再进行审查本身也有代价。每一轮修复都意味着又一次推送,这会重新触发 CI,并消耗掉每小时配额中的又一次审查。CodeRabbit 的支持平台列表中也没有 Forgejo,这反正也会在一个月后让事情结束。

如今审查发生在 PR 存在之前。当 Claude 完成一项工作后,它会在本地分支上提交,并针对它运行 Codex:

codex review --base origin/main -c model_reasoning_effort="xhigh"

Codex 使用 GPT-6.1 Sol 或 GPT-6 Astra 进行审查,始终以最高推理强度运行,绝不使用更小的模型。Claude 会逐条处理每个发现:真实的问题会被修复,错误的问题会得到书面反驳。然后 Claude 恢复同一个 Codex 会话,并要求对每个发现给出裁决:

codex exec resume "$SESSION" \
  "We addressed your findings in commit <sha>. Finding 2 is not a bug because ...
   Judge each of your findings: is it resolved? Did the fixes introduce anything new?"

这一过程会重复进行,直到 Codex 接受每一项修复或反驳,并且不再报告任何新问题。然后分支才会被推送,PR 才会被打开。

我们恢复会话,这样 Codex 仍然能在上下文中保留其先前的发现、Claude 的回答以及修复内容。全新的审查会从零开始,并且往往会再次提出那些已被反驳的发现。我们原本会在每一轮重复的规则被放入 AGENTS.md,Codex 在开始前会读取它。这些审查包含在我们的 OpenAI 订阅中。

Git 托管与 CI

GitHub 的故障曾多次导致我们的部署中断。当生产环境出现严重 bug 时,刷新 githubstatus.com 并不是我想花掉接下来一小时的方式。我们的 Actions 账单一度接近每月 900 欧元,对三个开发者来说这太多了。而且托管运行器很慢,尤其是 Windows 以及我们的 macOS 和 iOS 构建。

自托管运行器本可以在成本和速度上有所帮助,但对故障毫无作用,因为每个作业仍然依赖 GitHub 的控制平面。2025 年 12 月,GitHub 还宣布从 2026 年 3 月起对自托管运行器上的作业收取每分钟约 0.2 美分的费用,并在约 48 小时内推迟了该计划。我宁愿不要围绕一个已经试图按分钟对我自己的硬件收费的供应商来做预算。

于是我们迁移到了 Forgejo,这是由德国非营利组织 Codeberg e.V. 开发的 GPL 许可自由软件。它作为我们内部集群上的一个 pod 运行,因此其成本已经包含在服务器数字中。从 8 月起,它与 GitHub 并行运行,我们的主分支被镜像到其中;10 月 7 日,它成为我们的主要代码托管平台,并带有完整历史:分支、标签、发布以及每个保留原始编号的拉取请求。在我写这篇文章时,那还不到一周,所以六个月后再问我吧。我们的产品同事也在 Forgejo 中提交和跟踪 issue,而无需为任何人购买席位。

CI 在我们自己的机器上运行:四台 Linux 服务器,它们之间共有 24 个并行作业槽位,以及一台需要自定义安装的 Windows 机器,因为 Hetzner Cloud 没有 Windows 镜像。

我们的 macOS 运行器是办公室桌上的一台 M2 Mac mini,连接着办公室 Wi-Fi。NetBird 将它连接到其他机器,防火墙则将它和办公室网络的其余部分隔开。

这些加起来每月花费约 220 欧元,其中 Mac 按三年折旧。 GitHub 托管运行器在 Linux 上每分钟约半美分,在 macOS 上为 5.6 美分。我们四台 Linux 服务器的成本相当于每月约 21,600 GitHub Linux 分钟。

macOS 上的差异最大。分摊到三年,一台配备 M6、16 GB 内存和 512 GB 存储的新 Mac mini(不含增值税 €1,066)的成本大约相当于每月 530 分钟的 GitHub macOS 分钟数,约合每天 18 分钟。在法兰克福 AWS 上运行的一台常开 M2 Mac 每小时约 €0.95,最低 24 小时起,每月约 €700。这大约每七周就能买一台新的 Mac mini。

AI 订阅

我们每人都有两个订阅:Claude Max 20x 每月约 €180,用于开发,由 Claude Code 负责实现;以及 ChatGPT Pro 每月约 €90,用于通过 Codex 进行审查。这相当于每人约 €270,整个团队每月约 €820。我们在编码方面没有按量计费的 API 支出,而且在我通常同时运行五到九个代理的情况下,限额一直够用。

这种分配遵循工作负载,因为实现消耗的 token 远多于审查。我希望有第二个模型家族来检查 Claude 的工作,同时保留两家供应商,这样如果其中一家更改条款,我们还有地方可以转移工作。这种情况已经发生过一次:在 9 月的 DevDay 上,OpenAI 推出了约 €450 的 Pro 层级,并降低了同样价格的 €180 层级所包含的使用量。我们的 €90 套餐没有受到影响。

条款变化是真实存在的风险,因为订阅价格远低于 API 价格。ccusage 会按 API 标价对本地 Claude Code 和 Codex 日志进行计价。在过去 30 天里,我自己的使用量在 Claude Code 上约为 €9,000,在 Codex 上约为 €680,而订阅费用分别为 €180 和 €90。我不指望这样的价格能持续下去。

人员配置

没有代理,上述方案就需要人手:一个平台团队来运行它,或者托管服务加一个较小的平台团队。作为对比,我估算托管路线的成本约为每月 €5,000 到 €5,400,还不包括 macOS 和 Windows CI。我们 €820 所覆盖的一切,从编写和审查代码到运行平台和阅读日志,都将由人来完成。问题是用多少人。

在过去四周里,我们三个人在两个代码库中合并了 708 个拉取请求,这不包括机器人、发布 PR 或自动配置。也就是每周 177 个,或每人约 59 个,所有人都按正常的 8 小时工作日工作。其中 511 个在应用程序代码库中,每周 128 个。

LinearB 的 2026 年基准将每个 PR 超过 228 行更改评为“需要改进”。我们在应用代码库中的中位数是 548,包括测试和五种语言的翻译(第 25 百分位为 180,第 75 百分位为 1,523)。

作为基线,DX 测量出不使用 AI 的开发者每周合并 PR 的中位数为 1.4,每日使用 AI 的为 2.3,而频繁使用 Claude 的用户约为 4。LinearB 将每周超过 2 个视为精英水平。

把 PR 数量换算成人员编制很粗糙。为了压低数字,我只统计了应用代码库,与每周 2 个 PR 的精英开发者相比,这远高于 1.4 的中位数,并且忽略了我们 PR 的规模。这样算下来,我们的应用代码库的合并率大约相当于 64 名这样的开发者。然后我除以一个折扣系数,以弥补 PR 数量所遗漏的一切,并增加一名平台工程师来运行托管服务:

折扣系数建模团队超出我们 3 人的人员每月额外薪资
2×~3330~€255,000
3×~2219~€160,000
5×~1411~€94,000
10×~74~€34,000

薪资一栏假设每位高级工程师每月约 €8,500,这是德国正常的高级薪资加上雇主的社会缴款,不包括招聘、设备或管理成本。我们自己的薪资也在这个范围内。

协调完全不在模型里。一个 22 人的团队要花真实时间开会、让所有人保持同步,以及做人员规划。我们每两周做一次回顾,并定期开一次关于工具链的会议。其他事情出现时就开个短会。

我会选 3× 那一行。这是关于一个合并的 PR 代表多少实际工作的判断,你完全可以选另一行。按 3× 算,模型得出大约 22 人,每年额外工资约 190 万欧元,而我们订阅每年约 9,800 欧元。10× 那一行仍然是一个约 7 人的团队。

每月成本,使用 3× 那一行:

每月我们建模团队
人员3~22
服务器Hetzner,约 €480AWS,约 €3,700(采用 3 年计划约 €2,400)
CI自有 Linux、Windows 和 Mac 机器,约 €220GitHub 托管的 Linux,按假设 10% 利用率约 €570,外加 macOS 和 Windows 分钟数
监控自托管,计入服务器账单Grafana Cloud,精简基数后约 €660
Git 托管和议题Forgejo,计入服务器账单GitHub,约 €80(Team)到约 €420(Enterprise)
代码审查Codex人员,计入人数
AI€820无
工具和基础设施~€1,500约 €5,000 到 €5,400,不含 macOS 和 Windows CI

审查和测试

我的每个 agent 都在自己的 git worktree、自己的分支上工作,并运行自己的子 agent,所以我总是同时推进多个功能和修复。我通过它们的 PR 描述来跟进。我很久以前就不再读代码了。在这个量级上我也读不过来,而且有了我们的检查,我信任由 agent 审查的代码胜过由人审查的代码。在我做顾问的那些年里,我见过大量由一个人写、另一个人批准的烂代码。

应用仓库有以下检查:

  • 22 个 CLAUDE.md 文件,包含给 agent 的指南,每个都放在它所覆盖的代码旁边
  • 22 个项目技能,用于重复性工作,如审查门禁、议题分类、日志分类、依赖更新和发布
  • 每次变更在成为 PR 之前都经过 Codex 审查
  • 每次提交前完整构建:lint、类型检查、测试,以及复杂度、重复和死代码检查
  • 覆盖率规则:每次提交对其更改的代码都需要远高于 80% 的覆盖率
  • 3,596 个测试文件,7 月 1 日时为 1,254 个

规则很严格。我们的主分支上没有一个 linter 提示,更不用说警告了,错误更是绝对不允许。

我们在这个设置上花了几个月。早在 7 月之前我们就已经在使用 agent,随着模型和 harness 的改进,它们越来越多地自行完成工作。7 月我们每周合并约 100 个 PR;最近三周分别是 231、200 和 194。同一时期,应用仓库中 PR 的中位数从 428 行变更增长到 548 行。DX 跟踪了 400 多家公司,从 2024 年 11 月到 2026 年 2 月,它们对 AI 工具的使用平均上升了 65%。它们的 PR 吞吐量中位数上升了约 8%,DX 认为大多数组织从当前 AI 编码工具中获得的收益为 5% 到 15%。

我们刚开始时,agent 还不足以完成小步骤以上的工作。初始架构是我自己设定的,早期代码很多是我手写的。我认为这种缓慢的开始正是这套设置效果如此好的原因之一。在新项目中,我会再次在开始时放慢速度,然后再让 agent 放手去做。

在十几个需要四到八轮审查的 PR 中,某一轮发现的缺陷通常来自上一轮的修复。因此我们增加了一份书面检查清单,让智能体在提交任何修复前逐项核对:还有哪些地方必须随之修改、这个修复让哪些原本不可达的路径变得可达,以及最终的 diff 是否自相矛盾。

另外两条规则也是以同样的方式开始的。我们曾合并过一个还有五个测试分片仍在运行的 PR。我们没有把这些检查设为必需,所以自动合并就继续执行了。现在智能体通过一个小脚本进行合并,该脚本会重新检查 head commit 上的每一项检查是否都是绿色,然后精确合并那个 commit。而为修复编写的测试一直因为错误的原因通过:其中一个测试只检查某个键是否存在,而忽略了它的值。现在每个修复都会通过回滚来验证,并且只有为它编写的那些测试必须变红。

回滚率每月都保持在已合并 PR 的 0.4% 到 1.1% 之间,而每周吞吐量翻了一番。10 月到目前为止是 0.6%。

自 7 月以来,我们发生过一次严重的生产事故。9 月 11 日,一次 NestJS 升级让我们的全局速率限制器也作用于 WebSocket 消息。它对每一条消息都抛异常,所以我们的聊天应用对所有已升级到新版本的用户都停止响应了。Teams 机器人使用 HTTP,仍在继续回复,我们的定时任务也是如此。由于这些回复仍在进来,看起来一切正常,我们花了将近两个小时才发现问题。修复在发现后约 40 分钟就上线了。

预发布环境已经以同样的方式坏了两天。我们太马虎了,上线前没有在那里测试。事情顺利了一段时间,我们就放松了警惕。Claude 现在有了一个驱动我们 Web 应用的 CLI,所以它可以自行测试预发布环境。

接下来是什么

我们想在自己的硬件上运行开源模型,用于小型、边界清晰的修复,端到端无需人工介入。我们正在对此进行实验,并已有了第一批测试结果。

我们如何衡量

  • 吞吐量:git log --first-parent,统计我们三人在 2026 年 9 月 14 日至 10 月 11 日期间在两个仓库主分支上 squash 合并的 PR。机器人、发布 PR 和自动配置不计入。PR 大小是来自 --shortstat 的变更行数。
  • 监控量:我们自己的 Mimir 中 ingest 和 active-series 指标的七天平均值。
  • 价格:截至 2026 年 10 月 11 日的标价,除非另有说明,否则不含增值税,来自上文链接的供应商定价页面以及 eu-central-1 的 AWS 价格表。美元金额按 1.10 换算为欧元。
  • 基准:LinearB 的 2026 年软件工程基准报告、DX 的 2025 年第四季度和 2026 年第一季度 AI 影响报告,以及 DX 对 2024 年 11 月至 2026 年 2 月的纵向分析。
  • 按 API 价格计算的 AI 使用量:ccusage daily,基于我机器上 2026 年 9 月 11 日至 10 月 10 日的 Claude Code 和 Codex 日志。
  • 这篇文章:Claude 根据我的笔记和回答写成。Codex 分十二轮审查了它,检查事实以及听起来像 AI 写的句子。数字来自上述来源。与我们的代码相同的流程。

我们构建 amaiko,一个面向 Microsoft Teams 的 AI 同事。

来源:Hacker News · amaiko.ai