Codex有ChatGPT Plus $20/月的基础档，也有按token计费的“仅限Codex”席位（无速率限制），GPT-5.3-Codex每百万输入$1.75、输出$14，GPT-6.1 Sol每百万输入$2、输出$10——订阅制和按量计费混在一起，一个5人小组到底该全员Plus还是给重度用户开Codex-only席位，月账单的失控点到底在哪？

1. 问题的重新定义：从“选套餐”到“管边际”

“5 个人，是全员 Plus 还是给重度用户开 Codex-only 席位？”这个问法本身隐含了一个错误假设：它把采购决策当成一次性选择，而混合定价的真实性质是持续性的资源调度问题。订阅档的成本是固定的、可预测的；按 token 席位的成本是随行为变化的、事后才可见的。两者混在同一张账单上，管理难度并不来自加法，而来自两类成本的时间结构不一致。

笔者把这条主线概括为边际成本可见性（Marginal Cost Visibility, MCV），并将其拆成三个可操作维度：

• 可观测性：每一次请求的输入/输出 token 是否被记录、能否按人、按项目、按任务类型聚合；
• 可归因性：一笔超支能否被定位到具体的人、具体的会话、具体的失败重试；
• 可中断性：当消耗速率异常时，是否存在自动或半自动的刹车机制，而不是等到月末对账。

本文评述：云计算的成本治理（FinOps）之所以能形成一门实践学科，前提是账单具备标签体系与近实时可见性。按 token 计费的 AI 编码席位在这一点上更接近早期的云资源——单价透明，但消耗路径不透明。因此，把“选哪个套餐”升级为“建立边际成本可见性”，不是概念包装，而是决定后续所有优化是否可验证的前提。

需要明确边界：本文讨论的是团队级采购与成本治理，不涉及模型能力评测，也不对具体厂商的定价政策做长期承诺性判断——价格表会变，但成本结构分析方法不变。文中出现的价格数值均以题目给定口径为准，凡涉及消耗量的数字，除特别说明外均为模拟数据，用于演示推导过程，不代表任何真实团队的实际用量。

2. 背景：AI 编码工具的定价谱系与混合计费的形成

2.1 三种主流定价形态

观察 2023 年以来的 AI 编码工具市场，定价形态大致收敛为三类：席位订阅制（按人按月，含使用额度或速率限制）、纯按量计费（按 token 或按请求计费，无固定费）、以及混合制（订阅含基础额度，超出部分按量，或同时提供订阅席位与按量席位）。混合制的出现有其供给侧逻辑：推理成本随上下文长度与输出长度近似线性增长，固定订阅在重度用户上会产生负毛利，而纯按量又抑制轻度用户的尝试意愿。

学术界对这类“固定费 + 边际费”结构的讨论可追溯到非线性定价（nonlinear pricing）与两部定价（two-part tariff）文献。Wilson（1993）在《Nonlinear Pricing》中系统讨论了固定费与使用费组合在需求异质性下的效率与利润权衡；Mas-Colell、Whinston 与 Green 的微观经济教材则给出了两部定价在消费者异质时的经典结论：固定费提取消费者剩余，使用费逼近边际成本。本文评述：这些经典结论解释的是厂商侧定价动机，而团队侧真正需要的是反向问题——在给定价格表下，如何按成员异质性分配席位，使总支出与总产出之比最优。这两个问题方向相反，不能直接套用。

2.2 为什么“无速率限制”是一个关键变量

题目特别指出 Codex-only 席位“无速率限制”。在订阅档中，速率限制（rate limit）实际上是一种隐性的成本控制机制：它把重度用户的消耗约束在某个上限内，从而保护订阅方的毛利。一旦取消速率限制，成本控制的责任就从厂商转移到了采购方。这是一个容易被忽视的责任转移：你获得了吞吐能力，同时接管了预算风险。

