RunAI Coder

嘿，Product Hunt，我是 RunAI Coder 团队的 Marvin。

我们做这个产品是因为在编程助手这件事上不断撞同一堵墙：它们负责生成建议，而建议之后的所有事情都得我们自己来。我们真正想要的最小工作单元是一个已合并的 PR，所以我们的产品只交付这个。你用日常英语给它一个目标，它会做规划、把工作分发给并行 worker、跑测试，然后提交一份包含 diff、测试运行记录和完整 trace 的交付物。

我们最在意的是那个最不起眼的环节：

"完成"必须是被挣出来的。一个目标只有在逐条需求对照真实证据进行审计、通过全部检查之后才会被标记为完成；任何失败的校验都会阻断完成审批，而签批门槛会阻止它擅自越过本该由你做出的决策。

这是数据账本，因为你应该要求看到它们。一周的内部 dogfooding，一个人，一台机器：968 个合并的 squash PR，首次通过率 98.8%（1,807 次交付中通过 1,786 次），单日最佳为合并 98 个 PR。

关于成本，三项叠加的杠杆能让一笔 10 美元现金充值支撑每周 8-9 次交付，而它们是三种不同性质的声明。服务商的提示缓存折扣是他们的事，不是我们的；我们在那端唯一的职责是不去破坏自己的前缀缓存。上下文压缩是我们做的，而且是有数据支撑的：基于 7,222 次生产请求，中位数 2.83x。批量与弹性调度半价是价目表上的事实，不是工程成果。我们敢于署名的是那个我们真正做出来的 5.66x，即"压缩乘以节省"，计费按官方 API 挂牌价 x1.15 收取，早期访问期间免收附加费，所以请按它恢复来规划预算。公式与样例窗口：https://run.ceo/coder/perf?lang=en

它不是什么。1,807 次交付中有 21 次首次未通过，我们也照样数进去了。压缩倍数是中位数：p10 是 2.26x，我们在两条通道上的全舰队中位数更低，分别是 2.45x 和 1.89x，所以大量工作负载的节省远低于这个标题数字。批量定价是异步的，所以交互式会话拿不到半价。说压缩不损失质量的 A/B 测试只有 10 + 18 对 SWE-bench 样本，所声称的是在噪声范围内的持平，而不是更优。大型重构仍然需要人来读 diff，这也是为什么签批是一道门槛而不是走个过场。我们把这些工程内容连同免责声明一起公开：https://github.com/RunAI-Coder/a...

免费试用包价值 25-30 美元，一次性，14 天，无需信用卡。

最后也问你一个问题：你愿意让一个 agent 在无人监督下独立完成的最小工作单元是什么？这些回答对我们的路线图影响比任何功能请求都要大。