Claude的1M tokens多少钱？输入输出费用怎么算

Claude 中 1M tokens 需要多少钱？

1M tokens 表示 1 million tokens，是所有 Claude API（应用程序编程接口）价格所采用的计费单位。它没有统一价格，因为输入和输出按不同费率计费，而且每个模型都有各自的输入和输出费率。截至 2026 年 8 月，Claude Haiku 4.5 的 1 million input tokens 价格为 $1，Claude Sonnet 5 为 $2，Claude Opus 5 为 $5。

输出是费用较高的一部分。在所有当前模型中，输出费率都是输入费率的 5 倍，因此输入与输出的比例对账单的影响大于单独查看单价。发送长文档并返回简短答案的应用，与根据简短提示生成长答案的应用，费用结构会有很大不同。

本页介绍单位经济性：token 的成本，以及在构建应用前如何估算账单。若要了解工作过程中 token 的实际消耗位置，请阅读 Claude Code 会话中 token 的消耗位置。

1M tokens 的规模

token 是模型读取或生成的文本片段。Anthropic 的粗略估算是，每 4 个字符约对应 1 个 token，英文约为每 0.75 个单词对应 1 个 token。因此，1M tokens 约等于 750,000 个单词，或约 4 MB 的纯文本。

已发布的常见输入估算值可以更直观地说明这一规模。

[
  {
    "label": "Average web page (10 kB)",
    "tokens": "2,500"
  },
  {
    "label": "Documentation page (100 kB)",
    "tokens": "25,000"
  },
  {
    "label": "Research paper PDF (500 kB)",
    "tokens": "125,000"
  }
]

按这些比例计算，1M tokens 约等于完整读取 400 个平均长度的网页，或 8 篇同等规模的研究论文。它也相当于完整处理一个中等规模的代码库，或供 1 个人进行 1 个月的轻度聊天。

以上都只是估算值。代码、JSON 以及英语以外语言的文本，每个 token 包含的单词更少，因此 0.75 这个比例属于较乐观的情况。还有一个因素会改变计数结果：Claude Opus 4.7 及更高版本（包括 Opus 5 和 Sonnet 5）使用了更新的 tokenizer。对于相同文本，它生成的 token 数量比 Sonnet 4.6 及更早版本约多 30%。Claude Haiku 4.5 使用旧版 tokenizer。因此，在 Haiku 4.5 上测得的计数会低估相同输入在 Sonnet 5 上的计数。这意味着，跨越这一版本边界直接比较每百万 token 的价格并不公平。决定之前，请分别使用两个模型计算同一提示的 token 数量。

Claude 每百万 token 的费用

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug 2026)",
    "input_usd": 2,
    "output_usd": 10
  },
  {
    "label": "Sonnet 5 (from 1 Sep 2026)",
    "input_usd": 3,
    "output_usd": 15
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25
  }
]

Claude Sonnet 5 在 2026 年 8 月 31 日之前采用推广价：输入为 $2，输出为 $10。从 2026 年 9 月 1 日起，改用标准价格：输入为 $3，输出为 $15。Claude Opus 5 的价格为输入 $5、输出 $25。还有一个模型的价格完全高于上述范围：Claude Fable 5 的输入价格为 $10，输出价格为 $50，因此 这些价格是否值得支付取决于您实际将它用于哪些任务。

价格会变化。请将本页的所有数字视为截至 2026 年 8 月的示例，并在确定预算前，通过官方定价页面确认当前价格。

这些价格说明了 Claude 的费用，但不能说明它对您的工作负载而言是否更便宜；Claude 和 ChatGPT 的 3 个任务成本对比展示了两种 API 各自更具优势的场景。

上下文长度不会改变单价。在 Claude 4.6 及更高版本中，完整的 1M token 上下文窗口按标准价格计费，因此，900,000 token 的请求与 9,000 token 的请求具有相同的单 token 价格。长提示词的费用更高，是因为它包含更多 token；不会另外适用长上下文价格。

价格变动后仍然有效的计算方式

每笔费用都由两次乘法和一次加法组成。

cost = (input_tokens  / 1,000,000) * input_rate
     + (output_tokens / 1,000,000) * output_rate

写成可运行的代码：

INPUT_RATE = 2.00    # USD per million input tokens, Sonnet 5, August 2026
OUTPUT_RATE = 10.00  # USD per million output tokens

def cost(input_tokens, output_tokens):
    return (input_tokens * INPUT_RATE + output_tokens * OUTPUT_RATE) / 1_000_000

print(f"{cost(4300, 400):.4f}")

输出结果为 0.0126。一个请求发送 4,300 个输入 token，并接收 400 个输出 token，在 Sonnet 5 上的成本约为 1.3 美分。将两种费率集中放在代码中的同一处。价格变动时只需修改两行，系统中的所有估算值都会随之更新。

实际应用的估算示例

