Fork了CLIProxyAPI，增加了Codex账号权重选择，账号定时刷新，以及用量监控
OpenAI加强反代检测致大量账号Token失效，社区转向Fill-First策略及第三方调度插件。
1. 关键信息
- 项目核心：楼主 Fork 的 CLIProxyAPI (CPA) 增加了 Codex 权重选择、定时刷新及用量监控功能。仓库地址：https://github.com/jacobhere/CLIProxyAPI（#1）。
- Fill-First 策略更新：原 CPA 存在单账号使用、内存监控不可靠等问题。Fork 基于 fill-first 逻辑，按周剩余限额和重置时间给账号打分，优先用高分账号，可手动增删权重（#1）。该策略不会降低 cache rate，会优先填满一个账号再用下一个（#11, #13）。
- CPA 上游动态：@duanxu 指出 CPA 上游近期已自行增加了 fill-first 功能（#58）。楼主确认 Fork 正是基于此逻辑修改，因近一个月上游无重大更新故未频繁同步（#59）。目前楼主计划增加自动 CI 以合并上游新更新（如新模型支持），小更新仍可能忽略（#17, #20, #59）。
- 账号刷新机制：每 15 分钟刷新所有账号 reset 时间，刚过 reset 时发送约 70 token 的 probe 信息以刷新下一个 5 小时（#1）。
- 用量监控：使用独立项目 cpa-usage-keeper（SQLite 持久化+Dashboard），但无法导入旧版统计数据（#1, #9, #14）。CPA 原版已删除内置用量监控，被认为是为推出 pro/enterprise 版做准备（#15）；CPA 开发者拒绝所有关于数据监控的 PR，态度固执，故意将统计完全放在内存里（#7, #31）。
- GPT 5.5 上下文窗口：反代 context window 确认为 256k。此前有用户询问是否开启 1m，楼主曾回复约为 250k 且尚未开启 1m（#55, #56）；@xuexuekan 补充在 Codex 中可通过 /status API 查询到 1M 的上下文窗口，Cursor 中也存在该能力（#57）。
- 安全风险：CPA 默认在没有设置 API key 时允许任何 key 访问，存在安全风险（#30）。
- 其他 Fork/工具：第三方项目 cpa manager（https://github.com/seakee/CPA-Manager）只有列表无可视化（#8, #28）；@gedeepe 表示已 fork 楼主项目（#52）；new-api 可搭配 CPA 使用，但配置复杂需两个 docker、两个域名（#22, #24, #25, #28）。
2. 最新动态
- OpenAI 反代打击行动：近期 OpenAI 针对 CPA 这类反代软件加强了限制，常见表现为账号被强制退出登录、接口返回 401 报错（#62, #63, #65）。多位用户反馈认证后几小时内 Token 失效，导致服务不可用（#62, #64）。
- 社区应对策略：针对上述打击，社区结论是现阶段最好停止轮询模式，改用 Fill-First 模式来使用 Codex 账号，以减少触发风控的概率（#65）。
- 新调度插件发布：@jefferyz 发布了 CPA 的 Codex 账号调度插件，旨在解决反代限制问题并优化账号管理，详细背景见相关帖子讨论（#65, #p-8452175-h-1）。
- 构建方式澄清：@duanxu 反馈使用 docker compose 拉起后界面与预期不同，楼主确认需单独构建镜像而非直接拉取上游镜像（#60）。
- @gedeepege 反馈 OAuth 登录第 6 个账号开始报 401 错误，楼主确认十多个账户无此问题（#53, #54）。
- GPT 5.5 coding 表现被多位用户认为不错（#33, #57）。
3. 争议或不同意见
- CPA 作者态度：多位用户批评 CPA 作者固执，拒绝持久化统计 PR，文档质量极差（连 Claude/Opus 都读不明白），疑似为推商业版铺路（#7, #15, #31, #34, #39）。
- 部署复杂度与替代方案：有用户建议换 sub2api 等更成熟的项目（#2, #5, #12）；也有用户批评 CPA 搭配 new-api 使用需两个 docker、两个域名，配置繁琐（#24, #28）。@jefferyz 指出 NewAPI 功能集中在收费定价上，自用或团队内部使用过于繁琐（toB 属性强），推荐改用 Claude Code Hub（https://github.com/ding113/claude-code-hub）作为现代化替代方案，支持智能负载均衡、用户管理及自定义监控请求体/响应体（#61）。
- 双开 Codex 限制：楼主明确表示该 fork 不支持两个 codex 窗口分别使用不同账号，仅解决 fill-first 前提下平均消耗周额度（#42, #43）。@Xinye 和 @nadecantcode 指出 LLM 是 stateless 的，历史记录需存储在 project 文档而非账号中，双开处理不同 projects 可行但历史记录无法在账号间无缝切换（#44, #45, #46）。
- OAuth 报错：@gedeepege 报告的 OAuth 第 6 个账号起 401 报错问题被楼主否认存在普遍性（#53, #54）。