个人开发者，Claude Code 重度用户，每月 token 消耗折合官方 API 价约 30 左右。以下方法均可独立使用，叠加效果最佳。
先说结论：把 Claude Code 的实际成本压到官方价 1/5，靠的不是单一技巧，是四层叠加：
- 低内部汇率中转站（起点降到官方价的 33%）
- Prompt Cache（在此基础上再降约 50–60%）
- effortLevel 调节（进一步减少约 20–30% token 消耗）
- 上下文管理（用
/compact和/new控制每次请求的 token 总量）
每层独立有效，叠加后等效成本可以压到官方 API 直连的 10–20%。
方法一：选对中转站，起点就比别人低 3 倍
很多人只看美元标价，这是最大的认知坑。
中转平台通常以人民币充值，但按美元计费扣额度。内部汇率决定了充 ¥100 实际能换多少美元额度：
| 平台类型 | 内部汇率 | 充¥100 可用额度 | 相当于官方价格 |
|---|---|---|---|
| 低汇率平台 | ¥2.4/$ | ≈ $41.7 | ≈ 33% |
| 市场汇率平台 | ¥7/$ | ≈ $14.3 | ≈ 100% |
同样充 ¥100，低汇率平台能用的 token 是市场汇率平台的近 3 倍。
我目前主力用灵眸AI，内部汇率 ¥2.4/$，Claude Opus 4.7 加权均价约 ¥45.6/百万 token，是我对比过的8个平台里最低的。
但在用灵眸之前，我踩过一个更贵的坑——
识别"低汇率 + 高倍率"陷阱
有个平台宣传 ¥0.5/200，我以为捡到了。跑了不到一个月 Claude Code，额度消耗速度异常快，后来仔细算才发现它的内部倍率是 3×：官方 1M token 收 15。超低汇率的优势全被倍率吃掉，实际成本是灵眸的 2 倍多。
充值到账金额和消耗速率是两套独立数字，只看充值汇率完全发现不了这个问题。唯一可信的比较维度是换算后的 ¥/百万 token，充值前用实际消耗数据验证一次比什么都可靠。
各平台真实价格可以用这个计算器自己验证：calc.lmu.ai/（我自己做的比价工具，数据可实时编辑，填入月用量后显示月费估算）
灵眸AI 的缺点也要说清楚：文档做得比较简单，从官网首页找不到 Claude Code 的接入教程，第一次配置需要进后台才能看到。充值目前只支持微信支付，没有支付宝。低汇率平台的汇率也不是固定的，有权调整——不建议大额充值，按月用量充更稳。
方法二：开启 Prompt Cache，成本再降 50% 以上
这是 Claude Code 用户最容易忽略的成本洼地，也是收益最大的一项。
为什么 Cache 对 Claude Code 这么重要？
Claude Code 每次发起请求，都会携带完整的系统提示词（system prompt）。这个提示词包含工具定义、全局指令等内容，通常有几千 token。不走缓存的话，每次请求都按完整输入计费。
启用 Prompt Cache 之后：
- 系统提示词首次写入缓存，收取 Cache Write 费用
- 后续命中缓存，只收 Cache Read 费用（约为输入价格的 10%）
实测：在持续工作的 session 中（对话轮次较多、上下文连续），Claude Code 的 token 支出可以下降 50–60%。
缓存命中率高度依赖使用方式：连续在同一个 session 内工作、上下文不中断时命中率高；频繁开新 session 或上下文跳跃时命中率低。
重要前提：需要确认平台支持 Prompt Caching。
很多便宜平台使用的是逆向接口，不支持 Prompt Caching——表面价格低，但算上缓存差距后实际成本不一定更低。灵眸AI 支持 Cache Write 5分钟和1小时两档，Claude Code 场景下1小时档命中率更高。
接入方式
编辑 ~/.claude/settings.json：
{
"env": {
"ANTHROPIC_BASE_URL": "https://clawapi.fulitimes.com/",
"ANTHROPIC_AUTH_TOKEN": "你的API Key"
}
}
Cache 功能由 Claude Code 自动管理，无需额外配置，接入后直接生效。
方法三：调低 effortLevel，减少推理 token 浪费
Claude Code 支持通过 effortLevel 控制推理深度，默认为 high。
对于日常代码辅助任务——改 bug、解释代码、简单重构、写注释——medium 档的输出质量与 high 差异不明显，但 token 消耗明显更少。
在 ~/.claude/settings.json 中加入：
{
"effortLevel": "medium"
}
实测对于普通任务，token 消耗减少约 20–30%。
什么时候不适合降 effort：
- 复杂的架构设计、多文件重构
- 需要深度推理的 debug（错误链路长、涉及多模块）
- 性能优化分析
需要切回 high 时，修改 settings.json 中的 effortLevel 为 high 后重启 Claude Code 即可。如果不想频繁改配置文件，也可以在对话开头明确说"这是一个复杂任务，需要深度分析"，模型会相应调整推理深度。
方法四：用 /compact 和 /new 管理上下文，控制每次请求的 token 总量
这个方法最容易被忽视，因为它不影响单价，但直接影响每次请求的 token 消耗量。
问题在哪里
Claude Code 每次发送请求时，会把当前 session 的完整对话历史一起发出去。随着对话轮次增加，这个上下文越来越长——即使你只问了一句简单的问题，背后携带的 token 量可能已经是几千甚至上万。长上下文的每一轮请求，输入成本都在悄悄累积。
两个命令的用法
/compact — 压缩当前上下文
在对话中输入 /compact，Claude Code 会把当前的对话历史压缩成一段摘要，用摘要替换原始的完整历史。适合：
- 当前任务还没完成，不想开新 session
- 对话已经进行了很多轮，感觉上下文开始臃肿
- 刚完成一个子任务，准备进入下一阶段
压缩后上下文大幅缩短，后续每轮请求的输入 token 量明显下降。
/new — 开启新 session，彻底清空上下文
切换到完全不相关的新任务时用。前一个 session 的所有上下文不会被携带，从零开始计费。
实际使用节奏
开始任务 → 正常对话 →
上下文变长时用 /compact 压缩 →
任务完成或切换新话题时用 /new →
新 session 重新开始
对于长时间连续工作的 Claude Code 用户，合理使用这两个命令，每次请求的输入 token 量可以减少 30–50%，配合 Prompt Cache 效果更显著——上下文短，缓存命中的比例更高。
四层叠加的实际效果
以下数字基于这些假设：输入/输出权重 30/70、Cache 命中率 60%、effortLevel 节省 25%、上下文管理节省 30%（均为输入端）。
| 优化层级 | 相对官方价格 | 说明 |
|---|---|---|
| 官方 API 直连 | 100% | Claude Opus 4.7，市场汇率 ¥7/$ |
| 低汇率中转站 | ≈ 33% | 内部汇率 ¥2.4/$ |
| + Prompt Cache | ≈ 16% | 输入端 60% 命中，读取成本降 90% |
| + effortLevel medium | ≈ 12–13% | 输入 token 进一步减少约 25% |
| + /compact /new 管理 | ≈ 8–10% | 上下文缩短，输入量再减约 30% |
实际效果因使用场景而异。 四层方法不必全部启用——对轻量使用者，仅靠方法一就能获得最大收益；重度 Claude Code 用户叠加越多收益越显著。
选平台前的五步核查清单
在任何一个新平台充值之前，建议先跑完这五项：
- ¥/百万 token 是多少 — 换算后的数字，不是美元标价，不是汇率
- 内部倍率是否 1× — 充值后用小额测试，对比实际消耗速度
- 是否支持 Prompt Caching — 官方 API 接口才有，逆向接口没有
- 服务器在国内还是境外 — 直接影响 Claude Code 的首 token 延迟体感
- 是否支持小额充值 — 不确定时先充小额验证，不要一次充几百
用这个清单过一遍，基本能排掉大部分雷。
附：各平台价格对比工具
为了持续跟踪各平台的真实价格，我自己做了个在线比价计算器：
支持自定义权重、月用量估算、导出 Markdown/CSV，数据存本地不上传，也可以添加新平台自己对比。源码开放在 GitHub。
最后
一句话总结：低汇率平台 + Prompt Cache + effortLevel 调节 + 上下文管理，四层叠加可以把 Claude Code 的实际成本控制在官方价格的 10% 左右。
三个方法都是利用现有机制的合理配置，没有任何灰色操作，任何人都可以复现。唯一的风险点是低汇率平台的汇率稳定性，控制充值金额可以有效规避。
有其他省钱方法欢迎评论区分享，我会持续更新。
数据来源：2026年4月实测，基于 Claude Opus 4.7 比价工具：calc.lmu.ai/ 如发现数据有误，欢迎指正
