Skip to content

火山方舟 Coding Plan 实测: 包月成了"包时段", DeepSeek 新版也追不上

下午三点, 正赶工。Claude Code 里的 AI 突然罢工, 提示额度用完了。打开控制台一看, 当前时段的请求次数已经归零, 想再跑任务只能等额度刷新。

今天剩下的时间, 要么切回手动写, 要么干等。

这是不少火山方舟 Coding Plan 订阅用户的日常。最难受的其实不是钱--9.9 元本来也没指望什么--是写代码正上头的时候, 手感被生生掐断, 剩下的半天都在等一个刷新的时钟。

套餐宣传页上写的是"包月", 很多人冲着 9.9 元的首月价格买了单, 用起来才发现: 这个"包月"里藏着一层又一层的限额, 最直观的一条就是--额度用完就得停, 停到下个时段开始。

套餐长什么样

先把事实摆清楚。方舟 Coding Plan 目前的套餐结构(截至 2026 年 6 月的公开资料, 具体以官方页面实时为准):

套餐价格5 小时限额月限额
Lite原价 40 元/月, 限时 9.9 元1200 次请求18000 次
Pro原价 200 元/月, 限时 49.9 元6000 次请求90000 次

套餐集成了豆包编程模型、DeepSeek、GLM、Kimi 等主流模型, 兼容 Claude Code、Cursor、Cline 这些主流 AI 编程工具, 这部分体验是没得挑的--配置一个 Base URL 就能切换, 模型选择也全。

问题出在限额机制上。

"包月"的预期, 和实际的机制

看到"包月"两个字, 正常的预期是: 这个月之内, 随便用。

实际的机制是: 限额的主单位不是"月", 是 5 小时滚动窗口。Lite 套餐每个窗口 1200 次请求, 用完即停, 等下一个窗口。月限额 18000 次是第二道闸, 两个限额取先到的那条。

如果你下午两点把窗口额度烧完了, 下一个完整窗口要晚上才来, 而晚上烧完就得等半夜--体感上就是"今天用不了了, 等明天"。这就是很多用户吐槽"每天用了几次就用不了"的来源: 机制上它是 5 小时窗口制, 体验上它就是一天一到两次机会。

1200 次听着多, 为什么不够用

单看数字, 5 小时 1200 次请求, 平均每 15 秒一次, 怎么会不够?

关键在于请求数不等于对话数。这要分两种用法:

  • 手动问答: 你问一句, AI 答一句, 一次对话一两次请求。这种用法 Lite 完全够, 甚至算宽裕。
  • Agent 模式: Claude Code、Cline 这类工具, 你给它一个任务, 它自己拆解--读文件、改代码、跑验证、再修改, 每一步都是独立的模型请求。一个中等复杂度的任务, 背后是几十上百次请求。

现在的趋势恰恰是 Agent 模式成为主流。也就是说, 这类套餐的主要使用场景, 恰好是它限额最吃不消的场景。

有个真实案例很能说明问题。网上有开发者晒了记录: 用 DeepSeek 和 GLM 各请求了 12 次, 总共 24 次请求, 消耗约 600 万 token, 5 小时窗口的额度直接见底, 整个过程只用了 20 分钟。为什么会这样? 因为 Agent 模式下每次请求都拖着完整的上下文, 一个大项目的代码上下文塞进去, 单次请求的 token 消耗是手动问答的几十倍, 计费口径也跟着水涨船高。

20 分钟烧完 5 小时的额度, 剩下 4 小时 40 分钟, 只能看着。

有兴趣的可以翻翻自己上次大任务的请求日志, 一共发了多少次请求?

把限额翻译成"每天能干什么"

Lite 的两道限额里, 真正先见底的往往是月度总额。

单看 5 小时窗口: 一天 24 小时有 4.8 个窗口, Lite 每窗口 1200 次, 理论上限一天能跑 5000 多次请求, 看着挺富余。但月限额 18000 次摊到 30 天, 平均每天只有 600 次

600 次是什么概念? Agent 模式下一个中等任务几十上百次请求, 一天跑五六个任务, 月额度就见底了; 要是任务大一点、上下文重一点, 一天两三个任务就到线。也就是说, 真正卡脖子的往往不是那个"用完等刷新"的窗口, 而是月底才发现已经透支的月度总额--窗口限额让你当天难受, 月限额让你后半月难受。

这就是"包月"体感的第二层落差: 名义上买了一个月, 额度密度折算下来, 大概是"每个月的前十天"。

DeepSeek 都更新了, 套餐里还用不上

限额之外还有一层体验落差: 模型列表的"新"。

