订阅与按令牌付费的临界点很清晰

当订阅方案的每次可用尝试月度成本低于完成同样已验收工作的按量成本时，订阅就比按令牌付费更便宜。听起来很明显，但大多数比较把提示次数当作单位。提示次数几乎没有参考价值。团队为已验收的功能付费，而重试、不断增长的上下文、废弃分支和最低席位数都横亘在一次提示与一个已验收功能之间。

正确的计算应从一个功能开始，而不是一条消息。估计该功能需要多少次尝试、每次失败后令牌用量如何变化，以及有多少尝试会消耗付费容量却没有产生保留的代码。然后将功能模型扩展到一个月，并应用订阅方案的实际限制。临界点是一个区间，不是通用的重试百分比，因为功能规模和上下文策略带来的影响可能超过标价。

关键单位是已验收功能

已验收功能是团队会视为完成的最小工作单元，例如已连接 API 的登录页面、带测试的计费 webhook，或能正确保存数据的移动表单。使用团队计划中已有的边界即可。如果工程师仍需修复数据模型或重写测试，再好看的初稿也不能算已验收。

对每个功能，记录直至验收所经历的尝试次数。一次尝试从模型获得足够上下文、能够提出实质性实现方案时开始，到团队接受、拒绝或改变方向时结束。像询问文件位置这类细小的后续问题，可以归入周边尝试。保持一致比建立完美分类更重要。

基本的按量成本为：

metered_feature_cost = sum(attempt_input_tokens * input_rate
                         + attempt_output_tokens * output_rate
                         + tool_charges)

使用账单上实际出现的费率。如果缓存输入、推理令牌、图像输入或工具调用的费率不同，请将它们保留为单独项。只有先根据自身用量组合计算后，才可为快速估算使用综合令牌价格。

订阅侧也需要使用同样的边界：

subscription_feature_cost = allocated_monthly_subscription_cost
                            / accepted_features_within_plan

这会立刻暴露一个常见错误。把套餐费用除以每一条对话，会让订阅显得便宜，因为失败和无关紧要的对话抬高了分母。把令牌账单只除以成功提示，会让按量使用显得便宜，因为失败被忽略了。两边都必须以已验收功能为单位。

人工修复时间应单独跟踪。它属于更广泛的构建成本决策，但只把工程师薪资混入一边，会扭曲定价比较。先比较实现等量产出的平台支出。如果其中一个选项确实持续改变审查或修复时间，再加入人工成本。

重试率会以非线性方式改变尝试次数

重试率应指一次尝试失败并需要再次尝试的概率，而不是曾经发生过任何重试的功能占比。这两个定义会得出不同预测。若每次尝试都有独立失败概率 r，成功前的预期尝试次数为：

expected_attempts = 1 / (1 - r)

20% 的重试率意味着预期为 1.25 次尝试。50% 意味着 2 次。80% 意味着 5 次。这条曲线会变陡，因为每次重试本身也可能失败。计算 1 + r 最多只计算一次重试，会严重低估棘手工作。

独立性只是一种近似。失败的尝试往往集中在需求模糊、框架陌生，或上下文中持续存在错误架构选择的情况。为了进行实用预测，请直接从样本计算尝试次数：

observed_attempts_per_feature = total_material_attempts / accepted_features
observed_retry_rate = (total_material_attempts - accepted_features)
                      / total_material_attempts

如果 40 个已验收功能经历了 68 次实质性尝试，每个功能的尝试次数就是 1.7，观察到的重试率约为 41%。这个观察比例已包含反复失败，比凭记忆重建行为更可靠。

不要把每次修改都标为失败。比如先处理模式、再处理 API、最后处理界面的计划性序列，包含多个成功阶段。只有新的尝试替换或修复了本应通过验收检查的工作时，才算一次重试。这个区别很重要：迭代是一种生产方法，重试则是返工。将两者按同一种方式定价，会惩罚有意的拆分。

预算中至少使用两个重试区间。常规功能可能接近团队中位数，而迁移、陌生集成和模糊的创始人需求会落在高重试区间。单一平均值会掩盖常常耗尽套餐上限的长尾情况。

