1000万免费token够用吗？先算清每个PR烧多少

“我们的AI通道是免费的，为什么感觉还是很贵？”一位平台负责人在冲刺期发来这句话。问题不在通道本身，而在于没人把“免费”换算成她团队真正用来做预算的单位——合并的PR（Pull Request，代码合并请求）。

这个换算就是全部。如果你说不出免费额度能覆盖多少个合并PR，你手里就没有容量规划，只有一种感觉。

MonkeyCode的运营方给出了两个与决策相关的说法：免费模型访问，含1000万免费token；以及一个免费服务器选项。该项目也被描述为开源。配额的具体机制、有效期和公平使用规则尚未经过审计，在围绕它做规划之前，这些都应当在自己的账户里核实。

免费额度改变的是成本曲线的形状，而不是成本曲线是否存在。额度线以下，边际成本为零；越过这条线，要么付超额费用，要么自己拥有硬件。这是两种不同的生意，失败的方式也不一样。

第一步：测量每个合并PR消耗多少token

不要按席位算，不要按人天算，要按合并PR算。席位会掩盖空闲时间，人天会掩盖返工。

这里要用中位数而不是平均值，因为平均值会说谎。智能体会话有长尾——一个失控的循环就能把平均值翻倍，而中位数几乎不动。用中位数做规划，用p90（第90百分位）做最坏情况的门槛。如果中位数和p90相差超过3倍，说明工作流里存在无界循环，任何定价模型都救不了。

第二步：把额度换算成PR数量

这是一次除法，也是整个练习里最有用的数字：用额度token除以每个合并PR的token中位数。

按每个合并PR消耗45000个token的示例值计算，1000万token大约覆盖222个合并PR。这算宽松还是紧张，完全取决于你的团队——这个数字在遇到你的冲刺看板之前没有意义。

真正决定事情的问题是：我的试点需要超过约200个合并PR才能得出站得住脚的答案吗？如果是，你测的就不是免费通道，而是在把超额路径当成试点来测。

第三步：找到自建的盈亏平衡点

反直觉的地方在这里：自建几乎从不在token单价上取胜，它赢在控制权。把算术摆出来比直接下结论更有说服力。

按示例输入计算：每个合并PR消耗45000个token，额度用完后每百万token收费0.40美元，机器每月192美元（160小时×1.20美元/小时），运维每月6小时、每小时人力成本85美元。结果是每月约39000个合并PR才能证明自建划算。

每月39000个合并PR，那不是一支团队，那是一套有野心的CI流水线。在超额价格较低时，算术给出的结论是：留在托管方案，把运维时间留给能复利的事情。

把超额价格推高，答案会移动。把每个PR的token消耗缩小3倍，门槛就抬高3倍；再加一台SRE级别的机器，门槛又翻三倍。自建的盈亏平衡点是运营纪律的滞后指标，不是一次定价事件。

三道门槛

表格是对话工具，不是客观真理。用它逼出三个是或否的答案。

• 覆盖门槛：额度除以每个PR的token中位数，要大于等于试点所需的合并PR数，并为p90长尾留出30%的余量。过不了这道门，你测的是超额费用，不是免费通道。
• 运维门槛：指名一个人负责自建路径的补丁、升级和值班，并把工时写进日历。没有明确负责人，运维工时这个输入就是虚构的，盈亏平衡数字也跟着虚构。
• 可逆门槛：两条路径各自的退出成本是多少？迁移提示词、评测和CI钩子才是真正的账单。开源在这里比价格重要得多——你能读代码、能fork、能带着走。在依赖这一点之前，自己核对实际许可证。

适配标准

选免费的托管通道，当：试点落在覆盖门槛之内，没有数据驻留约束，瓶颈是评审时间而不是token支出。多数团队落在这里，假装不是这样会浪费一个季度。

选自建，当：你需要气隙隔离或驻留绑定的执行环境、自定义权重，或者离线CI。为这些理由去做，并且明说——盈亏平衡表不会在成本上支持你。

选付费席位，当：连续两个冲刺都越过了额度，且p90已经稳定。稳定的超额是购买可预测性的信号，不是建数据中心的信号。

局限与谁该跳过

这个模型忽略了延迟、排队、出口流量、存储，以及不同模型之间的质量差异。不同供应商的token并不等价，所以永远不要跨通道比较原始计数。配额条款和价格会变动，每次续约前重跑一遍表格。

如果你没有人能负责基础设施，如果你有硬性的数据驻留要求（这个决定已经替你做完了），或者你真正的约束是评审者的注意力，那就跳过这套算法——盈亏平衡表根本不是该看的那张表。

该结束会议的问题不是“免费选项好不好”，而是：哪一个输入会翻转我的决定？对多数团队来说，是每个PR的token消耗，不是价格。测两周，争论自然消散。