结果显示用了16亿，用量统计飙升 Codex

Quick fix

升级 cc-switch 至 v3.18.0 修复子代理历史重放双计 bug，系统会自动重建被污染的 Codex 用量数据。

Symptom

报错原文复制

结果显示用了16亿。模型由5.6 sol切换为5.6terra开始执行任务，然后触发压缩上下文，用量统计那里从16亿肉眼可见的飙升到19亿

Cause

在 v3.17.0 中，Codex session 解析器的子代理历史 replay 边界识别过早。当长任务或上下文压缩导致子代理 rollout 复制父线程的多轮历史时，解析器遇到第一个 thread_settings_applied 就立即返回，导致父历史中的 token_count 被使用新的子线程 request ID 再次写入数据库，造成数十亿级别的 token 重复计算。此外，本集群还包含其他用量异常变体：claude-mem 插件导致 Claude Code 后台偷跑额度（与 cc-switch 无关）；v10 数据库迁移导致旧聚合行丢失；以及 Windows 下文件 mtime 不更新导致同步卡在 deferred。

Fix

1. 1

   升级 cc-switch 至 v3.18.0 或更高版本。

2. 2

   重启应用，系统会自动备份并重建被污染的 Codex 用量数据，看板数字会逐步回填至真实值。

Affected Versions

ToolCodex

Version3.17.0 (受影响)，3.18.0 (已修复)

PlatformsWindowsmacOS

Source Issues

本页汇总自 5 个真实 issue

• #2075cc-switch获取cc官方max套餐使用量的方法是什么
• #4139反馈一个恶性多重请求 bug，导致 claude code 模型后台偷跑额度。
• #5335用量统计问题
• #5727[Bug] v10 usage_daily_rollups 迁移丢失 codex_session 聚合行（约 8.7B token 历史统计消失）
• #6023Codex 用量统计停止记录：4 个会话文件永久卡在 deferred，同步一直导入 0 条（v3.19.1 / Windows）

FAQ

Claude Code 模型在后台被大量计费偷跑额度是 cc-switch 导致的吗？

不是。这通常与 claude-mem 等第三方 Claude 插件的数据同步请求有关，建议排查或禁用相关插件。

升级包含 v10 迁移的版本后，Codex 历史统计突然消失了几十亿 token 怎么办？

这是因为迁移重建时丢弃了已压缩明细的旧聚合行。你可以从 ~/.cc-switch/ 目录下的自动备份数据库（如 db_backup_*.db）中手动导出并恢复 usage_daily_rollups 表的数据。

Codex 用量同步一直显示导入 0 条且卡在 deferred 怎么办？

这是 Windows 下会话文件 mtime 不更新导致同步器跳过写入中文件的 bug，需等待包含 last_size 双校验修复的后续版本（如 PR #6027）。

相关问题

查询用量必须同源请求 cc-switch在 cc-switch 中改用通用模板或自定义模板，并在请求地址中直接填写查询用量的 URL，即可绕过同源限制。4 issues mergedbash: 无法设定终端进程组 cc-switch这是 3.18.0 在 Linux 下检查本地代理环境的已知 Bug，降级到 3.18.0 之前的版本，并直接在终端手动配置代理。5 issues mergedcc-switch DeepSeek 用量统计不准/余额查询失败升级到 v3.19.2 并重建 Codex 用量；余额查询需正确填写 {{apiKey}} 或代理。17 issues merged