V4.1 Flash免费，但缩水了

OpenCode 把 DeepSeek V4.1 Flash 变成了免费模型

OpenCode 今天宣布免费提供 DeepSeek V4.1 Flash，用户在平台内使用该模型将不再消耗原有套餐额度，但免费版本默认只支持 200K 上下文窗口，明显低于模型原生标称的 1M。

OpenCode 是一款面向开发者的开源 AI 编程代理工具，核心能力是让模型直接读取代码、修改文件、执行命令并完成多步骤开发任务。这次调整的意义不只是“多了一个免费模型”，而是一个原本面向高频 Agent 工作流的主力模型，被放到了几乎没有使用成本的入口上。

免费版本的代价同样明确：200K 相比 1M 少了 800K token，窗口容量缩减了 80%。对于普通问答、单文件修改和中小型项目，这个限制未必容易碰到；但对于需要持续读取仓库、保留终端输出和反复调用工具的 Coding Agent，200K 和 1M 是两个完全不同的使用档位。

这次更新到底改了什么

上下文窗口是模型单次推理能够同时接收和处理的 token 总量，它通常包括系统提示词、用户输入、历史对话、工具返回结果、代码文件以及模型输出。上下文越大，Agent 理论上越不容易忘记此前读过的代码和做过的操作，但推理成本、首字延迟和显存压力也会随之增加。

OpenCode 此次开放的是免费使用资格，而不是把 DeepSeek V4.1 Flash 的全部原生规格无条件搬到免费层。根据目前披露和社区实测，免费模型的关键变化如下：

| 项目 | OpenCode 免费版 | 模型原生规格 | 差异 | |---|---:|---:|---:| | 使用成本 | 平台内免费，不计入原有额度 | DeepSeek 官方服务无免费 API 层级 | OpenCode 成本更低 | | 上下文窗口 | 200K token | 1M token | 减少 800K，降幅 80% | | 最大输出 | 元数据争议尚未完全厘清 | 最高 384K token | 免费端应以实际限制为准 | | 输入模态 | 文本、图像 | 文本、图像 | 基本一致 | | 适用场景 | 日常编程、局部重构、中型仓库 | 超长会话、大型仓库、长链路 Agent | 长上下文能力受限 | | 额度消耗 | 不计入 OpenCode 原有模型额度 | 按官方规则计费 | 免费不等于无限并发 |

免费不等于无限制，这一点需要特别强调。OpenCode 目前确认的是模型调用不再计入原有额度，但这并不能自动推导出没有速率限制、并发限制、公平使用策略或高峰期调度限制；在官方公布更完整的服务规则前，开发者不应把它等同于一项带稳定吞吐承诺的生产服务。

从 15 美元到免费，OpenCode 连续三次加码

OpenCode 对 DeepSeek V4.1 Flash 的资源倾斜并非临时起意，而是此前“Operation Cheepseek”计划的延续。今年 9 月，OpenCode 曾把该模型在 OpenCode Go 套餐中的可用额度从 15 美元临时提高至 60 美元；10 月 12 日，额度进一步调整为 80 美元；到了 10 月 15 日，平台直接将该模型改为免费使用，不再扣减对应额度。

这条时间线说明 OpenCode 正在用 DeepSeek V4.1 Flash 承担获客和提高 Agent 使用频率的任务。

| 时间 | OpenCode 调整 | 相比初始 15 美元额度 | |---|---|---:| | 2026 年 9 月 | 临时提高至 60 美元 | 增加 45 美元，提升 300% | | 2026 年 10 月 12 日 | 调整至 80 美元 | 增加 65 美元，提升约 433% | | 2026 年 10 月 15 日 | 平台内免费，不再计入额度 | 从定额福利转为免费入口 |

连续加码的背后是 DeepSeek V4.1 Flash 已经成为 OpenCode 的高频模型。OpenCode 的模型数据页面显示，截至 10 月 10 日，该模型近两个月累计处理约 184T token，独立用户约 170 万，完成会话超过 3000 万次，token 份额约为 19%，并位列最近一周平台使用量第一。

这些数据至少证明了一件事：DeepSeek V4.1 Flash 并不是为了丰富列表而存在的展示模型，而是已经进入真实开发工作流。免费开放很可能继续放大使用量，但也会让吞吐波动和资源调度问题变得更突出。