上下文增长的成本往往高于重试本身

反复尝试的令牌数很少相等。第一次尝试可能只包含简洁规格说明和少量文件。第四次可能携带原始请求、生成的代码、错误输出、测试失败、修正内容以及更多代码库上下文。在按量计费下，除非提供商对缓存输入提供更低费率，每次重复输入都可能再次收费。

使用观察到的令牌数或倍数来建模输入增长：

input_tokens_on_attempt_n = initial_input_tokens * growth_factor^(n - 1)
output_tokens_on_attempt_n = initial_output_tokens * output_factor^(n - 1)

假设初次尝试使用 30,000 个输入令牌和 4,000 个输出令牌。如果每次尝试的输入增长 35%，输出保持不变，那么第四次尝试大约会携带 73,800 个输入令牌。五个看起来相同的聊天气泡，不会产生五张相同的账单。

指数增长适合做压力测试，但许多工具会截断、总结、缓存或选择性重新加载上下文。请测量实际使用的行为。在可行时导出令牌用量，或记录一个有代表性周内请求级别的数量。如果界面隐藏令牌数，可根据文件大小和消息历史估算上下文，然后测试低倍数和高倍数，不要假装估算很精确。

还存在分支效应。两次失败后，团队可能会开启一个新对话以清除被污染的上下文。这会降低重复输入，却增加设置令牌，并且可能丢失只存在于聊天中的决策。将重置建模为一次新的初始尝试加上固定的重新补充上下文成本：

reset_cost = repository_context + specification + accepted_decisions

这为上下文卫生赋予了价格。把每次失败都保留在同一线程中可能耗费更多令牌。每次失败后都重置则可能反复发送代码库地图和规格说明。经济的重置点取决于线程增长速度，以及跨对话是否仍保留缓存。

对订阅套餐而言，即使没有可见的令牌收费项，上下文仍然重要。大型上下文可能更快消耗用量额度、触发限流，或减少在月度套餐内完成的功能数。应将包含的用量视为容量，而不是无限免费的令牌。

用一个公式求解临界点

清晰的比较应以每月已验收功能为共同产出。定义以下变量：

• S：每月订阅总成本，包括必需席位。
• F：每月已验收功能数。
• A：每个已验收功能的预期尝试次数。
• C(A)：这些尝试的按量令牌和工具成本，包括上下文增长。
• L：订阅在达到限制或超额费用前可支持的最大已验收功能数。

在包含的容量范围内，订阅在以下条件下胜出：

S / F < C(A), provided F <= L

等价地，月度功能临界点为：

F_crossover = S / C(A)

如果团队完成的可比较功能多于 F_crossover，且仍在套餐容量内，订阅成本更低。如果完成得更少，按量使用成本更低。功能规模不同时，应按实际组合计算总按量成本，而不是将一个平均值相乘。

要专门求解重试率，可代入 A = 1 / (1 - r) 以及上下文增长的成本函数。若每次尝试成本相同，为 c，简单情况是：

S / F = c / (1 - r)
r_crossover = 1 - (c * F / S)

此快捷方法只适用于每次尝试成本大致相同的情况。如果后续尝试携带更多上下文，请针对候选重试率计算 C(A)，并找出月度按量成本首次超过 S 的费率。面对分级缓存和套餐限制，小型电子表格比强行套用封闭形式的方程更清晰。

使用一张表格，将重试率列在行中，每月功能数列在列中。每个单元格应显示 metered_monthly_cost - subscription_monthly_cost。负值表示按量计费更便宜，正值表示订阅更便宜。再增加一个容量违规标记。财务上有利却超过套餐额度的单元格，不是可用的临界点。

一个计算示例揭示隐藏变量

设想一个四人产品团队评估每席每月 $120 的订阅方案，因此套餐每月成本为 $480。这只是示例价格，并非对任何具名服务的说法。团队预计一个月完成 24 个已验收的中等规模功能。

