AI 编程工具的上下文窗口与输出上限对比：窗口大不等于能用

「上下文窗口 1M token」这句话，在不同的官方文档里指的是不同的东西。有的指模型原生能力上限，有的指工具默认给你多少，有的指你额外付费后能拿到多少。把它们混在一起比大小，是这一轮 AI 编程工具对比里最常见的错误。

还有两个更隐蔽的问题。第一，窗口不是「装代码的容器」——系统提示、工具定义、历史对话、模型的思考过程全都挤在同一个池子里，而且官方明确说内容越多准确率越低。第二，「最大输出」和上下文窗口是两个独立参数，很多对比文章只写窗口不写输出上限，而后者往往才是长任务真正的瓶颈。

这篇把 Anthropic、Cursor、GitHub Copilot、Devin Desktop（原 Windsurf）四家的官方文档对齐，先把三种窗口分清楚，再把窗口折算成「能装下多大的代码库」，最后说明为什么窗口大不等于能用。数据于 2026 年 9 月 24 日重新核对官方文档。

本文方法：官方公开数据交叉核对，未做本地实测。所有数字均标注来源，核对日期见文末。

一、同一个模型，三个不同的「上下文窗口」

先看 Cursor 的官方模型表。它把每个模型的上下文拆成两列：默认和最大。这个区分在其他工具里很少见，但它是理解整件事的关键。

这张表里有三处值得单独指出。

第一，默认值和原生能力差最多 5 倍。Claude Sonnet 5 在 Anthropic 官方文档里的上下文窗口是 1M，在 Cursor 里默认只有 200k。这不是 Cursor 的「缩水」——官方在定价文档里写了另一层机制：Max Mode，「extends a model’s context window beyond the default limit and is billed at the model’s API rate plus 20%」。也就是说，从 200k 到 1M 这段能力是要额外付费的，加价幅度是模型 API 价格的 20%。

第二，Grok 4.7 的最大值低于同门的其他模型。Grok 4.5 和 4.6 在 Cursor 里只给了默认值 256k、没有最大值一栏；Grok 4.7 给了 500k。也就是说同一个厂商的三个版本，扩展上下文的能力并不一致——升级模型版本不一定升级窗口。

第三，Cursor 自家的 Composer 2.5 只有 200k，没有最大值。这一点经常被忽略：在很多「Cursor 免费/便宜」的用法里，实际跑的是 Composer 这个自有模型，而它的窗口是这张表里最小的档位之一。

再看 GitHub Copilot 这一侧。它的官方文档没有公布任何单模型的上下文窗口，只给了一条概括说明：模型具备「1 million token context window: Allows the model to process significantly more content in a single session」。而且这条能力带一个客户端限制，官方原文是：「The 1 million token context window is available in Visual Studio Code and Copilot CLI only.」

但 Copilot 的计费表泄露了它没有明说的边界。官方按「Threshold (input tokens)」把同一模型拆成 Default 和 Long context 两档，跨过门槛后输入单价正好翻倍：

这是一个可以从官方价格表里读出来的事实：Copilot 的「长上下文」不是免费的，门槛两侧的输入单价精确翻倍。而且它反过来暴露了官方没有公布的窗口边界——GPT 系列的门槛在 272K，Grok 系列在 200K。换句话说，如果你在 Copilot 里看到某个请求的输入超过 272K，你已经在按两倍单价付费了。

二、把窗口折算成「能装下多大的代码库」

要回答「1M 窗口能装下多大的项目」，必须先声明换算依据，否则这个数字没有意义。本文用的两步换算都是可追溯的：

• 第一步，token 与字符的比例。OpenAI 官方帮助中心给出的经验值是「1 token is approximately 4 characters」，并说明这是针对英文文本的粗略估计（「These are estimates, not exact counts」）。
• 第二步，一行代码的长度。按一行代码平均 40 个字符估算，得到约 10 token / 行。这一步是本文的估算，不是官方数据——实际会随语言、缩进风格、注释密度而变，压缩过的代码或长单行配置会显著偏高。

但这里有一个必须叠加的修正，也是本文最重要的原创增量点。Anthropic 官方文档明确说明，Claude 4.7 及之后的模型换了新的分词器：

「Claude 4.7 and later models and Claude Mythos Preview use a newer tokenizer. The same input text produces approximately 30 percent more tokens than on earlier models.」

这句话对「窗口能装多少代码」有直接影响：同样是 1M 的窗口，在 Claude 4.7 及之后的模型上，装得下的代码比旧模型少约 23%。官方还专门提醒不要把旧模型上测出的 token 数直接拿来估算新模型的成本或窗口容量（「don’t reuse token counts measured on the older model to estimate costs or context window fit」）。

这张图要连着看最后两行：同样是「1M 上下文」这个宣传数字，在新分词器下少装约 2.3 万行代码。如果两个模型的窗口都写着 1M，但一个是 Claude 4.7 之前的版本、一个是之后的版本，它们的实际容量并不相等。

还需要再扣掉一层。Claude Code 官方文档《Explore the context window》里写明，在你输入第一个字之前，已经有一批内容进了上下文：「CLAUDE.md, auto memory, MCP tool names, and skill descriptions all load into context.」此外还有输出样式、--append-system-prompt 追加的内容、系统提示本身。而官方对上下文的定义是：「Everything in the request counts toward the context window: the system prompt, every message in messages (including tool results, images, and documents), and your tool definitions.」

所以「1M 窗口能装 7.69 万行代码」是一个上限，不是可用容量。真实的可用额度要减去固定的启动开销，还要减去本次会话已经产生的对话历史。官方没有公布这些开销的精确 token 数——不同项目差异太大，本文不做推测。

三、窗口大不等于能用

