Claude输入和输出Token价格为何相差5倍？

为什么输出 token 比输入 token 更昂贵

在当前产品目录中的所有 Claude 模型里，输出 token 的价格都是输入 token 的 5 倍。原因在于计算方式不同。读取提示词只需对模型执行一次处理。生成回复则需要每生成 1 个 token 处理一次，而且每次处理都必须等待上一次处理完成。

价格表的每一行都采用相同比率，因此所选模型不会改变账单中输出部分的占比。实际占比由工作负载的输入输出结构决定。一个读取 60,000 个 token、生成 800 个 token 的代理步骤，输出成本几乎可以忽略。一个读取 2,000 个 token、生成 12,000 个 token 的起草任务，输入成本几乎可以忽略。下面将使用 Anthropic 公布的 August 2026 费率分别计算这两种情况。

Prefill 只运行一次，解码每个 token 运行一次

推理服务器分两个阶段处理请求，这两个阶段的成本差异很大。Prefill 读取提示词，解码生成回复。

Prefill 一次处理完整提示词。所有提示词 token 在同一次前向传播中进入网络，因此注意力和前馈计算会转化为少量大型矩阵乘法，每次覆盖数千个 token。模型权重只需从内存中读取一次，就能处理整个提示词。加速器的矩阵计算单元会持续繁忙，因此 Prefill 受计算能力限制：瓶颈是芯片执行矩阵乘法的速度。

解码无法采用这种方式，因为 token 2 依赖 token 1。模型刚生成的 token 会成为下一步的输入，因此这些步骤无法同时运行。每个输出 token 都需要单独进行一次前向传播，而且每次传播都要从高带宽内存中读取完整的模型权重，才能生成一个 token。因此，解码受内存带宽限制：瓶颈是权重移动的速度，而不是矩阵乘法的速度。Prefill 处理整个提示词所消耗的同等权重传输量，在解码阶段只能生成一个 token。

服务系统通过批处理缓解这一问题。多个请求一起解码，因此每次读取权重，都能为批次中的每个请求生成一个 token。这就是解码仍然具有可接受成本的原因。但上限仍由内存决定。每个正在处理的请求都会持有一个 KV cache（key/value cache，即截至当前为止每个 token 的已存储注意力状态）。该缓存会随生成的每个 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 包含扩展思考，因此模型在回答前进行思考时，这部分思考内容会按输出速率计费。要在发送提示词前估算其价格，POST /v1/messages/count_tokens 接受相同的请求正文，并在不运行模型的情况下返回 {"input_tokens": N}，且不收费。API 中并非只有这一项不收费，建议在为第一个项目编制预算前查看Claude API 中不会向您收费的功能。

截至 2026 年 8 月 Claude 每百万 token 的收费

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug)",
    "input_usd": 2,
    "output_usd": 10,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (from 1 Sep)",
    "input_usd": 3,
    "output_usd": 15,
    "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 出现两次，因为其优惠价格会到期。2026 年 8 月 31 日之前，输入价格为 $2、输出价格为 $10。从 2026 年 9 月 1 日起，适用输入 $3、输出 $15 的标准价格，输入和输出价格都高出 50%。下面的所有计算示例都使用 8 月价格。

价格会变化，因此不应在本页面查询当前价格。claude.com/pricing是权威来源。价格变化后仍然适用的是计算方法。

价格列表不会显示一个需要注意的事项。Anthropic 的文档说明，Claude 4.7 及更高版本使用了新版 tokenizer。对于相同文本，新 tokenizer 生成的 token 数量大约比 Sonnet 4.6 及更早版本使用的 tokenizer 多 30%。如果只比较每百万 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 (Aug)",
    "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%，因为整个价格表中的输入输出比例固定不变。按 8 月费率计算，该调用在 Opus 5 上的成本为 $0.32，在 Sonnet 5 上为 $0.128，在 Haiku 4.5 上为 $0.064。每天在 Opus 5 上执行 200 个此类步骤，成本为每天 $64。

看到输入输出的比例后，优化重点就很明确了。将答案从 800 个 token 减少到 400 个，只能节省约 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 (Aug)",
    "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 执行同一任务的成本。Batch API 将输入和输出成本都降低 50%。Opus 5 的每份草稿成本降至 $0.155。Batch 会在 24 小时内返回结果，而不是立即返回，因此适合夜间生成报告和批量分类。不适合需要人员等待结果的任务。

在这里，模型路由可以发挥作用，而在代理步骤中则完全不会带来这种效果。如果工作的冗长部分是机械性的，例如重新格式化文本，或扩展已经批准的大纲，那么使用低成本模型生成这些 token，价格只有五分之一。选择 Opus、Sonnet 和 Haiku介绍了实际的质量分界线。

缓存只降低输入成本，而且仅降低输入成本

提示缓存会在服务器上存储提示词前缀，再次读取时按输入费率的一部分收费。以 2026 年 8 月的价格为准，写入 5 分钟缓存的费率是基础输入费率的 1.25 倍，写入 1 小时缓存的费率是 2 倍，读取命中缓存的费率是 0.1 倍。

输出不包含在内。不存在缓存输出。模型每次生成的每个 token 都按完整输出费率计费，不受提示词中有多少内容命中缓存的影响。

在 Opus 5 上执行相同的代理步骤，其中 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.25 倍，因此命中一次后即可回本。写入 1 小时缓存的费率是 2 倍，因此需要命中两次才能回本。写入和读取费率，以及缓存何时不再划算对这一计算过程以及缓存何时不再划算进行了说明。

可控的4个杠杆

1. 将 max_tokens 设置为略高于 p95 输出长度，而不是模型最大值。
2. 将冗长步骤路由到更便宜的模型。
3. 将不需要任何人等待的任务批量处理。
4. 删除会让回复变长的指令。

max_tokens 是硬上限。单独将它设置得很高不会产生费用，因为计费依据是实际生成的 token，不会按上限计费。较宽松的上限只会取消对异常回复长度的限制。从日志中提取 output_tokens 分布，将上限设置为略高于第95百分位，并在代码中处理 stop_reason: "max_tokens"：继续生成回复，或重试。检测到的截断成本低于生成并丢弃一段4,000 token 的冗长回复。扩展思考也会计入 output_tokens，因此应根据同一证据设置该预算。

当步骤的高成本主要来自处理量而非判断时，路由才有效。让强模型负责决策，再将文字生成交给更便宜的模型。首先在自己的评估集上测量路由版本，因为需要尝试两次的便宜模型，成本可能高于一次昂贵的尝试。

批处理是唯一能降低输出费用的杠杆。两侧均可享受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 都需要重新执行一次读取完整模型权重的前向传播，因此硬件瓶颈变成内存带宽。Anthropic 对整个当前产品目录中的输出统一按输入的 5 倍计费，范围从 Haiku 4.5 到 Fable 5。

提示词缓存会降低输出 token 的价格吗？

不会。提示词缓存只适用于输入。截至 August 2026，缓存读取按基础输入价格的 0.1x 计费；缓存写入在 5 minute 有效期内按 1.25x 计费，在 1 hour 有效期内按 2x 计费。无论缓存执行了什么操作，每次调用的输出都会按完整价格计费。因此，缓存不仅会改变账单金额，也会改变账单构成：输入成本降低后，输出就成为最值得优化的部分。

如果回复很短，较高的 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，成本主要来自提示词，因此应缓存稳定部分并精简其余内容。如果比例低于 5:1，成本主要来自回复，因此应限制回复长度，并将生成大部分输出的步骤迁移到更便宜的模型或 Batch API。