乐于分享
好东西不私藏

你知道你的 AI 助手是如何向你收费的吗?

你知道你的 AI 助手是如何向你收费的吗?

一张关于日常 AI 编程助手使用的完整地图:会话、工具、skill、MCP、子代理——每样东西如何进入上下文窗口,又各自怎么计费。全文的流程梳理与计费核算以 Claude Code 为例,价格为其官方每百万 token(MTok)牌价[1],文中以「旗舰 / 主力 / 轻量」指代其三档模型;企业合同价可能与牌价不同,但各项之间的比例关系一致。文中的花费案例来自一份真实使用记录(详见第 9 节)。

太长不看:① 一份真实账单:半个月 $1,440、每天 $90,其中真正"产出"的输出只占 $300——大头花在反复重读上下文上;② token 计费的真正驱动是上下文大小 × 往返轮数,而不是你发了几条消息;③ 停顿超过 5 分钟,整个上下文按 1.25 倍全价重写一遍,最坏使用模式能比推荐模式贵 10–50 倍。降本手段见第 7 节与第 10 节速查表。
目录
  1. 基本循环:API 什么都不记得
  2. 上下文窗口里装了什么
  3. 四种价格,以及 KV cache 读/写到底是什么
  4. 逐项拆解:工具、skill、MCP、子代理、图片
  5. 热会话 vs 冷会话(5 分钟规则)
  6. 五种常见使用模式及各自的花费
  7. 推荐的使用模式:三条降本杠杆
  8. 最坏的使用模式
  9. 真实案例:半个月的账单拆解
  10. 一页降本速查表

1. 基本循环:API 什么都不记得

最重要的一个事实,也是下面所有成本的根源:模型服务器在两次请求之间不保留任何记忆。完整的聊天历史保存在用户电脑上的编程助手里。每一轮,它都把全部历史重新发一遍——系统提示、所有历史消息、所有历史工具结果——再加上新消息。服务器把这些全部读完,然后写出回答。

图 1 —— 请求循环。关键点:蓝色箭头每次都携带完整历史。所以真正的成本驱动是"上下文大小 × 轮数",而不是任何单条消息。

一个问题通常触发很多次往返:读一个文件(一次往返)、跑一条命令(一次往返)、改一个文件(一次往返)……每次往返都会把已经变得更长的历史重新发送一遍。一个要调 30 次工具的任务,历史大约被重发 30 遍。

2. 上下文窗口里装了什么

上下文是一个"栈"。顺序很重要,因为缓存作用在前面的部分("前缀")——稳定的东西排在前面,不断增长的历史排在后面。

图 2 —— 上下文栈。蓝色各层是"装了东西"就要在每个会话交的房租;橙色层是日常工作不断堆积的地方。

3. 四种价格,以及 KV cache 读/写到底是什么

KV 缓存是什么

读一遍很长的前缀,对模型来说是很重的计算。所以服务器提供一笔交易:处理完一段前缀之后,可以把处理结果暂存起来(即"KV 缓存")。如果下一个请求以完全相同的字节开头,服务器就跳过重复计算,只收一小笔"复用费"。

  • CACHE WRITE(缓存写)
    "处理这段前缀,并且存下来。"价格是普通输入价的 1.25 倍。第一次会发生,存的副本过期或作废之后也会再发生。
  • CACHE READ(缓存读)
    "这一段已经存过了——直接复用。"价格是普通输入价的 0.1 倍。会话之后每一轮为整个历史付的就是这个。
  • 暂存副本在最后一次请求后存活 5 分钟(编程助手用的是默认的 5 分钟生存期)[2]。每个新请求都会重置这个 5 分钟计时。

价格表(每百万 token,牌价)[1]

模型
输入
输出
缓存写(1.25×)
缓存读(0.1×)
旗舰模型
(最强也最贵)
$10.00
$50.00
$12.50
$1.00
主力模型
(日常主力)
$5.00
$25.00
$6.25
$0.50
轻量模型
(轻量帮手)
$1.00
$5.00
$1.25
$0.10

缓存到底省不省钱?算一笔完整的账

比较"有缓存 vs 无缓存"时,必须把缓存写的 25% 溢价也算进缓存的成本,否则会高估节省。用第 9 节的真实案例(半个月,旗舰模型)算完整账:

