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

为什么输出 token 的费用高于输入 token

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

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

预填充运行一次，解码每个 token 运行一次

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

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

解码无法采用这种方式，因为 token 2 依赖 token 1。模型刚生成的 token 会成为下一步的输入，因此这些步骤无法同时运行。每个输出 token 都需要单独执行一次前向传播，而每次前向传播都要从高带宽内存中读取完整的模型权重，才能生成一个 token。因此解码受内存带宽限制：瓶颈在于权重移动的速度，而不是矩阵乘法的速度。预填充处理整个提示词时产生的同等权重流量，在解码阶段只能生成一个 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}，但不会运行模型，而且免费。

截至 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。应比较完成任务的总成本，并使用实际计划采用的模型统计真实提示词。一百万个 Claude token 在实际文本中相当于什么介绍了这批 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%，提示词费用几乎可以忽略。多数人都会错误估计自己的比例，因此在优化之前，先从日志中获取实际比例。

代理工作负载：输入长上下文，输出简短答案

执行一次检索代理步骤：输入60,000个检索文档和对话历史标记，输出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删掉，则可节省约三分之一。对于读取密集型代理，单纯压缩输出长度接近于无效努力。编码代理的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 执行同一任务的费用。该 API 对输入和输出均提供 50% 的折扣。Opus 5 生成一份草稿的费用降至 $0.155。Batch 会在 24 小时内返回结果，而不是立即返回，因此适合夜间生成报告和批量分类。但它不适合任何需要人员等待结果的任务。

模型路由在这里可以发挥作用，但在代理步骤中不会这样。只要任务中较长的部分是机械性的，例如重新格式化文本，或扩展您已经批准的大纲，低价模型就能以五分之一的价格生成这些 token。选择 Opus、Sonnet 和 Haiku介绍了实际的质量分界点。

缓存只降低输入成本

提示缓存会将提示词前缀存储在服务器上。再次读取该前缀时，按输入费率的一部分计费。截至 2026 年 8 月，倍率如下：写入 5 分钟缓存按基础输入费率的 1.25x 计费，写入 1 小时缓存按 2x 计费，命中缓存读取按 0.1x 计费。

输出不包含在内。不存在缓存输出。模型每次生成的每个 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.25x 计费，因此一次命中后即可收回成本。写入 1 小时缓存按 2x 计费，因此需要两次命中才能收回成本。写入和读取倍率，以及缓存何时不再划算详细说明了相关计算。

您可以控制的 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 倍。控制持续运行代理的成本介绍了监控方面的做法；在开始花一周优化每个 token 的支出前，也应先确定对于你的使用模式，API 还是固定订阅更便宜，因为订阅可能已经覆盖了这些费用。

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