用 Commandcode 写了大半年代码我最深的体会是写代码有多爽对账就有多痛苦。官方命令行里确实会显示每次请求的 token 数但那个数字只在当前会话有效窗口一关就什么都没了。我上个月被账单教育了一次有个批量重构的活叠加并行跑了好几个会话实际花费比预估高了一倍才意识到 token 用量和成本不能靠感觉必须拿到明面上盯着。这篇文章就是我折腾 Commandcode 本地仪表盘的完整记录核心就三个词配额、Token、成本。如果你也在用这类终端 AI 编程助手对用量一头雾水或者想摸清每个项目到底烧了多少钱这篇文章应该能帮你省下不少时间和预算。1. 为什么需要一个本地仪表盘1.1 Commandcode 用着爽对账却很痛苦Commandcode 这类终端 AI 编程助手本质上就是把大模型塞进了命令行工作流里让它直接帮你读写代码、跑命令、做重构。用熟了之后确实回不去因为它已经把“修改代码 → 测试 → 再修改”这个循环压缩到几句话就能完成。但问题也随之而来你每天在这类工具上消耗的 token 数量远超你打开网页版聊天时的量级而且完全无感。这种“无感”才是最大的坑。一次对话可能就吃掉几万 token但界面上的数字只是冷冰冰的一串你不会意识到它对应多少钱。等账单出来发现这个月光 AI 辅助编程就花了大几百才真正肉疼。我就是这样被教育了一次之后才认真去翻历史用量结果发现官方渠道根本翻不出像样的历史统计。命令行里只显示当前会话服务商后台只有账号维度的总量既按不了项目拆也按不了时间轴看趋势。说白了Commandcode 自带的功能满足“当下的使用”但完全没有覆盖“历史的回溯”和“成本的核算”。对一个要长期高强度使用 AI 编程工具的人来说这两个缺失足以引发预算失控。1.2 用量数据散落在三处谁也没法直接看为了搞清自己的用量到底去了哪我把数据来源梳理了一遍发现这些数据其实都存在只是散落各处格式各异没有一个人能直接读明白。第一处是服务商后台。这里能看到账号维度的累计用量比如“本月已消耗 xxx 万 token”但粒度是服务商级别的。如果你同时用了好几家模型服务或者在一个工具里接入了不同厂商的模型那每个后台都只能看到自家那一部分完全没法横向对比也没法按“某个项目”去归因。第二处是 Commandcode 的本地日志。这个是最全的每次 API 调用的 model、token 数、耗时、会话 ID 全都记录在案文件是 JSONL 格式每一行就是一个请求。数据是完整但人眼去翻 JSON 就是一页页的灾难别说看趋势了正常人都不会这么干。第三处是命令行的实时输出。对话过程中会显示本次请求消耗的 token直观但不留存关掉窗口就等于什么都没发生。我需要做的就是把这三处数据收拢到同一个地方用一个统一的口径重新聚合、计算、展示。本质上就是一个很朴素的数据管道采集、清洗、存储、查询、可视化。这也是这个本地仪表盘的出发点。1.3 仪表盘要解决的四个核心问题动手之前我先定了四个必须解决的痛点后面所有功能都围着这四个转。第一配额剩余要清晰。很多服务商提供了免费额度或者包月包年套餐还有一些新用户券、赠金但这些额度的剩余量、到期时间在各家后台分散放着很容易就忘了。仪表盘需要把这些配额统一管起来。第二成本要实时换算。Token 不是钱但 token 乘以单价就是真金白银。只有让成本数字实时跳出来看到一次重构消耗了 2.7 美元你才会在继续调模型之前多想几秒。第三项目归因。同时维护几个项目时哪个项目在烧钱哪个只是偶尔用用必须一眼能看出来。否则你优化预算都不知道从哪下手。第四明细可回溯。某天用量突然暴涨能定位到具体是哪个会话、哪个请求吃掉了大量 token而不是只知道“今天用多了”。这四个问题解决之后仪表盘的价值就非常直接了它把模糊的“感觉用多了”变成精确的“哪个项目、哪个请求、多少钱”。2. 整体设计日志优先绝不侵入原工具2.1 数据源选型为什么锁定本地日志定了要做什么之后第一个决策就是数据从哪来。我一开始想过两个方案一是抓包在本地起一个代理服务把 Commandcode 发出的所有 API 请求都导一份二是直接解析它写在本地的日志文件。两个方案对比之后我立刻放弃了抓包。原因很实在。第一抓包是侵入式的需要在系统层面配代理环境变量Commandcode 一旦更新、或者你切换网络环境这套东西就可能失灵你花在维护抓包链路上的时间比写代码还多。第二抓包拿到的原始 HTTP 请求里面很多字段已经是序列化过的反而不如日志里结构化之后的 JSON 好读。第三安全洁癖问题所有请求都走本地代理等于给自己的流量多加了一道风险点没必要。而本地日志方案几乎零成本Commandcode 本来就会在本地写日志我只负责读不修改、不拦截、不影响原工具任何行为。即使它以后改了版本、换了路径我只需要改一下配置文件里的日志路径即可。日志文件是 JSONL 格式每一行都有完整的请求信息可以说数据源天然就是结构化且完整的。除了本地日志之外我还留了一个配额数据入口服务商 OpenAPI 的余额查询接口。如果你用的服务商提供了查询剩余配额的 API就通过定时任务拉取存到本地数据库里。这样仪表盘上就能同时展示“历史用量”和“剩余配额”两个维度。2.2 仪表盘整体架构整个系统的架构非常简单没有引入任何服务化的东西就是一条单向数据管道完全跑在本地日志解析器从 Commandcode 日志目录里读取 JSONL 文件把每一条请求记录清洗、去重之后写入 SQLite成本计算模块按模型价格表把 token 换算成金额配额模块定时拉取服务商剩余配额最后的 Web 面板从 SQLite 里聚合数据展示成表格、趋势图、进度条。选 SQLite 而不是随便搞个 CSV是因为后面要按时间、项目、模型、会话做多维聚合SQL 写起来最顺手。而且 SQLite 单文件存储备份也很方便一个文件就能拷走。整条链路都是本地运行数据不出本机这也符合我个人的使用习惯。组件之间互相独立解析器只管写库面板只管读库。哪天你觉得 Streamlit 面板不好看想换成前端技术栈重写展示层解析器和数据库完全不用动。这种解耦在个人项目里很容易被忽略但实际维护下来省心的程度远超预期。2.3 技术选型Streamlit 够用别为炫技上全家桶技术选型上我先踩了一圈弯路。最开始我想着上 Grafana Prometheus因为服务器监控的一套体系太成熟了后来放弃了——那是为云端基础设施设计的我这就一个本地数据看板引入时序数据库 采集器 面板全家桶光维护就够喝一壶的。然后考虑过 Next.js ECharts确实灵活好看但对一个纯 Python 项目来说等于为一个展示层多维护一套 Node 技术栈不划算。最后选了 Streamlit非常务实的选择。理由有三个第一它和 Python 无缝衔接日志解析、成本计算都是 Python 写的面板逻辑可以直接复用那些函数第二Streamlit 自带表格、折线图、进度条组件几十行代码就能出一个能看的面板而且支持热更新改完代码浏览器立刻刷新第三部署零成本一条命令启动浏览器本地访问没有任何运维负担。当然它也有缺点比如页面流畅度一般、深度定制有限制但对一个给自己看的工具来说完全够用。我始终觉得个人项目最忌技术栈过度设计能在一个语言里解决的问题就不要引入第二种运行时。3. 核心细节Token 统计、配额与成本计算3.1 从 JSONL 日志里把 Token 抠出来Commandcode 的日志文件是典型的 JSONL 结构我把它目录下离现在最近的 session 日志随便抽了一行简化之后大概是这样的{ request_id: req_8f3a2c9e, timestamp: 2026-05-13T14:23:11.582Z, model: claude-sonnet-4-20250514, session_id: sess_01HZQK, project: commandcode-dashboard, input_tokens: 18342, output_tokens: 1248, cache_read_input_tokens: 103200, status: success }解析的时候有几个细节必须注意。第一input_tokens 和 output_tokens 一定要分开记录不要合成一个总量因为很多模型的输入和输出单价不一样只有分开存才能在成本模块里准确计算。第二如果工具走的是流式输出单个 chunk 可能不携带完整 usage 数据这时候要以最终汇总的 usage 字段为准不然你会把同一次请求统计成好几份。第三去重逻辑很重要。日志在写入时偶尔会因为重试等原因产生重复记录我的做法是用 request_id 作为唯一键入库前先查一遍存在就跳过。我在解析器里把脏数据过滤也放在这一步字段缺失的、状态标记为失败的、以及明显是测试请求的都打上标签而不是直接丢弃。因为后面排查问题的时候这些“被过滤掉的数据”往往能帮你快速定位。3.2 配额计算硬配额和软配额分开管配额管理是这个仪表盘最实用的部分之一。我把配额分成两套体系分别处理。硬配额就是服务商给你的真实额度包括免费赠送的 token、包月套餐包含的 token、以及账号里预充值的余额。这类配额有固定数量会随着请求消耗递减。很多服务商还搞过“新用户赠送 xx 万 token”的活动有的还有时限过期就清零。这种“看不见的资产”最容易浪费我见过太多人压根不知道自己的免费额度已经过期了。所以仪表盘上我会在硬配额区域显示每个服务商的总额、已消耗、剩余量和到期时间。软配额是我自己设置的提醒阈值比如“这个模型每天最多跑 80 万 token”“这个项目每周预算不能超过 5 美元”。软配额不真实限制请求只负责在仪表盘上变红提醒。为什么不做成硬限制因为我发现真正让人控制用量的不是“卡住不让用”而是“亮红灯的时候你会自觉想一下有没有必要继续”。硬限制反而会逼着人去绕过它最后记账更乱。硬配额的数据来源我通过服务商 API 拉取拉不到的就用人工录入 基于日志消耗递减的方式来做。具体用哪种方式我会在配置文件里给每个服务商标注好避免面板上出现“配额 -1”这种尴尬事。3.3 成本计算把 Token 换成真金白银Token 统计只是第一步真正让人清醒的是成本换算。成本计算的核心是一张模型价格表我把常用模型维护在一个 YAML 配置里示例如下models: claude-sonnet-4: input_price_per_m: 3.0 output_price_per_m: 15.0 unit: USD # 统一以 每百万token 为单位 gpt-5-codex: input_price_per_m: 5.0 output_price_per_m: 20.0 unit: USD deepseek-chat: input_price_per_m: 0.27 output_price_per_m: 1.1 unit: USD计算逻辑很朴素成本 输入 token 数 / 1000000 × 输入单价 输出 token 数 / 1000000 × 输出单价。举个例子某天你用一档高端模型跑了 60 万输入 token、20 万输出 token按价格表一算就是 60/100 × 5 20/100 × 20也就是 3 4共 7 美元。这个数一旦显示在面板上你立刻就能感受到“长上下文会话”和“短平快会话”之间的成本差距。日志里如果带了 cache_read_input_tokens 字段我会单独把它拎出来按缓存读取的折扣价计算这样成本估算会贴近真实账单。还有一个容易忽略的细节不同服务商的计费单位不一样。有的按每千 token 计价有的按每百万 token 计价有的按“1K char”计价。配置价格表时一定要统一成同一个单位我统一成 USD / 每百万 token否则后面所有计算都是错的。3.4 认证失败请求要不要计入用量我在观察日志的时候发现偶尔会有一些 requests 导致 status 不是 success而是类似 authentication error 的状态这类请求也会记录 token 消耗。最初我一股脑全部计入统计结果发现有一天仪表盘上的成本比实际账单高了一截查了半天才发现是登录间断导致的认证失败请求被重复计入。后来我在解析器里规定只有 status 为 success 的请求才计入用量和成本认证失败、限流这类非正常请求单独存到一个 error_requests 表里面板上用飘红数字展示。这样既不影响成本核算的准确性也能直观看到你在登录状态上浪费了多少次无效请求。这类登录报错在终端 AI 工具里太常见了专业术语叫 token exchange failed字面意思就是在登录时交换访问令牌失败了。面向上游鉴权服务的登录请求没成功自然不会有合法的访问令牌下发。我的仪表盘里专门留了一栏叫“鉴权异动”专门统计这类失败事件目的是提醒你该去重新登录了而不是傻乎乎地继续发请求。4. 实操落地从零到能用的完整过程4.1 环境准备与项目结构先说最简单的环境。我的开发机是 macOS系统自带 Python 3.10直接创建虚拟环境就开工。项目结构长这样commandcode-dashboard/ ├── app.py # Streamlit 主面板 ├── parser.py # JSONL 日志解析器 ├── cost.py # 成本计算模块 ├── quota.py # 配额拉取模块 ├── config.yaml # 模型价格、日志路径、配额配置 ├── data/ │ └── dashboard.db # SQLite 数据库 └── requirements.txt依赖库很少就四个streamlit、pandas、plotly、watchdog。pip install streamlit pandas plotly watchdog其中 watchdog 是用来监听日志文件变化的后面细说。其他两个是数据处理和绘图的主力streamlit 负责把一切串成 Web 页面。4.2 数据库结构与初始化数据库我设计了四张表。requests 表存原始请求明细字段和日志行基本对应唯一键是 request_idmodels 表存模型价格配置quota_pool 表存服务商配额error_requests 表单独存鉴权失败等异常请求。CREATE TABLE IF NOT EXISTS requests ( request_id TEXT PRIMARY KEY, timestamp TEXT NOT NULL, model TEXT, session_id TEXT, project TEXT, input_tokens INTEGER DEFAULT 0, output_tokens INTEGER DEFAULT 0, cache_read_input_tokens INTEGER DEFAULT 0, status TEXT ); CREATE TABLE IF NOT EXISTS models ( model_name TEXT PRIMARY KEY, input_price_per_m REAL, output_price_per_m REAL, unit TEXT ); CREATE TABLE IF NOT EXISTS quota_pool ( provider TEXT, quota_name TEXT, total REAL, used REAL, expires_at TEXT, PRIMARY KEY (provider, quota_name) ); CREATE TABLE IF NOT EXISTS error_requests ( request_id TEXT PRIMARY KEY, timestamp TEXT, error_type TEXT, model TEXT );为什么 requests 表要单独存 project 字段因为 Commandcode 的日志里是带会话 ID 的而一个会话往往属于一个项目。我在解析器里维护了一个简单的映射关系看到 session_id 就猜测它属于哪个项目目录。如果猜不出来就标为“未分类”。后面想按项目统计成本全靠这个字段。4.3 日志增量解析不每次都全量扫最开始的版本很粗暴每次解析就把整个日志目录翻一遍把全部文件读入内存再解析。跑了半天发现一个问题日志文件越来越大每次全量解析越来越慢而且大量数据重复写库白白消耗性能。后来我改成增量解析核心逻辑是“记住上次读到的位置”。解析器维护一个 JSON 文件记录每个日志路径上次读取到的字节偏移量。每次启动时先打开文件跳转到偏移量处读取新增部分解析完毕后更新偏移量。这样即便日志文件已经几百 MB每次增量解析也只需要处理很小的一段。import json, os STATE_FILE data/parser_state.json def get_state(): if os.path.exists(STATE_FILE): with open(STATE_FILE) as f: return json.load(f) return {} def update_state(state): with open(STATE_FILE, w) as f: json.dump(state, f, indent2)同时我用 watchdog 监听日志目录的文件变化事件一旦有修改就触发解析这样面板上的数据最长延迟只有几秒。如果没有 watchdog退一步也可以写个定时任务每 5 分钟跑一次体验也不会差太多。4.4 三个核心视图的实现Streamlit 面板我拆成了三个页签。总览页放最核心的“配额、成本、趋势”数据明细页展示逐条的请求记录诊断页展示认证失败等异常事件。总览页的实现思路是从 SQLite 读出聚合结果。核心查询是按天汇总 token 和成本import sqlite3, pandas as pd import streamlit as st from cost import calculate_cost conn sqlite3.connect(data/dashboard.db, detect_typessqlite3.PARSE_DECLTYPES) daily_df pd.read_sql_query( SELECT substr(timestamp, 1, 10) AS day, SUM(input_tokens output_tokens) AS total_tokens, SUM(input_tokens) AS input_tokens, SUM(output_tokens) AS output_tokens FROM requests WHERE status success GROUP BY day ORDER BY day DESC LIMIT 30 , conn)趋势图直接用 plotly 画Streamlit 有现成的 st.plotly_chart 组件。配额进度条我用的 st.progress会把硬配额剩余量转换成百分比。成本数字用 st.metric 展示红绿颜色一比今天超没超预算一眼就知道。明细页就是一个数据表格加上筛选器支持按模型、按项目、按时间段筛选。这一页主要服务于“某个请求到底消耗了多少”这种回溯需求。诊断页则把 error_requests 表里的数据列出来并按错误类型分类这个我放到后面常见问题章节再展开。4.5 一键启动与后台运行日常使用我不希望每次都要敲一长串命令所以写了一个 start.sh#!/bin/bash cd $(dirname $0) source .venv/bin/activate # 先做一次增量解析再启动面板 python parser.py streamlit run app.py --server.port 8600另外我在脚本里加了端口参数避免和本机其他服务冲突。如果你希望后台常驻可以用 nohup 或者 tmux但我实测下来直接开一个终端窗口跑着最省事因为 Streamlit 面板本来就是用浏览器访问终端窗口留着反而能随时看到日志输出排查问题更直接。5. 常见问题与排查技巧实录5.1 登录报错 token exchange failed 的排查顺序这应该是终端 AI 工具用户遇到最多的一个错误。报错信息乱七八糟有时候是 sign-in could not be completed有时候是 login server error核心都是登录阶段的 token exchange 失败。这是指客户端拿临时授权码去换访问令牌时被鉴权服务拒绝通俗说就是“登录流程没走通”。我自己的排查顺序是这样共三步。第一步重新登录。这类工具的登录态经常因为刷新令牌过期而失效直接执行 logout 再 login通常能解决 80% 的问题。第二步检查本地凭据文件是否损坏。这类工具会把 refresh token 等凭据存在本地配置目录里文件损坏也会导致后续的 token 刷新失败此时删除本地凭据重新登录即可。第三步检查当前网络环境是否满足服务商要求。这类调用的鉴权服务器对出口环境有风控校验如果账号配置与当前访问环境不一致会直接拒绝交换令牌报文中可能带 403 或者 forbidden 字样。这里特别提醒一句遇到这个错误不要反复重试发请求因为每次失败都是一次无效请求会在日志里留下记录还会让仪表盘上的“鉴权异动”数字狂涨。先停下手头的工作把登录态修好再继续。5.2 refresh_token 失效配额数据停在原地了还有一种更隐蔽的情况 Commandcode 本身还能正常运行但仪表盘上的配额数据一直不更新。排查日志发现拉取服务商配额接口时提示 refresh_token 无效或者直接返回 400 bad requestinvalid refresh_token。这类问题常见于你已经在官方客户端里切换过账号或者本地的刷新令牌被收回比如服务商因为安全策略主动吊销了长期未使用的 refresh token。此时仪表盘不是坏了而是“上游登录态已经失效”之后任何需要鉴权的查询都会失败。我加了两个应对机制。第一配额拉取失败时面板上不显示错误而是把数据改为显示“上次更新时间”避免你误以为这是当前用量。第二提供一个“刷新登录态”按钮点一下会弹出一个命令行引导重新执行登录流程。更新完之后配额数据会自动恢复更新。5.3 日志路径对不上面板一片空白有段时间我更新了 Commandcode 到新版本结果仪表盘一夜之间变成了一片空白一行请求都没有。排查了半天发现新版把日志目录从旧的 ~/.commandcode/logs 挪到了新目录而且文件名也从 session_xxx.jsonl 换成了带日期的目录结构。这个问题的通用解法就是——不要硬编码日志路径在 config.yaml 里维护一个数组log_paths: - ~/.commandcode/logs - ~/Library/Application Support/Commandcode/logs - ~/projects/tools/claude-code/logs然后解析器启动时扫一遍所有路径能读到数据就算成功。把 Commandcode 和 Claude Code 这类工具的日志路径都列进去这样同时使用多个工具时也能在同一个面板里统查看量。设置好日志目录后解析器每次启动会把这些路径下所有 JSONL 文件都纳入扫描范围按增量偏移量去读。5.4 成本估算和真实账单对不上这是很多人跑了几天后都会来问的问题仪表盘上显示的成本和月底账单总是差一点为什么原因是多方面的。第一缓存读取计费。很多模型对 cache_read 的 token 有折扣价甚至只收原价的十分之一如果价格表里没有给 cache_read 设置单独的单价成本会算高。第二batch 批量接口。如果你用了批量处理服务商统一打折而仪表盘按标准价计算差额自然存在。第三服务商四舍五入规则。每毫秒级的用量进位方式不同导致微小误差。我的处理办法是在 models 表里增加 cache_read_price_per_m 和 discount 字段成本计算时单独处理缓存读取 token。这样算出来的成本和真实账单的误差基本能控制在 5% 以内。对于个人使用来说5% 的误差完全不影响预算判断重点是你已经能看见“大钱”在往哪里流而不是月底收到账单才一脸懵。我个人在实际操作中的体会是能看见才管得住。自从这个仪表盘跑起来我对 token 的心态发生了很大的变化每次启动一个长上下文会话之前都会下意识看一眼旁边那个成本数字心里有数之后反而更敢用了因为知道边界在哪里。整个项目代码也就一千多行但解决的是我日常最崩溃的对账问题那种“数据终于握在自己手里”的感觉比任何花哨的 AI 功能都踏实。后面我还打算加一个阈值告警函数成本超过当日预算的 80% 就推一条消息到手机让这个仪表盘从“看着管”变成“主動盯”。这个扩展也不复杂在成本计算模块里加个判断、接个通知接口就行。