无缓存(假设)
有缓存(实际)
前缀 token 共 5.7 亿(= 200 万未缓存 + 4,800 万写 + 5.2 亿读)
570M × $10 = $5,700
$20 + $600 + $520 = $1,140
输出(两种情况相同)
$300
$300
合计$6,000$1,440
净省 $4,560(76%)——这个数已经扣除了缓存写的溢价。单看"写"确实亏:同样的 token 按缓存写付 $600,按普通输入只要 $480,多付了 $120。这 $120 是买"以后能便宜复用"的入场费。盈亏平衡点:一段写入的前缀只要之后被复用至少 1 次就回本(写 1.25 + 读 0.1 = 1.35 倍,低于不缓存发两遍的 2.0 倍)。真正浪费钱的是"孤儿写入"——写完还没来得及复用,缓存就过期或作废了(典型:冷恢复重写之后马上又闲置)。

缓存读为什么会变大

它是一个乘法:上下文大小 × 往返次数。一个装着 20 万 token 的会话再跑 50 次往返,就要重读 1,000 万 token = 在旗舰模型上是 $10——哪怕只打了三个短问题。

缓存写为什么会变大

三个原因,日常工作里都很常见。注意:写本身不是浪费(新内容总要处理一次),浪费的是同样的内容被反复重写写了却从未复用:

  1. 闲置间隔。
    停下超过 5 分钟;暂存副本过期;下一轮要按 1.25 倍输入价把整个前缀重写一遍——这部分是纯重复劳动。
  2. 新内容。
    每个新的工具结果 / 消息都要写入缓存一次(不可避免,也是健康的)。
  3. 多个独立上下文。
    每个并行会话、每个子代理、每个 workflow 工作单元,都有自己的前缀,各写自己的一份缓存。

4. 逐项拆解每种操作

下面所有内容都遵循同一条规则:操作返回的任何东西都会追加进历史,从那一刻起,之后的每次往返都会重读它。所以一个大返回的真实成本 = 它的大小 × 它之后还有多少轮。

4.1 工具调用(Read、Bash/PowerShell、Grep、Edit …)

发生了什么:模型发出一个工具请求(按OUTPUT计费,因为它是模型生成的文本)。本地执行工具。结果文本追加进历史(先按CACHE WRITE计费一次,之后每轮按CACHE READ计费)。

例子
进入上下文的内容
典型大小
Read
 整个源文件
文件全文
2k–50k token
Read
 截图 / 图片
图片按视觉 token 折算
每张约 1k–2k token
Bash
 命令输出
全部 stdout(超 30,000 字符截断)
0.1k–8k token
Grep
(文件列表模式)
只有命中的文件路径
几十 token——最省的搜索
Grep
(内容模式)
命中行 + 上下文行
0.1k–3k token

算例:读一个 10,000 token 的文件,之后在旗舰模型上再跑 30 次往返:
写一次:10k × $12.5/M = $0.125 + 重读 30 次:300k × $1/M = $0.30 → 一次文件读取总计 ≈ $0.43。一个长会话里这样读十个文件 ≈ $4.3。这就是"只读需要的部分"的意义。

4.2 Skill

始终要付的(很小):每个已安装 skill 的名字 + 一行描述,放在每个会话的系统提示里——每个几十 token。20 个 skill ≈ 1–2k token 的固定房租。

被调用时才付的:当用户输入 /skill-name,或模型判断某个 skill 适用时,它的完整 SKILL.md 正文(以及它要求读取的文件)会加载进历史——通常 1k–10k token,每个会话一次,之后和其他内容一样被重读。

作用域规则:"始终要付"的是两类——全局 skill(装在用户主目录下)和工具内置 skill,它们的描述进入每个会话。项目 skill(放在某个项目的目录下)则不是全部读取:只有当会话在该项目目录树内启动时才会加载;会话可以同时看到当前目录与其上层目录里的 skill(同名时最具体的目录优先),但其他无关项目的 skill 完全不会被读取、也不产生任何费用。这就是全局列表要保持精简、场景化 skill 应下放到项目目录的原因。

4.3 MCP server