以一个支持助手为例。其系统提示词和产品文档共占 4,000 个 token。由于 Messages API 是无状态的，模型不会记住不同调用之间的内容，因此这些内容会随每个请求发送。用户问题增加约 300 个 token。回答约占 400 个 token。每个请求因此包含 4,300 个输入 token 和 400 个输出 token。

1,000,000 个输入 token 大约可支持 232 个这种请求。如果每天处理 1,000 个请求，应用每天会消耗 4,300,000 个输入 token。因此，“1M tokens”产生的流量不足 6 小时。

[
  {
    "label": "Opus 5, list rates",
    "cost_per_1k_usd": "31.50"
  },
  {
    "label": "Sonnet 5, list rates",
    "cost_per_1k_usd": "12.60"
  },
  {
    "label": "Sonnet 5, Batch API",
    "cost_per_1k_usd": "6.30"
  },
  {
    "label": "Haiku 4.5, list rates",
    "cost_per_1k_usd": "6.30"
  },
  {
    "label": "Sonnet 5, warm prompt cache",
    "cost_per_1k_usd": "5.40"
  }
]

使用 Claude Opus 5 时，每 1,000 个请求的成本为 $31.50。使用 Sonnet 5 时，成本为 $12.60。改用 Claude Haiku 4.5 后，成本降至 $6.30；在 Sonnet 5 上启用热提示缓存后，成本还会进一步降至 $5.40。

将其乘以 30，就是一个月的相同流量。按标价计算，Sonnet 5 每月约需 $378。使用热缓存的同一应用每月约需 $162。在这一流量规模下，模型选择和缓存决策带来的影响都超过了你能协商出的任何费率优惠。选择运行哪个模型是另一个问题；能够通过评估的最低成本模型就是最佳选择：如何在 Opus、Sonnet 和 Haiku 之间选择介绍了正确的测试方法。

提示词缓存可降低重复部分的成本

这 4,000 个 token 的前缀在每次请求中都完全相同，但每次都要按完整输入价格付费。提示词缓存会存储已处理的前缀，重复使用时按较低费率收费。

读取缓存的费用是基础输入费率的 0.1 倍。缓存写入费用为 5 分钟有效期基础费率的 1.25 倍，或 1 小时有效期基础费率的 2 倍。因此，5 分钟缓存读取一次即可回本：写入只额外增加 0.25 倍费用，而每次读取可节省 0.9 倍费用。1 小时缓存需要读取 2 次才能回本。

启用缓存最简单的方法是在顶层添加一个字段：

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 1024,
    "cache_control": {"type": "ephemeral"},
    "system": "You are a helpful assistant.",
    "messages": [
      {"role": "user", "content": "What are the key themes in Pride and Prejudice?"}
    ]
  }'

然后读取返回的 usage 块：

{
  "usage": {
    "cache_creation_input_tokens": 5120,
    "cache_read_input_tokens": 1800,
    "input_tokens": 50,
    "output_tokens": 503
  }
}

这 3 个输入计数器分别按 3 种不同费率计费，合计后才是实际输入量：total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens。启用缓存后，如果只读取 input_tokens 来估算成本，结果会严重失真。

有两种情况会导致缓存无法产生收益，而且都不会明确报错。

前缀必须逐字节一致。 缓存查找按前缀匹配，因此如果在系统提示词开头加入时间戳或用户名，前缀就会在每次请求中发生变化。这样每次都会按基础输入费率的 1.25 倍付费，而且一次缓存读取都不会发生。表现为 cache_creation_input_tokens 持续较高，而 cache_read_input_tokens 保持为 0。将 cache_control 放在内容在各次请求间保持不变的最后一个块上，并将所有可变内容放在它之后。修改 tools 定义会使其下方的整个缓存失效，因为失效顺序是先处理 tools，再处理 system，最后处理 messages。

前缀必须足够长。 Opus 5 的最小可缓存长度为 512 个 token，Sonnet 5 为 1,024 个，Haiku 4.5 为 4,096 个。较短的提示词不会被缓存，也不会返回错误。上例中的 4,000 个 token 前缀可在 Sonnet 5 上缓存，但无法在 Haiku 4.5 上缓存，因为 4,000 低于该模型的最低长度要求。当两个计数器都为 0 时，表示没有内容被缓存。

批处理可将费率降低一半

Batch API 会异步处理请求，输入和输出的费率都可享受 50 percent 的折扣。在上面的示例中，每 1,000 个请求的费用会从 $12.60 降至 $6.30。此折扣可与提示缓存叠加，因此，使用缓存的批处理作业是执行批量任务成本最低的方式。

代价是延迟增加，因此批处理不适合需要用户等待结果的任务。它适合在夜间执行分类任务，以及补处理文档。

单个会话中的聊天成本为何会增加

由于 API 不保存状态，客户端必须在每一轮重新发送完整的会话内容。因此，单个聊天中的 Token 用量会随会话长度的平方增长，而不是线性增长。

假设每轮平均包含 500 个 token。第 1 轮发送 500 个输入 token，第 2 轮发送 1,000 个，第 20 轮发送 10,000 个。使用 n(n+1)/2 求和可知，一个包含 20 轮的会话总共发送了约 105,000 个输入 token，而会话记录本身只有 10,000 个 token。