从工程角度看，无速率限制意味着系统的瓶颈从“配额”变成了“预算”和“下游资源”。当模型调用不再被限流，真正的约束会出现在代码仓库的合并队列、CI 流水线、代码评审人力上。笔者在多个团队的成本复盘中观察到类似现象：模型侧放开限制后，账单上升最快的往往不是最复杂的任务，而是高频、低价值的重复调用——例如反复重跑失败的测试生成、对同一文件的多次格式化重写。这类调用在限流环境下会被自然抑制，在无限制环境下则会放大。

2.3 行业观察与可引用的公开资料

关于 AI 编码工具的采用与成本，公开资料主要集中在三类：厂商定价页与用量文档、开发者调查报告、以及学术界的实证研究。Stack Overflow 的年度开发者调查长期跟踪 AI 工具使用率；GitHub 的 Octoverse 报告披露 Copilot 的采用规模；DORA 系列报告（Google Cloud 资助）讨论了 AI 辅助对交付效能的影响。学术侧，Peng 等（2023）的 Copilot 受控实验、Vaithilingam 等（2022）的可用性研究、以及后续关于代码生成质量与安全性的实证工作，构成了可引用的基础。

笔者认为，这些研究对成本决策的直接帮助有限，因为它们大多测量的是“有无 AI 辅助”的效能差异，而非“不同计费结构下”的成本差异。真正稀缺的是带 token 级埋点的团队级成本数据，这类数据通常留在企业内部，难以公开。因此本文的成本模型刻意保持参数化：读者代入自己的实测均值即可复算，而不必依赖某个外部基准。

3. 价格表的结构化解读：两套模型、四个价格维度

3.1 把价格表还原为参数

题目给出的信息可以结构化为以下参数表。注意两个关键点：其一，输入与输出价格不对称，输出通常显著更贵；其二，两个模型的价格关系并非“强者恒贵”，GPT-6.1 Sol 的输入单价更高但输出单价更低，这会改变任务类型的最优选择。

本文评述：输出/输入比是这张表里最被低估的参数。8.0× 与 5.0× 的差异意味着：对于“长输入、短输出”的任务（如代码库检索问答、日志分析），GPT-6.1 Sol 的输入溢价（$0.25/百万）很容易被输出节省抵消；而对于“短输入、长输出”的任务（如整文件生成、大段重构），GPT-5.3-Codex 的输出单价劣势会被放大。因此“哪个模型更便宜”没有全局答案，只有按任务类型分解的答案。

3.2 单位换算与直觉校准

为避免后文数字失去直觉，先做一次校准。按英文文本约 4 字符/token 的经验比例（OpenAI 分词器文档给出的粗略估计），100 万 token 约合 75 万英文单词，相当于 10 余本中等篇幅技术书。也就是说，$1.75 的输入单价对应的是“把十几本书读一遍”的量级。单次编码会话通常在数千到数万 token 之间，因此单次调用的绝对成本往往只有几美分——失控从来不是单次贵，而是次数多。

4. 成本模型：把月账单拆成可复算的四个部分

4.1 模型定义

设团队规模为 N（本文 N = 5），成员 i 的月度订阅席位指示变量为 s_i ∈ {0,1}，按量席位的输入/输出 token 量为 I_i、O_i（单位：百万），模型选择指示变量为 m_i ∈ {Codex, Sol}。则月度总成本可写为：

C = Σ_i [ 20 · s_i + (1 - s_i) · ( p_in(m_i) · I_i + p_out(m_i) · O_i ) ] + F

其中 F 为固定附加成本（如管理工具、日志存储、代理网关），本文暂设为 0 以便聚焦。这个式子看似平凡，但它揭示了三个结构性事实：第一，订阅与按量是互斥的（同一成员不会同时计费），因此决策是离散分配问题；第二，按量部分对 I_i、O_i 是线性的，没有阶梯折扣，意味着规模不带来单位成本下降；第三，成本对输出量的敏感度是输入量的 p_out / p_in 倍，这个倍数就是后文所有优化的杠杆点。

4.2 一个可复算的模拟算例

以下为模拟数据，仅用于演示推导，不代表真实团队。假设 5 人小组的月度用量分布如下（单位：百万 token，输入/输出）：