200K 不是不能用，但会更早触发压缩

上下文压缩是 Coding Agent 在历史记录接近窗口上限时，将旧对话、工具输出和代码信息归纳为摘要的机制。压缩可以避免会话直接溢出，但摘要无法完整保留每一处实现细节、错误日志和隐含约束，因此可能导致模型重复读取文件、忘记此前决策，甚至重新引入已经修复的问题。

GitHub 上已有用户指出，DeepSeek V4 Flash Free 在 models.dev 元数据中被设置为 200K，而模型原生支持 1M。按照该用户观察，OpenCode 的压缩机制可能在窗口使用量达到约 50% 时启动，因此 200K 配置下，实际会在接近 100K token 时开始压缩，而不是等到 200K 完全用尽。

100K 的有效历史空间对个人项目通常够用，但对大型 Agent 任务并不宽裕。一个中大型 TypeScript 或 Java 仓库，仅依赖文件树、关键模块、测试日志和构建输出就可能快速消耗数万 token；如果再让 Agent 连续执行搜索、修改、测试和回滚，100K 很容易在一次长会话中被吃掉。

社区提交的 GitHub Issue 将这次限制描述为“元数据配置问题”，并给出了手动改写本地模型限制的办法。不过，修改本地配置只会改变客户端如何计算窗口和触发压缩，并不能证明 OpenCode 服务端一定会接受完整的 1M 输入，也不能保证超出 200K 后仍有稳定吞吐。

开发者不应把修改元数据视为获得 1M 免费上下文的可靠方案。如果服务端存在硬上限，本地强行提高数值可能导致请求失败；如果服务端没有硬限制，更长上下文仍会带来明显的首字延迟、吞吐下降和会话不稳定。现阶段最稳妥的判断仍是：免费版按 200K 规划工作流，等待 OpenCode 对客户端配置和服务端上限作进一步说明。

Flash 的重点不是小，而是降低长输入成本

DeepSeek V4.1 Flash 是 DeepSeek 于 2026 年 9 月 10 日发布的原生多模态 MoE 模型，能够同时处理文本与图像输入。MoE 即混合专家架构，它不会在每个 token 上激活全部参数，而是根据输入选择部分专家参与计算，从而在扩大总参数规模的同时控制单次推理成本。

DeepSeek V4.1 Flash 的语言主干参数规模为 552B，并额外包含 196B Engram 条件记忆参数。Engram 是一种用于存储和调用条件记忆的参数结构，可以把部分知识检索和模式匹配能力从常规语言主干中拆分出来，让模型在不完全依赖主干计算的情况下调用相关信息。

模型采用因果编码器—解码器架构，40 层语言主干中的前 20 层是因果编码器，后 20 层是解码器。因果编码器负责对已有输入进行更高效的表征，解码器则继续按照自回归方式逐 token 生成结果；这种拆分让模型的 Prefill 计算量接近减半。

Prefill 是模型在开始输出第一个 token 前，对全部输入上下文进行计算的阶段。对于几百 token 的普通问答，Prefill 往往不是主要矛盾；但当 Coding Agent 一次塞入数万乃至数十万 token 的代码时，Prefill 会直接决定用户需要等待多久才能看到第一段输出。

这也解释了 OpenCode 为什么愿意重点推广 Flash。Coding Agent 的成本大头并不只来自最终生成的代码，还来自一次次读取仓库、回放历史、接收测试日志和重新构建上下文；一个能压低长输入计算成本的模型，比单纯追求高跑分的模型更适合高频开发任务。

真正的不确定性是速度，而不是免费资格

TPS 是模型每秒生成的 token 数量，它直接决定长代码、长解释和 Agent 连续操作的等待时间。社区对 DeepSeek V4.1 Flash 的讨论焦点，目前并不是模型能不能生成正确代码，而是不同时间和不同上下文长度下的 TPS 波动过大。

社区用户报告的最高速度约为 490 tokens/s，但这一数字并不稳定。在部分云端环境中，中午到下午时段的输出速度可能下降到每秒五六十 token；OpenCode Go 用户也曾反馈 TPS 跌到 100 以下。

