Usage Stats Missing and Disk Usage at 100% - CC Switch
Quick fix
Most related issues remain unresolved. Updating to the latest version and disabling the local proxy may restore usage display and reduce disk I/O.
Symptom
Section titled “Symptom”频繁sqlite写库,对hdd机械盘不友好,一启动ccswitch任务管理磁盘使用率就干满100%Frequent SQLite writes are unfriendly to HDDs. As soon as cc-switch starts, the task manager shows disk usage maxed out at 100%.
This issue cluster includes several related symptoms. The core mechanism is that cc-switch's local proxy feature uses SQLite to record requests and session usage frequently. In v3.18.0, SQLite is configured with journal_mode=delete and synchronous=2(FULL); each small transaction triggers multiple fsync calls, causing about 250–350× write amplification on HDDs. In addition, the backend's 60-second session sync timer uses the default MissedTickBehavior::Burst. After Windows wakes from sleep, it sends every missed tick with no interval, scanning thousands of session log files in full and keeping CPU at 100% for a long time. The missing usage stats issue (#3138) was restored in v3.16.0, and the Codex usage stats issue (#7081) was fixed in PR #6905. The opencode_session request log's total duration is always 0.0s (#6326) because latency_ms is hardcoded to 0 in the source. Enabling the routing master switch also causes the WebView2 GPU process to continuously use 10%–20% GPU (#5760).
Update cc-switch to the latest version. v3.16.0 restored the remaining quota display in the status bar and main window, and PR #6905 fixed the Codex usage stats issue.
If you do not need the local proxy feature, turn off the local proxy master switch in cc-switch settings to reduce disk I/O and GPU usage immediately.
If you use an HDD, move the .cc-switch database directory to an SSD, or add an SSD to the computer to ease the random-write IOPS bottleneck.
For the issue where the opencode_session request log's total duration is always 0.0s, latency_ms is currently hardcoded to 0 in the source; wait for an official fix.
Affected Versions
Section titled “Affected Versions”Source Issues
Section titled “Source Issues”This page is distilled from 7 real issues
- #3138315版本官方的统计中剩余用量看不见了
- #5164High CPU after resume from sleep on Windows (interval burst on wake)
- #5760[Bug] 开启路由服务总开关后 GPU 占用持续偏高(WebView2 GPU 进程 ~17%),导致风扇持续高速运转
- #5823HDD机械盘启动cc switch就占满100%
- #6326[Bug] opencode_session 请求日志总时长恒为 0.0s、首字时长缺失
- #6830Claude Desktop在使用kimi code作为提供商,且单对话长时间运行时(期间使用子代理),会高概率瞬时消耗大量额度
- #7081从2026-09-03起,codex用量统计出现问题
- What should I do if the remaining quota is missing after an update?
- Issue #3138 confirms that v3.16.0 restored the remaining quota display. Update to that version or later.
- Why is GPU usage high after enabling routing?
- Real-time refreshes in the routing panel and usage stats page continuously trigger WebView2 re-rendering, causing 10%–20% GPU usage while idle. Turn off the routing master switch to restore normal usage.
- Why does disk usage hit 100% on an HDD?
- The local proxy frequently logs request data through SQLite. journal_mode=delete + synchronous=FULL causes hundreds-fold write amplification on HDDs. Disabling the local proxy or moving the database to an SSD may help.
- What should I do if CPU stays at 100% after Windows wakes from sleep?
- The backend's 60-second session sync timer uses the Burst policy. After wake, it sends every missed tick, triggering a full scan. This issue (#5164) is still open; restarting cc-switch is a temporary workaround.
- What should I do if Codex usage stats look wrong?
- Issue #7081 confirms that this issue was fixed in PR #6905. Update to a version that includes the fix.
- Why is the total duration for opencode_session request logs always 0.0s?
- In session_usage_opencode.rs's insert_opencode_message, latency_ms is hardcoded to 0 and first_token_ms to None. This issue (#6326) is still open; wait for an official fix.
Related problems
Section titled “Related problems”This is an unofficial community wiki with no affiliation to the cc-switch authors or the project itself. Its content is compiled from the project's public GitHub issues. This site distributes no software.