Warp 套餐怎么选？把四档折算成「每美元多少 credits」就清楚了
选 Warp 的套餐时，大多数人是这么比的：$20 那档看着够用就先上 Build，团队用就上 Business，钱多就上 Max。这个思路会让你在两个地方吃亏——一个是明明该往上买却没往上买，另一个是把 Business 当成”贵一点的 Build”，结果为了根本用不上的东西每人每月多掏三十刀。
问题出在比较的方式上。四个档位的价格和额度都是明码标价，但它们不在一把尺子上，光看”$20 给 1500、$200 给 18000”很难有直观感受。把它们统统折算成每美元能买到多少 credits，档位之间的关系会立刻变得刺眼。
读完这篇你能做到三件事：算出每档的真实单价、判断自己该待在哪一档、以及在给团队采购前避开一个会让你半年后返工的坑。
先把四档摆到同一把尺子上
Warp 定价页上的四档（截至 2026-08-08）是这样的：
| 档位 | 月付 | 年付 | 含 credits | 备注 |
|---|---|---|---|---|
| Free | $0 | — | 页面未写明 | 可按 pay-as-you-go 价格补额度 |
| Build | $20 | $18 | 1,500 | 页面标注 Recommended |
| Max | $200 | $180 | 18,000 | |
| Business | $50/用户 | $45/用户 | 1,500/人 | 最多 25 席位 |
| Enterprise | Custom | Custom | Custom |
现在做除法，用月付价算：
| 档位 | 算式 | 每美元买到的 credits | 相对 Build |
|---|---|---|---|
| Build | 1500 ÷ 20 | 75 | 基准 |
| Max | 18000 ÷ 200 | 90 | 120% |
| Business | 1500 ÷ 50 | 30 | 40% |
三个数字，三个完全不同的故事。下面逐条说。
结论一：Warp 确实有批量折扣，用量大往上买是对的
Max 每美元买到 90 credits，比 Build 的 75 多出整整 20%。换个说法可能更有体感：如果你按 Build 的单价去凑 18000 credits，需要 18000 ÷ 75 = $240；而 Max 直接给你 18000，只要 $200。省下 $40，相当于打了 83 折。
这条结论听起来像废话（买得多当然便宜），但它并不是所有工具都成立的默认规律——很多产品的高档位只是把配额堆上去，单价原地不动，甚至因为附带了一堆企业功能而变贵。Warp 在 Build 到 Max 这一跳上是真给了折扣的，所以如果你的用量已经稳定超过 Build 的 1500，不要用”买额外额度”的方式往上补，直接跳档更划算。
付费档都可以额外购买 credits，也支持自动充值（auto-reload），这功能很方便，方便到会让人温水煮青蛙：每个月自动补几次，加起来早就超过了跳档的差价，账单却因为分散在多笔小额里而不显眼。建议每季度回头看一次总支出。
年付会让这条结论更明显一点。年付价 $18 / $180 / $45 对应约 10% 折扣，折算下来 Build 是 1500 ÷ 18 ≈ 83 credits/美元，Max 是 18000 ÷ 180 = 100 credits/美元。因为两档打的是同一个折扣，20% 的差距原样保留——年付并不改变档位之间的性价比关系，它只是把整条线往上平移。
结论二：Business 买的不是额度，是团队管理能力
Business 每美元只买到 30 credits，是 Build 的 40%。这个数字第一眼看上去很离谱，但它其实说明了一件事：Business 这一档根本不是拿来买额度的。
把账拆开看更清楚。Business 是 $50/用户，每人 1500 credits——注意，这个 1500 和 Build 档的 1500 是同一个数。也就是说，同样的 1500 credits，在 Build 只要 $20，在 Business 要 $50。多出来的 $30/人/月，买的全是额度之外的东西：定价页把这一档单列出来并设了席位上限，说明它面向的是需要统一管理的团队。
$30 占 $50 的 60%。换句话说，你在 Business 上花的每一块钱里，有六毛不是买算力的。
所以判断 Business 值不值，正确的问法不是”性价比划不划算”，而是这一串：我们需不需要统一计费、需不需要集中管理成员的加入和退出、需不需要在一个地方看到谁用了多少。如果这些问题的答案都是”其实不太需要，我们就三个人，各自开各自的号，发票攒一起报销”，那 Business 的溢价对你就是纯浪费——三个人各买 Build 是 $60/月，各买 Business 是 $150/月，多出来的 $90 换不来任何多余的 credits。
反过来，如果你是一家二十人研发团队的技术负责人，每个月为了对齐十几张个人订阅的发票要花两小时，那 $30/人 可能是这个团队里最便宜的一笔管理成本。按满编 25 人算，团队功能的总溢价是 25 × $30 = $750/月，一年 $9000。这笔钱值不值，取决于它替你省掉的行政摩擦和拿到的可见性——这是一道管理题，不是一道算术题。
我要老实说一句：Warp 定价页上没有逐条列出 Business 具体包含哪些团队功能的完整清单，我也不打算凭印象替它补。采购前请自己对着官方定价页逐项核对，尤其是你最在意的那几项（比如用量可见性到什么颗粒度）。别为一个你以为它有、实际没有的功能付 60% 的溢价。
结论三：25 席位是硬顶，扩张中的团队现在就得算
Business 最多 25 席位。超过 25 人，你没有第二条路，只能谈 Enterprise（Custom 定价，也就是要走销售流程）。
这一条对两类团队完全无害：一类是常年五六个人的小组，一类是早就超过 50 人、本来就该走 Enterprise 的。真正会被绊倒的是中间那一类——现在 18 到 22 人、并且还在招人的团队。
它绊人的方式不是”到了 26 人系统不让你加”，而是时间成本。你在 20 人的时候采购了 Business，跑得挺顺，半年后团队扩到 28 人，这时候你得重新走一遍采购流程：联系销售、等报价、法务过合同、财务改付款方式。Custom 定价意味着你今天算不出明年的预算，也意味着这个流程有多长完全不由你决定。如果这件事撞上了你正忙的季度，就会变成一次纯粹的时间黑洞。
所以如果你现在 20 人上下且明确要扩张，采购前把这三个问题问一遍：
- 未来 12 个月的人数上限预估是多少？如果大概率破 25，现在就该直接去问 Enterprise 报价，而不是先买 Business 再迁移。
- 25 人是硬性席位数，不是”活跃人数”。离职的人有没有及时释放席位，会直接决定你什么时候撞到这个上限。
- 如果只是短期内有几个外包或实习生要用，能不能让他们各自用 Build 甚至 Free，把 Business 席位留给长期成员？这是最省事的缓冲办法。
怎么测出你自己的月消耗
上面所有换算都建立在一个前提上：你知道自己一个月大概烧多少 credits。而绝大多数人不知道，只有”好像不太够用”这种模糊感受。
有个笨办法很好使，两天就能出结果：
- 先记一次余额。 打开 Warp，记下当前剩余的 credits 和记录时间。
- 照常干一整天。 关键是”照常”——别因为在测量就刻意省着用，也别故意多跑几个任务。你要测的是你的日常水位，不是极限值。
- 第二天同一时间再记一次。 两个数相减，就是这一天的真实消耗。
- 乘以你真正开工的天数。 不是 30，也不是 31。你一个月真正坐在编辑器前的日子可能是 18 到 22 天，节假日、开会、出差、写文档的日子都要扣掉。用 22 天算通常已经偏保守了。
如果这一天特别不典型（比如你正好在重构一个大模块，或者正好一整天都在开会），那就多测两天取中位数，别取平均——一次异常的重构会把平均值拉得面目全非。
这里有个我核不到的点，得如实交代：Warp 的官方文档里关于用量限制的那一页（docs 里的 request-limits）在 2026-08-08 是 404，所以**“credits 余额在客户端具体从哪个入口查”我没有可靠出处，不敢瞎写路径**。请自己在 Warp 的账户或设置区域里找一下当前版本的位置。同样核不到的还有：Free 档到底给多少 credits、“什么算一次请求”的判定口径、以及 credits 的刷新周期。这三个数字定价页和文档都没写明，我不编。也正因为如此，上面这套”记余额 → 干一天 → 再记 → 相减”的测法反而是最可靠的——它不依赖任何官方口径，测的是你账户里真实少掉的那部分。
对照档位的判断路径
拿到月消耗数字后，按下面这条路径走：
| 你的月消耗 | 建议 | 理由 |
|---|---|---|
| 远低于 1500 | 先在 Free 待着观察 | Free 具体额度页面未写明，但可以按 pay-as-you-go 补，先摸清自己水位再花钱 |
| 在 1500 上下 | Build | 页面标 Recommended 不是没道理，$20 这档的单价是 75 credits/美元 |
| 稳定超过 1500 但离 18000 很远 | Build + 按需补额度 | 补额度的灵活性 > 直接跳 Max 的 $180 差价 |
| 接近或超过 18000 | 直接上 Max | 单价从 75 涨到 90，越用越省，没有犹豫的理由 |
| 团队需要统一管理 | Business（先核团队功能清单，且人数别贴着 25） | 买的是管理能力，不是额度 |
有一点要提醒：从 Build 补额度补到接近 Max 的价位时，一定要重算一次。因为 Max 的批量折扣是实打实的 20%，而”额外购买的 credits”具体按什么价格结算，定价页只写了 Free 档可以按 pay-as-you-go 的费率补，付费档的额外额度单价我没核到——所以这个临界点在哪里，得你自己拿实际账单去比，别照搬别人的经验。
顺带说一句，“用量到顶之后会发生什么”这件事，不同工具的答案差别很大，值得单独放在一起看。有的是加钱续（credits 模式基本都属于这类），有的是降速用——比如 Cursor 的快速请求用完后会掉进慢速池，代价从钱变成了等待时间，这个机制我们在Cursor 额度用完了怎么办里拆过；也有的是按周期硬性重置，只能等。选套餐时把这一层想清楚，比反复纠结哪家模型更强有用得多。如果你同时在评估多家的档位设置，GitHub Copilot 的五档套餐也可以拿来做个横向参照。
最后
Warp 这四档的定价逻辑，用一句话概括就是：纵向是批量折扣，横向是功能溢价。
纵向指的是 Build 到 Max，75 涨到 90，买得多单价确实降，用量上来了就该往上跳，别犹豫。横向指的是 Build 到 Business，价格从 $20 涨到 $50 而 credits 一动不动，多付的钱全在管理能力上——这一档不该用性价比去衡量，该用”我们团队现在有多少行政摩擦”去衡量。
再加上 25 席位这个硬顶，就构成了完整的决策图：先测出月消耗定纵向的档，再看团队规模和管理需求定横不横过去，最后确认 25 席位的上限不会在一年内撞上。
至于额度到底怎么被消耗掉、一次请求算几个 credits，Warp 官方目前没有公开口径，我也不会替它编一个。这方面唯一靠谱的做法还是那句：记余额，干一天，再记一次，相减。你自己账户里的数字，比任何人的经验都准。