前面算的是容量。接下来是三个让「容量」无法完全兑现的机制，全部来自官方文档。

机制一：上下文腐烂（context rot）。Anthropic 官方在上下文窗口文档里写得很直接：

「A larger context window allows the model to handle more complex and lengthy prompts, but more context isn’t automatically better. As token count grows, accuracy and recall degrade, a phenomenon known as context rot. This makes curating what’s in context just as important as how much space is available.」

这段话是官方自己写的，不是第三方评测的结论。它推翻了「窗口越大越好」这个直觉：把 10 万行代码全塞进去，模型的准确率和召回率会下降。官方给出的对策是「curating what’s in context」——挑选放什么，比窗口有多大更重要。

机制二：输出和 thinking 也占窗口。官方原文是「The context window holds the conversation history plus the new output Claude generates」，而且「The output Claude generates for the turn, including its extended thinking, counts too」。也就是说，一个 128K 最大输出的请求，理论上要在这 1M 里预留 128K 给输出——如果开了 thinking，这部分思考 token 同样计入。

这解释了一个容易被误解的报错。官方对溢出的行为定义得很细：如果输入本身就超过窗口，API 返回 400 invalid_request_error，信息是「prompt is too long」；但如果输入没超、只是「输入 + max_tokens」超了，Claude 4.5 及之后的模型会接受请求，然后在生成到窗口上限时停下，返回 stop_reason: "model_context_window_exceeded"。两种情况的处理方式完全不同——前者要你改输入，后者是生成被截断。

机制三：缓存不省窗口，只省钱。官方原文：「Cached prompt prefixes still occupy the context window: prompt caching changes what you pay for those tokens, not whether they count.」这是一个非常实用的提醒——开启 prompt caching 后账单会降，但可用窗口一点没变。

顺带一个数量级的参考：官方说明单个请求最多可包含 600 张图片或 PDF 页面（200K 窗口的模型是 100 个）。如果你打算把大量设计稿或文档塞进上下文，这个限制会先于 token 上限生效。

四、「最大输出」是独立的另一把尺

这是本文想强调的第二个原创增量点：上下文窗口和最大输出是两个独立参数，而很多对比只写前者。先看 Anthropic 官方公布的数字：

注意 Haiku 4.5 这一行：窗口缩小到 200K 的同时，最大输出也从 128K 掉到 64K。这两个参数是同向变化的，但变化幅度不同（窗口降到 1/5，输出只降到 1/2）。

对比另外两家的披露程度：

• GitHub Copilot：最大输出 token 数官方未披露。官方文档公布了每个模型的输入、缓存输入、缓存写入、输出四种单价，但没有公布任何一个模型的最大输出 token 数。唯一与窗口相关的数字是「1 million token context window」，且限于 VS Code 与 Copilot CLI。
• Devin Desktop（原 Windsurf）：上下文窗口与 token 上限官方未披露。官方文档唯一给出的量化表述是关于效率而非容量：「The Devin Local agent is significantly more token-efficient, with a greater focus on prompt caching. Most tasks take up to 30% fewer tokens than Cascade to accomplish the same result.」注意这是与上一代 agent（Cascade）的对比，不是容量数字。Cascade 已于 2026 年 7 月 1 日退役。

所以「上下文窗口与输出上限对比」这件事，在四家里的可对比程度差别很大：Anthropic 公布了完整的两个数字，Cursor 公布了默认与最大窗口但没有公布最大输出，Copilot 公布了窗口能力的客户端限制但没公布单模型窗口，Devin Desktop 两个都没公布。

五、三个容易踩的坑

六、按场景怎么选

• 做单文件、小范围修改：200K 级别完全够用，大约是 1.5 万到 2 万行代码的量。这个场景下不需要为 1M 窗口付费，也不需要开 Max Mode。
• 跨文件重构、要理解整个模块：需要 300K 以上。注意 Cursor 的默认值：Sonnet 5 是 200k、Opus 5.5 与 Fable 5.1 是 300k，要到 1M 需要走 Max Mode（模型 API 价 + 20%）。
• 要喂进整个中小型代码库：先做除法。按 10 token/行，1M 大约 10 万行，但 Claude 4.7+ 的分词器下只有约 7.69 万行，再扣掉启动开销与对话历史。先统计你自己的仓库行数，再决定要不要 1M。
• 用 Claude Code 跑长任务：记住三个数字。原生 1M 模型默认在约 967K 处自动压缩；Sonnet 4.6 / Opus 4.6 无扩展上下文时在 200K 处压缩；压缩后单个超过 5,000 token 的文件只会留下路径引用。第三个数字最容易被忽略——如果你的关键文件是 2,000 行的模块，压缩后模型就看不到它了。
• 在 Copilot 里跑长会话：盯住 272K / 200K 这两个门槛。跨过之后输入单价翻倍。另外确认你在哪个客户端——1M 上下文只在 VS Code 和 Copilot CLI 里可用。
• 需要长文输出（生成长文件、大批量代码）：看最大输出而不是窗口。Claude 大窗口模型是 128K，Haiku 4.5 只有 64K。Copilot 的最大输出官方未披露，采购前需要向官方确认。
• 要在多家之间比「窗口大小」：先确认比的是哪一个窗口。原生上限、工具默认值、工具最大值是三个不同的数字，混着比会得出完全错误的结论。这一篇的第一张表就是为此准备的。

最后回到方法上。这篇和本站前几篇做的是同一件事——把订阅价格拉平、把 token 单价拉平、把每张图成本拉平。这一篇拉平的是「上下文窗口」：先把原生上限、工具默认值、工具最大值三者分开，再扣掉分词器差异和启动开销，剩下的才是你真正能用的那部分。而官方自己已经说了，那部分也不是越大越好。