1. 项目背景在使用 CodeBuddyVSCode 扩展tencent-cloud.coding-copilot的过程中很多开发者会关心一个问题每天到底烧了多少 Token、花了多少积分、哪个项目在烧、用的哪个模型、缓存命中多少。官方没有提供本地化的用量统计工具而数据其实都写在本机磁盘上。本项目就是为解决这个问题而生把本地 CodeBuddy 的会话与 Token 消耗数据解析出来用一个本地看板直观展示。数据全部来自本机磁盘不联网、不上传、不依赖任何官方接口。项目开源地址该项目的开源代码托管于 GitHub可通过以下链接访问GitHub - freezeLUO/CodeBuddy-Usage-Dashboard: CodeBuddyVSCode 扩展 tencent-cloud.coding-copilot的会话与 Token 消耗数据看板展示 · GitHub该仓库提供了 CodeBuddy 使用情况仪表盘的完整实现包含前端可视化界面、数据采集逻辑及部署配置说明支持开发者快速搭建与定制化使用。2. 功能特性总览 KPI总 Token、总积分、请求数、会话数、缓存命中率、思考 Token。趋势每日输入/输出 Token 堆叠柱 当日积分折线以及区间累计积分曲线。分布项目消耗树图面积 Token、模型用量环形图含免费模型的 0 积分。热力日历热力图按天展示积分消耗强度。会话明细分页列表 中文标题搜索点开抽屉看逐请求明细模型、缓存命中率、峰值上下文、思考 Token、耗时。筛选时间范围、项目、模型任意组合粒度可按天/按周切换。3. 快速开始后端环境要求 Python 3.12前端使用 pnpm 构建。启动步骤如下# 1. 后端环境Python 3.12 cd backend python -m venv .venv uv pip install --python .venv/Scripts/python.exe -e . 2. 前端依赖与构建 cd ../frontend pnpm install pnpm build 3. 启动在项目根目录 python run.py # → http://127.0.0.1:9000Windows 下也可以直接双击start.bat会自动检查前端产物、必要时构建。首次启动会自动全量解析本地数据约 1 秒并写入data/codebuddy_cache.db之后每次启动只做增量检查约 100ms。3.1 开发模式# 终端 1 cd backend .venv/Scripts/python.exe -m uvicorn app.main:app --reload --port 9000 终端 2 cd frontend pnpm dev # → http://localhost:5173/api 已配置代理到 9000注意uv venv生成的python.exe在部分 Windows 策略下会被应用程序控制策略拦截因此后端环境固定用python -m venv创建uv只用来装包。4. 数据来源CodeBuddy 把数据写在%LOCALAPPDATA%\CodeBuddyExtension\不在 VSCode 的globalStorage里。各路径与内容对应关系如下路径内容Data/账号/VSCode/账号/history/workspaceHash/会话ID/index.json会话与请求元数据requests[].usage是每请求的权威用量Data/.../messages/消息ID.json单条消息模型名与statsSnapshot思考 Token、耗时在这里Logs/VSCode/日期/*.log每步usage:明细只滚动保留约 10 天本工具未使用4.1 关键口径usage.inputTokens是各 step 累计上下文之和每步都会重发完整历史因此它就是真实计费量不是重复计数。credit是 CodeBuddy 计费积分。免费预览模型hy3、hy4-preview的credit为 0 是真实值不是缺失。模型名只存在于消息文件里通过extra.requestId requests[].id关联实测 100% 命中。会话所在目录名workspaceHash可由工作区路径反推md5(路径.replace(/, \\) 且盘符小写、去前导反斜杠)无工作区窗口为md5(\\)。权威反查源是%APPDATA%\Code\User\workspaceStorage\*/workspace.json。4.2 解析策略不读全部消息文件。每个会话只读最早一条 user 消息抽标题 每个已完成请求内最后一个 assistant 消息取模型与快照合计约 1090 / 12692 个文件8.6%冷启动不到 1 秒。为规避 VSCode 运行中原地重写文件、以及file-tree/里的超长路径Windows MAX_PATH扫描只做两级 glob 定点读取并对每个文件做重试与容错跳过。5. 项目结构codebuddy_token/ ├─ run.py # 启动入口 ├─ start.bat # Windows 双击启动 ├─ PLAN.md # 设计与数据契约 ├─ data/codebuddy_cache.db # SQLite 缓存可随时删除重建 ├─ backend/ │ ├─ pyproject.toml │ ├─ scripts/verify.py # 对账脚本 │ └─ app/ │ ├─ main.py # FastAPI 实例、CORS、SPA 托管 │ ├─ config.py # 路径配置支持环境变量覆盖 │ ├─ db.py / schema.sql # 连接与建表 │ ├─ refresh.py # 增量刷新编排 │ ├─ ingest/ # 扫描 / 解析 / 入库 / 工作区解析 │ └─ api/ # 路由 / 响应模型 / 聚合 SQL └─ frontend/ # Vue 3 TS Vite Element Plus ECharts └─ src/{api,stores,components,views}数据库共 6 张表workspace、conversation、request、message_stat、scan_file增量指纹账本、sync_meta。增量以会话为失效单元(mtime_ns, size)指纹变化 → 级联删除并重新解析磁盘上消失 → 一并删除。整个写入过程在单个事务内完成。6. 接口设计所有接口支持共享筛选参数start_date、end_date本地时区闭区间、workspace可重复、model可重复。方法路径说明GET/api/overviewKPI 汇总Token、积分、请求/会话/项目数、缓存命中率、思考 Token、平均耗时GET/api/timeseries?granularityday|week时间序列输入/输出/积分/请求数GET/api/projects按项目汇总GET/api/models按模型汇总含缓存命中率GET/api/conversations?pagesizeqsortorder会话列表分页、标题搜索、排序GET/api/conversations/{id}会话详情逐请求明细POST/api/refresh触发增量刷新返回added/updated/deleted/errors/duration_msGET/api/meta上次同步时间、库路径、项目/会话总数接口文档http://127.0.0.1:9000/docs6.1 环境变量变量默认值用途CODEBUDDY_DATA_ROOT%LOCALAPPDATA%\CodeBuddyExtension\Data数据根目录CODEBUDDY_WORKSPACE_STORAGE%APPDATA%\Code\User\workspaceStorage工作区映射来源CODEBUDDY_DB./data/codebuddy_cache.db缓存库路径CODEBUDDY_DIST./frontend/dist前端产物路径7. 验证与对账backend/.venv/Scripts/python.exe backend/scripts/verify.py脚本会做四件事退出码非 0 表示失败对照实测基准值断言库内聚合input913,734,087、output5,119,598、credit4027.63、544 次请求、97 个会话、542 条快照、9 个模型的分布逐一比对。独立重走一遍 JSON不复用应用代码交叉核对总量与按项目小计。恒等式检查total input output、input cache miss违例数必须为 0。增量幂等连续刷新两次第二次必须updated deleted errors 0。基准值对应 2026-09-30 的本地快照。随着继续使用 CodeBuddy数值会增长此时应更新verify.py里的EXPECTED常量独立遍历与恒等式检查仍然有效。8. 已知限制不做Logs/的单请求 step 级钻取因此看不到一次请求内 Token 随 step 的增长曲线日志只有约 10 天。会话标题取自user_query块少数以引用/命令开头的会话会显示成路径片段6 个空会话无标题。项目名相同时会附加父目录消歧如re-web (Desktop)与re-web (D:)所有图表以 hash 为 key、显示名仅作标签。前端产物约 1.7MBElement Plus 全量引入本地工具未做按需引入优化。页面按容器宽度自适应auto-fit栅格窄窗口下会自动折叠为单列。9. 总结CodeBuddy 用量看板是一个完全本地化的数据解析与可视化工具。它不依赖任何官方接口也不会上传任何数据所有统计都基于本机磁盘上的会话与消息文件。通过增量指纹与单事务写入冷启动与日常刷新都非常轻量。对于希望精确掌握自己 Token 与积分消耗的开发者来说这是一个实用且透明的本地解决方案。