跑一个 Issue 到底花多少钱

实测数据

46 次真实交付,在我们自己的仓库上实测

Orbi 的每次交付跑两个 Agent session —— 实现,外加一个能修分支、能重跑测试的独立审查。截至 2026-09-12,我们聚合了 orbi 仓库自身 n=46 次交付(Python、完整 CI、Issue 写得规范)的 session 日志。样本就是当天磁盘上还在的 worktree —— 会随 worktree 清理而变化 —— 所以 n 是截至标注日期的快照,不是永久事实。下面是按次统计的 totalTokens 完整分布 —— 也就是 Provider 实际计费的口径,含缓存读取:

数据来源,任何人可按此复核:orbi-build/orbi 仓库各 git worktree 的 Agent session 日志(<repo>/.worktrees/*/.pi-session/*.jsonl),聚合于 2026-09-12。一次交付 = 一个 worktree 的 implement + review session;单次 totalTokens = 该 worktree 全部记录的 usage.totalTokens 之和;n = 日志中含至少一条 usage 记录的 worktree 数(不记 usage 的新旧 session 不计);分位用 nearest-rank。样本会随 worktree 清理而变化。token 的去向:95.9% 缓存读取、3.4% 输入、0.7% 输出。

先说清楚三条限定

这一页不承诺的三件事

• 只测了我们自己
  这是我们仓库的实测区间,不是对所有人的承诺

  Python、完整 CI、Issue 写得规范,让我们的上下文保持很短。上下文更长、测试更慢、Issue 更模糊的仓库,分布会落在别处。上面的表格是什么就是什么:我们仓库的实测区间。

• 缓存是承重墙
  95.9% 缓存读取,前提是 Provider 支持 prompt caching

  整个成本结构压在缓存命中上。换到不支持 prompt caching 的端点 —— 每个 token 都按 miss 计价 —— 同样的工作成本大约要涨一个数量级。外推之前先查你的 Provider。

• 按计费口径统计
  数字是 totalTokens,含缓存读取

  这才是 Provider 实际计费的口径。只算 input + output 会漏掉约 96% 的真实消耗,把数字做好看 —— 那恰恰是这一页反对的事。

为什么这么便宜

缓存命中单价是 miss 的 1/50,而 95.9% 的工作都是命中

每次交付都在重读同一批仓库上下文:目录树、约定、Issue、失败的测试。prompt caching 把这些重复阅读变成按 $0.003/1M 计价的命中,而不是按 $0.15/1M 计价的 miss。就这一个比值,让一整次交付 —— 实现加上能修能重跑的独立审查 —— 只要几分钱。这也是问任何 BYOK Agent 厂商时唯一诚实的问题:你的 token 里命中占比多少?你的 Provider 对命中收多少钱?