三层成本,从"永远在付"到"按次付":

  1. 房租server 使用说明 + 工具名,始终加载。
    每个注册的 server 都会把它的使用说明和工具名列表注入该作用域内的每个会话——不管用没用。如果开启了延迟加载(只预载工具名字,完整 schema 按需拉取),这一层会小很多;但挂 10 个 server 的使用说明,依然是每个会话实打实的房租。
  2. 首次使用时工具 schema。
    某个工具第一次要用时,它的完整参数定义被拉进上下文。
  3. 每次调用调用返回。
    这是大头。一次邮件搜索可能返回几十 KB 的 JSON(正文、header、元数据);一次 Slack 历史查询、一个 Jira issue 详情——同理。这些 JSON 落进历史,之后每轮都被重读。

经验法则:MCP 贵不是因为调用了它。贵在(a)从不调用的 server 也在每个会话里交房租;(b)一个肥大的 JSON 返回,会在会话余下的每一轮里持续花钱。

4.4 子代理与 workflow

发生了什么:子代理是一个独立、全新、小巧的上下文。它自己跑自己的往返(自己的缓存写 + 读 + 输出,用它自己的模型),只有最终总结回到主会话的历史里。

好处主会话保持苗条:子代理内部的 30 次文件读取完全不碰主上下文——回来的只有约 1k token 的总结。

注意每个代理为自己的前缀写一份自己的缓存。一个铺开 100 个代理的 workflow 就是 100 次独立的缓存写。每个代理小、用便宜模型时没问题;每个代理都背着大 prompt 跑旗舰模型时就贵了。

最佳用法:探索、批量提取、机械检查 → 交给轻量模型上的子代理(每 token 便宜 10 倍)。困难的推理留在主会话。

4.5 模型选择与 effort

同样形状的会话,在主力模型上便宜 2 倍,在轻量模型上便宜 10 倍——四种价格全部同比例。effort 设置主要改变OUTPUT(思考 + 正文长度)——effort 越高想得越久。输出是单价最贵的 token 类型(旗舰模型上 $50/M),但量通常最小;第 9 节的案例里,输出约占 $1,440 中的 $300。

警告:会话中途切换模型会作废全部缓存(新模型必须把所有内容重写一遍)。要切就在任务之间切,别在一个任务中间切。

5. 热会话 vs 冷会话——5 分钟规则

"热" = 轮次间隔不到 5 分钟,缓存一直活着。"冷" = 停顿更久,缓存过期,下一轮必须把整个前缀重写一遍。同样的工作,账单差别很大。

图 3 —— 5 分钟规则。一次冷恢复的价格是一次热轮次的 12.5 倍(写 $12.5/M vs 读 $1/M)。两个闲置间隔就让同样 5 轮的账单翻了一倍多。注:算例为简化,假设上下文恒为 20 万 token,忽略了每轮的少量新增写入与输出费用——它们在两种情形下相同,不影响对比结论。

这是最安静的漏钱口。闲置之后屏幕上看不出任何变化——会话正常继续。但服务器刚刚把 20 万 token 的完整历史按"全价再加 25%"重新处理了一遍。第 9 节案例中 $600 的缓存写,一部分来自这种冷恢复,一部分来自子代理集群。

6. 五种常见使用模式及各自的花费

模式
形态
钱花在哪
结论
A. 快问快答
1–3 轮,上下文小,几分钟结束
几乎不花钱——一次小写入、极少的读、一点输出
最便宜。不需要任何优化。
B. 专注工作会话
30–100 次往返,连续,单一任务,上下文涨到 100–200k
缓存读(上下文 × 轮数)+ 输出。第 9 节案例中,读的花费约是输出的 1.7 倍。
正常的日常工作。保持热度;控制工具返回大小。
C. 被打断的会话
和 B 一样,但夹着咖啡、会议、任务切换(>5 分钟)
反复的全前缀缓存写——每次恢复是热轮次的 12.5 倍
安静的燃烧器。要么一口气做完,要么 /clear 后小上下文重启。
D. 铺开(子代理 / workflow)
主会话 + N 个并行代理
N 份独立缓存写 + N 份输出。代理小、用轻量模型时便宜;每个都背大 prompt 跑旗舰模型时贵
好工具,剂量决定毒性。案例中曾单日产生约 130 个子代理、当日花费约 $240,即此模式。
E. 大杂烩
一个永生会话:所有 MCP、整文件贴进来、闲置间隔、从不 /clear
全都占:巨大前缀 × 很多轮 × 反复重写
最坏情况。见第 8 节。

