Claude Code 100 万 Token 上下文窗口：成本、限制及适用场景

Abhishek Ray

更新于 2026 年 3 月 13 日：Anthropic 已取消 Opus 4.6 和 Sonnet 4.6 的长上下文溢价。100 万 Token 窗口现已按标准费率正式可用，不再有 2 倍的价格乘数。下文所述的价格断崖对这些模型已不复存在。

新建议： 需要时直接使用 100 万 Token 窗口。选择它本身免费，每 Token 也不会产生额外费用。

实测了 Claude 的 100 万 Token 上下文窗口：长会话仍应坚持使用 20 万

Claude Opus 4.6 和 Sonnet 4.6 现在支持 100 万 Token 的上下文窗口——大约相当于 75 万个英文单词、一个中型代码库，或者一场持续 200 轮且始终无需压缩的会话。

逐步增加上下文规模，分别发送了 50K、100K、200K、400K 和 600K Token 的请求，并测量每个规模下的检索准确率、延迟、成本与缓存行为。把“针”藏进了“干草堆”。

100 万 Token 窗口确实有用，但它有用的原因并非大多数人想象的那样，而且绝大多数会话也用不上它。

简而言之：日常使用 Claude Code 时，大多数会话不需要 100 万 Token 窗口。它真正能发挥价值的场景，是在单次请求中输入大型代码库或文档。对于长对话，它的成本会高出 3 倍，而且质量上的取舍也确实存在。本文余下部分将给出证据。

上下文窗口如何工作（简明版）

你每次在 Claude Code 中发送消息，整个对话都会重新发送给 API。第 1 轮会发送系统提示词、工具、CLAUDE.md 和你的消息。第 50 轮则会发送上述全部内容，再加上此前 49 轮对话。在提示词缓存深度解析中详细介绍过这一点。

上下文窗口对模型在单次请求中能够容纳的内容设定了硬性上限。窗口为 200K Token 时，大约到第 50～80 轮就会触及上限（具体取决于累积了多少工具输出）。届时，Claude Code 会启动自动压缩：概括对话、丢弃历史记录，然后从摘要继续。

窗口扩大到 100 万 Token 后，可用空间变为 5 倍。理论上，你永远无需压缩：所有内容都保留在模型的记忆中，没有摘要，没有上下文丢失，也不会因遗忘指令而造成质量下降。

为什么 100 万 Token 窗口花了这么久才实现

既然 100 万 Token 上下文窗口如此有用，为什么三年前的模型没有它？答案不是有人故意保留能力，而是每个 Transformer 内部的核心算法在处理长序列时确实代价高昂；要绕开这一障碍，需要真正扎实的工程工作。

O(n²) 问题

每个 Transformer 处理文本时，都会让每个 Token 与其他所有 Token 相互比较。这一机制称为注意力（attention），也是这些模型能够推理长文本中各种关系的原因。

问题在于：它按平方速度扩展。序列长度翻倍，内存占用就变成四倍。这就是每位工程师都学过要尽量避开的经典 O(n²) 曲线。

注意力机制的平方级扩展示意图

早期模型受限的不是想象力，而是硬件。2020 年，以 4K 上下文训练 GPT-3 就已经逼近可负担成本的极限。如果使用 100K 上下文，每次训练运行的成本会高出数百倍。

突破口：算法层面的改进（2022 年）

2022 年，斯坦福大学的一位研究人员发表了名为 FlashAttention 的论文。其洞见并非新的数学方法——结果与标准注意力完全一致。真正的洞见在于，注意力机制之所以缓慢，不是因为计算本身，而是因为大量数据需要在高速片上内存与低速片外内存之间来回搬运。

如果你曾通过改善缓存局部性来优化紧密循环，其中的思路完全相同。FlashAttention 将计算切分成小块，让数据在高速内存中停留更久。内存占用由 O(n²) 降至 O(n)，长序列训练因而变得可行。

这是 100K、200K 和 100 万 Token 上下文得以实现的最主要原因。硬件并没有太大变化，算法却变了。

FlashAttention 的内存局部性示意图

上下文窗口的演进时间线

