这周收到一条私信，某位开发者把官方文档里的一句话截图发我，话只截了一半：

Claude Code can be used with your Claude subscription or billed based on API usage through your……

他问我后半句是不是漏了，“through your”后面到底接什么。其实句子没坏，只是断在了一个容易被忽略的位置。完整的意思很简单：Claude Code 有两种付费方式，一种把你已有的 Claude 订阅额度拿来用，一种按 API 实际消耗计费，账单挂在你的 API 账号（也就是开发者控制台那个工作区）下面。

很多第一次用终端代理型编程工具的人，都会卡在“同一套工具怎么有两个账单”这个问题上。我自己最开始也分不清，订阅也续着，API Key 也配着，结果两边都在扣费才知道出了大问题。这篇就把两套计费入口彻底拆开讲清楚，包括它们怎么工作、各自适合谁、哪些场景最容易翻车，以及我现在到底怎么选。如果你是个人开发者、接外包的，或者在小团队里负责成本控制，应该都能用得上。

1. 两套计费通道，先分清“入口”再看“账单”

1.1 先确认我们聊的是同一个工具

Claude Code 是一个跑在终端里的编码代理，你在命令行里给它下指令，它能自己读项目、搜文件、改代码、跑测试，改什么之前先给你看 diff，你确认之后它才动手。它和网页聊天最大的区别是：它真的会动你的代码库，而且干活的时候会频繁读取文件、执行命令、把大量上下文塞进模型里。

正因为这样，单次会话消耗的 token 往往比聊天多一个数量级。很多只聊过天的用户第一次用命令行版时，会惊讶“我就让它改了个排序，怎么用掉这么多量”。这个认知差异，是后面所有计费困惑的根源。

1.2 那句话里省略掉的“your”到底是什么

补全那句话大概是这么个意思：你可以用 Claude 订阅套餐的额度来跑 Claude Code，也可以让 Claude Code 按 API 用量来计费，费用记在“你的 API 控制台账号”下。

也就是说，这段话实际上是在描述两种认证方式和两套结算对象：

• 订阅模式：登录你的 Claude 订阅账号，用量计入订阅套餐里包含的额度。
• API 模式：配置一个 API Key，每个请求按 token 结算，月底或按量出账单，钱从你的 API 账号余额/绑定的支付方式里扣。

所以“through your……”后面缺的其实就是 your API account 或者 your Console workspace。它不是一句没写完的话，而是官方文档默认读者知道“API 账号”是什么。第一次接触的人被卡住很正常。

1.3 快速判断自己当前走的是哪条路

判断当前终端里 Claude Code 用哪种模式，最直接的办法是看你有没有设置环境变量：

echo $ANTHROPIC_API_KEY

如果输出了一串sk-ant-开头的密钥，说明当前 shell 里已经存在 API Key。很可能你启动 Claude Code 时，它会优先走 API 计费而不是订阅额度。如果输出为空，说明你大概率走的是订阅登录模式。

更稳妥的做法是看 Claude Code 启动时的欢迎信息或账号提示，它会显示当前使用的账号身份。但我个人的经验是：环境变量是最容易阴人的地方，因为很多人早就在.bashrc或.zshrc里导出过 API Key，自己都忘了。

2. 同一个工具，为什么账单模型差这么多

2.1 身份体系完全不同：登录态 vs API Key

订阅模式本质上是你和官方之间有一个“会员关系”。你登录之后，服务端知道你是某个套餐的用户，于是按套餐规则给你分配额度。而 API 模式更像一个“预付费/后付费的开发账号”，你不需要买会员，只需要一把钥匙，每次调模型都是按量计费。

这两套身份在工程上是隔离的。你用 Claude 订阅账号登录网页能用，不代表同一个账号在开发者控制台里能看到 API 账单；反过来，你有一把 API Key，也不代表你能解锁会员专属的 Web 功能。Claude Code 比较特殊的地方在于，它把两条路都接上了，于是“同一个工具、两种身份、两种账单”就成了常态。

类比一下：订阅像健身房年卡，你办了卡就能用器械，但高峰时段可能排不上；API 像打车，每跑一公里算一公里钱，路线随便你规划，只要你愿意付钱。年卡用户骂高峰排队，打车用户骂价格贵，其实是两种完全不同的产品逻辑。

2.2 订阅模式不是“免费无限用”，它是额度包

很多人以为订阅之后 Claude Code 就是随便用。实际上订阅套餐给你的是一个额度池，额度用完之后不是自动扣钱，而是停在那儿让你等额度刷新。对短期高强度使用来说，这就非常难受。

我见过有人让 Claude Code 通宵跑一个大型重构，结果凌晨三点额度耗尽，任务中断，睡醒一看代码改到一半。这个“中断”不是提示你充值，而是告诉你当前时段额度不够了，请等下一波额度刷新。既不是省钱，也不省时间。