长上下文会进一步放大吞吐问题。已有用户观察到，上下文超过 100K 后，输出速度可能降到不足 100 tokens/s；接近 200K 时，速度约为 50 tokens/s。若一次任务需要生成 5000 token，按 490 tokens/s 计算约需 10 秒，而按 50 tokens/s 计算则需要约 100 秒，两者相差接近 10 倍。

这些速度数字都来自社区观测，而不是标准化基准测试。服务器负载、地区网络、上下文长度、缓存命中、输出内容以及平台调度都可能影响结果，因此不能把 490 tokens/s 当作稳定承诺，也不能把 50 tokens/s 视为所有用户都会遇到的固定下限。

免费开放之后，峰值速度反而可能更难维持。OpenCode 如果没有同步增加推理资源，新增用户会把原本偶发的拥堵变成更常见的高峰波动；对交互式编程而言，稳定的 100 tokens/s 往往比偶尔冲到 490 tokens/s、随后掉到 50 tokens/s 更有价值。

哪些任务适合用免费版

200K 免费窗口足以覆盖大多数日常编程工作，但不适合被当成无限记忆。开发者可以把 DeepSeek V4.1 Flash Free 视为一个便宜且能力较强的默认执行模型，而不是专门承载超大型仓库全量分析的长上下文模型。

以下任务更适合免费版：

• 单文件或少量文件的功能开发、Bug 修复与代码审查；
• 中型项目中的模块级重构，而不是一次性读取整个仓库；
• 根据截图理解界面，再修改前端组件和样式；
• 运行测试、分析报错并完成数轮修复；
• 高频生成脚本、单元测试、类型定义和迁移代码；
• 允许拆分成多个短会话的批量开发任务。

以下任务更容易受到 200K 限制影响：

• 同时分析数百个源码文件的大型单体仓库；
• 持续数小时、包含大量工具输出的自主 Agent 任务；
• 需要保留完整设计讨论和历史决策的跨模块重构；
• 把文档、代码、日志、数据库结构一次性全部放入上下文；
• 对压缩后细节丢失高度敏感的安全审计与复杂迁移。

更合理的使用方法是主动管理上下文，而不是等 Agent 自动压缩。开发者可以按模块拆分任务、减少无关构建日志、让模型先生成结构化项目摘要，并在进入新阶段时开启新会话；这些操作看起来不如直接使用 1M 窗口省事，却能显著降低长会话中的信息污染。

OpenCode 用上下文换来了更激进的免费策略

OpenCode 这次更新本质上是一笔清晰的资源交换：平台免掉 DeepSeek V4.1 Flash 的额度消耗，用户则接受原生上下文从 1M 降到 200K，以及尚未明确的速度和公平使用边界。对于绝大多数日常开发任务，这笔交换是划算的；对于依赖超长记忆的 Agent 工作流，它则不能替代完整规格版本。

这次免费开放也会给同类 AI 编程工具带来压力。开发者越来越难接受“订阅之后还要精打细算每次 Agent 循环”的产品设计，而 OpenCode 正在用一个已经验证过使用量的模型，把高频调用变成默认能力。

DeepSeek V4.1 Flash 最值得关注的地方也不是名字中的 Flash，而是它已经开始替代部分过去必须交给高成本模型的工作。如果代码生成、视觉理解和工具调用都达到够用水平，产品团队便可以把 AI 从少数关键流程扩展到默认开启的代码审查、测试补全和持续修复中。

OpenCode 现在需要补上的不是更多宣传，而是更透明的服务边界。免费模型究竟有没有速率上限、200K 是客户端元数据限制还是服务端硬限制、手动设置 1M 是否被正式支持、最大输出是否仍为 384K，这些问题都应有明确答案。

现阶段的结论很直接：DeepSeek V4.1 Flash Free 是一个值得立即尝试的免费 Coding Agent 模型，但它不是完整 1M 版本的等价替代品。普通开发者得到的是一项实用福利，长上下文重度用户得到的则更像是一个经过限容的高性能入口。

参考来源

• IT之家：OpenCode 宣布 DeepSeek V4.1 Flash 免费提供，但仅支持 200K 上下文——报道免费开放、额度调整、模型架构及社区速度反馈。
• GitHub Issue #40958：DeepSeek V4 Flash Free 上下文元数据争议——记录免费模型默认 200K、约 100K 触发压缩及本地配置讨论。