FlashAttention 打开了大门，随后上下文窗口迅速扩张——每一次重大跃升，都来自更完善的训练基础设施，以及投入算力训练更长序列的意愿。

上下文窗口大小的演进时间线

2023 年，Claude 2 将窗口扩大到 100K，这是第一个重大拐点：相较 GPT-3.5 猛增 25 倍，出乎所有人的预料。2024 年，Gemini 1.5 跃升至 100 万 Token，构成第二个拐点。更关键的是，Google 从预训练一开始，就以支持 100 万 Token 为目标构建了该模型。

这一区别很重要，下一节就会看到原因。

窗口够大，与真正能用好它，是两回事

模型不能只是能够接收长上下文，还必须学会如何使用长上下文。

预训练期间，模型会接触不超过某个最大长度的序列，并学习如何处理它们。输入任何更长的内容，模型就会遇到从未见过的位置，性能也会随之下降，有时甚至会急剧下滑。

这就像让一位从来只审查过 100 行 diff 的开发者，突然审查一份 10,000 行的 diff。这种能力不会自动迁移。

在 256K 时，Opus 得分为 93%；到 100 万 Token 时，则降至 76%。Sonnet 4.5 在 100 万 Token 时更是跌到 18.5%。仅仅拥有 100 万 Token 窗口，不代表模型能用好它。

预训练上下文长度与检索质量对比图

为什么上下文中间的内容容易被忽略

还有一个效应值得了解：模型不会对上下文窗口里的所有内容投入同等注意力。它们总是更关注开头和结尾，对中间部分则关注不足。研究人员称之为“迷失在中间”（lost in the middle）。

仍以代码审查为例：审查一份涉及 500 行改动的 PR 时，开头几个文件最能抓住你的注意力，最后几个文件仍清晰地留在脑海中，中间的文件却往往只是匆匆扫过。模型也有同样的偏差，而且这种偏差在预训练期间就已经固化进权重。

实际使用时，如果你采用 100 万 Token 上下文，并且有模型必须使用的关键信息，请将它放在上下文开头或结尾。放在中间无异于碰运气。

如何启用

在 Claude Code 中

使用带 [1m] 后缀的 /model 命令：

/model opus[1m]
/model sonnet[1m]
/model claude-opus-4-6[1m]
/model claude-sonnet-4-6[1m]

如果你的账户支持 100 万 Token 上下文，这些选项就会出现在模型选择器中。

不会因为选择了 100 万 Token 模型，计费就立即发生变化。上下文不超过 200K Token 时，你仍按标准费率付费；超过以后，溢价费率才会生效。

价格断崖

这是理解 100 万 Token 上下文时最重要的一点。它的定价并非线性增长，而是以 200K 输入 Token 为硬性阈值的阶跃函数。

为什么长上下文的服务成本更高

在看价格表之前，先说明一点：2 倍的价格乘数并非随意制定，背后有实实在在的基础设施成本。

上下文中的每个 Token，都需要模型在 GPU 内存里存储一小块数值状态——可以把它看作模型工作记忆所需的 RAM。在标准上下文规模下，Anthropic 能够在同一套硬件上并行运行许多会话，每个会话的内存占用都在可控范围内。

达到 100 万 Token 后，每个活跃会话仅为保存这些状态，就需要数百 GB 的 GPU 内存。这些内存不会与其他用户共享，而是只为你的会话预留，并贯穿会话始终。每台服务器能够容纳的会话更少，因此单个会话的成本也更高。

此外还有冷启动问题。首次打开一个没有缓存的 100 万 Token 会话时，模型必须从头处理每个 Token。在 100 万 Token 下，其计算量约为 200K 冷启动的 25 倍；在第一个 Token 抵达之前，所有计算都要先在 Anthropic 的服务器上完成。

缓存预热后，情况会显著改善。缓存读取会跳过重复计算——这就是为什么在 500K 上下文下，首 Token 时间（TTFT）能从 35 秒降至 3.5 秒（参见实验 3）。但内存成本并不会消失。即使是已经缓存的会话，也仍然需要在 GPU RAM 中保存所有这些状态。