所以订阅模式适合的场景是：使用频率稳定、单次任务可控、能接受偶尔被额度卡住。千万不要拿它跑无人值守的自动化长任务。

2.3 API 模式是“按里程计价”，token 要会算账

API 模式的计价单位是 token，token 可以粗略理解为“模型读到的一段字符片段”。一个英文单词通常是一到两个 token，中文一个字大概对应一到两个 token，代码里的标识符、标点、空格也都会算 token。

Claude Code 这类工具尤其费 token，因为它不是简单地问一句答一句。它会把你项目里的文件内容、命令输出、diff 结果统统塞进上下文，而上下文越长，后续每次请求要重读的历史也越长。一次涉及多个文件的改动，烧掉几十万 token 是常有的事。

这里额外强调一下“上下文窗口”的影响。同样一个指令，在短对话里可能只需要几千 token，但如果前面已经积累了十轮文件读取和命令执行，后面每发一次请求都要带着前面所有历史重新算一遍。这不是工具在乱扣费，而是 transformer 模型的工作方式决定的。理解了这一点，你就明白为什么“同样的活，分几次做比堆在一个会话里做更省 token”。

3. 订阅套餐里的隐藏规则：哪些人会被“额度墙”拦住

3.1 不同订阅档位，差距不只是“贵一点”

我一般会把订阅档位分成“偶尔用”和“高强度用”两档，而不是只看月费数字。低一档的套餐适合在小型项目里改改 bug、写写测试、做点脚手架；高一档的套餐适合整天泡在终端里、同时开好几个项目、还经常跑大重构的人。

官方对套餐额度的描述在不同时期会调整，最靠谱的办法是看你登录后实时显示的剩余额度。我自己比较常用的判断标准是：

• 如果一周里你只有两三个下午在用，低档套餐基本够。
• 如果你工作日每天都要用，而且每次会话动不动跑半小时，直接考虑高档。
• 如果你已经把 Claude Code 当成“自动外包程序员”，每天给它派十几个任务，那订阅档位很大概率会撞墙。

一旦撞墙，你的选择只有两个：等额度刷新，或者切到 API 模式继续干。很多人就是在撞墙之后被迫开了 API，然后订阅也没退，两边一起付钱。

3.2 最容易把订阅额度烧干的三个习惯

根据我的观察，下面三种行为最容易让订阅额度快速见底：

• 长时间挂着一个会话不关。让它一直保持上下文，哪怕你中间吃饭去了，后面继续对话时前面历史全还在，每一条新指令都在为之前的“挂机”买单。
• 多终端窗口同时开。左边项目 A 跑重构，右边项目 B 跑迁移，每个窗口都在独立消耗上下文，额度是叠加烧的。
• 让它在大型仓库里漫无目的地探索。有些任务本身很模糊，比如“帮我看看这个项目哪里有问题”，它会为了搞清楚整个仓库结构反复读文件，token 消耗会非常夸张。不是工具笨，而是指令边界没定好。

这几条在订阅模式下会让你更早撞到额度墙，在 API 模式下则直接变成账单上涨。不管哪条路，先把“给 agent 明确任务边界”这件事做好，是省成本的前提。

4. API 计费的真实账本：单价、控费与告警

4.1 模型选型直接决定单价差异

API 模式下，不同模型的单价差距可以非常大。为了让你有一个数量级的概念，我这里用一组“示意单价”来算账，具体数值以官方定价页为准。假设某个标准模型的输入是 3 美元/百万 token，输出是 15 美元/百万 token，而某个旗舰模型可能是标准模型的好几倍。

比如一个任务跑了 100 万输入 token 和 20 万输出 token：

• 标准模型：1 * 3 + 0.2 * 15 = 6 美元
• 旗舰模型：按 3 倍算，大概 18 美元

一次简单会话就差了 12 美元。如果一天跑十次，差距相当可观。所以建议你在 Claude Code 里看清楚当前用的到底是哪个模型，而不是默认一路用到黑。很多人在 API 账单飙升之后才发现自己一直在用旗舰模型跑日常小任务，属于典型的“杀鸡用牛刀”。

4.2 给 API 模式装上“刹车”：Key 隔离、提醒与对账

API 模式最大的风险不是单价，而是失控。一个失控的任务，比如 agent 陷入循环反复改同一个文件，或者某个测试脚本无限制地调用模型，都可能让账单在几小时内飙出一个吓人的数字。我的经验是：不要相信自己的自制力，要多装几道闸。

第一道闸是Key 隔离。不同项目、不同环境用不同的 API Key，别所有项目共用一把。你可以把 Key 放到项目目录的.env文件里，而不是全局.bashrc。这样每个项目消耗多少，在 API 控制台里一眼就能分出来。