应用团队实际的输入、缓存输入和输出组合后，其按量费率为每个输入令牌 $0.000006、每个输出令牌 $0.000018。工具费用未计入，因为团队在该工作流中不使用收费工具。首次尝试平均为 40,000 个输入令牌和 5,000 个输出令牌。每次重试时输入增长 30%，输出保持 5,000 个令牌。

在零重试时，一个功能的成本为：

40,000 * $0.000006 + 5,000 * $0.000018 = $0.33

24 个功能仅需 $7.92，因此按量计费明显胜出。在 50% 的独立重试率下，预期尝试次数为两次。按每个功能两次尝试近似计算：

attempt 1: 40,000 input + 5,000 output = $0.33
attempt 2: 52,000 input + 5,000 output = $0.402
feature total: $0.732
monthly total: $17.568

订阅仍以很大差距落后。即使是上下文增长的五次尝试，在这个例子中每个功能也只需约 $2.42，整月约为 $58。初始功能较小且令牌费率较低时，单靠高重试率无法让 $480 的套餐变得划算。

现在改变功能规模，而不是重试率。一次全代码库重构从 900,000 个输入令牌和 35,000 个输出令牌开始，输入增长 25%。按相同费率，第一次尝试成本为 $6.03。五次尝试的成本约为 $41.88。若有 24 个这样的功能，按量使用会达到约 $1,005。订阅可能胜出，但前提是其容量支持该工作负载。

在上下文增长前，等成本尝试的快捷公式可给出一个粗略阈值。设 $S = 480、$F = 24，首次尝试成本 $c = 6.03：

r_crossover = 1 - (6.03 * 24 / 480)
            = 0.6985

粗略临界点为 69.85% 的重试率。上下文增长会降低这个阈值，因为后续尝试的成本高于 $6.03。场景表应将更现实的临界点置于已测试费率之间，而不是制造虚假的小数精度。

这个例子也解释了为什么别人的重试阈值无法照搬。将初始上下文从 40,000 个令牌改为 900,000 个令牌，对决策的影响远大于失败率的小幅变化。复制方法，不要复制百分比。

席位可能抹去有利的令牌比较结果

订阅定价通常将成本绑定在访问权限上，按量定价则将成本绑定在消耗上。十个人偶尔提示的团队，即便主要用量来自两个人，也可能需要十个席位。这一差异可能让临界点超出任何现实的重试率。

根据计费席位数而不是日活用户计算 S：

S = required_seats * seat_price + fixed_plan_fees

然后将结果分配到真正需要订阅的工作上。如果设计、产品和工程团队都需要直接访问以进行审查或提示，就将他们计入。如果利益相关者只阅读导出结果，且条款允许这种工作流，就不要为他们虚构席位。席位数量由合同和实际协作方式决定。

席位利用率也值得单独计算：

seat_utilization = active_prompting_days / available_workdays

利用率低并不自动说明席位浪费。发布经理可能只在部署周使用工具，却避免了昂贵的交接问题。不过，需要许多轻度使用席位的套餐，应与具有适当访问控制的按量账户比较，而不是与两名最高用量用户的令牌账单比较。

团队扩张会形成阶梯函数。第五名新员工可能增加完整的席位费用，却只贡献一个月中部分功能产出。按量成本则随该员工的实际使用增长。应按当前人数以及承诺期内预计的人数运行模型。

年度折扣也需要同样处理。将全部承诺金额换算为月度等值，再考虑用量低的月份。不要拿折扣后的年度月均金额与高峰月的令牌账单相比。应比较年度成本和年度工作量，其中包括假期、招聘空缺和安静的维护期。

用量限制会形成第二个临界点

订阅在纸面上可能更便宜，却仍无法支撑工作负载，因为包含的容量受上限、限流或合理使用规则约束。第一个临界点是财务上的。第二个是运营上的：套餐能否在所需时间窗口内完成建模的尝试。

用提供商实际执行的单位表示套餐限制。它可能是消息数、加权请求、算力积分、令牌数，或滚动时间窗口。使用同一尝试分布将该限制换算为已验收功能：

feature_capacity = usable_monthly_units
                   / expected_units_per_accepted_feature