2 倍溢价体现的正是 Anthropic 的基础设施成本：每个会话需要更多 GPU 内存，冷预填充需要更多计算，因此每次请求的成本更高。

标准上下文（输入不超过 200K） 长上下文（输入超过 200K） 倍数
Opus 4.6 输入 $5.00/M $10.00/M 2 倍
Opus 4.6 输出 $25.00/M $37.50/M 1.5 倍
Sonnet 4.6 输入 $3.00/M $6.00/M 2 倍
Sonnet 4.6 输出 $15.00/M $22.50/M 1.5 倍

关键细节是：一旦跨过 200K，所有 Token 都会按溢价计费，而不只是超过阈值的部分。输入为 201K Token 的请求，全部 201K Token 都要按溢价费率计算。

Opus 上的 199,000 个输入 Token：199K × $5.00/M  = $0.995
Opus 上的 201,000 个输入 Token：201K × $10.00/M = $2.010

跨过阈值的成本：多出 2,000 个 Token，成本却增加 $1.015。
这 2K Token 的实际费率：$507.50/M

这一点对提示词缓存同样适用。进入长上下文区间后，缓存读取和缓存写入都会乘上溢价倍数：

类别 标准上下文 长上下文
Opus 缓存读取 $0.50/M $1.00/M
Opus 缓存写入 $6.25/M $12.50/M
Sonnet 缓存读取 $0.30/M $0.60/M
Sonnet 缓存写入 $3.75/M $7.50/M

长上下文费率下仍可享受 90% 的缓存折扣，只不过折扣是从更高的基础价格开始计算。Opus 的缓存读取费率会从 $0.50/M 涨到 $1.00/M。

快速模式（fast mode）是一个例外。它的输入/输出定价分别为每百万 Token $30/$150，且在整个 100 万 Token 上下文窗口内统一适用，不会再叠加长上下文附加费。不过，即使订阅了 Max 套餐，快速模式也始终按额外用量计费，不包含在套餐的速率限制额度中。你只是把 2 倍的长上下文乘数换成了 6 倍的快速模式乘数。

实验

编写了一个脚本，通过真实 API 调用来测量上下文不断增长时会发生什么。以下发现。

实验 1：实际发生的价格断崖

逐步增加上下文规模，分别发送了 50K、100K、150K、199K 和 250K Token 的请求，并记录 API 响应中的 usage 字段。

前四个请求都保持在 200K 以下，按标准费率计费；第五个请求跨过了阈值。

从 199K 增至 250K 时，上下文只增加 25%，缓存读取成本却从 $0.099 跃升至 $0.250，增幅达到 2.5 倍。这个阶跃确实存在，而且来得十分突然。

实验 2：干草堆里找针

在不断变大的上下文中填满程序性的企业文本，并把一条特定事实——虚构的员工 ID 和薪资信息——分别埋在不同位置。然后，要求模型找出这条信息。

“干草堆”由合成的商业文档构成，包括季度报告、人力资源政策和工程规范。“针”则是一句话：“员工 Sarah Chen（ID：EMP-7429）在第三季度获得了 $8,750 的绩效奖金。”

脚本默认测试 50K、100K 和 200K。400K 与 600K 两行需要 Tier 4 访问权限（RUN_LARGE=1），按 Opus 长上下文费率计算，每次成本超过 $5。

Opus 4.6 结果：

上下文    针位于 25% 处    针位于 50% 处    针位于 75% 处
──────────────────────────────────────────────────────────
  50K      ✓ 正确            ✓ 正确            ✓ 正确
 100K      ✓ 正确            ✓ 正确            ✓ 正确
 200K      ✓ 正确            ✓ 正确            ✓ 正确
 400K*     ✓ 正确            ✓ 正确            ✓ 正确
 600K*     ✓ 正确            ✓ 正确            ~ 部分正确

* 需要 Tier 4 访问权限（RUN_LARGE=1）

Opus 4.6 在不超过 400K 时表现出色，准确率堪称完美。达到 600K 后，在 75% 深度位置的检索开始变得模糊：它能返回正确的员工姓名，但有时会编造奖金金额或将其错误归给其他人。

