Zed 该自带密钥还是买订阅？三档里有两档支持 BYOK
Zed 的三档里，有一个容易被忽略的结构性选择：编辑器的钱和模型的钱，可以分开付，也可以一起付。
| 档位 | 月价 | 模型费用怎么走 |
|---|---|---|
| Personal | $0 | 自带 API 密钥（BYOK） |
| Pro | $10/月 | 预置 $5 token 额度，超了按 API list price + 10% |
| Business | $30/席位/月 | 按使用计费，或自带密钥直接付给供应商 |
三档里有两档明确支持 BYOK。 这不是边缘功能，是一条正经的路线。
一、两条路的成本结构
走订阅（Pro）
你付的：$10 月费 + 超出 $5 之后的部分（供应商标价 × 1.1）
你得到的：无限编辑预测 + 不用管密钥和账单
成本可预测性：月费固定，超额部分要按用量估。注意超额是滚动扣的——官方原文是「每产生 $10 超额就扣一次，或月底扣，谁先到算谁」，所以 $10 月费是起点不是上限。
走 BYOK（Personal 或 Business）
你付的：编辑器这边 $0（Personal）或 $30/席位（Business）+ 你直接付给供应商的模型费用
你得到的：没有加成，供应商标价就是你付的价
成本可预测性：两笔账分开，各自清楚，但要你自己去两个地方看
二、BYOK 真正的代价不是钱
省下 10% 听起来划算，但 BYOK 的代价主要不在金钱上：
你要自己管密钥。 申请、保存、轮换、防泄漏。如果同时用好几家供应商，就是好几套。
你要自己看账单。 供应商那边的用量和费用，没人替你汇总。用超了也没人提醒你——订阅制至少有个额度用完的信号。
你要自己判断故障在哪一侧。 出问题时，是模型服务的问题还是编辑器的问题？走订阅的话，你只有一个地方要问；BYOK 的话，两边都可能，得自己划界。
你要自己应对变化。 供应商调价、改模型、废弃旧接口，这些你得自己跟。
这四条的共同点是：它们花的是你的时间和注意力，不是钱。
所以判断 BYOK 划不划算，本质上是在问：省下的那 10%，值不值得你付出这些管理成本？
三、按处境对号
明确该走 BYOK 的
你已经有 API 账号，而且在用。
那 10% 对你是纯粹的浪费——你本来就在管密钥、看账单，多喂一个工具的边际成本接近零。
你同时用好几个 AI 工具。
一套密钥喂多个工具，比每个工具各买一份订阅清爽得多。而且你能在一个地方看到总消耗，不用把账单拼起来。
你的用量很大。
加成比例是相对量——用得越多，那 10% 的绝对金额越可观。
你有合规或数据方面的要求。
需要指定供应商、指定区域、或者需要模型调用的账单和日志留在自己这边。这种情况下 BYOK 往往不是选择，是必须。
明确该走订阅的
你没有 API 账号，也不想申请。
那 $10 买的是「不用管」，很值。
你的用量不大。
用量小的时候，10% 的绝对金额可能还不如你花在比价和管理上的时间值钱。
你是重度的编辑预测用户。
这一条最关键，而且跟加成比例无关。 Personal 档只给 2000 个编辑预测，Pro 和 Business 是无限。如果你靠行内补全工作，那 Personal + BYOK 这条路会被 2000 个额度卡住——BYOK 解决的是 token 那部分，不解决编辑预测。
你不想管两笔账。
尤其是需要报销的场景，一笔订阅费比「订阅费 + 供应商账单」好处理得多。
特殊：Business + BYOK
Business 档（$30/席位/月）也支持自带密钥直接付供应商。这个组合的含义是：
你买的是「编辑器 + 席位管理 + 无限编辑预测」，模型费用完全自理。
适合的团队：已经有统一的 API 账号和额度管理，想把工具费和模型费分开核算的。
这个组合的好处是账目清晰：$30 × 人数是确定的固定成本，模型消耗在供应商那边统一看。对做预算的人来说，这比「每人一份订阅 + 各自的超额」好算得多。
四、一个容易被忽略的中间选项
还有一种情况：你既有 API 账号，又是重度编辑预测用户。
这时候 Personal + BYOK 会被 2000 个编辑预测卡住，但 Pro 的 $5 token 额度对你又是多余的（你有自己的密钥）。
这种情况下 Pro 仍然可能是对的选择——因为你买的其实是「无限编辑预测」这一项，那 $5 额度只是附赠。
判断方法：把 $10 月费全部看成是买编辑预测的钱（假装那 $5 不存在），问自己「无限编辑预测值不值 $10 一个月」。
- 值 → 上 Pro，token 那块用不用它的额度都行
- 不值 → Personal + BYOK，接受 2000 个的限制
五、先用两周试用测
Zed 的 Pro 有 2 周免费试用，含 $20 token 额度（比月费里包含的 $5 还多）。
用这两周同时测两件事：
测编辑预测的依赖度。 刻意重度用一段时间行内补全，感受一下自己有多依赖它。这决定了 2000 个够不够、无限值不值。
测 token 消耗速度。 看 $20 消耗得多快，推算月消耗。超出 $5 的部分乘以 1.1，就是走订阅时的超额支出；拿这个数字跟你直接从供应商买同样用量的价格比，就知道那 10% 值不值。
两周结束时，你手里会有两个数字，足够做决定了。
六、BYOK 之后，故障排查会变复杂
这一条值得单独展开，因为它是最容易被低估的代价。
走订阅时，出了问题你只有一个地方要问。走 BYOK 之后，链路变成了：
你 → 编辑器 → 你配的供应商 → 模型
中间多了一环，而报错通常只反映最外层的表象。你会遇到那种「报错说连接失败，但不知道是编辑器的问题还是供应商的问题」的情况。
几个能快速划界的对照实验（这套方法对所有 BYOK 类工具都适用）：
换一个模型试。 换了就好，说明是那个模型或它的额度有问题，跟编辑器无关。
换一个供应商试。 比如从中转服务换成官方直连（或反过来）。换了就好，说明问题在那个接入层。
在编辑器之外验证密钥。 用 curl 直接调一次那个供应商的接口。通了说明密钥和网络没问题，问题在编辑器这边；不通就先去修供应商那边。 这一步是整套排查里最有价值的分界线。
看报错措辞里的线索。 如果报错里出现 Cannot read properties of undefined 这种 JavaScript 运行时错误的措辞，那是程序内部解析响应时崩了——通常意味着供应商返回了编辑器没预料到的结构，而不是你的配置写错了。这种情况下反复改配置是白费力气。
记下你的完整链路：编辑器版本 + 供应商 + 模型 + 接入方式。出问题时这四样就是你做对照实验的坐标。
把这些算进 BYOK 的成本里——不是说不该走 BYOK，而是说决定之前要知道自己接下了什么。
七、总结
- Zed 三档里有两档支持 BYOK（Personal $0、Business $30/席位），这是一条正经路线不是边缘功能。
- BYOK 真正的代价不是钱，是管理成本：自己管密钥、自己看账单、自己划故障边界、自己跟供应商变化。
- 该走 BYOK 的：已有 API 账号、同时用多个工具、用量大、有合规要求。
- 该走订阅的：没有也不想要 API 账号、用量不大、重度编辑预测用户、不想管两笔账。
- BYOK 不解决编辑预测的额度问题——Personal 那 2000 个的限制跟你有没有自己的密钥无关。
- Business + BYOK 是团队的清晰选项：固定成本（$30 × 人数）和模型消耗分开核算。
- 两周试用能同时测出两个数字：编辑预测的依赖度、token 的消耗速度。有这两个数就够做决定了。
本文数字来自 Zed 官方定价页，核对日 2026-08-08。定价与计费机制会调整，以官方页面为准。本文不提供任何供应商的模型单价，请以各供应商官方定价页为准。