我把两个Claude账号打通了

我手上有两个 Claude 的订阅。一个 Pro，每个月 20 美元；一个 Max，每个月 100 美元。Max 是主力，Claude Code 日常干活全靠它，特别是 Fable 这个模型只有 Max 订阅才能跑。Pro 因为没有fable，只能做做问答，基本不知道额度怎么用。

Claude 的额度机制是，每周给一个固定的量，用不完就清零，不累积到下周。Pro 那边的额度在每个周快到期时，我总得挖空心思来把这个额度用掉。

因为我的 Pro 办的是年卡，退不掉，所以非常蛋疼。后来我想到，Max 的主代理在干活的时候经常要派子任务出去，我们的 worker 机制就是干这个的。如果这些子任务能走 Pro 的 Opus 额度，那 Pro 的 token 就有地方用了。

问题就变成了：能不能让 Max 上跑的主代理，在派子任务的时候，用 Pro 账号的身份去跑？

先搞清楚子代理到底是怎么回事

我们日常在 Claude Code 里让主代理派活给子代理，这个动作看着就一句指令的事。但子代理这个概念其实藏着两种完全不同的实现方式，不搞清楚这个就走不下去。

先说第一种。Claude Code 里有一个内置的 Agent 工具，主代理可以调用它来起一个子任务。这种子代理跟主代理运行在同一个进程里面，共享同一份登录凭证，同一个会话环境。可以想象成主代理伸出一只手去干另一件事，但这只手还长在自己身上。这种方式下，子代理用的就是主代理的账号，没有任何入口可以指定"这个子任务换个账号跑"。怎么改配置都做不到，这条路堵死了。

再说第二种。我们自己搭的 worker 机制不是这样的。它通过一个 shell 脚本去启动一个全新的 claude 进程，这个进程跟主代理之间没有进程级别的父子关系，是一个完全独立的程序实例。关键在于，这个独立进程用哪个账号的身份运行，取决于它启动时一个叫 CLAUDE_CONFIG_DIR 的环境变量指向了哪个目录。

这就有搞头了。

换账号比想象中简单

Claude Code 在本地管理登录状态的方式其实很朴素。每次用一个 Google 账号登录 Claude，它会在本地创建一个目录，里面存一份 OAuth 凭证文件。如果在同一台机器上先后登录过两个账号，本地就会有两个这样的目录，各自存着各自的凭证。

我们两个账号都在这台机器上登录过，所以本地确实有两套档案，Pro 一套，Max 一套，安安静静地各自待在自己的目录里。

到这里解法就清楚了。worker 脚本在启动子进程之前，根据任务指定的账号，把 CLAUDE_CONFIG_DIR 设成 Pro 档案所在的目录，然后再启动 claude 进程。这个进程读到的凭证就是 Pro 的，跑起来花的就是 Pro 的 Opus 额度。

实际改动很小。我们在 worker 脚本里加了一层解析：模型名后面可以带一个账号标记，比如 claude-opus-5@pro，脚本看到这个标记就去找 Pro 的档案目录。不带标记就走默认的 Max 账号，跟以前一模一样。用本地模型（比如 Qwen 27B）跑的那些任务完全不涉及账号的概念，也不受任何影响。

改完之后跑了一次测试，确认 worker 进程确实以 Pro 的身份在运行，额度扣的也是 Pro 那边的池子。跨账号的路，就这么通了。

通了之后新问题马上来了

能跨账号当然是好事，但如果每次派任务都要手动想一下"这个该走 Pro 还是走 Max"，那也太累了。更关键的是容易判断失误。

Claude 对每个账号有两层额度限制。一个是 5 小时的滚动窗口，限制短时间内不能用太猛；一个是 7 天的周窗口，限制每周的总用量。两个账号的这两个窗口各走各的进度，四个数字（Pro 的 5 小时和 7 天，Max 的 5 小时和 7 天）都在独立变化。

可能 Pro 的 5 小时窗口还很宽裕，但周额度已经快见底了；Max 可能正好反过来。靠人脑去跟踪这四个数字、判断哪个账号更适合当前这个任务，这种负担放在日常流程里是不现实的。一旦判断错了，选了一个快撞线的账号，任务跑到一半额度耗尽，前面消耗的 token 全白费，反而更浪费。

所以下一步很自然：让脚本自己去查额度、自己决定用哪个账号。

额度怎么查：零成本的探针

要自动选账号，前提是能实时知道每个账号当前还剩多少额度。

我们的做法是利用 Claude 的 SDK 做一个探针。原理是对每个账号发一次最小的 API 请求，请求本身不产生实际的 token 消耗（不开真正的对话），但返回的信息里会附带当前账号的用量数据。能拿到的东西包括：5 小时窗口用了百分之多少，7 天窗口用了百分之多少，各自什么时候重置。

两个账号各探一次，整个过程大概 7 秒，零 token 消耗。

探到的结果会缓存到本地，5 分钟之内有效。如果 5 分钟内连续派了三个任务，只有第一个任务会真正触发探针，后面两个直接读缓存就行。既保证数据足够新鲜，又不会频繁探测浪费时间。

实测拿到的数据长这个样子：

Pro 账号：5 小时窗口用了 0%，7 天窗口用了 34%，周四重置Max 账号：5 小时窗口用了 6%，7 天窗口用了 26%，下周日重置