套餐宣传的卖点之一是模型全--豆包编程模型、DeepSeek、GLM、Kimi 都在列。但"在列"和"最新"是两回事。DeepSeek 这两个月热度拉满: V4 系列七月才被接进套餐, 八月中旬 V4 Pro 又凌晨突击更新, 社区一片沸腾。然后你打开 Coding Plan 的模型列表--还是旧版本(截至发文实测), 新版不在套餐里。

说实话是馋的。新模型凌晨发布, 第二天满屏都是跑分和评测, 你手上的包月套餐安安静静, 像办了年卡的健身房把新器械锁起来只卖单次票。

想尝鲜只有一条路: 去开按量付费的 API 单独调用, 按官方定价真金白银地烧。于是"全模型包月"的承诺打了个折: 每次新模型发布, 订阅用户都得在外面再付一份钱。

这个滞后其实和限额是同一套逻辑: 套餐要控成本, 模型列表也要控成本。新模型刚上线单价高, 先让按量付费的用户扛一波, 热度稳了、成本降了, 再挂进套餐。商业上说得通, 但站在订阅者角度: 付着包月的钱, 追新的速度永远慢半拍, 而追新恰恰是很多人订阅的原始动机。

为什么设计成这样

平心而论, 窗口限额不是方舟独有的发明。Claude 官方订阅也是 5 小时窗口制, 这是大模型订阅服务的通行做法--推理成本实打实在那里, 不设限额, 9.9 元的价格撑不住。

真正的问题是价格锚点和额度体验的错位。9.9 元的首月价格把用户预期拉到了"白菜价包月随便用", 而限额条款藏在细则里; 等用户真跑起 Agent 任务, 才发现 9.9 元买到的额度密度支撑不了宣传画面里那种用法。限时折扣(首两个月 2.5 折, 2026 年 6 月到 8 月)进一步放大了这个落差: 原价 40 元的套餐, 用户按 40 元的预期来要求, 平台按促销价的成本来控制。

问题不在能不能用, 是"包月"这个词给人的承诺, 和实际给到的额度节奏, 中间隔着一道信息差。限制性条款这种直接决定买不买的东西, 不放进宣传页的明处、专藏在细则里, 这点确实让人喜欢不起来--控成本可以理解, 藏字游戏就是另一回事了。

所以 9.9 元的定价, 你觉得是给开发者的普惠, 还是拉人进门钩子? 每个人的答案大概取决于自己被限额卡过几次。

怎么避坑

如果你在用或打算订阅这类套餐, 几条实际经验:

1. 先算请求数, 再看价格。 评估自己每天跑多少 Agent 任务, 每个任务大约多少次请求(工具日志里都能看到)。Lite 的月限额 18000 次, 平均每天 600 次--听起来不少, 一天跑两三个大任务就见底了。

2. 区分场景用不同服务。 手动改代码、问问题, 用套餐很划算; 重度 Agent 长任务, 用按量付费的 API 或者更高档的套餐, 算下来反而可控。怕的不是花钱, 是花着钱在关键时刻被停。

3. 长任务挑窗口跑。 额度刚刷新的时候跑大任务, 别在窗口尾巴上启动--这是没办法的办法, 但能救急。

4. 留意替代方案。 市面上也有用量口径更透明的服务, 比如按 token 计费明码标价的 API, 或者第三方聚合套餐。选型时把"限额单位"和"计费口径"两件事问清楚, 比看宣传页价格有用得多。

5. 盯着用量面板干活。 方舟控制台有 Token 用量和请求统计, 养成跑大任务前看一眼的习惯--窗口还剩多少、本月还剩多少, 心里有数才能安排任务节奏。别等报错了才知道额度见底, 那时候任务跑到一半, 上下文丢了重来更浪费。

这些是我们目前摸索出的打法。大家手上有没有更省的组合, 或者其他家更实惠的 code plan?

踩坑之后的选型观

我们在给 aiots 工业物联网平台做 AI 写脚本的能力--数据过滤、场景联动这些脚本, 目标是让 AI 来写、平台里直接验证。选编码模型服务的时候, 把市面上几家套餐都实测了一圈, 方舟这套限额机制就是这么摸清楚的。

教训只有一条: 看订阅套餐, 先看限额单位, 再看价格。"包月"不代表包你用一个月, 可能只是包你"在限额内用一个月"。宣传页最大的字永远是价格, 最重要的字永远在细则里。


数据说明: 文中套餐价格与限额为 2026 年 6 月公开资料, DeepSeek 模型版本支持情况为 2026 年 8 月 15 日实测; 促销活动有截止时间, 订阅前请以火山引擎官方页面实时信息为准。