Clipping 微信公众号

同样用 Claude Code,有人月花 50,有人月花 500——差在哪?

by 三元同学 原文 ↗
Created: 2026-06-10

公众号名称:三元同学

作者名称:三元同学

发布时间:2026-06-10 10:10

最近有个读者来找我吐槽,说他用 Claude Code 用了两个月,账单一看吓了一跳——一个月花了快 500 块,而且感觉也没干多少活。

我说,你先给我看看你的 cache 命中率。

他问我:什么是 cache 命中率?

我当时就知道问题在哪了。

先说个残酷的事实

用 Agent 写代码,你的钱大部分花在了你看不见的地方。

Manus 官方公布过一组数据:在 Agent 运行过程中,输入和输出的 token 占比大概是 100:1。

100:1 什么概念?你的 Agent 每生成 1 个 token 的回答,背后有 100 个 token 的输入在支撑。

这其实很好理解。Agent 是多轮对话的,每一轮都要把完整的对话历史发给模型。第一轮你发了 5000 token,第二轮变成 8000,第三轮 12000… 到了第二十轮,输入可能已经膨胀到 10 万 token 了。而每一轮模型的输出可能就几百 token。

你的 API 账单里,90% 以上的钱都花在了输入 token 上。

这意味着什么?意味着不管你用的是 Claude、GPT 还是 Gemini,真正能帮你省钱的,不是找一个便宜的模型,而是想办法降低那 90% 的输入成本。

而降低输入成本,核心就一个词:Prompt Cache

Prompt Cache:你可能听过但没重视

我之前写过一篇文章专门聊这个,这里简单回顾一下核心逻辑。

Prompt Cache 的原理是前缀匹配。你这次请求的输入,和上次请求从第一个字符开始一模一样的那部分,就能命中缓存。命中缓存的 token 价格只有原价的 1/10

Agent 场景天然适合 Prompt Cache——每一轮对话都是在上一轮的基础上追加内容,前面那一大段对话历史就是完美的「共享前缀」。

各家模型的缓存折扣基本都在 90% 左右:

模型缓存折扣
Claude (Anthropic)90% off
DeepSeek99% off
Gemini (Google)80~90% off

算一笔账:假设你用 Claude Code 跑一个任务,产生了 100 万输入 token。如果没有缓存,全价要花 30 块左右。如果 cache 命中率 90%,实际花费只要 6 块。

同样的工作量,5 倍左右的成本差距,就差在这一个参数上。

这就是开头那个朋友的问题——他完全没有意识到 Prompt Cache 的存在,每次请求都在付全价。

为什么你的 cache 命中率可能很低

道理都懂了,但问题来了。

不是说 Agent 天然适合 Prompt Cache 吗?为什么我朋友用了两个月都没享受到?

因为 cache 能不能命中,不光取决于你怎么用,还取决于你的 API 是怎么接的。

这里有两个关键因素,很多人根本不知道。

第一个:渠道轮转。

如果你是通过一个 API 平台来调用模型的,这个平台背后可能有多个渠道(或者叫多个 API Key)。你的请求进来之后,被轮转分配到不同的渠道上。

上一轮请求走了渠道 A,写入了缓存。下一轮被轮转到渠道 B——渠道 B 上根本没有你之前的缓存,直接 miss。

你以为自己在享受缓存,实际上每一轮都在付全价。

第二个:缓存 TTL。

Prompt Cache 有时间窗口,Anthropic 默认是 5 分钟。Agent 跑起来的时候,两次请求间隔一般就几秒钟,5 分钟完全够用。但如果平台的调度延迟高,或者中间有排队机制,实际间隔可能被拉长,缓存就过期了。

所以你看,cache 命中率这件事,不是模型决定的,是你的 API 接入方式决定的

这就是为什么同样用 Claude Code,有人月花 50,有人月花 500。差的不是模型能力,是基础设施。

说说我自己的经历

说实话,这事我也是交了学费才搞明白的。

API 聚合平台和官方订阅方式我都折腾过。官方订阅难度会比较大、过程稍微曲折,也比较贵,如果你想了解具体方法,这里不太方便展开,你可以去公众号回复”cc”来领取详细攻略。

而开头那个读者刚好是用的 API 聚合平台,这个我也研究过,在这个尝试的过程中我发现真正让我在意的其实就两个点:一个是 API 稳定性,包括延迟;另一个就是 Prompt 缓存命中率。

后来我才真正明白:选 API 聚合/中转平台,倍率只是表面功夫,cache 命中率才是关键。

折腾了一圈之后,我现在稳定在用的是 Nbility 这个平台,也是我的一个朋友出来做的,用下来体感不错。

Nbility 首页

它本质上是一个大模型 API 聚合平台,统一接入了 OpenAI、Claude、Gemini、DeepSeek 等 40 多种主流模型,生图模型也支持(比如 gpt-image-2)。一个 API Key 就能调所有模型,接口格式兼容 OpenAI 标准,接入 Claude Code 和 Codex 都是无缝的。

