1M 上下文不是免费午餐：超过 200K 输入价格翻倍，怎么算账怎么控

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 都翻倍。在这个坎附近做好控制，能省的钱比你想象中多。

参考链接

长上下文定价：https://platform.claude.com/docs/en/about-claude/pricing#long-context-pricing
上下文窗口文档：https://platform.claude.com/docs/en/build-with-claude/context-windows
Token Counting API：https://platform.claude.com/docs/en/build-with-claude/token-counting