复算过程（以 A 为例）：输入 40 × $1.75 = $70.00；输出 8 × $14.00 = $112.00；合计 $182.00。B：30 × $2.00 = $60.00；6 × $10.00 = $60.00；合计 $120.00。C：8 × $1.75 = $14.00；2 × $14.00 = $28.00；合计 $42.00。D：3 × $2.00 = $6.00；1 × $10.00 = $10.00；合计 $16.00。E：2 × $2.00 = $4.00；1 × $10.00 = $10.00；合计 $14.00。

若全员 Plus：5 × $20 = $100/月。若全员按量：$182 + $120 + $42 + $16 + $14 = $374/月。若 A、B 走按量，C、D、E 走订阅：$182 + $120 + $60 = $362/月。若仅 A 走按量：$182 + $80 = $262/月。可以看到，在这个模拟分布下，“全员 Plus”最便宜，但这是以牺牲重度成员的吞吐能力为代价的——Plus 档的速率限制会直接约束 A、B 的可用性。因此成本比较必须与产出约束联立，不能单看账单。

4.3 成本结构的可视化直觉

把上述模拟数据画成堆叠条（用 HTML 模拟，非图片）：

笔者认为，这张对比图最重要的信息不是“全员 Plus 最省”，而是成本曲线的斜率在重度成员处急剧变陡。A 一人的按量成本（$182）就超过了全组订阅成本（$100）的 1.8 倍。这意味着团队的成本风险高度集中，少数几个重度用户决定了账单的量级。治理资源应当优先投向这部分人，而不是平均分摊到全员。

5. 盈亏平衡推导：重度用户的临界点在哪里

5.1 单成员临界条件

对单个成员，订阅与按量的成本相等条件为：

p_in · I + p_out · O = 20

但这里有一个常被忽略的约束：订阅档存在速率限制，按量档没有。因此临界点不能只按成本算，还要按可用吞吐算。设订阅档在高峰期可用的有效吞吐为 T_sub（token/小时），按量档为 T_pay，且 T_pay > T_sub。若成员的实际需求吞吐 T_need > T_sub，则即使成本上订阅更便宜，订阅也不是可行解——它会造成等待、重试和上下文切换，这些隐性成本往往超过价差。

代入 Codex 价格，若假设输出占比为 r = O / (I + O)，则总 token 量 T = I + O 的临界值为：

T* = 20 / [ p_in · (1 - r) + p_out · r ]

对 GPT-5.3-Codex，当 r = 0.2（典型编码任务，输出占比约两成）时，分母为 1.75 × 0.8 + 14 × 0.2 = 1.4 + 2.8 = 4.2，T* ≈ 4.76 百万 token/月。对 GPT-6.1 Sol，分母为 2.0 × 0.8 + 10 × 0.2 = 1.6 + 2.0 = 3.6，T* ≈ 5.56 百万 token/月。当 r = 0.5 时，Codex 分母为 1.75 × 0.5 + 14 × 0.5 = 7.875，T* ≈ 2.54 百万；Sol 分母为 2.0 × 0.5 + 10 × 0.5 = 6.0，T* ≈ 3.33 百万。

本文评述：这个推导给出了一个反直觉的结论——输出占比越高，订阅越划算。因为输出单价是输入的 5–8 倍，高输出占比会迅速推高按量成本，使订阅的固定费显得便宜。反过来，如果团队的主要用法是“大上下文检索 + 短答案”，按量成本的增长会慢得多，订阅的性价比反而下降。因此“重度用户”不能只按调用次数定义，必须按输出 token 占比细分。

5.2 团队级临界面

把单成员条件推广到团队，决策变量是分配向量 s = (s₁, …, s_N)。在无吞吐约束时，最优解是逐成员比较：若成员按量成本 > $20 且订阅吞吐足够，则订阅；否则按量。但在有吞吐约束时，问题变成带约束的整数规划，且约束是软约束（等待时间可被容忍到某个阈值）。实践中不必求解精确最优，只需按以下优先级排序：

