搜索“Roo Code 价格”的人，通常会发现一个反差：扩展本身不收费，账单却可能比订阅制工具更高。原因不复杂——Roo Code 采用自带密钥（BYOK）模式，软件免费，模型调用按 token 付费，而编码 Agent 恰恰是 token 消耗大户。
本文不给出固定价格，因为模型单价、缓存规则和订阅额度都会调整。我们只讲清楚成本结构、计算方法和控制手段，具体费率以站内模型价格和各产品官网为准。
说明：Roo Code 是其权利人的商标，Cursor、Claude、GitHub Copilot 等名称归各自权利人所有。本文仅作技术说明，与相关厂商无隶属关系。Roo Code 扩展已于 2026 年 5 月 15 日停止维护，仓库归档，社区分支 Zoo Code 延续开发；后续状态以官方仓库为准。
一、Roo Code 的收费结构：软件免费，成本在模型
Roo Code 是一款开源 VS Code 扩展，本体不按席位收费，也没有内置的模型额度。你在 Provider 里填自己的 Key，请求直接发往模型供应商或网关，费用由那边按 token 结算。它不转售 token，也不从单次调用里抽成。
要区分两个容易混淆的东西：Roo Code 扩展和 Roo Code 公司后来推出的云端产品是两套计费体系。云端产品可能有自己的订阅和额度，本文讨论的是本地扩展的 BYOK 成本。扩展停止维护后，社区分支 Zoo Code 仍沿用同一模式，因此下面的算法对两者都适用。
所以“Roo Code 价格”实际由三部分组成：模型输入 token、模型输出 token，以及缓存、推理等附加计费项。工具本身的价格是零，但你的使用方式决定了总账。
二、订阅制与按量计费的本质区别
订阅制工具把编辑器功能、Agent 能力和一定模型额度打包成固定月费；BYOK 则把软件和模型拆开，软件免费，模型用多少付多少。两者不是简单的贵与便宜，而是风险承担方式不同。
| 维度 | 订阅制 | BYOK 按量计费 |
|---|---|---|
| 付费节奏 | 固定周期，便于预算 | 随用量波动，按实际调用结算 |
| 成本上限 | 通常有套餐额度或次数限制 | 取决于 Key 限额，不设限则可能超支 |
| 模型选择 | 以产品支持的模型为准 | 可自行切换供应商和模型 |
| 闲置成本 | 不用也照付 | 不用不产生模型费 |
| 高峰成本 | 额度内不额外计费，超额受限 | 用量越大账单越高 |
| 适合场景 | 每天高频使用、追求省心 | 用量不均、需要特定模型或集中管控 |
订阅制的隐藏成本是“额度用完后怎么办”：降速、排队、限制模型，或购买加量包。按量计费的隐藏成本是“失控”：自动批准、循环重试、子任务膨胀，都可能在无人值守时推高账单。选择前先确认自己更能接受哪一种。
三、编码 Agent 的 token 到底花在哪里
聊天机器人的成本主要是“你问一句、它答一句”。编码 Agent 不是。它每一轮都要把系统提示、工具定义、模式说明、历史对话、已读文件、终端输出和差异内容重新发给模型，输入 token 会随任务推进不断累积。
一个中等复杂度的任务，产生十几次到几十次模型请求很常见。输出 token 通常少于输入，但多数模型的输出单价高于输入；如果模型支持推理或思考模式，这部分 token 也可能按输出计费。真正的大头往往不是“最后那段代码”，而是反复发送的上下文。
还有几类容易被忽略的消耗：
- 工具调用失败后的重试：命令报错、文件路径不对、补丁冲突，都会让模型重新读取和规划。
- 上下文压缩：接近窗口上限时，Roo Code 会压缩历史；压缩本身要调用模型，压缩后缓存前缀也会变化。
- 子任务与 Orchestrator：每个子任务有独立上下文，规划越细，请求次数越多。
- 长会话：同一任务聊得越久，每轮携带的历史越长，单次请求越贵。
- 缓存未命中：重复前缀没有命中缓存时，全部按普通输入计价。
因此，比较“Roo Code 贵不贵”，不能看一次问答，而要看一个完整任务的请求次数和上下文规模。
四、把账算清：公式与步骤
单任务成本可以拆成四项。把价格页的单价代入，就能得到可复算的结果：
单任务成本 =
未缓存输入 tokens × 输入单价
+ 缓存写入 tokens × 缓存写入单价
+ 缓存读取 tokens × 缓存读取单价
+ 输出 tokens × 输出单价
具体操作按下面六步：
- 选三个有代表性的任务：单文件小改、多文件功能、跨文件排错。
- 在网关控制台打开请求日志，记录每个任务的请求次数、输入、输出、缓存读取和缓存写入。
- 从模型价格页面取得当前单价，注意输入、输出、缓存写入、缓存读取可能分别定价。
- 按上面的公式计算单任务成本，再乘以每日任务数和每月工作天数。
- 加上重试、上下文压缩和子任务的额外消耗，预留一部分缓冲，不要按理想路径估算。
- 把结果与订阅方案的总价、额度、超限规则对比，而不是只比标价。
举例说明算法，不代表实测数据：假设某任务产生 40 次请求，每次平均输入 1.5 万 token，其中七成命中缓存，输出合计 8 千 token。把这三类 token 分别乘以对应单价，才是这个任务的真实成本。若你的日志里没有缓存字段，说明该通道未返回缓存明细，估算时应按全部输入未命中处理，避免低估。
五、缓存是最大的杠杆，但别神化
编码 Agent 的上下文高度重复：系统提示、工具定义、模式说明、项目规则、早期对话，在每一轮里几乎一样。支持提示缓存的供应商会把这些重复前缀存下来，后续请求按缓存读取计价，通常明显低于普通输入。
要让缓存真正生效，需要几个条件同时满足：
- 前缀稳定：系统提示、工具定义、模式说明尽量固定，不要在开头插入时间戳、随机 ID 或频繁变化的内容。
- 模型一致：缓存通常按模型隔离，中途切换模型会重新计费。
- 周期匹配：缓存有有效期，间隔太久会失效；短会话可能还没摊薄写入成本就结束。
- 通道支持：不是所有 OpenAI 兼容端点都实现缓存，也不是所有网关都会返回缓存命中字段。
- 压缩有代价：上下文压缩会改写历史，压缩后的前缀需要重新建立缓存。
实践上，先保证“同一类任务用同一个 Profile、同一个模型、同一套规则”，再谈缓存优化。把缓存当成“可能拿到的折扣”，而不是“必然节省的比例”。如果网关日志能区分缓存读取和普通输入，按真实数据核算；如果不能，就按保守口径估算。
六、预算上限：把“省”变成可控
按量计费最大的风险不是单价，而是没有刹车。控制成本要从网关和客户端两头做。
网关侧：为每个成员、每个项目建立独立 Key，设置日额度和月额度，开启用量告警；如果平台支持模型白名单，限制每个 Key 可调用的模型；定期导出用量，按成员、项目、模型三个维度核对。这样即使某个任务失控，损失也被限制在单把 Key 的额度内。
Roo Code 侧：用 API Configuration Profiles 给不同 Mode 绑定不同模型，规划用强模型，问答和批量修改用轻量模型；给高消耗 Profile 设置 Rate Limit，限制两次请求的最小间隔；谨慎使用自动批准，尤其是会执行终端命令、删除文件或安装依赖的操作；为 Orchestrator 单独规划 Profile，因为子任务会继承父任务的配置并在整个生命周期内保持。
习惯侧：把大任务拆成可验证的小步，及时结束无关会话；不要在一个会话里同时做重构、排错和写文档；发现模型反复失败时先停手，检查工具调用和文件路径，而不是让它继续重试。Checkpoint 能帮你回滚代码，但不会退还已经消耗的 token。
七、什么时候订阅更划算，什么时候按量更省
没有一种模式对所有团队都更便宜，只有匹配不匹配。
订阅制更适合：每天都用、任务量稳定、不想管理 Key、能接受产品限定的模型和额度。它的价值是把成本变成固定项，省掉预算和审计工作。但如果经常触顶、需要额外加量，或团队里有人几乎不用却占着席位，实际单位成本会上升。
BYOK 更适合：用量波动大、需要特定模型、希望统一走网关、需要按成员和项目看账。它对“轻量使用”更友好，不用时为模型付零；但对“高频重度使用”不一定便宜，尤其是长上下文、多子任务的 Agent 工作流。
混合方案也常见：日常编辑用订阅制工具，批量重构、自动化脚本、特定模型任务走 BYOK。这样既保留固定成本的便利，又保留按量计费的灵活性。需要注意的是，Roo Code 已停止维护，迁移到 Zoo Code 或其他工具的时间成本，也应计入总成本。
八、用 30 天做一次真实验证
不要凭感觉切换计费模式。用一个月跑一轮小范围对照：
- 第 1 周：保持现状，只记录三个代表任务的 token 和请求次数，建立基线。
- 第 2 周：固定系统提示和模式配置，减少模型切换，观察缓存命中是否改善。
- 第 3 周：给 Key 加额度和告警，给高消耗 Mode 换轻量模型，记录成本变化。
- 第 4 周：把月累计成本与订阅方案对比，同时看额度是否够用、模型是否满足需求。
验证期间不要同时改太多变量，否则无法判断哪项优化有效。最终决策看三个数：月总成本、任务完成率、超限或重试比例。只便宜但经常失败，不算省。
常见问题
Roo Code 本身收费吗？
本地扩展本体不按席位收费，采用 BYOK，模型调用由你填写的 Key 按 token 计费。Roo Code 公司的云端产品是另一套计费体系，不要和本地扩展混为一谈。扩展已于 2026 年 5 月停止维护，社区分支 Zoo Code 延续开发。
按量计费一定比订阅便宜吗？
不一定。轻量、间歇使用通常更省；每天高频、长上下文、多子任务的重度使用，订阅制可能更可控。要用自己的请求日志和当前单价计算，不能只看宣传页。
为什么实际账单比预估高很多？
常见原因是输入 token 被低估：每轮都会重发历史、文件和工具输出；其次是重试、上下文压缩、子任务和推理 token。先看网关日志里的请求次数与输入构成，再判断是单价问题还是用量问题。
缓存能省多少？
取决于前缀稳定性、模型、缓存有效期和通道实现。前缀越稳定、会话越集中，缓存读取占比越高；频繁切换模型或改写系统提示，会让缓存反复失效。不要预设固定折扣，按日志里的缓存字段核算。
团队怎么防止账单失控？
一人一 Key、按项目分 Key，在网关设置日额度和月额度并开启告警；限制每个 Key 的模型范围；在 Roo Code 里给高消耗 Mode 绑定轻量模型和 Rate Limit；定期审计异常用量。控制粒度越细，定位和止损越快。
下一步
如果你准备把编码 Agent 的成本管起来，可以先从注册入口创建一把带额度的测试 Key，用真实任务跑一周日志，再按本文公式核算。模型单价、缓存规则和额度政策会调整，请以模型价格页面的实时信息为准。
相关阅读：