因此，聊天功能的成本会高于会话记录所显示的成本。在较长的会话中，缓存稳定的前缀或总结较早的轮次通常可以抵消自身的成本。循环调用工具的代理也具有相同的增长趋势，而且情况更严重：每个工具结果都会保留在历史记录中，并在之后的每一轮重新发送。在这里，为自行运行的代理设置严格的支出上限尤为重要，因为这种增长会自动发生，而且没有人监控。

在猜测前先统计 token

不要再根据单词数推算 token 数。API 会为您统计 token，且不收取费用。此统计使用独立于消息创建的速率限制。

curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "system": "You are a scientist",
    "messages": [{
      "role": "user",
      "content": "Hello, Claude"
    }]
  }'

响应包含一个字段：

{ "input_tokens": 14 }

将实际的系统提示词和工具定义，以及一条具有代表性的用户消息传入该接口，然后将返回的数量代入上面的成本函数。该端点接受与消息请求相同的请求体，因此也能正确统计图像和 PDF。需要注意两点。该数量是估算值，可能与实际计费数量略有差异。统计使用您传入的模型对应的 tokenizer，因此应传入实际运行的模型。

无法提前统计输出 token，因为它们尚不存在。使用 max_tokens 限制输出数量，然后在生产流量中通过 usage.output_tokens 测量实际分布。

账单中还有哪些费用

大部分费用来自 tokens。有几项费用不是 tokens，常常会让人意外。

• 每次请求都会将工具定义计为输入 tokens。仅 Opus 5 的工具使用系统提示词就会增加 286 到 406 个 tokens，且还未计入您自己的 schema。10 个冗长的工具描述可能让一个较短的提示词长度翻倍。
• Web search 的费用为每 1,000 次搜索 $10；此外，搜索结果进入上下文后所消耗的 tokens 也会计费。
• Web fetch 本身不收取额外费用，但获取的页面会转换为输入 tokens。一个 100 kB 的文档页面大约包含 25,000 个 tokens。
• 在 Claude 4.6 及更高版本中，使用 inference_geo 请求仅在美国进行推理，会将每类 token 的费用乘以 1.1，缓存读取和写入也包括在内。

API 是否值得购买，取决于您的用量。通常是在套餐达到用量上限后，才会开始考虑这个问题；突破用量限制的方法包括等待窗口重置，或将这部分工作转移到按量计费的 API 调用。低于某个用量水平时，固定月费套餐明显更划算；将 API 与 Claude 订阅进行比较可以用实际数字完成这项比较。

FAQ

Claude 中 1M 个 token 的成本是多少？

这取决于模型，以及这些 token 是输入还是输出。截至 2026 年 8 月，Claude Haiku 4.5 的 1,000,000 个输入 token 成本为 $1；采用引入期定价的 Claude Sonnet 5 为 $2；Claude Opus 5 为 $5。这些模型的输出成本均为输入价格的 5 倍。2026 年 9 月 1 日起，Sonnet 5 的输入价格将调整为 $3，输出价格将调整为 $15。价格会变化，因此在将具体金额纳入预算前，请先在官方定价页面确认。

1M 个 token 等于 1M 个单词吗？

不等于。1 个 token 大约对应 4 个英文字符，或约 0.75 个单词，因此 1,000,000 个 token 约对应 750,000 个单词。这个比例只能作为参考。代码、JSON 以及英语以外的语言通常每个单词需要更多 token。Claude Opus 4.7 及更高版本还使用了新的 tokenizer。对于相同文本，它生成的 token 数量比 Claude Sonnet 4.6 及更早版本多约 30%，因此不同模型代际之间的计数不能直接换算。请使用免费的 /v1/messages/count_tokens endpoint，并传入计划运行的模型。

prompt caching 是否总能节省费用？

不能。5 分钟的缓存写入成本是基础输入价格的 1.25 倍。因此，写入后从未读取的前缀，其成本比直接发送高 25%。从第一次读取开始，缓存即可抵消写入成本。缓存会以两种方式静默失效。如果请求之间的缓存前缀发生变化，查找就不会匹配，因为它要求完全匹配前缀。如果前缀短于模型可缓存的最小长度，则不会缓存，也不会返回错误。Sonnet 5 的最小长度为 1,024 个 token，Haiku 4.5 为 4,096 个 token。当 cache_creation_input_tokens 和 cache_read_input_tokens 都为 0 时，缓存没有发挥作用。

为什么账单增长速度比消息数量更快？

因为每一轮都会重新发送完整对话。Messages API 不保存状态，因此聊天进行到第 20 轮时，前 19 轮内容会再次作为输入发送。如果每轮平均包含 500 个 token，20 轮对话会发送约 105,000 个输入 token，而转录内容总长度只有 10,000 个 token。Agent 循环的行为相同，因为每个工具结果都会保留在历史记录中。请缓存稳定的前缀，或汇总较早的轮次并将其从请求中删除。