Sonnet 4.6 结果：

上下文    针位于 25% 处    针位于 50% 处    针位于 75% 处
──────────────────────────────────────────────────────────
  50K      ✓ 正确            ✓ 正确            ✓ 正确
 100K      ✓ 正确            ✓ 正确            ✓ 正确
 200K      ✓ 正确            ✓ 正确            ~ 部分正确
 400K*     ~ 部分正确        ✗ 未找到          ✗ 未找到
 600K*     ✗ 未找到          ✗ 未找到          ✗ 未找到

* 需要 Tier 4 访问权限（RUN_LARGE=1）

Sonnet 的退化速度要快得多。到 400K 时，它已经不再可靠；到 600K 时，基本只是在猜测。

Anthropic 自己公布的 MRCR v2 数据也印证了这一点。在 100 万 Token、包含 8 根“针”的变体上，Anthropic 的 Opus 4.6 发布公告给出了以下结果：

模型 MRCR 得分
Opus 4.6 76.0%
Gemini 3 Pro 26.3%
Sonnet 4.5 18.5%

关于 Gemini 的数字需要说明：Gemini 3 Pro 比 Gemini 1.5 Pro 更新；后者才是从预训练之初就专门面向 100 万 Token 上下文打造、并在 Google 自家测试中取得近乎完美召回率的模型。它们是同一家族的不同代际产品。26.3% 是 Anthropic 在自家基准测试中测得的 Gemini 3 Pro 得分，并不能反映 Gemini 1.5 Pro 曾经达到的表现。

Opus 在 256K 时得分为 93%，在 100 万 Token 时为 76%。Sonnet 4.5 到 100 万 Token 时则跌至 18.5%。Anthropic 尚未公布 Sonnet 4.6 的 MRCR 得分；它或许比 4.5 表现更好，但在数据公布之前，仍应保持谨慎。仅仅拥有 100 万 Token 窗口，不代表模型能用好它。

研究人员称这一现象为“上下文腐化”（context rot），即随着序列增长，注意力质量逐渐退化这一有充分记录的规律。每个 Transformer 都或多或少存在这一问题，而 Opus 4.6 抵抗它的能力远胜以往模型。

实验 3：延迟

使用流式请求，在不断增大的上下文规模下测量首 Token 时间（TTFT）。每个规模都运行三次调用：一次用于预热缓存的写入、一次缓存读取（热启动），以及一次使用独特系统提示词以防复用缓存的无缓存冷请求。

脚本默认测试 50K、100K 和 200K。300K 与 500K 两行需要 Tier 4 访问权限（RUN_LARGE=1）。你可以亲自运行实验，获得符合自身网络状况的数据；下表展示的是变化规律，而非放之四海皆准的常数。

上下文      TTFT（已缓存）    TTFT（冷启动）
──────────────────────────────────────────
  50K        ~0.8 秒           ~2 秒
 100K        ~1.1 秒           ~4 秒
 200K        ~1.6 秒           ~9 秒
 300K*       ~2.2 秒           ~16 秒
 500K*       ~3.5 秒           ~35 秒

* 需要 Tier 4 访问权限（RUN_LARGE=1）
  冷启动 = 没有缓存，模型从头处理所有 Token
  已缓存 = 上一次请求已将缓存预热

有两点尤为突出：

  1. 冷预填充按超线性速度增长。 上下文越多，等待时间就以不成比例的幅度延长。面对 500K 个未缓存的 Token，模型开始响应前要等待 30 多秒。按照这条曲线外推到 100 万 Token（幂律指数约为 1.24），模型开始响应前很可能要等待 60～90 秒。
  2. 缓存预填充很快。 有热缓存时，即使 500K 上下文也只会增加几秒钟。模型会加载已保存的状态，而不是从头重新处理所有内容。这正是提示词缓存的底层原理：模型存储上下文处理后的状态，后续轮次便无需再次完整读取。（如果你还没有看过提示词缓存深度解析，那么在深入研究 100 万 Token 上下文之前，很值得先理解这套机制。）