使用可用单位，而不是宣传的最大值。为调查、规划和偶发的严重重试链保留容量。若所有计划功能仅在每次尝试都如中位数般顺利时才装得下，这个套餐已经过于紧张。

团队越过限制时，通常会发生四种情况之一：工作等待重置、请求变慢、开始产生超额费用，或团队购买更高档套餐。将实际后果放入模型。含按量超额费用的套餐，其月度成本为：

hybrid_cost = subscription_cost + max(0, usage - included_usage) * overage_rate

硬上限需要不同的决策。如果上限阻碍交付，即使标称成本更低，该套餐也不可行。不要给它虚构一个美元价值然后宣称问题已解决，应将容量缺口与价格并列报告。

用量窗口与月度总量同样重要。发布日下午出现 40 次重试密集的尝试，可能触及短周期滚动上限，即使该月其余时间很安静。请测试最繁忙的一天和最繁忙的一周，而不只是月均值。

Koder.ai 提供免费版、专业版、商业版和企业版，因此应比较席位数和容量匹配团队的档位，而不是展示中最便宜的档位。它的规划模式、快照和回滚也可能改变观察到的重试次数，这意味着团队应测量试点结果，而不是照搬其他工作流的重试率。

不自欺地测量试点

有价值的试点会收集足够的细节，以便重现定价决策。对于稳定团队，两周可能足够，但样本必须包含常规工作以及至少几个困难功能。如果这段时间只有打磨过的演示任务，结果会低估上下文和重试。

每次实质性尝试记录一行，字段包括：

• 功能 ID 和功能规模区间；
• 尝试编号以及验收或拒绝结果；
• 输入、缓存输入和输出令牌，或套餐单位；
• 上下文重置、工具费用和已用工作窗口；
• 发起尝试的席位或人员。

在不同选项之间保持验收测试稳定。如果订阅试点中一个功能只需看一眼视觉效果就验收，而按量工作流要求通过测试，产出便不等价。试点前写下验收规则，并对两边都执行。

区分重试原因。标记需求变更、模型失败、上下文污染、工具失败和用户错误。只有部分原因会因不同定价方案或界面而改变。一项变更三次的需求会在任何地方消耗容量。快照和回滚工作流可能降低错误分支的成本，但不会让不清晰的需求免费。

结束时计算三个视角：中位数功能、高重试功能和实际月度组合。中位数反映常规经济性。高位区间测试容量。组合决定账单。应全部报告，因为单一平均数可能描述一个从未真正发生过的月份。

对不确定输入运行敏感性检查。每次单独提高功能数量、重试率、上下文增长和席位数。如果 10% 的变化就会改变选择，请协商更短的承诺期，或在团队拥有更多数据前保留按量计费。如果每种合理情况都偏向同一选项，决策就很稳定。

按工作负载形态选择套餐，而不是按理念

按令牌付费通常更适合零星使用、小型上下文、实验性团队，以及可以暂停而不造成后果的工作负载。它也提供清晰的边际价格：未使用账户几乎不会产生推理成本。代价是要承受长上下文和反复失败带来的风险，尤其是在多个智能体或工具产生隐藏请求时。

订阅适合稳定吞吐量、成本高的功能，以及能充分使用多数席位且不突破包含容量的团队。可预测性有价值，但不要把这种价值伪装成令牌节省。若订阅多花 $200，却消除了财务部门无法接受的账单波动，请将这 $200 记录为可预测性的价格。

「重试感觉频繁时就换套餐」这一流行建议是错误的。人们记得痛苦的五次尝试功能，却忘记十几个便宜的成功案例。账单按令牌加权，记忆按挫败感加权。一个月的尝试级数据可以解决这种不一致。

不要仅因订阅宣传可使用较新模型就选择订阅。模型选择只会通过其验收的工作、消耗的令牌和触发的容量规则影响成本。能力更强的模型可能需要更少尝试，但每个令牌收费更高。较便宜的模型可能成功完成小型界面改动，却在跨领域的数据迁移上耗费时间。按功能区间拆分试点，并让每个选项使用称职操作者实际会选择的模型。