7. 推荐的使用模式:三条降本杠杆

图 4 —— 推荐流程。主会话 = 小而热;子代理用便宜模型吸收大批量读取;/clear 在任务之间给计价器归零。

一句话说清它为什么有效:上面每条规则,要么缩小前缀(每轮房租更少),要么减少重写(保持热度、/clear),要么把大批量 token 挪到便宜 10 倍的计价器上(轻量模型子代理)。

8. 最坏的使用模式

图 5 —— 最坏模式不是一个大错误,而是六个小"方便"乘在一起。倍数为量级示意,非精确测量。

9. 真实案例:半个月的账单拆解(旗舰模型,16 个自然日)

数据来自一份真实的重度使用记录(各项数字均已取整),日常任务包括代码、文档、数据分析与批量子代理。

计费类型
Token 量
牌价
花费
解读
INPUT
 未缓存输入
200 万
$10 / M
$20
非常小——说明缓存在正常工作
OUTPUT
 回答 + 思考 + 工具请求
600 万
$50 / M
$300
真正"产出的工作"
CACHE WRITE
 缓存写
4,800 万
$12.5 / M
$600
最大单项:冷恢复 + 单日上百个子代理 + 新内容
CACHE READ
 缓存读
5.2 亿
$1 / M
$520
上下文 × 轮数的乘法结果
合计$1,440
= 每自然日 $90

无缓存对照(完整算账,含写溢价):同样的 token 流若完全不用缓存,5.7 亿前缀 token 全按 $10/M 输入价 = $5,700,加输出 $300,合计 = $6,000。有缓存实付 $1,440,净省 $4,560(76%)——细节见第 3 节。

降本应瞄准的位置:缓存写这一行($600)对应的手段是减少闲置后的冷恢复、缩小/降级代理集群。缓存读这一行($520)对应的是更小的前缀(少挂全局 MCP、控制工具返回、/clear)和每个任务更少的轮数。输出($300)大部分是真实工作——不用管它。

10. 一页降本速查表

操作
按什么计费
旗舰模型上的体感
在热会话里发一条短消息
读整个前缀 + 一点写入 + 输出
100–200k 上下文时,每轮约 $0.10–0.40
闲置 > 5 分钟后继续
重写整个前缀
(1.25× 输入价)
100–200k 上下文时约 $1.2–2.5——是热轮次的 12.5 倍
读大文件 / 拿到肥大的 MCP JSON
写一次 + 之后每轮重读
10k token 在后续 30 轮里 ≈ $0.43
调用一个 skill
skill 正文进历史一次
通常不大(1–10k token)
挂着 10 个不用的 MCP server
说明书每轮、每会话被重读
纯房租——移除或改成按项目挂载
铺开 100 个子代理
100 份独立缓存写 + 输出
轻量模型上没问题,旗舰模型上很重
会话中途切换模型
缓存全部作废 → 全量重写
和一次冷恢复同等代价
任务之间 /clear
下个任务从极小前缀开始
免费,而且给计价器归零
一句话总结:费用 = 摆在模型面前的 token 数量 × 它们被重新处理的次数——所以把前面摆的东西弄小(MCP 按项目挂、/clear、控制工具返回),让会话保持热度(5 分钟规则),并把大批量工作放到便宜模型上(轻量模型子代理)。

如果这篇帮你看清了 AI 助手的账单,建议收藏备查——下次账单异常时,对着第 10 节速查表逐条排查就行。也欢迎留言聊聊:你踩过最深的"漏钱坑"是哪一个——冷恢复、肥大的 MCP 返回,还是从不 /clear?

附录:参考链接

[1] Anthropic 官方模型定价文档:
https://platform.claude.com/docs/en/pricing

[2] Anthropic prompt caching 官方文档:
https://platform.claude.com/docs/en/build-with-claude/prompt-caching

说明:牌价与缓存倍率(默认 5 分钟生存期下缓存写 = 输入价 × 1.25、缓存读 = 输入价 × 0.1,写入后复用一次即回本:1.25 + 0.1 = 1.35 < 2.0)以上述官方文档为准,企业合同价可能与牌价不同。案例 token 量来自一份为期半个月的真实使用记录,文中数字均已取整。