实际影响是：100 万 Token 上下文会话中的第一条消息很慢，后续消息则没有问题——前提是缓存始终保持热状态（TTL 为 5 分钟，每次使用都会重置）。

如果你在会话中离开键盘 6 分钟，导致缓存过期，那么下一条消息若处于 500K 上下文，模型将需要 30 多秒才会开始响应。这就是冷重启的代价。

何时应使用 100 万 Token 窗口

适合以下场景：

单次完成大型文档分析——在一次请求中输入完整的代码库、合同或研究资料库。模型只需读取一遍全部内容，进行推理并给出响应。由于没有多轮对话分散注意力，上下文腐化程度很小。这正是该窗口为之打造的用例。

不能承受上下文丢失的深度调试会话。 当你要跨越 15 个文件追查错误，而完整堆栈跟踪、复现步骤和已经失败的假设都不可或缺时，压缩恰恰会破坏你最需要的信息。

拥有大量共享状态的智能体团队。 当多个智能体读取文件、分享发现并在彼此成果上继续推进时，累积上下文会迅速增长。100 万 Token 窗口让团队负责人能够保留所有智能体报告，而无需压缩。

需要精确引用的合规与审计工作。 如果需要模型引用一份 300 页合同或大型政策文档中的具体段落，100 万 Token 窗口可以一次把全文放入上下文，而不必切成碎片，再寄希望于没有内容从缝隙中漏掉。

不适合以下场景：

常规 Claude Code 会话。 数据显示，大多数会话在压缩前的上下文峰值为 80K～120K。它们从未接近 200K，更不需要 100 万 Token。即使选择 100 万 Token 模型，仍会按标准费率付费——与 200K 模型并无区别。

本就适合重新开始的长会话。 经过 80 多轮以后，模型往往能从清空重来中受益。早期轮次里的陈旧上下文反而可能造成伤害：模型把注意力浪费在已经无关的前期探索上，而不是专注于当前任务。执行 /clear 后重新开始，往往比压缩和 100 万 Token 上下文都更好。

在 100 万 Token 下使用 Sonnet 4.5。 Sonnet 4.5 在 100 万 Token 下的 MRCR 得分仅为 18.5%；你要按 2 倍溢价付费，换来的却是模型几乎无法利用的上下文。Sonnet 4.6 可能表现更好（目前尚无公开的 MRCR 得分），但在数据公布之前，长上下文检索任务应默认选择 Opus。

经常离开键盘的会话。 缓存 TTL 只有 5 分钟，因此 500K 上下文的冷重启需要 30 多秒。按照延迟数据外推到 100 万 Token，等待时间将达到 60～90 秒。如果你不断在任务间切换，喝完咖啡才回来，这种延迟惩罚会非常难受。

决策框架

选择 100 万 Token 上下文窗口的决策框架

启用前值得了解的五件事

  1. 上下文保持在 200K 以下时，选择 opus[1m] 不会产生额外成本。让这个选项可用并没有坏处——在跨过阈值之前，100 万 Token 模型的行为与标准模型完全相同。
  2. 一旦跨过 200K，包括缓存 Token 在内的所有 Token 都要支付 2 倍溢价。上下文达到 400K 的会话，与压缩后保持在 80K 的会话相比，每轮成本约为 5 倍。压缩税（$0.21）很便宜，长上下文税却不便宜。
  3. 长上下文工作应使用 Opus，而不是 Sonnet。Opus 4.6 在 100 万 Token 下的 MRCR 得分为 76%；Sonnet 4.5 只有 18.5%。无论选择哪一个都要付溢价，而 Opus 才真正有能力使用这些上下文。
  4. 最理想的场景是单次分析。把大型代码库或文档资料库放进一个请求。这样上下文腐化最少，溢价只需支付一次而不是每轮支付，也无需操心缓存管理。
  5. 对大多数编程任务而言，更好的会话管理胜过更大的窗口。有意识地用 /clear 划分边界、让子智能体负责探索、采用“转储并清空”（dump-and-clear）模式——这些做法都能让上下文保持精简、缓存保持热状态、成本维持低位。面对大多数编程任务，注意力集中的 50K 上下文会胜过注意力被稀释的 500K 上下文。