说说我是怎么管理这 7 个 cc 账户的，当单号用量满、被动切号时依然不丢失任何 token 工作量： 1. tmux 接入 cc harness 层（最关键） - tmux 最核心的作用是不让一个 bash 进程随着发起者主进程的关闭而关闭（可以认为 tmux 自身就是一层 harness），能够不让 cc subagent 发起的长工作流成为 cc 的子进程，不跟随 cc 换号/单套餐额度满导致的进程关闭而关闭。 - 新号恢复读取 tmux list-session 的时候直接从 cc harness 层直接读取 tmux session 索引，知道 cc session 和 tmux session 的对应关系，以便会话和工作量完整恢复。 - tmux log stream 要准确注入 cc harness 的日志吸收层，不要让 cc session 主动 fetch 日志，一方面是实时性不行，浪费控制层用量，一方面是可观测性，如果不把 tmux 接入 cc app background tasks UI 的话，后台的子任务进度基本是没法用的。 - 官方桌面端为什么不自己接 tmux，原因很明确，他们不希望自己的 session 脱离于自己的主进程管理。 2. cc harness 层对于单帐号的实时额度余量要有感知，三个时间维度的额度任意一个到达 95% 都发信号介入，保存会话，记录 tmux session 的关联，留下后任接手指南，随时准备下一个账户接管。 3. 后台要有一个脱离于 cc 的独立进程要时时刻刻同步多账号的对话历史（cc 桌面端是分账户隔离开对话数据的），必须保证重新登录能看到一模一样的东西。这个同步器也是可以扩展到 codex 的（当然有很多文本杂音要处理），双向同步会话历史，随时切换。 ——这几步做下来基本是不太可能让你用到额外的 api credit 的，最大程度在自用前提下控制成本，并且节省会话任务进度和时间。