Claude 的 100 万 token 上下文：什么时候真用得上

哪些 Claude id 真的有 100 万上下文

目录里 12 个 Claude id，有 9 个是 100 万 token 上下文加 12.8 万输出上限：claude-opus-5、claude-opus-4-8、claude-opus-4-6、claude-sonnet-5，它们各自的 stable-* 版本，以及两个 Fable——stable-claude-fable-5 和 stable-claude-fable-5-1。

另外三个不是。claude-sonnet-4-6 和 stable-claude-sonnet-4-6 按 20 万 token 上下文、6.4 万输出提供；stable-claude-haiku-4-5 同样是 20 万和 6.4 万。

值得注意的是上下文大小和价格并不挂钩：claude-sonnet-5 给满 100 万，官方 3/15 美元、0.1 倍率，和只有 20 万上下文的 claude-sonnet-4-6 官方定价一模一样。你多付或少付的钱，不是为窗口付的。

装满一次要花多少钱

在把架构建立在大窗口之上以前，先把账算清楚。claude-sonnet-5 输入官方 3 美元每百万、0.1 倍率，实付 0.30 美元。所以把上下文填满一次，Sonnet 5 的输入成本是 0.30 美元，claude-opus-5 是 0.50 美元（官方 5 美元每百万，同样 0.1 倍率）。

但真正要留意的不是这一次调用，而是对话每一轮都会把上下文重发一遍。一个二十轮、始终维持接近满窗的会话，等于把将近一百万 token 发了二十次——账单上的输入项随轮数线性增长，答案质量并不会。

所以"把整个仓库贴进去"是一个花钱的决定，不是一种技巧。不管这些 token 有没有承重，模型都按同样的单价收。

# max_tokens 1 keeps the answer short so usage.input_tokens is what you are reading.
curl -sS https://token-share.app/v1/messages \
  -H "x-api-key: $TOKEN_SHARE_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "max_tokens": 1,
    "messages": [{"role": "user", "content": "Paste the working set you were about to send here."}]
  }' | jq '.usage'

# claude-sonnet-5 bills $0.30 per 1M input tokens.
# input cost = input_tokens / 1e6 * 0.30, charged again on every turn that resends it.

什么时候这个空间是真值

当"不用大窗口"的代价比 token 钱更高时，这个窗口就值了。最清楚的情形是工作集切不开：schema 加上所有动过它的 migration，或者一个必须同时看三个服务才说得通的 bug——硬拆开的结果往往是每一块都答对了，合起来是错的。

第二种是长时间的 agent 跑批。工具调用循环会不断累积 transcript，本来跑到一半就得截断或者做摘要的会话，现在可以直接往下走。你买到的是"少了一道压缩工序"，不是"推理变强了"。

还有一个常被忽略、但很多人真正需要的是 12.8 万的输出上限（1M 那批 id 都有）。一次生成一个长文件或者一整套迁移脚本，卡住你的是 max output，不是 context。

空间不等于记忆，缓存才是杠杆

窗口大，不代表模型对里面的一切都同样上心。把跟问题无关的材料塞满上下文，既加钱又给模型增加了筛选负担；很多时候一个更短、挑得更准的 prompt 反而答得更好，还更便宜。

当长前缀确实会在多轮之间重复时——系统提示词、对话反复回头看的那份规格——让大窗口变得付得起的是 prompt caching。缓存读取是单独一类计价，与新输入分开，稳定前缀就不必每轮按全价输入重算一遍。

判断方法很朴素：量一下每次请求实际发出去多少 input token，再看其中有多大比例是上一轮之后才变的。如果绝大部分逐轮不变，该做的是缓存；如果大部分都在变，那窗口确实在干活，这钱花得实。

常见问题