顶级AI烧钱榜：OpenAI月付130万美金账单背后的Token成本解析

是的，你没看错。

“龙虾之父”Peter Steinberger最近披露，他单月在API token上的花费，竟然超过了130万美元。

具体数据令人咋舌：30天内总计消耗了6030亿token，处理了760万次请求。

消息一出，立刻在开发者社区炸开了锅。有网友直言不讳地评论：“雇一支完整的开发团队，成本可能都比这低。”

质疑声紧随其后。另一位网友追问道：“老兄，你最好真能做出点那些百万美元年薪工程师都搞不定的东西。否则，这恐怕要成为前沿AI实验室泡沫破裂的第一个信号了。更何况，这还只是补贴后的价格，实际成本恐怕要高得多。”

面对质疑，Steinberger的回应相当淡定。他解释说，只要关掉“快速模式”，成本立刻能下降70%，这样算下来，“也就相当于一个员工的薪水”。

当然，也有更尖锐的嘲讽：“一个月烧掉130万美金，结果啥实际产品都没交付？你这简直是史上最失败的营销案例。” Steinberger则回击道：“这取决于你怎么定义‘交付’。你的定义恐怕有点特别。”

那么，这笔巨款到底花在了哪里？Steinberger随后详细阐述了他的“AI驱动开发”实践。他透露，大部分代码由Codex生成，而那些比较杂乱、后来需要整理的拉取请求，则可能出自Claude之手。

在引发广泛讨论后，Steinberger很快给出了更系统的解释。他声称，这一切都是为了探索一个核心问题：

如果Token成本不再构成约束，未来的软件将如何构建？

他的团队正在进行的，是一场全方位的自动化实验：

他们长期在云端运行着大约100个Codex实例，审查每一个拉取请求（PR）和问题（Issue）。一旦主分支合并了一个修复，专门的智能体（@clawsweeper）就能自动定位到那些挂了半年之久的旧问题，并引用相关提交将其关闭。

每次代码提交都会触发Codex进行安全检查，因为人工太容易遗漏安全漏洞。

利用Codex对Issue进行去重和聚类分析，自动生成最紧迫问题的报告。

部署能复现复杂环境的智能体，它们可以启动临时测试机器，登录Telegram等平台录制视频，并在PR中直接发布修复前后的对比证据。

还有一些Codex负责监控新提交的Issue。如果其内容符合既定的产品愿景，它们会直接自动创建修复PR，然后由另一个Codex实例来审查这个新生成的PR。

甚至用Codex来扫描评论区的垃圾信息，并自动封禁相关用户。

运行Codex实例来验证性能基准测试，一旦发现性能回归，便自动报告到Discord频道。

更有智能体直接旁听团队会议，并主动开始工作。例如，当会议讨论到某个新功能时，它们能在讨论过程中就实时创建出对应的PR。

他们还构建了clawpatch.ai，将项目拆分为功能单元，用于审查、发现Bug和回归问题。在安全方面也采用了类似架构，结合Vercel的deepsec和Codex Security来发现安全漏洞和回归。

这一整套自动化流水线，使得他们能够以极其精简的人力团队来运营整个项目。

说到这里，问题来了：如此惊人的开销，究竟由谁承担？答案出乎很多人意料。

Steinberger轻描淡写地表示：“OpenAI并没有向我收取这些token的费用。”

Tokenmaxxing：这场吞吐量竞赛的终局何在

Steinberger的案例，无疑将“Tokenmaxxing”这场竞赛推向了新的高度。

所谓Tokenmaxxing，即最大化token使用量，此前已在AI圈内引发热议。Meta、亚马逊等科技巨头甚至公开了内部的token消耗排行榜，将使用AI工具、消耗token变成了员工事实上的KPI之一。

在当时，Meta内部排名第一的用户平均消耗了2810亿token，根据不同模型的定价，其背后可能是数百万美元的成本。而Peter Steinberger单月6030亿token的消耗量，无疑是对这一数据的“降维打击”。

前特斯拉和OpenAI科学家Karpathy也在播客中坦言，感受到了最大化使用AI的压力。“关键在于token，”他说，“你的token吞吐量是多少？你能调动多少token吞吐量？”

这指向一个清晰的趋势：Token正在成为一种新的、核心的生产资料，甚至演变为衡量AI运转密度和团队产能的单位。一个团队只要拥有足够高的token吞吐量、精巧的任务拆分流程以及可靠的验证闭环，就有可能实现过去需要大型团队才能支撑的工程密度。

就在近日，OpenAI总裁Greg Brockman也发推印证了这一观点：“Token正在迅速成为解决问题的通用输入。”

然而，值得深思的是，token竞赛绝非简单的“以量取胜”。如同Steinberger所演示的，关键在于如何将这些海量的token消耗，嵌入一个设计良好的、高度自动化的智能体工作流与项目管理模式中。这或许才是决定未来软件开发效率的决胜关键。盲目堆砌token而无视工作流优化，恐怕只是另一种形式的资源浪费。