第二道闸是启动提醒。如果你经常在 API 模式和订阅模式之间切换，可以写一个极简包装脚本，在启动 Claude Code 之前提示你当前走的是哪条路：

#!/usr/bin/env bash # ~/.local/bin/my-claude.sh if [[ -n "$ANTHROPIC_API_KEY" ]]; then echo "[提醒] 当前 shell 检测到 ANTHROPIC_API_KEY" echo "本次运行可能按 API 计费，请确认是否继续。" read -r -p "继续? (y/N) " answer [[ "$answer" != "y" ]] && exit 0 fi ANTHROPIC_API_KEY="$ANTHROPIC_API_KEY" claude "$@"

这个脚本不是官方功能，而是我给自己的“防呆”措施。实测下来很有用，尤其是你同时管理订阅号和 API Key 的时候，启动前那一行提示能避免很多手滑。

第三道闸是定期对账。API 控制台里能看到用量明细，我一般每周看一次：哪个 Key 消耗最多、哪个时间段消耗最猛、有没有夜间跑飞的定时任务。订阅模式看不到 token 明细，只能看剩余额度，所以如果你需要精细的成本归因，API 模式反而是更好的选择。

5. 三个真实的账单翻车现场

5.1 场景一：订阅没到期，API 账单里却出现了扣费

这是我朋友亲历的事。他一直续着订阅，自认为 Claude Code 肯定走订阅额度，结果月底打开 API 账单一看，有二三十美元消耗。查了很久才发现，他一年前为了测试某个脚本，在.zshrc里写死了一行export ANTHROPIC_API_KEY=...，之后终端每次启动都会带上这串 Key。Claude Code 检测到环境变量里有 Key，就自动按 API 计费了，压根没用他的订阅额度。

这个坑最阴险的地方在于：订阅模式照样能登录，界面看起来一切正常，但实际请求全走了 API。排查方式很简单，就是前面提到的echo $ANTHROPIC_API_KEY。如果你发现输出有 Key 但自己平时不需要它，直接删掉那行 export 即可。注意只unset当前变量还不够，下次开终端的.zshrc还会把它再导出来，必须去配置文件里删干净。

5.2 场景二：一个项目多只手，API Key 混在公共环境里

另一个常见问题是团队协作时，大家共用同一份环境变量文件。几个同事同时跑 Claude Code，每个人都用同一把 Key，月底账单根本分不清是谁干的。更要命的是，如果有人写了一个循环调用脚本忘了关，整个团队的 API 额度都会被它吃掉。

解决办法还是 Key 隔离：每个成员、每个项目单独申请一把 Key，成本归到各自头上。没有人会因为“查不出是谁超支”而继续乱跑任务。这事听起来麻烦，但真出了大账单之后你会感谢当初做了隔离。

5.3 场景三：订阅额度耗尽了，还以为“没花钱就没事”

有人觉得订阅是固定支出，额度用完就等刷新，反正不会再扣钱。这句话没错，但它忽略了“时间成本”和“组合成本”。我见过一个开发者，订阅额度在下午四点耗尽，手头任务晚上要交，他等不及，就去开通了 API 继续跑。API 跑得很爽，任务也交了，但他没意识到：下个月订阅还会继续扣钱，而 API 那个月的消耗又叠加了一笔。

这算是“两条路都走”的最差姿势：订阅的固定费用没省，API 的按量费用又叠加了。如果你已经决定了某段时间要心无旁骛地冲任务，建议直接按那个阶段的用量算清楚，是继续续订阅还是切 API，不要“两边各付一遍”。

6. 我现在的选择建议：什么情况走订阅，什么情况走 API

6.1 一张表帮你快速决策

我可以把自己的选择逻辑整理成一张决策清单，给不同使用方式的人做参考：

这张表不会适合所有人，但绝大多数人可以从里面找到自己的影子。

6.2 我的实践心得：两条路可以混用，但必须“门儿清”

我现在个人是这么用的：日常的小改动、写文章配的示例代码、临时验证想法，全部走订阅额度；接外包项目、需要长时间跑大任务的场景，单独申请一把 API Key，只放在对应项目的.env里，跑完就对账。这样既不容易撞订阅额度墙，也不会让 API 账单失控。

最关键的一条经验是：永远不要依赖全局环境变量来决定计费通道。全局的环境变量是隐形的，它会接管你的选择，让你误以为自己在用订阅模式，实际上却在烧 API 余额。把 API Key 收进项目局部环境，把订阅登录态留给日常会话，两边的账才会真正分开。

如果你现在正卡在“through your……”这句话上，我的建议是别急着开 API，也别急着退订阅。先跑一遍echo $ANTHROPIC_API_KEY，看看自己当前到底走的是哪条路。很多计费困惑，其实是环境变量在背后偷偷做决定。