Opus 4.6 第一次给 Opus 级别的模型开了 1M token 的上下文窗口。以前只有 Sonnet 有这个能力，现在旗舰模型也能塞进去一整个中型项目的代码了。
但这个 1M 窗口有个不那么显眼的价格条件：输入超过 200K token 后，整个请求的价格翻倍。不是超出部分翻倍，是整个请求的所有 token 都按高价计费。
很多人看到"1M context"就兴奋，没细看价格表。上线后发现账单不对劲——这篇就把这个账算清楚。
价格结构
| 输入 token 数 | 输入价格 | 输出价格 |
|---|---|---|
| ≤ 200K | $5/MTok | $25/MTok |
| > 200K | $10/MTok | $37.50/MTok |
关键细节：200K 的阈值只看输入 token，包括 input_tokens + cache_creation_input_tokens + cache_read_input_tokens。输出 token 数不影响是否触发溢价，但一旦触发，输出价格也跟着涨。
举个例子。你发了一个请求，输入 250K token，输出 2K token。
正常价格（如果没超 200K）：250K × $5 + 2K × $25 = $1.25 + $0.05 = $1.30
实际价格（超了 200K）：250K × $10 + 2K × $37.50 = $2.50 + $0.075 = $2.575
差了一倍。
再看一个更极端的场景：输入 199K 和 201K 的差异。
199K 输入 + 2K 输出：$0.995 + $0.05 = $1.045
201K 输入 + 2K 输出：$2.01 + $0.075 = $2.085
多了 2K 个 token（大概多了 4-5 段文本），成本翻了一倍。这个阶梯效应非常陡。
怎么判断是否被收了溢价
API 响应的 usage 字段里有三个数字：
{
"usage": {
"input_tokens": 210000,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 0,
"output_tokens": 1500
}
}
三者加起来超过 200,000，就是按溢价计费了。
建议在调用层加一个检查：
def check_long_context_pricing(usage):
total_input = (
usage.input_tokens
+ usage.cache_creation_input_tokens
+ usage.cache_read_input_tokens
)
if total_input > 200_000:
print(f"警告：长上下文溢价已触发，总输入 {total_input} tokens")
return total_input > 200_000
什么时候该用 1M，什么时候不该
该用的场景：
你需要让模型一次性看到大量相关内容，而且这些内容之间有关联，拆开喂会丢失信息。比如审查一整个微服务的代码（通常 100K-300K token）、分析一份 200 页的合同、或者在一个大型日志文件里找异常。
Anthropic 在 MRCR v2 测试里展示了一个数据：Opus 4.6 在 1M 的 8 针"大海捞针"测试里拿了 76%，Sonnet 4.5 只有 18.5%。也就是说 Opus 4.6 不只是"能装下"，还"真的能用"——在超长上下文里保持注意力的能力强了好几倍。
不该用的场景：
你可以把内容拆开处理，或者通过 RAG 检索只喂相关片段。绝大多数场景不需要一口气塞 200K+ token 进去。
一个常见的反模式：把整个代码仓库塞进上下文"以防万一"。这不仅贵，还会稀释模型对关键信息的注意力。先用 RAG 或文件树筛选，只送相关文件进去，效果通常更好。
控制策略
1. 请求前预检
发请求之前先算一下 token 数（用 Anthropic 的 Token Counting API）。超过阈值就决定：要不要拆、要不要削。
count = client.messages.count_tokens(
model="claude-opus-4-6",
messages=messages
)
if count.input_tokens > 180_000: # 留 20K 余量
messages = trim_context(messages) # 你自己的裁剪逻辑
2. 阈值附近的优化空间
如果你的输入经常在 180K-220K 之间浮动，优化的收益最大。砍掉 20K token，可能省一半的钱。
优先砍的内容：
- 对话历史中的旧轮次（尤其是简单的确认和重复）
- 工具调用的中间结果（保留最终结果就行）
- 重复出现的上下文信息
3. 跟 Prompt Caching 叠加
长上下文溢价和 Prompt Caching 是独立计算的。超过 200K 后，缓存写入和缓存命中的价格也跟着涨：
| 项目 | ≤ 200K | > 200K |
|---|---|---|
| 缓存写入（5分钟） | $6.25/MTok | $12.50/MTok |
| 缓存命中 | $0.50/MTok | $1.00/MTok |
即使缓存命中的单价也翻倍了，但相对于未缓存的 $10/MTok 来说，$1.00/MTok 还是划算得多。如果你一定要用长上下文，缓存是必开的。
4. 考虑 Batch API
Batch API 的 50% 折扣同样适用于长上下文场景。如果你的任务不需要实时返回（比如批量文档分析），用 Batch 可以把 $10/MTok 降到 $5/MTok——刚好跟标准价一样。
1M beta 的准入条件
1M 上下文目前是 beta 功能，只对 Usage Tier 4 和自定义费率的组织开放。你不是想用就能用的。
如果你在 Tier 1-3，请求超过 200K token 会直接报错，不是按溢价计费。要么升级 Tier，要么控制输入长度在 200K 以内。
一个决策树
你的输入 token 数是多少？
├── < 150K → 正常用，不用想太多
├── 150K - 200K → 有优化空间，能砍就砍
├── 200K - 300K → 问自己：能用 RAG 替代吗？
│ ├── 能 → 用 RAG，控制在 200K 以内
│ └── 不能 → 上 1M，开缓存，考虑 Batch
└── > 300K → 确认你真的需要模型一次性看到所有内容
├── 是 → 上 1M + 缓存 + Batch + 预算监控
└── 不是 → 拆成多次请求
200K 是个硬坎。多一个 token 都翻倍。在这个坎附近做好控制，能省的钱比你想象中多。