1. 识别吞吐需求超过订阅上限的成员，强制走按量（可行性优先于成本）；
2. 对其余成员，按“按量成本 / $20”的比值降序排列，比值 > 1 的优先考虑按量；
3. 对边界成员（比值在 0.7–1.3 之间）保留订阅，因为按量的波动性会带来预算不确定性；
4. 每季度用实测数据重跑一次排序，而非一次性定死。

6. 失控点解剖：六类可观测的账单放大器

回到文章标题的问题：“月账单的失控点到底在哪？”笔者认为失控点不是某个单价，而是六类可观测的行为模式。每一类都对应可埋点、可告警的指标。

6.1 重试风暴（Retry Storm）

当模型输出不满足格式要求（如 JSON 解析失败、测试未通过）时，自动化流水线可能触发重试。每次重试都会重新发送完整上下文，导致输入 token 成倍增长。若重试逻辑没有指数退避与次数上限，单次任务可能产生 5–10 倍的成本。可观测指标：单任务重试次数分布、重试请求的输入 token 占比。

6.2 上下文膨胀（Context Bloat）

编码助手通常会把整个文件、相关依赖、历史对话一并塞入上下文。随着会话变长，每轮请求的输入 token 线性增长，而输出可能只有几十 token。这类“长输入、短输出”的模式在按量计费下极其昂贵，因为输入虽便宜但量大。可观测指标：每会话平均输入 token 与轮次的相关性。

6.3 模型错配（Model Mismatch）

把简单任务（格式化、重命名、注释生成）交给高价模型，是常见的隐性浪费。按题目价格，若某任务用 Sol 而本可用 Codex，且任务以短输出为主，则输出单价从 $10 升到 $14，单位成本上升 40%。可观测指标：按任务类型 × 模型的价格加权成本。

6.4 缓存缺失（Cache Miss）

许多厂商对重复前缀提供缓存折扣（如提示缓存）。若团队的调用模式是“同一系统提示 + 不同用户输入”，而系统提示未被缓存，则每次都要为相同前缀付费。缓存命中率每下降 10 个百分点，输入成本可能上升数个百分点（具体取决于折扣比例与前缀长度）。可观测指标：前缀缓存命中率。

6.5 并发放大（Concurrency Amplification）

无速率限制的席位允许高并发。当多个自动化任务同时运行（如批量生成测试、批量重构），瞬时消耗速率可能远超预期。由于按量计费是事后结算，团队在当天往往感知不到异常，直到次日或月末对账。可观测指标：每小时 token 消耗的 P95 与峰值/均值比。

6.6 影子使用（Shadow Usage）

成员可能用个人账号或未纳入统计的工具完成工作，导致账单与产出无法对应。这类问题在混合计费下尤其危险，因为它破坏了可归因性。可观测指标：账单席位与代码提交/评审记录的匹配率。

7. 降本手段的边界条件：缓存、批处理与上下文压缩

7.1 提示缓存

提示缓存（prompt caching）的原理是复用相同前缀的 KV 计算结果，从而降低重复前缀的计费。其有效性依赖三个条件：前缀足够长、前缀足够稳定、调用足够密集。若系统提示每天变动，或调用间隔超过缓存有效期，命中率会显著下降。本文评述：缓存不是免费的午餐——它要求团队把提示工程从“随手写”升级为“版本化管理”，这本身有维护成本。对小团队而言，只有当同一前缀的日调用次数达到数十次以上时，缓存收益才可能覆盖管理成本。

7.2 批处理

部分厂商提供批处理接口，以更低的单价换取更长的延迟。对编码场景，批处理适合非交互任务（如夜间批量生成测试、批量文档更新），不适合交互式补全。边界条件是：任务必须可延迟、可重排、失败可重试。若任务对时延敏感，批处理省下的钱会被等待成本抵消。

7.3 上下文压缩与检索增强

