原生 Grok Build 用量导入缺失 - CC Switch Usage

Quick fix

多数相关 issue 仍未解决；升级至 v3.19.0 可自动导入官方 OAuth 模式的 Grok Build 用量；Composer 2.5 Fast 定价仍需手动维护。

Symptom

报错原文复制

Grok Build 没有任何原生用量通道

Cause

该报告在 CC Switch 3.16.4 中指出，Usage 的原生 session 导入器及应用筛选项未覆盖 Grok Build，用户只能通过外部脚本写入 CC Switch 数据库后在“All”中查看用量。维护者确认，v3.19.0 已为官方 OAuth 模式加入从 `~/.grok/sessions`（含归档）`updates.jsonl` 自动读取用量、按 per-turn ID 去重、防抖避免与代理记录重复计入，并在 Usage 面板加入 Grok Build 筛选项；同时修正了 Grok Build 成本回填中 cache 部分重复计价的问题。

该 issue 的计价需求仍未解决：`grok-composer-2.5-fast` 的内置定价，尤其 `cache_read` 单价，尚未加入；将价格标为估值及改价后一键重算历史成本也仍是待跟踪的功能请求。

Fix

1. 1

   将 CC Switch 升级到 v3.19.0，并验证官方 OAuth 模式下的 Grok Build 用量是否自动显示为 “Grok Build (Session)”。

2. 2

   对于 `grok-composer-2.5-fast`，暂时在 Usage 的定价设置中手动维护价格；“估值”标记与历史成本一键重算原帖尚未提供可验证的解法。

Affected Versions

ToolCC Switch Usage

Versionv3.19.0（已修复原生导入）

PlatformsWindows

Source Issues

本页汇总自 1 个真实 issue

• #4702[usage] 原生 Grok Build 用量导入缺失 + grok-composer-2.5-fast cache_read 计价未发布

FAQ

Grok Build 用量是否考虑原生支持，还是接受社区外部导入方案？

维护者表示 v3.19.0 已支持官方 OAuth 模式的自动用量导入；此前外部 Python 脚本是报告者采用的个人变通方案。

官方未发布 Composer cache_read 单价时，Usage 应如何展示？

原帖将其作为待讨论的功能请求；目前 `grok-composer-2.5-fast` 仍需要在 Usage 的定价设置中手动维护。

改价后是否能按 data_source 一键重算历史成本？

尚未实现，维护者表示会继续跟踪该功能建议。

相关问题

cc-switch 用量统计与 DeepSeek 官网不一致 / 不更新先升级到 v3.19.2 或更新版本，然后在「使用统计」页执行一次「重建 Codex 用量」，历史虚增或漏记的数据才会被修正。22 issues mergedPrompt files are never rebuilt数据库恢复后 Prompt、实时配置与缓存未完整重建；原帖尚未提供可验证的解法，需跟进源帖合并后的审查进展。1 issues merged[GEMINI-SYNC] 从未出现在日志中：Gemini CLI升级到 cc-switch v4.0.1；该版本修复了 Gemini CLI `.jsonl` 会话文件识别和增量记录解析。2 issues merged