为什么保留账号池，而不是再套一层单 token Router
从额度切换、失败隔离和维护成本出发，记录 Coding Agent 工作流里账号池与单 token Router 的取舍。
关联项目：Coding 运行时与账号池方案评测这次评估一个本地 Router 时，最先要确认的不是“能不能启动”，而是它能不能解决真实问题。目标是一个账号额度用完后，后续请求能够自动切换到另一个可用账号。结果很明确：单 token Router 和已有账号池解决的是两个不同层次的问题。
单 token Router 的边界
单 token Router 适合把一个外部模型接口接入统一的模型选择流程。它可以负责请求转发、模型映射和基本的健康检查，但如果一个 provider 只保存一把 key，就不能凭空获得双账号轮换、冷却、额度统计和失败接管。把两把 key 直接拼进同一个凭据字段，也不是账号池。
现有工作流为什么更合适
当前桌面控制面已经有账号池和冷却逻辑，可以在当前账号不可用时把后续请求交给另一个可用账号。它不保证正在进行的请求无感切换，但满足“后续请求自动接管”的实际目标，也避免再引入一套凭据存储、轮换策略和状态展示。
因此本次接入判断是保留现有工作流，暂不启用额外 Router。这个结论不代表 Router 没有价值，而是说明新增组件必须先补齐多账号合同、失败策略、冷却恢复和不泄露凭据的状态检查，才能进入下一轮评测。