同一规则也适用于智能体数量。一条可见的用户提示可能在界面背后启动规划、实施、审查和修复智能体。按量账单可能计入每个请求，而订阅可能把工作换算为加权用量单位。不要只比较两边各一条可见消息。比较完整的已验收功能，并记录每张账单或套餐所展示的消耗单位。

不确定性需要一个预算项，而不是自信猜测。对每个输入保留低值、预期值和高值。预期情况应来自试点。低值和高值应反映观察到的波动，而非任意百分比。计算三种组合，然后找出改变决策的输入。如果上下文增长会改变结论而席位数不会，更好的上下文遥测比再花一周讨论人数更有价值。

承诺期限会改变可接受的节省空间。月度套餐可以在估算临界点附近测试，因为团队很快就能退出。年度合同需要为工作负载变化留出空间。签约前设定所需的节省幅度，例如足以吸收一个较安静季度或两个空置席位的金额。这个幅度是商业选择，不是数学临界点的一部分，因此应单独展示。

税费、货币兑换和承诺消费积分属于账单层。计算原始服务消耗后，再一致地应用它们。只有团队很可能在到期前使用完的积分，才能降低成本。大量未使用积分不是节省，而是团队未能转化为已验收工作的预付容量。

最后，确定谁负责测量。如果没有人检查实际用量是否符合预测，准确的临界点模型会随着功能规模、模型、费率和人员变化而失效。定价变化、团队增加席位，或每个功能观察到的尝试次数有实质变化时，应重新审查。这是一项小型运营工作：更新输入，保留旧场景，并记录为什么该选择仍然成立或为何需要调整。

审批前，应将假设视为运营承诺。预测有 30 个已验收功能，意味着产品团队拥有足够明确的工作，审查者能够评估，且套餐能在团队工作时间内交付。如果审查容量将产出限制在 18 个功能，使用 30 会让订阅显得更便宜，却不会创造更多已验收工作。即使成本比较只覆盖平台，分母也必须反映整个交付系统。

如果提供商允许，也应测试混合计费方案。两名重度用户使用订阅，加上偶尔使用者的按量访问，可能优于全员席位和全员按量两种方案。分别计算每个群体，再相加成本。不要在应用席位费用前平均重度和轻度用户，因为这个平均值不代表任何人，也可能掩盖本可避免的席位。

采购部门有时会要求给出一个盈亏平衡重试率。请给出与明确假设关联的区间：例如，当每月已验收功能保持在两个观察值之间、上下文在测得区间内增长时，范围为 55% 到 65%。还要包含容量失效的费率。这个答案不如单一百分比整齐，却更适合发布月与维护月不同的现实情况。

续约决策中不要加入沉没成本。若团队正在决定下一个周期购买什么，已承诺的订阅费用不应让下一次按量请求看似免费。不过在当前已付费周期内，未使用的包含容量可能没有边际现金成本。请标明模型支持的是即时路由决策还是未来合同决策，因为这两个问题使用不同的成本边界。

安全性、数据位置、源代码导出、部署和回滚可能会在计算价格前决定哪些选项有资格。将这些要求视为筛选条件，而非虚构的金额调整。删除无法满足强制要求的选项。只在剩余选择中比较成本。这样可以避免低令牌报价推翻团队无法交换的约束。

也要记录被拒绝和废弃的功能。功能取消后，按量费用依然存在，而订阅会消耗无法收回的容量。将这些成本归入废弃桶，而不是悄悄分摊到成功功能中。然后再运行一个视图，将废弃成本分配给导致它的产品领域。这能揭示定价问题是否实际是规格说明问题。

金额只在展示时四舍五入。计算中应保留完整令牌数和费率精度，尤其是缓存输入和未缓存输入价格不同时。但应将临界重试率报告为区间或整数百分比。像 62.437% 这样的结果暗示输入数据并不支持的精确性。

做决策时，并列写下两个数字：每个已验收功能的成本，以及在最繁忙用量窗口内的已验收功能容量。第一个数字说明订阅与按令牌付费在财务上在哪里相交。第二个数字说明这个交点在实际中是否可用。只要其中一个数字缺失，电子表格描述的就是价格，而不是你的生产工作负载。