接 Claude 的时候，最容易被问住的一句就是「一个 token 多少钱」。这个问题没法张口就答：同一个模型输入和输出不是一个价，缓存读写又是另外的口径，中转渠道还会再叠一层倍率。这篇不讲具体数字，只给一套能反复用的方法：去哪查当期单价、怎么把单价换算成你一次任务的真实花费、以及在什么情况下这套换算会失灵。
接 Claude 的时候，最容易被问住的一句就是「一个 token 多少钱」。这个问题没法张口就答：同一个模型输入和输出不是一个价，缓存读写又是另外的口径，中转渠道还会再叠一层倍率。所以先记住一件事：你要的不是一个数，而是一套口径。
这篇不讲具体数字，只给一套能反复用的方法：去哪查当期单价、怎么把单价换算成你一次任务的真实花费、以及在什么情况下这套换算会失灵。数字会变，方法不会过时，把方法固化成脚本和表格，比背一个价格有用得多。
为什么「一个 token 多少钱」没有单一答案
很多人以为价格是一张一维表：模型 → 单价。实际是二维甚至三维的：方向（输入还是输出）、缓存状态（命中还是未命中）、以及渠道（官方直连还是中转）。这四个维度任意一个变了，单价就变。所以当你被问「多少钱」，正确的反问是：按什么口径、哪一段、多少量。
- 输入 token
- 你发给模型的全部内容，包括系统提示词、历史对话、检索回来的资料
- 输出 token
- 模型生成的内容，一般按生成量计费，通常比输入段贵
- 缓存写
- 把一段内容存进缓存以备复用的那次操作，按写入量计费
- 缓存读
- 下次命中缓存时读取的开销，单价通常明显低于未命中输入
- 倍率
- 中转渠道在官方口径之上叠加的系数，用于对齐它的成本与利润
查当期单价的正确入口和读法
价格是会动的，所以任何写死的数字都有保质期。你要建立的习惯是：需要数字的时候去站内对应页面看当期的，而不是翻聊天记录或者记忆里的旧值。官方规格和计价单位以 /official-api/providers/anthropic 为准，这是基准线。
- 先到 /official-api/providers/anthropic 看官方规格与计价单位，这是基准
- 要横向比价再进 /official-api 与 /price-watch，注意页面标注的生效时间
- 模型名称与能力对照去 /models 查，别凭记忆认版本，名字相近的档位差价可能很大
- 拿不准单位含义（比如每百万 token 的口径）就去 /tools/token-price-calculator 换一遍，避免差出数量级
读价格表有个容易踩的坑：单位。有的页面按每百万 token 标，有的按每千 token 标，你按单 token 心算很容易差两三个数量级。凡是看到单价，先确认单位，再确认生效时间，最后才做乘法。三步少一步都可能把预算估歪。
把一次调用拆成四段来算
想把账算清，就不能把一次调用当成一个整数。建议固定拆成四段记：输入、缓存写、缓存读、输出。缓存命中的那部分单价明显低于未命中，如果你的业务重复提示词很多，命中率高低会让同一任务的成本差出一截。
| 计费段 | 对应什么 | 常见易错点 |
|---|---|---|
| 输入 | 系统提示词、历史、检索内容 | 把整段上下文都当普通输入算，忽略可缓存部分 |
| 缓存写 | 首次把内容写入缓存 | 只算一次却按每次请求重复计入 |
| 缓存读 | 命中缓存后读取 | 把命中和未命中混在一起平均，估出来的数没意义 |
| 输出 | 模型生成内容 | 输出长度不可控，估预算时低估长回答的比例 |
计价单位统一到「每百万 token」再乘用量，别拿单 token 的数字口头估算，那样误差会被放大。另外要按任务而不是按请求估算：一轮用户交互里可能包含好几条请求，还有工具调用和重试，只数请求数会漏算。
从用量记录倒推钱的实操顺序
单看账单你只能知道花了多少，单看日志你只知道用了多少。真正有用的是把两边接起来，倒推出「哪个任务花了多少」。顺序错了会很痛苦，所以这里给一个固定的四步流程，按顺序做就不会乱。
- 补全日志字段确保每条调用记录里都有模型名、输入 token、输出 token、缓存读写量、时间戳；缺字段的先补埋点，否则后面全是估算。
- 按模型分组求和把日志按模型分组，各自求和，再各自乘当期单价；不要先把所有模型混在一起算总量，那样分不清钱花在哪个档位上。
- 归并成任务成本把同一任务的多条请求归并，算出一个「任务级成本」，交给业务侧判断这个功能值不值这个价。
- 和账单对账拿算出来的数和账单页面逐项核对；差额大多出在缓存段和重试上，先查这两处，再查是否有未计入的调用来源。
第一次对账大概率对不上，这很正常，差额本身就是信息：它告诉你日志漏了哪一段、或者某个环节在偷偷重试。把对账结果回写到日志字段设计里，下一轮就准了。
不同档位模型怎么选才不亏
选模型不是比单价谁低，而是比「达标成本」。能用小模型稳定跑通的活，就别上大模型，省的主要是输出那一段。判断标准是质量达标线：如果小模型产出需要人工返工，那它再便宜也是亏的。
| 任务特征 | 重点看哪一段 | 选型倾向 |
|---|---|---|
| 长输入、短输出（总结、分类、抽取） | 输入段单价 | 上下文长度和缓存命中率比模型档位更影响成本 |
| 短输入、长输出（写作、代码生成） | 输出段单价 | 输出是成本大头，档位选择要谨慎 |
| 多轮对话、反复带同一段提示词 | 缓存读单价 | 优先看缓存机制是否可用、命中率能到多少 |
| 对延迟和上下文有硬要求 | 不是价格维度 | 这类场景选型权重不在单价上，先满足硬指标 |
什么情况下这套不适用：如果业务对延迟、上下文长度、或输出格式稳定性有硬要求，选型权重根本不在价格上，这时候用价格表做决策会跑偏。先满足硬指标，再在满足的候选里比价格。
先把预算和告警立起来，再谈省钱
很多人是月底看到账单才反应过来，那时候已经花完了。正确顺序是先立预算和告警，再谈优化。按月给一个上限，再拆成日预算，超出就走降档或排队，别等月底看账单。
- 接入前先估算：拿一周真实用量乘当期单价，得到一个可解释的月度区间
- 给每个线上任务标一个单次成本阈值，超阈值就告警，而不是等总量超
- 把 /usage 里的真实用量当参照，用来校准你估算的偏差方向
- 省钱动作有优先级：控制上下文长度 > 提升缓存命中 > 降档模型 > 减少无意义重试
省钱动作里，控制上下文长度和提升缓存命中通常立竿见影，因为它们直接砍掉的是最贵或最大量的那一段。降档模型影响面大，要配合质量回归测试做。减少重试属于工程侧优化，先把超时和报错处理做好，重试自然就少了。
直连和中转的价格差异怎么对齐
中转站标价通常是「官方口径 × 倍率」或者自己重新定义的套餐口径，直接拿它和官方原价比大小是没有意义的。比价前先对齐三件事：计价单位、是否含缓存段、倍率按什么基数算。三件事不对齐，比出来的结论不可用。
换渠道前还要问自己一句：我换的是价格还是稳定性。如果是因为直连经常超时、限流才想换中转，那评估重点应该是可用性和响应一致性，而不是单价。什么情况下不建议只看价格：合规、数据出境有要求的项目，价格根本不该排在决策第一位。
上手清单：一次把账算明白
- 建价格表建一张表：模型、输入单价、输出单价、缓存单价、生效日期；数字从站内当期页面取，别抄旧值。
- 写汇总脚本写一条脚本按天汇总用量并乘单价，连跑一周，看估算和实际的偏差有多大、往哪个方向偏。
- 设任务成本阈值给每个线上任务标一个单次成本阈值，超了就告警，把问题拦在发生的那一刻而不是月末。
- 每月对账一次固定花十分钟做账单与用量的双向核对：账单对用量、用量对任务，两边都能解释清楚才算过关。
这套流程跑顺之后，「一个 token 多少钱」对你来说就不再是一个要背的数字，而是一个随时能查、能算、能对账的动作。价格会变，脚本和表格会跟着变，但口径这套东西是稳定的。
价格是别人给的，口径是你自己定的；口径不统一，比价就是自欺欺人。下一步先去把官方规格和当期计价单位看清楚，再用计算器把你的真实用量换算一遍，心里就有底了。→
常见问题
Claude 一个 token 到底多少钱？
这个问题没有单一口径的答案。同一个模型输入和输出是两个价，缓存写入和缓存命中又是另外两段价，输出通常最贵。而且官方单价会调整，所以正确做法是到 /official-api/providers/anthropic 看当期数字，再按自己的输入输出比例加权算出一个混合单价。
输入和输出的价格为什么不一样？
生成输出要逐 token 解码，算力占用比读入一段现成文本高，所以输出段单价普遍高于输入段。这意味着同样长度的任务，写代码、写长文这类输出多的活，成本明显高于做总结、做分类这类输入多输出少的活。
用中转站会比官方便宜吗？
不一定，要看口径。中转站通常在中转价上乘一个倍率，倍率低于一是打折，高于一就是加价，而且缓存段是否同样打折各家不一样。比价前要先对齐计价单位和是否含缓存段，别拿两边的表面数字直接比。
为什么我按单价算出来的钱和账单对不上？
最常见的原因是漏了缓存读写和重试。缓存命中的部分单价和普通输入不同，重试如果产生新请求也会计入；另外账单可能跨结算周期。建议先把用量日志字段补全，再按模型分组求和与账单逐项核对，差额基本都能定位到这几项上。
控制成本最有效的动作是什么？
先看上下文长度。历史消息、检索结果、示例全都塞进输入的用法，很容易让输入 token 翻几倍，砍掉冗余上下文往往一次就能省下大头。其次是提缓存命中率，再往下才是换小模型和减少重试。前提是质量不能掉，质量不达标返工反而更贵。