有了这些数据，选账号就有依据了。

选账号的规则：先排除危险的，再挑最合适的

拿到额度数据之后，选账号的逻辑分两步。

第一步是排除。如果某个账号的 5 小时窗口已经用了超过 70%，这一轮就暂时不选它。为什么设在 70% 而不是等到 100%？因为一个 worker 任务从开始到结束要消耗不少 token，如果 5 小时窗口已经用了七成还往上堆，很可能任务跑到中途窗口就满了。任务中断不说，前面花掉的 token 也收不回来。70% 是一个留有余量的安全线，具体数字可以根据实际情况调。

那周额度（7 天窗口）呢？周额度不做排除。原因很简单，我们搞这一套的目的就是把每周的额度尽量用光，所以不应该因为周额度用得多就不让用了。周额度只参与下一步的排序。

第二步是排队。对没被排除的账号，我们算一个叫"节奏比"的数字。公式很简单：

节奏比 = 周额度还剩的比例 ÷ 这周时间还剩的比例

举个例子。假设今天是周三，这一周过了大约 40%，还剩 60% 的时间。Pro 的周额度用了 34%，还剩 66%。那 Pro 的节奏比就是 66% ÷ 60% ≈ 1.1。

这个数大于 1，说明什么？说明 Pro 的额度消耗速度比时间流逝的速度慢。时间走了 40%，额度才用了 34%，节奏慢了，额度在"攒着"。应该多用用，不然到周末就浪费了。

同一时刻如果 Max 的节奏比是 0.9，说明 Max 那边消耗得比时间稍快一点，可以缓缓。这时候系统就会选 Pro。

这个数字的好处在于它会随时间自动调整。周一两边刚重置，节奏比差不多，可能 Pro 稍高一点（因为 Pro 总量小，相同消耗占比更大），那就先用 Pro。到了周五周六，如果哪边还攒着很多没花，时间分母越来越小，节奏比就会飙高，系统自然会集中火力去用那个账号。

所以它同时覆盖了两种场景：平时优先用额度宽裕的那个，快到重置了就赶紧把剩得多的用掉。一个除法，两件事都解决了。

额度用完了不能一刀切

以前只有一个账号的时候，额度用完了只能整个系统暂停，等窗口重置。现在有两条路了，如果一个账号撞线还是全停，那多一个账号的意义就大打折扣了。

改成按账号分开管。Pro 的额度用完了，系统只关掉 Pro 这条路，自动切回 Max 继续接活。主代理本身跑在 Max 上，它自己的工作完全不受 Pro 那边的影响。等 Pro 的 5 小时窗口重置了，下一次探针会发现 Pro 又有余量了，Pro 就重新回到候选队列里。

只有两个账号同时用完了，系统才真正暂停。但有了排除规则和节奏比排队，两个池子轮流喝水，同时见底的概率比以前一个账号单打独斗的时候低了不少。

记账也得分清楚

技术上打通了，调度也自动了，但还有一个问题：时间一长，怎么知道 Pro 花了多少、Max 花了多少？

两个账号的 worker 进程共享同一个项目目录，任务做完后的记录文件混在一起。这些文件本身不带账号标识，打开统计面板看到一堆会话记录，分不清哪些是 Pro 跑的、哪些是 Max 跑的。

解决办法是加一份台账。每次分配任务的时候，脚本生成一个会话 ID，连同"这个会话用的是哪个账号"一起写进一个日志文件。统计的时候按会话 ID 去关联，就能把每条记录归到对应的账号名下。

面板里加了一个按账号分组的视图，能看到每个账号这周花了多少、还剩多少、什么时候重置。每周扫一眼就知道两边消耗是否均衡，有没有哪边剩太多需要加大力度用。

跑起来什么样

改完之后实测派了一个小任务。脚本先去探了两边的额度，发现 Pro 这周的节奏比更高（额度剩得更多，时间也紧一点），就自动选了 Pro。worker 进程以 Pro 的身份启动，跑完之后报告首行标注了 Pro 的账号标识，统计面板里也正确地把这条记录归到了 Pro 名下。

整个过程主代理那边完全感知不到变化。Fable 在 Max 上照常干自己的活，它只知道"我派了一个子任务出去，结果回来了"。至于这个子任务到底用的是谁的额度，它不需要知道，也不需要关心。

两个订阅的钱，终于都在干活了。

几个要注意的地方

Pro 的 Opus 额度天然比 Max 小。日常的小任务没问题，但如果是一个预计要消耗很多 token 的大活，Pro 那边的余量不一定够跑完。我们的经验是第一次派大任务的时候关注一下日志里输出的百分比变化，心里有个底，之后交给自动排除规则去处理就行。

Pro 账号的 OAuth 授权会过期。过期之后探针拿不到数据，脚本检测到这个情况会自动跳过 Pro 走 Max，不会卡住流程。但如果一直不重新登录，Pro 就一直处于被跳过的状态，又变成白白浪费了。脚本里加了提示，认证失败的时候日志会打一行提醒。

最后，这套东西的前提是同一台机器上有两个账号的登录档案。只有一个订阅的话，选账号的逻辑一进来发现就一个候选，直接走那个账号，所有新加的代码等于没执行，不影响正常使用。

我建了一个AI学习研究群，目前几十来人，都是在真正动手搞AI的人。