上下文压缩的思路是用检索（RAG）替代全量上下文：只把相关代码片段送入模型，而非整个仓库。这在理论上能显著降低输入 token，但引入了检索质量风险——若检索遗漏关键依赖，模型输出质量下降，反而增加重试。笔者认为，压缩的收益需要按“净成本”评估：净成本 = 压缩后调用成本 + 因质量下降导致的重试成本。只有当检索召回率足够高时，净成本才为正收益。

7.4 模型路由

按任务复杂度动态选择模型，是最直接的降本手段。实现上可用轻量分类器或规则引擎：简单任务（格式化、注释、单测骨架）路由到低价模型，复杂任务（跨文件重构、架构推理）路由到高价模型。风险在于分类错误——把复杂任务误判为简单，会导致输出质量下降与重试上升。可观测指标：路由决策的准确率与误判成本。

8. 工程实践：可落地的席位策略与预算护栏

8.1 席位分配的操作路径

对 5 人小组，笔者建议采用“2 + 3 起步、按季度重估”的策略：先给 2 名吞吐需求最高的成员开按量席位，其余 3 人用订阅；运行 4 周后，用实测数据重跑第 5 节的临界条件，调整分配。具体步骤如下：

1. 第 1 周：埋点。在调用网关记录每次请求的成员、模型、输入/输出 token、任务类型、是否重试、耗时。数据落到本地表，保留 90 天。
2. 第 2 周：基线。让全员先用订阅档运行一周，记录吞吐受限的次数与等待时长，作为“订阅是否够用”的证据。
3. 第 3 周：试分配。给吞吐受限最严重的 2 人开按量席位，观察其成本曲线与产出变化。
4. 第 4 周：复算。用实测的 r 与 T 重跑临界公式，判断边界成员是否应切换。
5. 季度重估。价格表、任务结构、团队规模任一变化时，重跑上述流程。

8.2 预算护栏的三层设计

护栏的目标不是限制使用，而是把“事后惊讶”变成“事中可控”。建议三层：

预算基数建议按“上月实际消耗 × 1.3”设定，而非拍脑袋。1.3 的系数用于吸收正常波动，超过则说明结构变化，应触发复盘而非简单提额。

8.3 监控指标清单

建议至少跟踪以下 8 个指标，按周汇总：单任务平均成本、输出 token 占比 r、重试率、前缀缓存命中率、模型错配率、每小时消耗峰值/均值比、按量席位成本占比、账单与提交记录的匹配率。前四个直接对应第 6 节的失控点，后四个对应治理有效性。

8.4 拓展资源

以下资源可用于深入理解成本治理与用量优化（在新窗口打开）：

• OpenAI 提示缓存文档——缓存机制与计费口径的官方说明；
• OpenAI 批处理指南——批处理的适用场景与延迟权衡；
• FinOps Foundation 框架——云成本治理的通用方法论，可迁移到 token 计费；
• Stack Overflow 开发者调查——AI 工具采用率的公开数据；
• GitHub Octoverse——开发者生态与 Copilot 采用的年度报告；
• DORA 报告——AI 辅助对交付效能影响的实证研究；
• LLM 成本优化视频合集——工程实践分享。

9. 对比与局限：混合定价的适用边界

9.1 三种配置的对比

9.2 局限与反例

本文模型有三处明确局限。第一，它假设 token 消耗与产出线性相关，但实际存在“无效消耗”（如模型输出被丢弃、重试失败）。第二，它未纳入人力成本——若治理本身消耗工程师时间，小团队的治理收益可能为负。第三，价格表是外生变量，厂商调价会改变所有临界值，因此结论应视为方法而非数字。

反例也值得注意：若团队的任务以“短输入、短输出、高频次”为主（如代码补全），按量成本可能极低，此时全员按量反而优于订阅；反之，若任务以“长输出”为主（如整文件生成），订阅的性价比会显著上升。笔者认为，任何“一刀切”的席位建议都不可靠，可靠的只有“按实测 r 与 T 复算”的流程。

10. 结论与展望：把成本治理纳入研发基础设施

🔒 复制本站文章内容需登录并达到 L3。当前：未登录