作者： Claude输入与输出Token成本为何相差5倍？
Claude输出 token 价格是输入的5倍。本文解释 Prefill 与解码的速度差异，并计算长上下文代理和长篇起草任务对每月账单的实际影响。
为什么输出 token 的成本高于输入 token
当前目录中的每个 Claude 模型，输出 token 的成本都是输入 token 的 5 倍。这是由计算方式决定的。读取提示词只需对模型执行一次计算。生成回复则需要为每个 token 执行一次计算，而且每次计算都必须等待前一次完成。
价格表中的每一行都采用相同比例，因此选择的模型不会改变账单中输出 token 所占的成本。决定成本的是工作负载的结构。一个读取 60,000 个 token、生成 800 个 token 的 agent 步骤，输出成本几乎可以忽略。一个读取 2,000 个 token、生成 12,000 个 token 的起草任务，输入成本几乎可以忽略。下面根据 Anthropic 发布的费率，使用 2026 年 10 月 27 日核对的数据，分别分析这两种情况。
预填充只运行一次，解码每个 token 运行一次
推理服务器分两个成本差异很大的阶段处理请求。预填充读取提示词。解码生成回复。
预填充一次处理整个提示词。每个提示词 token 都在同一次前向传播中进入网络，因此注意力和前馈计算会转化为少量大型矩阵乘法，每次覆盖数千个 token。模型权重只需从内存中读取一次，就能处理整个提示词。加速器的矩阵计算单元会保持繁忙，因此预填充通常受计算能力限制：瓶颈在于芯片执行矩阵乘法的速度。NVIDIA 的服务文档指出了例外情况：非常短的预填充，以及已有较长前缀命中缓存的预填充，会转而受内存带宽限制。
普通解码无法采用这种方式，因为 token 2 依赖 token 1。模型刚生成的 token 会成为下一步的输入，因此各步骤必须依次运行。每个输出 token 都需要单独进行一次前向传播，并且每次传播都要从高带宽内存中读取完整的模型权重，以及 KV 缓存（key/value cache，即截至当前 token 保存的注意力状态），才能生成一个 token。因此，解码通常受内存带宽限制：瓶颈在于权重和缓存状态的传输速度，而不是矩阵乘法速度；对于长上下文，NVIDIA 特别指出 KV 缓存读取是瓶颈。预填充处理整个提示词所消耗的同等权重传输量，在解码阶段只能生成一个 token。
推测解码改变了这一规则，但没有违背它。小型草稿模型会提前预测多个 token，大型模型在一次传播中并行检查这些 token；NVIDIA 表示，这可能使解码转为更受计算能力限制。大型模型仍会按顺序接受这些预测，并在第一个错误预测处停止，因此长回复仍需要进行多次传播。
服务系统会通过批处理来缓解这一限制。多个请求同时解码，因此一次读取权重就能为批次中的每个请求各生成一个 token。这正是解码仍然可承受的原因。上限再次取决于内存。每个正在处理的请求都拥有自己的 KV 缓存，该缓存会随生成的每个 token 增长；当加速器内存被填满后，批次就无法继续扩大。
这些因素都无法给出精确数字，因此不应将 5x 理解为经过测量的硬件比例。这是 Anthropic 根据这种不对称性确定的价格。你可以自行验证的是趋势，而这大约只需一分钟。
自行测量输入与输出之间的差距
在任意 Ubuntu 主机上安装工具：
sudo apt update && sudo apt install -y curl jq moreutils现在发送一个要求长回答的简短提示，并记录每一行到达的时间。
curl -sN https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
"messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
| ts -s '%.s'ts -s 会在每行前添加自命令开始以来经过的秒数。输出中有两点值得关注。第一行 content_block_delta 是首个 token 的耗时，所有 prefill 都在这一行内完成。之后的每一行都是一次小的解码步骤，时间戳会持续增加，直到 message_stop 到达。
现在反转这个形状。在提示中放入一篇长文档，并将回答限制为几个 token。
curl -sN https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d "$(jq -n --rawfile doc ./long-document.txt \
'{model:"claude-sonnet-5", max_tokens:16, stream:true,
messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
| ts -s '%.s'第一个时间差比使用简短提示时更长，因为 prefill 需要读取的文本多得多。它到达后，响应几乎立即结束，因为只剩几个 token 需要解码。输入了数万个 token，但时钟几乎没有变化。输出了几百个 token，但时钟在整个过程中都持续运行。
每个非流式响应都会以计费所依据的数字结尾。
{
"usage": {
"input_tokens": 41283,
"output_tokens": 6,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 0
}
}记录每个请求的全部 4 个字段。output_tokens 包含思考 token，因此模型在回答前进行思考时，这些思考 token 会按输出速率计费。要在发送提示前估算其价格，POST /v1/messages/count_tokens 对大多数请求使用相同的请求正文，返回 {"input_tokens": N} 作为估算值而不运行模型，并且在其自身的速率限制内免费。它会拒绝一些 Messages API 接受的请求正文：大多数服务器工具，例如 web search、MCP connector，以及源为 url 或 file 的图像或文档块。因此，统计这类内容时，应将图像和 PDF 作为 base64 发送。API 中并非只有这一部分不收费；在为第一个项目编制预算前，值得查看 Claude API 中哪些部分永远不会向您收费。
截至 2026 年 10 月 Claude 每百万 token 的收费
此图表背后的数据
[
{
"label": "Haiku 4.5",
"input_usd": 1,
"output_usd": 5,
"output_multiple": 5
},
{
"label": "Sonnet 5",
"input_usd": 2,
"output_usd": 10,
"output_multiple": 5
},
{
"label": "Opus 5",
"input_usd": 5,
"output_usd": 25,
"output_multiple": 5
},
{
"label": "Fable 5",
"input_usd": 10,
"output_usd": 50,
"output_multiple": 5
}
]最后一列是输出价格除以输入价格，每一行都显示为 5。Haiku 4.5 的输入价格为 $1，输出价格为 $5。Opus 5 的输入价格为 $5，输出价格为 $25。Fable 5 最贵，输入价格为 $10，输出价格为 $50；在您直接放弃最高价位之前，值得先阅读Fable 5 的这些价格能为您带来什么。沿价格区间向上移动时，输入和输出价格会同时乘以相同的倍数，因此总费用会变化，但输入与输出的比例保持不变。
Sonnet 5 的输入价格为 $2，输出价格为 $10。Anthropic 将这一价格作为介绍性定价，持续到 2026 年 8 月 31 日；原计划在 9 月 1 日上调至 $3 和 $15，之后改为将 $2 和 $10 设为标准价格。此次上调从未生效，因此下面每个示例使用的都是您今天实际支付的价格。
自本页面首次发布后，Anthropic 还发布了更新的模型；claude.com/pricing 目前将上面四个模型列为仍可用的旧版模型。新模型仍保持相同的 5 倍比例。Opus 5.5 的收费为 $4 和 $20，Sonnet 5.5 的收费为 $2 和 $10，Fable 5.1 的收费为 $10 和 $50；Haiku 5.5 对不超过 100,000 token 的提示词收费 $0.10 和 $0.50，超过该数量后收费提高到 $0.50 和 $2.50。下面进一步计算的 60,000 token agent 步骤低于这一界限，但如果 agent 的历史记录持续增长，最终会超过该界限；Haiku 5.5 的两个价格层级在实际任务中的表现说明了这一跳升会如何影响账单。Opus 5.5 的基础输入和输出价格比 Opus 5 低 20%，因此下面所有未使用缓存的 Opus 5 费用，在 Opus 5.5 上都会低 20%。使用缓存时费用还会进一步下降，因为 Opus 5.5 读取缓存命中内容的价格是每百万 token $0.20，而 Opus 5 是 $0.50，降幅为 60%。下面的 Opus 5 缓存 agent 步骤费用为 $0.0725，在 Opus 5.5 上约为 $0.047，低约 35%。
价格会变化，因此不应在此页面查询价格。claude.com/pricing 是权威来源。价格变化后仍然适用的是计算方法。
Anthropic 价格表下方的注释中还有一个注意事项，而不是价格本身的一部分。Anthropic 的定价页面说明，Claude 4.7 及更高版本的模型使用更新的 tokenizer；对于相同文本，它生成的 token 数量比 Sonnet 4.6 及更早版本使用的 tokenizer 约多 30%。如果只比较每百万 token 的价格，较新的模型会显得更划算，因为同一份文档在该模型上会产生更多 token。应比较完成一项任务的成本，并根据您实际计划使用的模型统计真实提示词的 token 数量。不同供应商之间也存在同样的陷阱，因为它们使用的 tokenizer 也各不相同，因此分别计算同一项实际任务在 Claude 和 ChatGPT 上的费用，比把两张价格表并排比较更有参考价值。一百万 Claude token 在实际文本中相当于什么介绍了这一数量在实践中的表现。
输出何时开始占据账单的大头？
当输出的定价是输入的 5 倍时，盈亏平衡点很容易记住。将输入 token 数记为 I，将输出 token 数记为 O。输入成本为 I。输出成本为 5 乘以 O。当 5 乘以 O 大于 I 时，输出成本超过总支出的一半，此时输入与输出的 token 数比例为 5:1。
因此，如果提示词长度超过回复长度的 5 倍，输入就是更大的成本项。低于这一比例时，输出成本更高。
此图表背后的数据
[
{
"label": "100:1",
"input_share_pct": 95.2,
"output_share_pct": 4.8
},
{
"label": "75:1",
"input_share_pct": 93.75,
"output_share_pct": 6.25
},
{
"label": "20:1",
"input_share_pct": 80,
"output_share_pct": 20
},
{
"label": "10:1",
"input_share_pct": 66.7,
"output_share_pct": 33.3
},
{
"label": "5:1",
"input_share_pct": 50,
"output_share_pct": 50
},
{
"label": "1:1",
"input_share_pct": 16.7,
"output_share_pct": 83.3
},
{
"label": "1:6",
"input_share_pct": 3.2,
"output_share_pct": 96.8
}
]当比例为 100:1 时，输出占总支出的 4.8%，此时只有压缩提示词值得投入精力。比例为 5:1 时，输入和输出成本相等。比例为 1:6 时，输出占 96.8%，提示词成本可以忽略不计。大多数人都会错误估计自己的比例，因此在进行任何优化前，先从日志中获取实际数据。
Agent 工作负载：输入长上下文，输出短答案
执行一个检索 agent 步骤：输入 60,000 个检索文档和对话历史 token，输出 800 token 的答案。这相当于 75 比 1。对于任何先读取、后生成的任务来说，这很正常。
此图表背后的数据
[
{
"label": "Haiku 4.5",
"input_cost": 0.06,
"output_cost": 0.004,
"total_cost": 0.064
},
{
"label": "Sonnet 5",
"input_cost": 0.12,
"output_cost": 0.008,
"total_cost": 0.128
},
{
"label": "Opus 5",
"input_cost": 0.3,
"output_cost": 0.02,
"total_cost": 0.32
},
{
"label": "Fable 5",
"input_cost": 0.6,
"output_cost": 0.04,
"total_cost": 0.64
}
]在每个模型上，输出都占该调用的 6.25%，因为整个价格表中的比例都是固定的。该调用在 Opus 5 上的成本为 $0.32，在 Sonnet 5 上为 $0.128，在 Haiku 4.5 上为 $0.064。每天在 Opus 5 上执行 200 个此类步骤，成本为每天 $64。
了解输入和输出的比例后，优化重点就很明确。将答案从 800 token 减少到 400 token，只能节省约 3% 的调用成本。将提示中的 20,000 个过时上下文 token 删除，可节省约三分之一的成本。对于以读取为主的 agent，限制输出长度几乎是在浪费精力。编程 agent 的 token 实际消耗位置详细说明了这些提示内容的来源。
一次生成工作负载：短提示词，长草稿
现在反过来看。一个 2,000 token 的简介，一份 12,000 token 的草稿，比例为 1 比 6。
此图表背后的数据
[
{
"label": "Haiku 4.5",
"input_cost": 0.002,
"output_cost": 0.06,
"total_cost": 0.062,
"batch_total_cost": 0.031
},
{
"label": "Sonnet 5",
"input_cost": 0.004,
"output_cost": 0.12,
"total_cost": 0.124,
"batch_total_cost": 0.062
},
{
"label": "Opus 5",
"input_cost": 0.01,
"output_cost": 0.3,
"total_cost": 0.31,
"batch_total_cost": 0.155
},
{
"label": "Fable 5",
"input_cost": 0.02,
"output_cost": 0.6,
"total_cost": 0.62,
"batch_total_cost": 0.31
}
]输出成本占这笔费用的 96.8%。使用 Opus 5 时，每份草稿的费用为 $0.31，而 Haiku 4.5 为 $0.062。这 5 倍的差距几乎完全来自输出部分，而这正是低价模型最能帮您节省费用的地方。
最后一列表示通过 Batch API 完成同一任务的费用；该 API 将输入和输出费用都降低 50%。使用 Opus 5 时，每份草稿的费用降至 $0.155。Batch 是异步的，不会立即返回结果。Anthropic 表示，大多数批处理会在 1 小时内完成；但如果批处理在 24 小时后仍在处理，就会过期，其中截至该时间尚未处理到的请求也会返回为已过期、不计费且不包含消息。因此，它适合夜间生成报告和批量分类，但对任何过期的请求都需要重新提交。不适合让人坐着等待结果的任务。
在这里，模型路由的价值体现在生成步骤上，而不是代理步骤上。如果工作中较长的部分是机械性的，例如重新格式化文本或扩展您已经批准的大纲，那么低价模型可以以五分之一的价格生成这些 token。在 Opus、Sonnet 和 Haiku 之间进行选择有助于确定质量界限的实际位置。
缓存只降低输入成本，不降低输出成本
Prompt caching 会将 prompt 的前缀存储在服务器上，再次读取时按输入价格的一小部分收费。截至 2026 年 10 月 27 日，在本页列出的模型中，写入 5 分钟缓存的价格是基础输入价格的 1.25x，写入 1 小时缓存的价格是 2x，命中缓存后的读取价格是 0.1x。最新模型的缓存命中读取价格更低：Opus 5.5 和 Sonnet 5.5 为 0.05x，Fable 5.1 为 0.025x。
输出不包含在这项优惠中。不存在缓存的输出。模型每次生成的每个 token 都按完整输出价格计费，无论 prompt 中有多少内容命中缓存。
在 Opus 5 上执行相同的 agent 步骤，其中 60,000 个输入 token 中有 55,000 个来自热缓存。
此图表背后的数据
[
{
"label": "No cache",
"input_cost": 0.3,
"output_cost": 0.02,
"total_cost": 0.32
},
{
"label": "55k prefix cache read",
"input_cost": 0.0525,
"output_cost": 0.02,
"total_cost": 0.0725
}
]调用成本从 $0.32 降至 $0.0725。输出成本没有变化：调用前为 $0.02，调用后为 $0.02。缓存会降低账单，并改变成本构成。输出原本占该调用成本的 6.25%。现在已超过四分之一，因此下一步应该优化的成本项也随之改变。
首次调用需要支付写入费用。写入 5 分钟缓存的成本是基础输入价格的 1.25x，因此一次命中后即可收回成本。写入 1 小时缓存的成本是 2x，因此需要两次命中。写入和读取乘数，以及缓存何时不再划算详细说明了这一计算过程。
您可以控制的 4 个杠杆
- 将
max_tokens设置为输出长度的 p95，而不是模型最大值。 - 将冗长步骤路由到更便宜的模型。
- 将任何无人等待的任务进行批处理。
- 删除会拉长回复的指令。
max_tokens 是硬上限。单独提高它不会产生费用，因为您只需为实际生成的 token 付费，而无需为上限付费。宽松的上限会取消对异常回复长度的限制。从日志中提取 output_tokens 分布，将上限设置为略高于第 95 百分位，并在代码中通过继续响应或重试来处理 stop_reason: "max_tokens"。检测到截断的成本低于支付 4,000 个 token 的冗长回复后再将其丢弃的成本。思考内容也会计入 output_tokens，并计入 max_tokens，因此应根据相同的数据设置上限；对于支持自适应思考的模型，如果思考内容持续占用回复空间，应降低 effort 级别。
当某个步骤的昂贵部分是处理量而非判断时，路由才有效。让能力更强的模型负责决策，再将文字生成交给更便宜的模型。首先在您自己的评估集上测量路由后的版本，因为真正重要的是每个已完成任务的成本。在上面的 agent 步骤中，两次 Haiku 4.5 尝试的成本为 $0.128，而一次 Opus 5 尝试的成本为 $0.32，因此价格差可以覆盖一两次重试。但它无法弥补无人发现的错误答案。
批处理是唯一能降低输出价格的杠杆。输入和输出两部分都可享受 50% 折扣，大多数批处理任务会在一小时内完成；任何按计划运行的任务也符合条件，前提是任务会重新提交在 24 小时标记处过期的内容。
最后一个杠杆最容易被忽略。“务必全面”和“解释你的推理过程”之类的短语会增加您今后每次调用的输出长度。将它们替换为您需要的具体格式，例如：“最多用 3 句话回答”，或“只返回 JSON 对象，不要添加前言”。系统提示每次让回复增加 300 个 token，其成本是提示中同样 300 个 token 成本的 5 倍。控制持续运行的 agent 成本介绍了监控方面的内容；在花一周调整按 token 计费的支出之前，最好先确定对于您的使用模式，API 还是固定订阅更便宜，因为订阅可能已经覆盖了这部分费用。对某个主要由一名开发者使用的场景来说，关键在于Claude Pro 每月 $20 的费用及其使用限制是否足以覆盖原本需要按量计费的工作。如果您已经在会话中途触及这些限制，应先弄清楚您正在等待哪个时间窗口，因为之后的解决方案可能是使用更小的模型、减少上下文、增加用量额度，或将这部分工作迁移到按量计费的 API。如果按量计费的 API 最终证明承载这部分工作更便宜，那么降级到更低级别的套餐或取消订阅不会影响您已经支付的当月服务，因此切换时不会产生退出成本。如果您正在与 Pro 比较的套餐是 ChatGPT 的套餐，而不是按量计费的 API，那么并列展示两个订阅层级的价格可以说明哪个方案对编码工作更便宜。如果这个问题针对的是团队而不是单个开发者，请注意，Claude Enterprise 将按席位收取的费用与按这些相同 API 费率计量的 token 结合起来，因此本页介绍的每个杠杆仍适用于账单中按量计费的部分。
FAQ
为什么输出 token 比输入 token 更贵？
生成输出 token 所需的加速器时间多得多。处理提示词时，模型会在一次前向传递中处理全部内容，因此一次读取模型权重即可覆盖数千个 token，硬件通常受乘法吞吐量限制。普通解码会逐个生成回复 token，每个 token 都需要单独进行一次前向传递，并再次读取模型权重和不断增长的 KV cache，因此硬件通常受内存带宽限制。推测解码等技术可以缩小这一差距，但无法消除差距。Anthropic 目前整个产品目录中的输出价格都是输入价格的 5 倍，从 Haiku 5.5 到 Fable 5.1 都是如此。
prompt caching 会降低输出 token 的价格吗？
不会。Prompt caching 只适用于输入。截至 2026 年 10 月 27 日，大多数模型的 cache read 费用是基础输入价格的 0.1 倍（Opus 5.5 和 Sonnet 5.5 为 0.05 倍，Fable 5.1 为 0.025 倍）；cache write 的费用在 5 分钟有效期内为 1.25 倍，在 1 小时有效期内为 2 倍。无论 cache 的处理结果如何，每次调用的输出都按完整价格计费。因此，缓存不仅会改变账单金额，也会改变账单构成：输入成本降低后，输出就成为最值得优化的部分。
如果回复很短，较高的 max_tokens 会增加费用吗？
不会。您只需为模型实际生成的 token 付费，因此 max_tokens 是上限，不是预留额度。但它仍然很重要，因为这是限制失控回复的唯一硬限制。将其设置为略高于您观测到的 output_tokens 的第 95 个百分位，然后在代码中处理 stop_reason: "max_tokens"，不要直接发布被静默截断的答案。
如何计算自己的输入与输出 token 比例？
从每个响应的 usage 对象中记录 input_tokens、output_tokens、cache_read_input_tokens 和 cache_creation_input_tokens，然后按一周的总量计算比例。如果输入与输出的比例高于 5:1，成本主要在提示词上，因此应缓存稳定部分并精简其余内容。如果低于这一比例，成本主要在回复上，因此应限制回复长度，并将生成大部分输出的步骤迁移到更便宜的模型或 Batch API。