先交代背景我是 Claude Code 的重度用户基本上是当主力在用。订阅版有两道闸——5 小时一个滚动窗口外加一个每周上限。活儿一忙5 小时的额度下午两三点就见底然后就只能干等窗口刷新。最朴素的解法谁都想得到多搞几个账号一个用满了切下一个。我一开始也是这么干的手动改ANTHROPIC_BASE_URL、或者写个小脚本轮换 token。能用但用着用着我发现一件很别扭的事越切额度掉得越快。切过去的新账号往往没聊几句5h 进度条就往上窜一大截。明明只是换了个账号继续同一段对话凭什么代价这么大?后来把这事彻底搞明白之后我顺手把一个老项目(teamclaude)重构成了现在这个 nextclaude。但这篇主要不是来安利工具的——我觉得这背后那个为什么本身比工具有意思得多。反直觉的点切账号不是免费的要讲清楚得先说prompt caching(提示词缓存)。Claude Code 每发一个请求带的上下文是很吓人的system prompt、一大堆工具定义(Read/Bash/Edit……)、再加上整段对话历史和你读过的文件。一个跑了一会儿的会话光上下文轻松十几万 token。如果每次都全量重新计费根本没法用。救命的就是缓存。Claude Code 会在请求里打cache_control断点把这段巨大的前缀标记成可缓存。于是命中缓存的部分计为cache_read_input_tokens价格大约是普通输入的10%而且对限流额度近乎不占(Anthropic 官方文档里明确写了对大多数模型cache_read不计入 ITPM 速率限制);没命中、要新写进缓存的部分计为cache_creation_input_tokens大约1.25 倍价而且是全额计入你的额度。关键来了——这个缓存是按组织/账号隔离的。也就是说A 账号辛辛苦苦建立起来的那十几万 token 的热缓存对 B 账号完全无效。你一切到 BB 这个组织从没见过这段上下文于是整段前缀全部 miss按cache_creation满价重写一遍而且一分不少地砸进 B 账号那 5 小时的额度里。用一张糙图感受一下同一次请求、两种账单的区别同一个账号(缓存是热的): 上下文 [■■■■■■■■■■ ~150K ] 账单 cache_read ≈ 计 15K 等效 · 几乎不占 5h 额度 ← 便宜 刚切到的新账号(缓存全冷): 上下文 [■■■■■■■■■■ ~150K ] 账单 cache_creation ≈ 计 190K 等效 · 全额砸进新号 5h ← 一次切换的真实代价所以越切越费根本不是错觉每次切账号你都在为重建缓存付一笔正比于当前上下文大小的费用。上下文越大这笔越贵。更要命的是你通常是在 A 账号快用完的时候才切——而那往往是对话进行到后期、上下文最臃肿的时刻正好是重建最贵的那个点。这就是手动轮换最反直觉、也最容易亏的地方你以为多账号是把额度加起来其实每次衔接都在漏。一个消不掉的下限和一堆能省的地方把账算明白之后我先泼自己一盆冷水这笔重建有一部分是物理上消不掉的。一个任务如果要横跨 N 个账号的额度才能跑完那它至少要付N−1 次满上下文重建——因为跨组织无法共享缓存这是 Anthropic 那边的硬约束任何本地代理都绕不过去。想明白这条下限反而踏实了既然消不掉那目标就清晰了——让实际重建次数恰好等于 N−1(别因为乱切变多)并且让每一次重建尽量小。围绕这两点能做的事其实不少1. 会话亲和别来回横跳。把一个对话用稳定特征(system 工具 首条消息的哈希)算出一个 session key钉死在一个账号上直到它真的耗尽才往下一个走而且绝不回头(它的缓存早在 5 分钟 TTL 时就凉了回去就是再付一次冷重建)。顺带还修了一个隐蔽的并发 bug如果用一个全局游标来选号多个并发会话会互相把对方的账号顶掉各自触发冷重建。2. 把不可避免的那一刀砍在上下文最小的地方。代理没法替你触发/compact(这是客户端的行为没有反向通道)。但代理能观测请求体的大小——Claude Code 每轮都重发全量历史所以一旦请求体骤然变小就说明客户端刚自动 compact 过、上下文进入了低谷。于是策略是越过软阈值后先别急着切冲浪到这个低谷再切让那次不可避免的重建从十几万 token 缩到几万。这是唯一能真正压低每次重建大小的办法。3. 真要切的时候挑最能扛的账号。优先选 5h 剩余最多的;5h 打平就比谁的周额度剩得多。这样一次切换尽量长时间不必再切把总切换次数也压下来。4. 配额跨重启持久化。把每个账号的 5h/周用量落到本地重启后直接从剩额度最多的账号开始而不是傻乎乎从配置里的第一个开始(我就因为这个吃过亏重启后一股脑全怼到一个其实更满的账号上)。还有几个看起来很聪明、其实是坑的方向我特意没做顺便说说为什么预热/镜像(提前把上下文打到备用账号上让将来切过去时直接命中)听着美实则是把那笔cache_creation提前到现在付还要重复付给每个被镜像的账号缓存 5 分钟还会过期——纯纯负优化。代理改写请求体做压缩客户端才是对话的真相源下一轮它照样发全量你改的那份和它永久分叉缓存一直 churn还得额外掏一次摘要调用的钱顺手把tool_use/tool_result配对搞坏。这些都属于把成本搬个家而不是真省识别出来比堆功能更重要。让这一切看得见光省不够得能看见自己省得怎么样不然全是玄学。所以我把每个请求的缓存账单直接摊在面板上活动区里每一行是一次请求关键就三类数hitcache_read从缓存读出来的对额度近乎免费;missinput cache_creation这一刀真正烧 5h/周额度的部分;✎cache_creation冷重建的大小。一行里 hit 命中率很低、✎ 又很大就是一次昂贵的切换——一眼就能逮到。比如上图里绝大多数请求都是hit 8xxk · 100%意味着上下文几乎全走缓存、基本不花额度;而真正掏钱的是偶尔那几次 ✎ 拉满的冷重建。把这两类掰开摆出来你才知道额度到底花在哪了——而不是看着进度条干着急。账号卡片上还有每个号的 5h / 周进度条、重置倒计时、累计命中率、冷重建总量。nextclaude status在无 TTY 的环境里(比如挂成服务)会打印同样的纯文本。安装和使用零依赖只用 Node 内置模块Node 18 即可npminstall-gnextclaude nextclaude login# 浏览器 OAuth 登录一个账号,多账号就多跑几次nextclaude server# 起代理,带上面那个面板nextclaude run# 另开一个终端,让 Claude Code 走代理跑已经在 Claude Code 里登录过的直接nextclaude import把凭证导进来更省事。它本质就是夹在 Claude Code 和api.anthropic.com之间的一层透明代理按上面那套逻辑选号、转发。几句老实话说点局限免得你装上之后觉得被骗N−1 次重建是消不掉的。工具能保证你不超过这个下限、并把每次重建尽量缩小但跨账号的那笔冷重建是物理成本谁也变不出来。空闲账号的实时配额没法免费探到。我本来想用count_tokens(这个接口不计费)去顺手探一下没在用的账号还剩多少额度实测发现它根本不返回anthropic-ratelimit-unified-*这些头——所以一个从没经过代理的号得等它真跑过一次请求面板上才有数(好在配额会持久化之后重启就有了)。多账号本身的合规性请你自己评估。这工具只是把你自己的账号池在一起、并尽量省具体怎么用、和各家条款的关系得你自己拿捏。它是在 MIT 协议的 teamclaude 基础上重构来的这点必须挂出来。写到这儿其实我最想分享的不是工具而是那个切账号 重建缓存 烧额度的认知。搞清楚之后哪怕你不用任何工具、纯手动轮换也至少知道别在对话后期、上下文最大的时候切以及尽量让一段对话待在一个账号上别来回跳——光这两条就能省下不少。代码和更详细的说明在这https//github.com/youyve/nextclaude(npm i -g nextclaude)。有问题或者发现我哪里讲错了欢迎评论区拍。
多账号跑 Claude Code，我才发现真正烧额度的不是写代码，而是“切号“
发布时间：2026/6/5 2:06:46
先交代背景我是 Claude Code 的重度用户基本上是当主力在用。订阅版有两道闸——5 小时一个滚动窗口外加一个每周上限。活儿一忙5 小时的额度下午两三点就见底然后就只能干等窗口刷新。最朴素的解法谁都想得到多搞几个账号一个用满了切下一个。我一开始也是这么干的手动改ANTHROPIC_BASE_URL、或者写个小脚本轮换 token。能用但用着用着我发现一件很别扭的事越切额度掉得越快。切过去的新账号往往没聊几句5h 进度条就往上窜一大截。明明只是换了个账号继续同一段对话凭什么代价这么大?后来把这事彻底搞明白之后我顺手把一个老项目(teamclaude)重构成了现在这个 nextclaude。但这篇主要不是来安利工具的——我觉得这背后那个为什么本身比工具有意思得多。反直觉的点切账号不是免费的要讲清楚得先说prompt caching(提示词缓存)。Claude Code 每发一个请求带的上下文是很吓人的system prompt、一大堆工具定义(Read/Bash/Edit……)、再加上整段对话历史和你读过的文件。一个跑了一会儿的会话光上下文轻松十几万 token。如果每次都全量重新计费根本没法用。救命的就是缓存。Claude Code 会在请求里打cache_control断点把这段巨大的前缀标记成可缓存。于是命中缓存的部分计为cache_read_input_tokens价格大约是普通输入的10%而且对限流额度近乎不占(Anthropic 官方文档里明确写了对大多数模型cache_read不计入 ITPM 速率限制);没命中、要新写进缓存的部分计为cache_creation_input_tokens大约1.25 倍价而且是全额计入你的额度。关键来了——这个缓存是按组织/账号隔离的。也就是说A 账号辛辛苦苦建立起来的那十几万 token 的热缓存对 B 账号完全无效。你一切到 BB 这个组织从没见过这段上下文于是整段前缀全部 miss按cache_creation满价重写一遍而且一分不少地砸进 B 账号那 5 小时的额度里。用一张糙图感受一下同一次请求、两种账单的区别同一个账号(缓存是热的): 上下文 [■■■■■■■■■■ ~150K ] 账单 cache_read ≈ 计 15K 等效 · 几乎不占 5h 额度 ← 便宜 刚切到的新账号(缓存全冷): 上下文 [■■■■■■■■■■ ~150K ] 账单 cache_creation ≈ 计 190K 等效 · 全额砸进新号 5h ← 一次切换的真实代价所以越切越费根本不是错觉每次切账号你都在为重建缓存付一笔正比于当前上下文大小的费用。上下文越大这笔越贵。更要命的是你通常是在 A 账号快用完的时候才切——而那往往是对话进行到后期、上下文最臃肿的时刻正好是重建最贵的那个点。这就是手动轮换最反直觉、也最容易亏的地方你以为多账号是把额度加起来其实每次衔接都在漏。一个消不掉的下限和一堆能省的地方把账算明白之后我先泼自己一盆冷水这笔重建有一部分是物理上消不掉的。一个任务如果要横跨 N 个账号的额度才能跑完那它至少要付N−1 次满上下文重建——因为跨组织无法共享缓存这是 Anthropic 那边的硬约束任何本地代理都绕不过去。想明白这条下限反而踏实了既然消不掉那目标就清晰了——让实际重建次数恰好等于 N−1(别因为乱切变多)并且让每一次重建尽量小。围绕这两点能做的事其实不少1. 会话亲和别来回横跳。把一个对话用稳定特征(system 工具 首条消息的哈希)算出一个 session key钉死在一个账号上直到它真的耗尽才往下一个走而且绝不回头(它的缓存早在 5 分钟 TTL 时就凉了回去就是再付一次冷重建)。顺带还修了一个隐蔽的并发 bug如果用一个全局游标来选号多个并发会话会互相把对方的账号顶掉各自触发冷重建。2. 把不可避免的那一刀砍在上下文最小的地方。代理没法替你触发/compact(这是客户端的行为没有反向通道)。但代理能观测请求体的大小——Claude Code 每轮都重发全量历史所以一旦请求体骤然变小就说明客户端刚自动 compact 过、上下文进入了低谷。于是策略是越过软阈值后先别急着切冲浪到这个低谷再切让那次不可避免的重建从十几万 token 缩到几万。这是唯一能真正压低每次重建大小的办法。3. 真要切的时候挑最能扛的账号。优先选 5h 剩余最多的;5h 打平就比谁的周额度剩得多。这样一次切换尽量长时间不必再切把总切换次数也压下来。4. 配额跨重启持久化。把每个账号的 5h/周用量落到本地重启后直接从剩额度最多的账号开始而不是傻乎乎从配置里的第一个开始(我就因为这个吃过亏重启后一股脑全怼到一个其实更满的账号上)。还有几个看起来很聪明、其实是坑的方向我特意没做顺便说说为什么预热/镜像(提前把上下文打到备用账号上让将来切过去时直接命中)听着美实则是把那笔cache_creation提前到现在付还要重复付给每个被镜像的账号缓存 5 分钟还会过期——纯纯负优化。代理改写请求体做压缩客户端才是对话的真相源下一轮它照样发全量你改的那份和它永久分叉缓存一直 churn还得额外掏一次摘要调用的钱顺手把tool_use/tool_result配对搞坏。这些都属于把成本搬个家而不是真省识别出来比堆功能更重要。让这一切看得见光省不够得能看见自己省得怎么样不然全是玄学。所以我把每个请求的缓存账单直接摊在面板上活动区里每一行是一次请求关键就三类数hitcache_read从缓存读出来的对额度近乎免费;missinput cache_creation这一刀真正烧 5h/周额度的部分;✎cache_creation冷重建的大小。一行里 hit 命中率很低、✎ 又很大就是一次昂贵的切换——一眼就能逮到。比如上图里绝大多数请求都是hit 8xxk · 100%意味着上下文几乎全走缓存、基本不花额度;而真正掏钱的是偶尔那几次 ✎ 拉满的冷重建。把这两类掰开摆出来你才知道额度到底花在哪了——而不是看着进度条干着急。账号卡片上还有每个号的 5h / 周进度条、重置倒计时、累计命中率、冷重建总量。nextclaude status在无 TTY 的环境里(比如挂成服务)会打印同样的纯文本。安装和使用零依赖只用 Node 内置模块Node 18 即可npminstall-gnextclaude nextclaude login# 浏览器 OAuth 登录一个账号,多账号就多跑几次nextclaude server# 起代理,带上面那个面板nextclaude run# 另开一个终端,让 Claude Code 走代理跑已经在 Claude Code 里登录过的直接nextclaude import把凭证导进来更省事。它本质就是夹在 Claude Code 和api.anthropic.com之间的一层透明代理按上面那套逻辑选号、转发。几句老实话说点局限免得你装上之后觉得被骗N−1 次重建是消不掉的。工具能保证你不超过这个下限、并把每次重建尽量缩小但跨账号的那笔冷重建是物理成本谁也变不出来。空闲账号的实时配额没法免费探到。我本来想用count_tokens(这个接口不计费)去顺手探一下没在用的账号还剩多少额度实测发现它根本不返回anthropic-ratelimit-unified-*这些头——所以一个从没经过代理的号得等它真跑过一次请求面板上才有数(好在配额会持久化之后重启就有了)。多账号本身的合规性请你自己评估。这工具只是把你自己的账号池在一起、并尽量省具体怎么用、和各家条款的关系得你自己拿捏。它是在 MIT 协议的 teamclaude 基础上重构来的这点必须挂出来。写到这儿其实我最想分享的不是工具而是那个切账号 重建缓存 烧额度的认知。搞清楚之后哪怕你不用任何工具、纯手动轮换也至少知道别在对话后期、上下文最大的时候切以及尽量让一段对话待在一个账号上别来回跳——光这两条就能省下不少。代码和更详细的说明在这https//github.com/youyve/nextclaude(npm i -g nextclaude)。有问题或者发现我哪里讲错了欢迎评论区拍。
