Claude Fable 5.1 API 价格怎么算：Token、缓存与批处理费用

Claude Fable 5.1 的官方 API 价格是：普通输入每百万 token 10 美元，输出 50 美元，缓存命中读取 0.25 美元。缓存首次写入另有单价；能接受异步返回的任务，使用 Message Batches 后，token 费用再打五折。核算时最容易出错的地方，是把已经单独计费的缓存 token 再算成普通输入，或把缓存读取降价误认为整张账单都会同比下降。

以下按 2026 年 9 月 19 日核验的 Claude 直连 API 官方价格计算，模型 ID 为 claude-fable-5-1，货币为美元，默认采用 global 推理，不含税费、私有合同价和额外工具服务费。价格与适用范围见官方定价页及Fable 5.1 模型说明。文中的数字演算都是假设示例，并非实测账单。

先看完整价目表：五类 token 分开算

Fable 5.1 的输入不只有一种价格。普通输入、两种有效期的缓存写入、缓存读取需要分开记录，再加上输出，才能还原 token 费用。

Batch 一列已包含五折，使用该列后不要再乘一次 0.5。官方明确说明，缓存价格系数可与 Batch 折扣叠加；上表的 Batch 缓存价格据此计算。来源：官方 token 与 Batch 价格。

Fable 5.1 相比 Fable 5 的缓存读取单价从 1 美元降到 0.25 美元，降幅为 75%；普通输入、输出和缓存写入单价没有随之下降。所以，只有原账单里缓存读取这一部分享受该降幅。输出占比较高、重复前缀较少，或频繁发生缓存未命中的任务，整单节省会小得多。官方同时说明，完整 100 万 token 上下文沿用相同 token 单价，没有长上下文溢价；这并不意味着多放入几十万 token 不增加费用。参见Fable 5.1 定价说明。

用 usage 还原账单，别把缓存算两遍

应以响应里的 usage 为计算依据。input_tokens 只表示未缓存输入，不包含已经归入缓存读取、缓存写入的 token。总输入量可以把三者相加，但计费时仍要按各自单价计算。官方缓存文档给出了这些字段的定义。

设未缓存输入为 U、5 分钟写入为 W5、1 小时写入为 W60、缓存读取为 R、输出为 O，各变量都使用原始 token 数，则常规请求的费用为：

text
token 费用（美元）=
(10 × U + 12.5 × W5 + 20 × W60 + 0.25 × R + 50 × O) ÷ 1,000,000

例如，一个统计时段内，多次请求合计产生以下用量：

json
{
  "input_tokens": 2000,
  "cache_creation_input_tokens": 18000,
  "cache_creation": {
    "ephemeral_5m_input_tokens": 8000,
    "ephemeral_1h_input_tokens": 10000
  },
  "cache_read_input_tokens": 40000,
  "output_tokens": 3000
}

这里的总输入是 60,000 token，但不能直接按普通输入单价收费。正确拆分为：

如果这组用量全部来自 Batch，则 token 费用为 0.240 美元。这只是相同用量在不同价格下的比较，不表示把同一批业务迁到 Batch 后必然得到相同的缓存写入量和读取量。

还要注意，思考 token 属于计费输出的一部分。不能只数最终显示给用户的回答，也不能在 output_tokens 之外再重复加上已经包含其中的思考用量。参见官方思考 token 计费说明。

缓存什么时候划算，5 分钟和 1 小时怎么选

选择缓存有效期，关键是同一个前缀会隔多久再次使用，以及是否真的命中。Fable 5.1 的可缓存前缀至少需要 512 token；低于门槛时，请求会按未缓存方式处理，不会因为这一点返回缓存错误。可以在请求顶层加入 cache_control: {"type":"ephemeral"} 开启自动缓存，默认有效期为 5 分钟；需要 1 小时时可指定 ttl:"1h"。具体写法与限制见官方提示词缓存文档。

把计算缩小到一个完全相同的 10,000 token 前缀，会更容易看清回本条件。假设每次输出、其他输入都相同，后续使用全部命中，期间也没有过期或修改前缀：

因此，5 分钟缓存从第一次复用开始，就能在这部分前缀费用上省钱；1 小时缓存要到第二次复用，也就是总共使用三次，才低于全部按普通输入计费。这个比较只涉及相同前缀，不能拿来直接预测整张账单。

命中会刷新缓存有效期，不需要重新支付写入费，但本次读取仍按读取单价收费。有效期从写入或读取请求的开始时间计算，而不是从响应结束时计算。因此，稳定高频地调用相同前缀，5 分钟缓存也可能持续被刷新；不能仅因为一个会话持续超过 5 分钟，就认定必须选 1 小时。反过来，若相邻请求间隔超过 5 分钟而小于 1 小时，较长有效期才可能减少重复写入。缓存有效期规则需要结合实际请求间隔判断。

