DeepSeek 上线额度管理：C 端用户或将面临限额

11 月 13 日的线上构建里，DeepSeek 已经把额度计量做进了聊天页：按模型拆分的配额、耗尽提示、五分钟一次的轮询，一应俱全。但把它读成“要卖 Coding Plan 套餐”，目前没有证据。这篇文章只讲可复现的部分。

结论先摆在这里

三条判断，逐条对应证据强度：

1. 额度体系是真的。 我在当前线上构建中复现了中英文提示文案、quotas 数据结构、轮询逻辑与提示条 UI，不是二手描述。
2. 套餐是推测。 “Coding Plan”这个名字在该构建声明的全部 603 个 JS 分块中零命中，也没有任何价格、支付、订阅入口。
3. 官方零表态。 开放平台定价页仍只有按 token 计费，没有任何订阅项。

所以能站住的表述只有一句：DeepSeek 的 C 端用户，可能很快会第一次遇到“用量上限”这件事；至于上限之后是等待恢复还是付费解锁，现在没有官方答案。

我核验了什么

核验对象是 2026 年 11 月 13 日的线上构建，不是缓存快照。

方法是三步：从构建清单里解析出分块映射表，并行下载全部分块，再做全量字符串检索。这样能排除“只看了首屏包”的盲区。

代码里有什么，没有什么

确有的四样东西

第一，两句已经写死的提示。 中文是使用额度已达上限，请额度恢复后再试，英文是Usage limit reached. Please try again after your quota resets.，都在主包的语言资源里随包下发，不需要等接口返回。

第二，一套按模型拆分的配额结构。 代码里的额度对象包含 model_type（归属模型）、is_exhausted（是否用尽）、reset_at（恢复时间戳）、msg（服务端说明）、alert（运营提示位，含标题、正文、样式与按钮数组）。reset_at 说明额度是周期性恢复的，不是一次性总量；alert.action[] 说明提示条可以带按钮，指向哪里由服务端决定。

第三，五分钟一次的额度轮询。 页面可见时，客户端同步各模型的剩余额度、禁言状态与服务端文案；提示条的触发条件是 quotas 数组里存在 is_exhausted 为真的项。

第四，服务端可下发的横幅与配色。 样式表里有 --quota-image、--quota-tint-light、--quota-tint-dark，意味着额度提示可以带一张服务端指定的横幅图，并自动适配明暗主题。这解释了它为什么会被读成“付费墙”——结构上确实留了这个位置。但预留运营位，和已经排期上线一个付费产品，是两件事。

零命中的清单

这是本次核验最关键的部分。全量检索结果：

没有价格字符串，就没有定价页；没有支付字符串，就没有收银台；没有订阅字段，就没有会员体系。一个准备在近期上线的付费套餐，不可能在客户端一行都不留。

作为对照，官方定价页目前只有两个模型：deepseek-flash（对应 V4.1-Flash-1017）与 deepseek-v4-pro，计费单位是每百万 token，分高峰与非高峰两档。页面上没有任何月度订阅、额度包或会员档位。

“Coding Plan”这个名字是怎么来的

单源时间线

• 11 月 13 日，快科技以“前端出现额度管理”推断“终于要推套餐”。
• 11 月 14 日 09:20，IT之家成稿，写明代码“指向一个名为 Coding Plan 的专属套餐”，同时注明官方未公布价格、层级与上线日期。
• 此后，itbear、it007、腾讯新闻、中关村在线等均为转述，没有一家提供独立信源。

单源、转述、配图由 AI 生成——这条链不足以支撑产品判断。还有一个容易忽略的混淆源：「Coding Plan」并不是 DeepSeek 的原创词，国内已有厂商用它命名编程套餐，站内智谱清言收费吗那篇就拆过会员、API 与 Coding Plan 三笔账。名字先在别处流行，再被套到 DeepSeek 头上，是更省力的解释。

更合理的解释：限流，而非收银

把字段放回语义里看：mute 与 mute_until 是禁言，reset_at 是恢复时间，is_exhausted 是用尽。三者拼起来，是限流系统的典型结构，不是收银系统。

禁言字段尤其说明问题：付费墙不需要“禁言”，风控才需要。一套只为卖套餐设计的系统，不会同时维护 mute_until 这种滥用处置状态。

补上这一层计量，最直接的收益有三个：把算力从滥用请求里省出来、给重度用户一个可预期的节奏、以及在真要做付费时不必从零搭计量。收费是这套系统的可能用途之一，不是唯一用途，更不是已被证实的用途。

对普通用户意味着什么

你现在会看到什么

• 现在打开网页，大概率看不到额度条，因为还没触发。
• 一旦触发，输入框上方会出现提示条，首页欢迎区会换成服务端下发的额度说明。
• 额度按模型区分，恢复时间由服务端配置。具体数值没有公开，任何“每天多少次”的说法目前都是猜的。
• 这不影响 API 用户。开放平台仍是独立计费，与聊天页是两套账，具体端点与账单结构可以看DeepSeek 全家桶 API 上手。

如果你的用法是每天写代码、跑长任务，真正该提前准备的不是“买套餐”，而是把调用量测出来。多渠道比价的思路可以参考免费大模型 API 怎么选；把额度当成固定预算来规划，比等一个还没公布的价格更实际。同类产品的收费路径差异，可以对照智谱清言收费吗，那篇把会员、API 与 Coding Plan 分成三笔账讲清了。

接下来盯三个信号

1. 官方定价页是否出现订阅项。
2. 前端是否出现价格、支付、订阅管理字符串。
3. 额度文案是否从“恢复后再试”变成“升级后继续”。

三个信号里出现任意两个，才能说“付费”；只出现额度条，只能算“限额”。这也是本文标题停在“或将面临限额”的原因。

常见问题

Q：deepseek 额度在哪里看？

当前线上构建里，剩余额度不是常驻展示项，只在耗尽时通过提示条与首页说明出现。代码里没有独立的“额度中心”页面。

Q：deepseek 额度多久刷新一次？

数据结构里有 reset_at，说明按周期恢复，但周期长度与数值由服务端下发，客户端没有写死。网上流传的“每日刷新”没有官方依据。

Q：deepseek 额度用完会怎样？

按现有代码，会拦截发送并提示“额度恢复后再试”，即等待恢复，而不是引导付费。这一点恰恰是“套餐说”的反证。

Q：deepseek 会收费吗？

官方目前只对 API 按 token 收费。聊天页是否引入付费，官方没有公布任何方案。把“有计量”直接等同于“要收费”，中间少了一步。

Q：Coding Plan 是真的吗？

截至 11 月 14 日，官方没有任何公告，客户端代码里也检索不到这个名称。它目前只是一条媒体转述，不是产品事实。

Q：API 用户会受影响吗？

不会。开放平台的计费与聊天页额度是两套独立系统，这次前端改动没有触及 API 的定价与限流规则。