很多人第一次看 Claude 的价目表会卡在同一个地方：页面上有好几列价格，但自己一笔请求到底按哪一列扣钱说不清。尤其当项目里同时用了缓存、长上下文和批量任务，月底账单和当初估的数常常对不上。这篇不讲具体数字，只讲计费口径怎么读、哪些字段会互相叠加、估算时该按什么顺序拆，最后给一份可照着走的核对流程。
很多人第一次看 Claude 的价目表会卡在同一个地方：页面上有好几列价格，但自己一笔请求到底按哪一列扣钱说不清。尤其当项目里同时用了缓存、长上下文和批量任务，月底账单和当初估的数常常对不上。这篇不讲具体数字，只讲计费口径怎么读、哪些字段会互相叠加、估算时该按什么顺序拆。
先把心态摆正：单价会变，口径相对稳定。你真正要掌握的是「这笔请求命中了哪几个计价项」，而不是背住某一行的数字。数字一律到站内资料库与价格追踪页核对当时的版本，本文只给拆账方法。
价目表里的几列分别是什么
价目表通常把不同计价项平铺成列，一张表能同时列出基础输入、基础输出、缓存写、缓存读、批量等口径。你要做的第一件事不是比大小，而是确认每一列的计量单位：是按每百万 token 标，还是按每千 token 标。单位口径没对齐，比较就是白比。
| 列名 | 对应什么 | 是否必然产生 |
|---|---|---|
| 基础输入 | 系统提示、历史对话、检索资料等送进模型的文本 | 是 |
| 基础输出 | 模型实际生成的内容 | 是 |
| 缓存写入 | 把一段前缀存进缓存的那一次操作 | 否，只有开了缓存才有 |
| 缓存读取 | 命中缓存后复用前缀的那部分 | 否 |
| 批量口径 | 离线提交任务时套用的独立计价 | 否，只有走批量才有 |
- 轻量档、标准档、旗舰档之间的差距是量级差距，不是小数点后一位的差别，别用同一套预算套所有档位
- 可选的加成项（缓存、批量）不用就完全不产生费用，估算时可以先按「全不开」算一版保底
- 同一张表里不同模型的行，规格可能不一样，比价前先确认是不是同一口径
- 价目表旁边的规格说明同样要看，token 换算和最大长度常写在那里，不在价格行里
一次请求里，钱花在输入还是输出
一笔请求的费用基本可以拆成两块：进了多少内容、出了多少内容。输入这一侧不只是你当次敲进去的那句话，系统提示、历史对话、检索塞进来的资料都算，而且每一轮都要重新算一遍。这就是为什么聊得越久，单轮成本越高——不是模型变贵了，是你每轮带进去的东西变多了。
输出这一侧按实际生成长度算，不是按你设的上限扣费。你把最大输出设得很高，只要模型没写那么长，就不会按上限收。反过来，如果你让模型输出结构化内容或带工具调用参数，输出天然会变长，单价本身没动，账单却会上去。
- 先拆输入把一次请求里送进去的部分列出来：系统提示多少、历史对话多少、外部资料多少。能复用的前缀先标出来，后面决定要不要开缓存。
- 再估输出按典型回答长度给一个区间，而不是按最大上限。让模型输出 JSON 或工具参数的场景，区间要往高放。
- 乘上频次单次成本乘日均调用次数，再乘上多轮对话的平均轮数。这一步最容易低估，因为轮数是乘法不是加法。
- 留冗余最后加一档给重试和异常流量。不给冗余的预算几乎没有参考价值。
同一段话被反复塞进上下文，就是被反复计费；省成本的第一刀往往砍在「别再重复塞」上。
缓存写入和缓存读取是两个不同的计价项
缓存不是「开了一律便宜」。它拆成两个动作：写入和读取。写入通常按高于普通输入的口径计一次，读取则按低于普通输入的口径计。也就是说，缓存是先付一笔更高的写入成本，再用后续多次读取把总账拉回来。用一次就丢的内容开缓存，纯亏。
| 场景 | 开缓存是否划算 | 判断依据 |
|---|---|---|
| 固定系统提示、大量重复调用 | 通常划算 | 同一前缀被反复读取 |
| 内容每次都变 | 通常不划算 | 写入了但读不到 |
| 调用频次很低 | 通常不划算 | 有效期过了缓存就失效 |
| 长文档反复问答 | 看复用次数 | 同一文档被问几轮 |
- 缓存有有效期，隔太久再调用等于重新写入，前面省下的会被吃掉
- 缓存前缀要尽量放在前面且保持稳定，中间随便改一个字符就可能整段失效
- 判断划不划算的唯一可靠方式是：把开缓存前后的用量日志拉出来对一遍，而不是凭感觉
- 什么情况下不适用：一次性脚本、内容每轮都变的对话、调用量小到写入成本收不回来的场景
批量任务与长上下文对价格的影响
批量提交一般有独立的折扣口径，但代价是返回节奏不由你控制。它适合不着急、量又大的活儿；不适合用户在线等回复的场景。长上下文则是另一个方向：内容塞得越多，越可能触发更高档的计价，别默认「多塞点也一样价」。
长文档处理的成本结构，关键不在文档多大，而在你把它切成几段、每段被复用几次。一次切成十段各问一次，和一次性整篇问一次，账算出来可能完全不同。先想清楚复用模式，再决定切法。
- 适合走批量：离线跑批、模型评测、数据清洗、夜间生成的报表
- 不适合走批量：交互式对话、需要即时反馈的接口、用户在前台等待的链路
- 长上下文适合：需要跨段推理的整体分析；不适合：明明可以分块独立处理却硬塞一起
- 切分文档时优先按语义段落切，别按固定字数硬切，后者往往带来更多无效 token
容易漏掉的几类费用
预算对不上，往往不是主单价算错了，而是漏了几项边缘消耗。第一类是重试：失败请求未必不计费，要看失败发生在哪一步，已经生成了一部分就很可能已经产生费用。第二类是输出膨胀：结构化输出和工具调用会让输出变长，间接抬高单次成本。
第三类最容易踩：接入渠道不同，计价口径不一定一致。官方直连、云厂商托管、中转，三者的计费方式可能各有各的算法。比价之前先把口径拉齐，否则比出来的差异可能只是口径差异，不是真便宜。
- 重试流量
- 失败后重发的请求，已生成部分通常照算，预算里要单列一档
- 输出膨胀
- 结构化输出、工具调用参数让生成变长，单价没变但账单变高
- 多模态输入
- 图片、文件按什么折算成 token，去对应模型的资料页看换算规则
- 渠道口径
- 官方、云托管、中转的计价方式可能不同，比价前先对齐
从用量记录倒推预算的四步法
估预算最靠谱的起点不是价目表，而是你自己的用量日志。先抓一周真实流量，把输入、输出、缓存三项分开统计，你会立刻发现钱主要花在哪一项上——很多时候和直觉相反。之后按业务增长倍数放大，别按「感觉会涨一点」估。最后给重试和异常留一档冗余，并设预算告警，把跑飞限制在一晚以内。
- 抓一周日志分出输入、输出、缓存读、缓存写四类用量。没有分项日志的，先加日志再谈预算。
- 按倍数放大用业务增长的明确倍数（比如调用量翻几倍）乘上去，而不是拍一个百分比。
- 留冗余给重试、异常和流量峰值留一档。冗余不是浪费，是没有它预算就会失准。
- 设告警按日或按小时设用量告警，触发时先看是哪一项在涨，再决定是砍调用还是换档位。
这些数字到底去哪看
本文刻意不写任何具体数字，因为单价和规格会变，写死了很快就不准。你要做的核对动作是固定的：打开站内对应模型的资料页看规格与计费项，再去价格追踪页看当时的口径与变动记录。两个页面口径对齐之后再下结论。
- 单价与规格：到站内模型资料库核对当时的数字与单位口径
- 价格变动与历史：到价格追踪相关页面看口径调整记录
- 渠道对比：到站点导航与可信度页面先确认渠道口径是否一致
- 测试与验证：到站内测速工具页实测延迟和可用性，别只看文档
- 用哪个模型：到模型目录页按场景筛，别按价格一行行比大小
| 你要确认的事 | 去哪里看 | 看到后先做什么 |
|---|---|---|
| 某模型当前单价与单位 | 站内模型资料页 | 确认是按每百万还是每千 token |
| 价格最近是否调过 | 站内价格追踪页 | 对齐新旧口径再比 |
| 某个渠道靠不靠谱 | 站内中转站检测与导航页 | 先看口径是否与官方一致 |
| 模型选型 | 站内模型目录 | 按场景筛，再比成本 |
常见问题
Claude 的 API 是不是比订阅制贵？
两者比的不是同一个东西。订阅是按人头、按额度上限卖使用权限，API 是按实际消耗卖量。低频、单人、交互式使用，订阅往往更省；高频、批量、要接进自己系统，API 才合适。真要折算，得先把订阅额度换算成 token 量级再去站内对比。
为什么我按价目表估的账单和实际差很多？
最常见的原因是漏了输入被重复计费这件事：多轮对话里历史消息每轮都会重算。其次是漏了缓存写入这类单独计价项，以及失败重试产生的消耗。建议先抓一周用量日志，把输入、输出、缓存三项分开看，差异通常立刻能解释。
开了缓存一定更便宜吗？
不一定。缓存写入那一笔本身有成本，只有当同一段内容在有效期内被重复读取足够多次，省下的部分才能盖过写入成本。内容每次都变、或者调用频次很低的场景，开缓存反而更贵。先跑一段时间对比用量日志再决定。
长上下文是不是越塞越贵？
是，而且贵得不线性：超长区间可能触发更高档计价，同时每一轮都要重复支付这部分输入。判断标准是这段长内容会不会被复用很多轮，会就值得想办法压缩成摘要，不会就干脆别塞进去。
不同渠道的 Claude 价格为什么对不上？
可能是计价口径不同（含不含缓存、按不按输入输出分列），也可能是渠道自身加价或走的是云厂商托管版本。比较前先统一单位、统一包含项，否则算出来的差价没有意义。