实现上，把稳定的工具定义、系统提示词和可复用材料放在前面，把本次用户输入放在后面。命中要求前缀一致；修改前面的系统内容、工具定义、消息，或顶层 effort 设置，都可能使相关缓存失效。上线后应比较 cache_read_input_tokens 与写入量，而不是只看请求中是否放了 cache_control。如果读取量一直为零，先核对长度、前缀一致性与请求间隔，再考虑延长有效期。

一万条离线任务，Batch 能省多少

对于离线分类、批量摘要、资料标注等不要求立即返回的任务，Batch 的价格优势更容易估算：所有 token 费用为常规请求的一半。它采用异步处理，不提供响应流式输出。多数批次可在一小时内完成，但官方允许最长处理 24 小时，届时未完成请求可能过期，因此不能把“一小时左右”写进必须保证的交付时限。官方批处理文档说明了完成时间与结果状态。

假设有 10,000 条任务，每条实际使用 2,000 个普通输入 token、500 个输出 token，暂不使用缓存，也没有其他计费项：

text
常规请求：10,000 × (2,000 × 10 + 500 × 50) ÷ 1,000,000
        = 450 美元

Batch：450 × 0.5 = 225 美元

这是一个便于做预算的无缓存基线。如果任务共享很长的前缀，可以继续评估缓存；但 Batch 中的请求会异步并发执行，不能假设“第一条写入，剩下 9,999 条全部命中”。官方将 Batch 的缓存命中描述为尽力而为，实际费用仍须从每条成功结果的 usage 汇总。1 小时缓存可能改善命中机会，但也提高了写入价格，值得先用代表性样本比较。

提交和对账时，保留以下边界即可避免常见误判：

• 单批上限为 100,000 条请求或 256 MB，以先达到者为准。请求数不多，也可能因内容体积超限。
• 使用 custom_id 对应原始任务，不能按结果返回顺序对号入座。
• 结果从批次创建起保留 29 天，应及时保存成功响应及其用量。
• 官方定义的 errored、canceled、expired 请求不计费；succeeded 已完成生成，即使内容未通过你的业务验收，也已经发生用量。再次成功生成会另行计费。

这些限制均见Message Batches 使用说明。

从样本估月费，还要补上哪些费用

月费应从代表性业务样本推算。客服系统可以按短问答、多轮对话和长资料问答分别采样；离线系统可以按输入长度或输出类型分组。对每组汇总五类 token，算出每个完成任务的平均费用，再乘以预计月任务量。这样才能保留长对话、缓存未命中和重试对成本的影响。

例如，前文用量组合的常规费用为 0.48 美元。假设它确实代表一个业务任务的平均用量，每月完成 1,000 个同类任务，token 预算就是 480 美元；若它代表 100 个任务的合计用量，就必须先除以 100，不能直接乘月任务数。采样口径比多保留几位小数更重要。

在 token 小计之外，再核对三个会改变预算的条件：

例如，前文 0.48 美元的用量若同时使用 Batch 和美国推理区域，token 费用是 0.48 × 0.5 × 1.1 = 0.264 美元。这个 1.1 系数适用于 Claude 直连 API 的该选项，不能直接套给 Amazon Bedrock 或 Google Cloud 的地区价格。见官方数据驻留定价。

工具也不只是一次函数调用。工具定义、结果和后续对话历史会增加输入 token；服务端工具还可能单独收费。例如，官方网页搜索价格为每 1,000 次搜索 10 美元，另加 token 费用。不要把 Batch 的 token 五折自动用于这笔工具服务费。见官方工具计费说明。

预算表至少保留模型、日期、请求模式、推理区域、五类 token、工具费用以及业务成功数。中文字符数与 token 数不存在适用于所有内容的固定换算比例，估输入时应使用官方 token 计数接口，最终以实际响应 usage 校正；输出预算则要把思考用量与业务要求的回答长度一并考虑。

常见问题

已经购买 Claude 订阅，还需要支付 API 费用吗？

需要分别核算。本文讨论的是按用量计费的 Claude API，不能把消费端订阅费用或使用额度视为 API 余额。具体 API 单价以官方定价页为准。

缓存读取只要普通输入价格的 2.5%，为什么账单没明显下降？

0.25 美元确实是 10 美元的 2.5%，但这个比例只适用于成功命中的输入部分。首次写入更贵，未命中的输入仍按对应价格收费，输出也不享受缓存读取价。先检查读取量、重复写入量和输出费用各占多少，再判断问题是否出在缓存上。

应该为了便宜，把所有请求都放进 Batch 吗？

不应只看五折。Batch 适合能等待异步结果的任务；实时客服、需要流式显示的交互不满足这个条件。对于离线任务，先确认最长处理时间、失败重试与结果保存符合业务要求，再比较实际用量下的费用。

价格算清楚以后，怎么判断是否该迁移到 Fable 5.1？

费用只是迁移决策的一部分，还要检查现有模型、任务质量、工具行为与配置变化。本文的计算可作为成本输入；模型选择与迁移注意事项可继续看Claude Fable 5.1 迁移、价格、缓存与 effort 指南。