claude fable 5价格

很多人拿到一个 Claude 模型名，第一反应是搜价格，结果看到一堆数字却对不上自己的账单——因为输入、输出、缓存写、缓存读这四项根本不是同一个价，长上下文和批处理还可能另算。这篇不写死任何数字，只讲这个版本模型的计费结构怎么读、按什么顺序自查、什么情况下按单项单价估算会算错，以及去站内哪几页拿到当时的真实报价。

搜「claude fable 5价格」的人，多半是想快速判断自己这个月账单大概会长什么样。但真到看账单的时候会发现，输入和输出是两个价，缓存写和缓存读又是另外两个价，如果任务跑在批处理或者超长上下文上，还可能再叠一层档位。所以光记住一个数字没用，得先把计费口径拆开，再按自己的调用模式去对。

这篇不给你任何写死的数字，因为价格本来就会调。只讲这个版本模型的计费结构怎么读、按什么顺序自查、什么情况下按单项单价估算会算错，以及最后去站内的哪几页拿当时的真实报价。

先搞清这个模型按哪几项收钱

很多人以为价格就是「一个数 × 总 token」，实际不是。输入和输出是两条完全独立的单价曲线，输出通常比输入贵不少；而缓存写入、缓存读取这两项又各自有自己的价，和普通输入不是一回事。你如果只拿输入单价乘全部用量，估出来的数字会明显偏低。

输入 token

你发给模型的内容，包括系统提示、历史对话、检索到的文档等

输出 token

模型生成回来给你的内容，单价通常和输入不在一个档

缓存写入

把一段固定内容存进缓存时产生的费用，一般只在第一次或缓存过期后发生

缓存读取

命中缓存后读取那部分内容的费用，通常比普通输入便宜，但仍是单独一项

批处理、长上下文、思考型输出这几类，在一些厂商那里会走单独的档位。你得先确认这个模型有没有被划进这些档，别默认它和普通对话一个价。判断方法很简单：到站内的价格汇总页看这个模型条目下有没有单独列出批处理或长上下文的行，有就说明该模式另算。

按什么顺序估一次调用的钱

估算顺序错了，后面全白算。正确做法是先把一次请求拆开，看清楚哪部分算输入、哪部分算输出、哪部分命中了缓存，再分别乘对应单价，最后才乘请求量。下面这个顺序可以直接照着走。

1. 拆一次请求把这次调用的内容分成三块：会走缓存的固定前缀、普通输入、模型输出。缓存命中的部分单独记，别混进普通输入里。
2. 分别乘对应单价输入、输出、缓存读、缓存写各乘各的价，不要用平均单价糊一个大数。缓存命中率高的任务，这一项省下来的钱往往比换模型还明显。
3. 乘请求量得区间用日请求量或月请求量乘单次成本，得出一个区间而不是一个点。输出长度不稳定的任务，区间会拉得很宽，这本身就是有用信息。
4. 留波动余量在区间上限上再留一部分余量，覆盖重试、失败请求和缓存未命中的情况，这样预算表才不容易被实际账单打脸。

真实数字去哪里核对

价格会调整，所以任何写死的数字都只有短期参考价值。你要做的是建立一个「随时能查到当时价」的入口，而不是把某个数字抄进代码注释或者预算表。

哪些情况下这套估法不成立

按单项单价加总的方法，只适用于按量计费、且输出长度相对可控的场景。下面这几种情况，你照上面那套算出来的数字会和实际支出差很远，得换一套判断方式。

• 走订阅套餐而不是按量计费时，你掏的是固定月费，单价和实际成本不是一条线，这时该看的是用量上限和超限规则；
• 经中转站或云厂商托管调用时，会在官方单价上再叠一层倍率和汇率，得先对齐口径再比价，否则比出来的是两种货币；
• 输出长度完全不可控的任务，比如开放式生成或长文摘要，按平均输出长度估会明显偏低，应该用实际日志里的分位数来算；
• 缓存命中率忽高忽低的任务，缓存读和缓存写两项的占比会剧烈波动，单次成本可能差出好几倍，这时要按命中率高、低两个场景分别估。

一句话判断：如果你的调用模式里存在「长度不可控」或「计费口径不统一」这两件事中的任意一件，就别用单点估算，改用区间加实际日志校准。