但这些不是我选它的原因。API 聚合平台多了去了,能接入主流模型的也不止它一家。

**我选它的核心原因就一个:cache 命中率。**当然还有其他原因,后面再讲。

Nbility 做了一件关键的事:它不是简单地做负载均衡轮转,而是保证你的连续请求尽量落在同一个渠道上。这样你上一轮写入的缓存,下一轮大概率还能命中。

最终效果就是 **85% 以上的 cache 命中率。**就我目前使用 claude opus 模型的经验来讲,很稳,大量用都能维持在 85% 以上的缓存率:

缓存命中

回到前面那笔账:同样 100 万输入 token,全价 30 块,90% cache 命中只要 6 块。如果你一个月跑 1000 万 token(重度 Agent 用户很正常),差距就是 240 块。

而且稳定性方面,我用了这么久基本没碰到过掉链子的情况。对于 Agent 场景来说,稳定性其实跟成本一样重要——Agent 跑到一半断了,之前积累的整个对话上下文全废了,你只能从头再跑一遍。不光浪费钱,还浪费时间。

除了缓存和稳定性,我平时生图比较多,生图算是一个比较大的需求,这个平台上有 playground 可以直接玩起来:

用的 gpt-image-2 模型,业界最强生图模型。

首页导航栏上可以直接找到提示词库,然后在 playground 里面玩起来:

基本各种常见的风格和效果都在里面了,即使不用生图功能,这些 prompt 也是很有参考价值的。

怎么接入 Claude Code 和 Codex

既然说到实操了,顺便把接入步骤也说一下。

接入 Claude Code 其实非常简单。注册之后拿到 API Key,然后在 Claude Code 的配置里设置一下 base URL 和 key 就行了:

# 在 Claude Code 的设置里修改
export ANTHROPIC_BASE_URL=https://api.nbility.dev
export ANTHROPIC_API_KEY=你的key

Codex 的接入也是一样的思路,改一下 OpenAI 的 base URL 就行:

export OPENAI_BASE_URL=https://api.nbility.dev/v1
export OPENAI_API_KEY=你的key

两分钟搞定,后面就是透明的了。你正常用 Claude Code 和 Codex,底层的模型调用、缓存优化、渠道管理都是平台帮你处理的,完全无感。

几个实战省钱建议

既然聊到了 Agent 成本优化,再分享几个我这一年总结下来的实战经验。

第一,善用上下文压缩。

我之前写过一篇文章聊 Manus 的上下文压缩方法论——Reduce、Offload、Isolate 三板斧。核心思想是:不要把所有东西都往上下文里塞,用完的信息及时清理或压缩。上下文越精炼,不光模型表现更好,token 消耗也更少。

Claude Code 本身有 compaction 机制(输入 /compact 就能手动触发),Codex 也有类似的上下文管理。平时用的时候注意一下,不要让上下文无节制地膨胀。

第二,选对模型。

不是所有任务都需要上旗舰模型。日常的小改动、简单 bug fix,用 Sonnet 或者 Haiku 级别的就够了,价格差几倍甚至十几倍。旗舰模型留给复杂的架构设计、大规模重构这种场景。

第三,System Prompt 保持稳定。

这点直接影响 cache 命中率。你的 system prompt 放在请求最前面,是所有请求共享的前缀。如果你频繁改 system prompt,每次改动都会导致后面的缓存全部失效。

用 Claude Code 的时候,你的 CLAUDE.md 文件就相当于 system prompt 的一部分。稳定之后就别老改它——改一次,之前的缓存全废了。

第四,一个 Agent 任务别跑太长。

这个经验可能反直觉。你可能会想,让 Agent 一次性跑完整个需求不是效率最高吗?

实际上不是。Agent 跑到后面,上下文膨胀到几十万 token,模型的注意力分散了,输出质量会下降——我之前写过的 Context Rot 就是这个问题。而且超长对话即便有 cache,每一轮的增量部分也很大,成本依然不低。

我现在的习惯是,一个功能拆成两三步来做。第一步让 Agent 做完之后,手动触发一次 compaction,然后再开始下一步。这样既能保证上下文质量,又能控制每轮的 token 消耗。

第五,关注真实到手成本,不要只看标价。

这是我踩过最大的坑。有的平台标价很低,倍率看着也好看,但 cache 命中率低,实际花费反而更高。就像前面算的那笔账——cache 命中率从 90% 掉到 30%,你的实际成本可能翻了好几倍。

所以别光看表面价格,跑一段时间之后去看实际账单,算一下真实到手成本。数字会告诉你一切。

最后

用 AI 写代码这件事,模型能力已经不是瓶颈了。真正拉开差距的,是你怎么用、怎么搭环境、怎么控制成本。

如果你也在用 Claude Code 或者 Codex,可以试试看 Nbility。通过评论区置顶的链接注册会有额外的额度奖励。


你每个月在 AI 编程上花多少钱?有没有关注过自己的 cache 命中率?评论区聊聊。


内容效果不满意?点此反馈

输入关键词开始搜索