claude4.5 token价格

你在做选型或续费时，八成会同时搜到新旧几个 Claude 版本的 token 单价，看着数字差不多就直接选了。问题在于输入输出不是同价、缓存读写又是另一套口径，跨版本对比时很容易拿 A 的输入价去比 B 的输出价。这篇给一条从认口径到算自己账单的顺序，再说明什么情况下这套比法不成立。

你在做选型或续费时，八成会同时搜到新旧几个 Claude 版本的 token 单价，看着数字差不多就直接选了。问题在于输入输出不是同价，缓存读写又是另一套口径，跨版本对比时很容易拿 A 的输入价去比 B 的输出价，比完还觉得自己算对了。

这篇不从价目表本身下手，而是先帮你把计价口径对齐，再给一条「认维度—填同表—算自己账—去核对」的顺序。照着走一遍，你会发现自己该看的其实不是某一列数字，而是你自己用量结构下算出来的那个加权单价；同时也会说清什么情况下这套比法根本不成立。

先分清 Claude 的计价有几个维度

很多人脑子里的价格只有两个格子：输入一个、输出一个。实际计费表上通常至少有四个格子，缓存写和缓存读各占一行，而且这两行和输入输出不是一个量级。你如果只按输入输出去估预算，多轮对话类应用的实际账单往往对不上。

输入 token

你发给模型的上下文，包括系统提示、历史对话、检索进来的资料。

输出 token

模型生成的内容，一般比输入单价高一截，长回答场景要重点盯。

缓存写

把一段重复出现的前缀存进缓存时产生的费用，长系统提示、固定知识库常用到。

缓存读

后续请求命中缓存、复用那段前缀时的计费项，通常是四项里最关键的一项。

除了这四个维度，还要留意通道档位。同一个模型往往同时存在标准通道和批量、异步之类的折扣通道，两者的适用条件不一样：批量通道一般要求你不急着拿结果。把标准档的单价和折扣档的单价塞进同一张对比表，比出来的差价可能只是通道差异，跟模型新老没关系。

• 先确认自己看的是四项里的哪一项，别拿一项代表整个模型
• 再确认这个数字属于标准档还是折扣档，两档分开列
• 最后确认计价单位是每百万 token 还是每千 token，各家页面写法不统一
• 三项都对齐了再抄数字进表，否则抄进去也没法用

把新老版本放在同一张表里，要先对齐三件事

对齐之后你就会明白，跨版本比价真正的工作量不在找数字，而在统一单位、档位和口径。下面这张表建议你直接照着在表格软件里搭一份，把每个版本每个维度一行行填进去，填不出来的格子先留空，别凭印象补。

还有一种容易踩的坑：把官方直连价和云厂商托管价混着比。云厂商有时会按自己的颗粒度或打包方式结算，中转站的折算价可能还叠了倍率和并发限制。这三种数字放在同一列里，看起来是同一模型，实际结算逻辑完全不同。

用你自己的用量结构决定哪个版本更省

价目表上的单价高低，跟你实际账单的高低不是一回事。真正决定总账的是你的用量结构：四项占比各是多少。同样是换新版本，一个以短输入短输出为主的任务，和一个长系统提示加多轮追问的任务，结论可能完全相反。

1. 捞出四项占比从你的调用日志里统计输入、输出、缓存写、缓存读各自的 token 总量占比，拿不到全量就先抽一周样本。
2. 做加权用占比乘以各版本对应维度的单价，算出你这套任务在旧版本和新版本下的加权单价，别直接比单项。
3. 算差额再下判断把两个加权单价相减，看差额乘以你的月用量后是多少，再决定值不值得动。
4. 复核一次换版本前用一小批真实请求试跑，确认输出长度、缓存命中情况跟你的估算没有量级偏差。

这里特别提醒一句：长上下文、多轮追问、固定知识库这类场景，缓存写和缓存读的占比会明显高于普通问答，这一项对总账的影响经常比输入输出单价还大。所以只盯着输入输出单价选版本，很容易选到表面上便宜、实际更贵的那一档。

数字去哪儿核对，以及什么时候这套比法不适用

单价随时会调，本篇不写死任何数字。你要看当时的官方口径，去站内的官方价格页核对；想看历史波动和新老版本的变化趋势，去价格追踪页看曲线。如果你走的是云厂商托管或中转，计价可能叠加倍率、按不同颗粒度结算，得回到对应的中转站目录页去对那个折算口径。

• 官方直连：到 /pricing 核对当时的输入、输出、缓存四项单价
• 历史与波动：到 /price-watch 看价格追踪，判断是新老差异还是普调
• 中转折算：到 /sites 对具体站点的计价口径与倍率说明
• 模型资料：同一模型的上下文长度等参数变化，会影响你的缓存策略

什么情况下这套比法不成立？短期试用、量极小的情况，两个版本的加权单价差额乘以你的用量，可能还抵不上迁移配置、重新调试提示词和验证输出的工时，这时候性价比的算法要换成「总投入」而不是「单价」。另外如果你的业务对输出稳定性有硬要求，版本切换带来的行为变化本身也是一种成本，不能只看计价维度。