尧图网站建设 
【免费下载链接】codeburnFree, local tool to track AI coding token usage and cost across 37 tools and agents (Claude Code, Cursor, Codex, Gemini and more), by model, project, and task. npx codeburn项目地址https://gitcode.com/gh_mirrors/co/codeburn点击查看免费下载Roo Code 是广受欢迎的 VS Code AI 编程扩展Cline 的分支CodeBurn 通过内置的roo-codeprovider 在本机直接读取 Roo Code 的任务存储按模型、项目与任务统计 token 消耗与费用。本文以 docs/providers/roo-code.md 为核心骨架结合 roo-code.ts、共享解析器 vscode-cline-parser.ts 及 roo-code.test.ts 源码完整讲解该集成的数据来源、存储格式、发现与解析流程、去重机制以及排障修复方法。读完你将清楚 Roo Code 用量是从哪里读、怎么读、怎么算钱也能在数据异常时准确定位问题属于 Roo Code 特有还是 Cline 家族共有。集成概览一个约 30 行的薄包装器CodeBurn 对 Roo Code 的集成非常轻量。完整的 provider 实现位于 src/providers/roo-code.ts全文仅 31 行核心逻辑几乎全部委托给共享的 Cline 家族解析器vscode-cline-parser扩展 IDrooveterinaryinc.roo-cline定义于roo-code.ts:4这是定位 Roo Code 在磁盘上任务数据的唯一钥匙Provider 标识name为roo-codedisplayName为Roo Coderoo-code.ts:8-9所有报告、CLI 过滤与去重键都以此为准加载方式eager随核心 Provider 一起加载。在 src/providers/index.ts 中静态导入rooCode并列入coreProviders数组index.ts:198与 Claude、Cline、Codex、Copilot 等 30 个核心 provider 同批注册无需按需动态加载模型与工具显示名modelDisplayName与toolDisplayName均为原样透传roo-code.ts:11-17不对模型名做任何美化或裁剪。从接口契约看rooCode实现了 types.ts 中Provider的全部核心方法probeRoots()向codeburn doctor报告扫描根目录types.ts:159discoverSessions()产出SessionSourcecreateSessionParser()产出逐次 API 调用的ParsedProviderCall。这三者全部由共享 helper 实现roo-code.ts自身只负责传入扩展 ID 与 provider 名。数据来源VS Code globalStorage 与三条平台路径Roo Code 是 VS Code 扩展其任务数据存放在 VS Code 的globalStorage/extensionId/目录下。roo-code.ts将实际目录解析委托给clineTaskRoots而后者最终调用 vscode-cline-parser.ts 的getVSCodeGlobalStoragePaths。这段实现有一个容易被忽略但很重要的细节每个平台都会扫描三种 VS Code 变体而不是只扫一个平台扫描路径home为主目录macOS~/Library/Application Support/Code/User/globalStorage/、~/Library/Application Support/Code - Insiders/User/globalStorage/、~/Library/Application Support/VSCodium/User/globalStorage/Windows%APPDATA%/Code/User/globalStorage/、%APPDATA%/Code - Insiders/User/globalStorage/、%APPDATA%/VSCodium/User/globalStorage/Linux~/.config/Code/User/globalStorage/、~/.config/Code - Insiders/User/globalStorage/、~/.config/VSCodium/User/globalStorage/路径拼接按平台选择posix.join或win32.joinvscode-cline-parser.ts:16。这意味着无论用户用的是 VS Code 稳定版、Insiders 预览版还是 VSCodiumCodeBurn 都能找到对应的rooveterinaryinc.roo-cline数据目录。三个变体目录会先做路径级去重discoverClineTasksInBaseDirs中的seenSetvscode-cline-parser.ts:61-69避免同一任务被多次发现。clineTaskRootsvscode-cline-parser.ts:49-53还支持覆盖目录roo-code.ts的工厂函数createRooCodeProvider(overrideDir?)接受单个路径或路径数组传入后probeRoots()与discoverSessions()就会放弃默认的 globalStorage 路径、只扫描覆盖目录。测试正是通过createRooCodeProvider(tmpDir)注入临时目录来验证发现逻辑roo-code.test.ts:209。存储格式每个任务一个目录、两个 JSON 文件Roo Code 在globalStorage/rooveterinaryinc.roo-cline/下按任务task组织数据每个任务一个子目录baseDir/tasks/taskId/ ui_messages.json # 事件流event stream api_conversation_history.json # 完整提示历史含模型标签ui_messages.json一个 JSON 数组记录任务的 UI 事件流。其中两类事件对统计至关重要{type:say, say:api_req_started, text:...}记录每次 API 请求的 token 数据text字段是 JSON 字符串{type:say, say:user_feedback|text, text:...}记录用户消息文本api_conversation_history.json一个 JSON 数组元素形如{role, content:[{type:text, text:...}]}内容块中携带model.../model标签与Current Workspace Directory (...)信息是模型名与项目名的主要来源。两个文件缺一不可发现阶段只把存在ui_messages.json的任务目录当作候选会话vscode-cline-parser.ts:88-92测试也明确验证了只有api_conversation_history.json而没有ui_messages.json的任务会被跳过roo-code.test.ts:216-225。发现流程逐目录扫描 tasks 子目录discoverSessions()走的是discoverClineTasks(EXTENSION_ID, roo-code, Roo Code, overrideDir)roo-code.ts:24底层逻辑在vscode-cline-parser.ts:72-96对每个根目录拼出baseDir/tasks/readdir列出所有任务 ID 子目录若目录不存在直接返回空数组测试用例不存在的目录返回空验证了这一点roo-code.test.ts:227-231逐个检查子目录是否为目录、是否包含ui_messages.json符合条件的任务生成一个SessionSource { path, project: Roo Code, provider: roo-code }。discoverClineTasksInBaseDirs会对多个根目录的结果做整体去重vscode-cline-parser.ts:61-69。另外CodeBurn 对每个 provider 的发现做了故障隔离即使某个 provider 的目录扫描抛异常如遇到构造损坏的文件index.ts 的discoverOne会捕获错误、对每个 provider 每次运行只告警一次并跳过绝不拖垮整轮扫描——Roo Code 的解析失败不会影响其他 30 provider 的统计。解析流程模型、项目、token 与成本的完整链路发现会话后createSessionParser(source, seenKeys, roo-code)roo-code.ts:27-29返回一个异步生成器逐任务产出ParsedProviderCall见 types.ts 的字段定义。核心步骤全部在vscode-cline-parser.ts的createClineParser135-232 行中模型与项目归属来自 api_conversation_history.jsonextractHistoryMetavscode-cline-parser.ts:103-129遍历历史消息的 user 内容块用两条正则提取model([^])/modelMODEL_TAG_RE98 行命中后取标签内文本若含/如带前缀的完整模型 ID则取最后一段。找不到模型标签时回退到cline-autocreateClineParser的fallbackModel默认值135 行测试roo-code.test.ts:105-120专门验证了这一回退Current Workspace Directory \(([^)])\)WORKSPACE_DIR_RE99 行提取工作区绝对路径workspaceToProject取其basename作为项目名131-133行并同时填充projectPath。token 与成本来自 ui_messages.json 的 api_req_started 事件解析器筛出所有api_req_started事件vscode-cline-parser.ts:170逐个将其text字段 JSON.parse得到字段含义落点tokensIn输入 tokeninputTokenstokensOut输出 tokenoutputTokenscacheReads缓存读取cacheReadInputTokens/cachedInputTokenscacheWrites缓存写入cacheCreationInputTokenscostRoo Code 自带成本可选costUSD关键成本逻辑vscode-cline-parser.ts:207如果事件里带了cost字段就原样采用否则调用 src/models.ts 的calculateCost(model, tokensIn, tokensOut, cacheWrites, cacheReads, 0)按模型单价推算。测试roo-code.test.ts:177-189验证了无 cost 字段时costUSD 0的兜底计算。此外还有两条健壮性规则零 token 事件跳过tokensIn与tokensOut都为 0 的条目不产出调用vscode-cline-parser.ts:200时间戳防御entry.ts只做真值检查若遇到垃圾字符串或越界数字会导致new Date(...).toISOString()抛RangeError从而中断整个会话解析因此解析器专门校验Number.isNaN(tsDate.getTime())204-206行非法时间戳输出空字符串而不是中断。用户消息与工具信息只取事件流中第一条user_feedback/text文本作为userMessage且截断到 500 字符vscode-cline-parser.ts:162-168后续用户轮次只计入用量、不展现在调用记录里。每次调用还输出speed: standard、reasoningTokens: 0、webSearchRequests: 0与空tools/bashCommands数组——Roo Code 的任务存储没有暴露这些维度CodeBurn 就不编造数据。缓存与去重全权委托给共享 helper缓存roo-code在 provider 层不设任何缓存直接委托给共享解析链路。这意味着增量刷新、会话缓存session cache等机制都由上层统一的 parse/cache 管线处理provider 无需感知去重每个api_req_started条目使用${providerName}:${taskId}:${index}作为去重键vscode-cline-parser.ts:173其中index是该条目在ui_messages.json中的数组下标。同一个任务多次解析例如重复运行统计时seenKeysSet 会拦下已见过的键。测试roo-code.test.ts:122-138用同一个seenKeys跑两遍解析第二遍结果为 0 条验证了去重生效。测试覆盖247 行测试锁定的行为契约roo-code的测试位于 tests/providers/roo-code.test.ts分三组解析组验证 token/cost 字段映射62-89 行、模型提取91-103 行、cline-auto回退105-120 行、跨次解析去重122-138 行、缺失ui_messages.json返回 0 条140-149 行、无效 JSON 优雅降级151-161 行、零 token 跳过163-175 行、无 cost 字段时的单价计算177-189 行发现组用createRooCodeProvider(tmpDir)注入临时目录验证能发现带ui_messages.json的任务201-214 行、跳过不带的任务216-225 行、不存在的目录返回空227-231 行元数据组name/displayName正确性、模型与工具显示名透传234-247 行。这些测试同时是共享解析器vscode-cline-parser的间接覆盖——因为 Roo Code、Cline、KiloCode、IBM Bob 共用同一解析器见 docs/providers/README.md 的共享 helper 表格改共享代码必须四份测试全部通过。与 Cline 家族其他成员的关系只差一个扩展 IDRoo Code 并非唯一复用该解析器的成员。从源码看Cline 家族的 VS Code 扩展包装器结构几乎相同唯一本质差异是扩展 IDProvider扩展 ID额外差异Clinesaoudrizwan.claude-dev额外扫描~/.cline/data数据根并按ui_messages.json的 mtime 对重复任务 ID 做最新优先去重Roo Coderooveterinaryinc.roo-cline无KiloCodekilocode.kilo-code任务树之外还并行扫描本地 SQLite 存储IBM Bobibm.bob-code非 VS Code 应用走discoverClineTasksInBaseDirs且模型回退名为ibm-bob-auto因此文档中反复强调的一个工程事实是凡是 Cline、Roo Code、KiloCode 共有的解析问题都应当修在共享的 vscode-cline-parser.ts 里而不是在某个 provider 包装器里打补丁若某个扩展的上游 JSON 形状确有不同则应利用发现函数已有的扩展 ID 参数分支处理而不是复制一份解析器。新增同家族 provider 时按cline.ts/roo-code.ts同构写一个薄包装文件并注册进 src/providers/index.ts 即可。使用方式与排障指南在终端中通过npx codeburn运行见 README.md统计默认扫描全部 provider只聚焦 Roo Code 时用--provider过滤npx codeburn --provider roo-code # 只看 Roo Code 的用量与成本 npx codeburn --provider roo-code --since 7d # 近 7 天roo-code实现了probeRoots()因此 src/doctor.ts 会在codeburn doctor中展示并检查它实际扫描的路径——当没统计到 Roo Code 用量时先运行codeburn doctor确认扫描根目录是否存在可区分扩展未安装/未使用与路径覆盖配置错误两种情况。遇到统计异常时的修复清单依 docs/providers/roo-code.md 的When fixing a bug here部分展开先在 Cline 与 KiloCode 上复现如果问题同样出现在这两个 provider 上几乎可以确定是共享解析器的缺陷应在 vscode-cline-parser.ts 修复并同步跑cline.test.ts、ibm-bob.test.ts、kilo-code.test.ts、roo-code.test.ts四份测试若仅 Roo Code 复现差异大概率来自上游 JSON 形状例如某个 Roo Code 版本在api_req_started.text中改了字段名、或在api_conversation_history.json的其他位置放置模型标签。此时应制作一个最小 fixture 放到tests/providers/下复现并考虑让共享解析器按扩展 ID 分支而不是重写正则或复制解析器动手前先读docs/providers/vscode-cline-parser.md那里记录了共享解析器的模型解析、token 提取、去重键与已知 quirks是修改共享代码的必读文档。小结Roo Code 集成是 CodeBurn provider 体系中薄包装 共享解析设计模式的典型样本roo-code.ts只负责声明扩展 ID 与 provider 身份任务发现、模型/项目提取、token 与成本计算、去重全部由 vscode-cline-parser.ts 统一承担并以 roo-code.test.ts 的 247 行测试锁定行为。理解这条链路既能解释为什么 Roo Code 用量不需要额外配置就能被统计也能在跨 provider 数据异常时快速判断问题归属——是共享解析器的锅还是 Roo Code 上游 JSON 特有的形状差异。赞分享【免费下载链接】codeburnFree, local tool to track AI coding token usage and cost across 37 tools and agents (Claude Code, Cursor, Codex, Gemini and more), by model, project, and task. npx codeburn项目地址https://gitcode.com/gh_mirrors/co/codeburn点击查看免费下载相关推荐codeburn 集成指南KiloCode VS Code 扩展的用量追踪实现与解析原理codeburn 集成指南KiloCode VS Code 扩展的用量追踪实现与解析原理 本指南聚焦 codeburn 如何接入 KiloCodeVS CoCodeBurn 的 Qwen Code CLI 集成JSONL 会话解析、Token 成本核算与去重机制全解析CodeBurn 的 Qwen Code CLI 集成JSONL 会话解析、Token 成本核算与去重机制全解析 CodeBurn 是一款本地运行、无需账号的为 Roo Code 接入 Hindsight 持久化长期记忆hindsight-roo-code 集成实战指南为 Roo Code 接入 Hindsight 持久化长期记忆hindsight roo code 集成实战指南 导读 本指南完整讲解 Hindsight 官人工智能AI AgentAgent 记忆MCP 服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CodeBurn 的 Roo Code 集成指南：从 VS Code globalStorage 提取 token 用量与成本
【免费下载链接】codeburnFree, local tool to track AI coding token usage and cost across 37 tools and agents (Claude Code, Cursor, Codex, Gemini and more), by model, project, and task. npx codeburn项目地址https://gitcode.com/gh_mirrors/co/codeburn点击查看免费下载Roo Code 是广受欢迎的 VS Code AI 编程扩展Cline 的分支CodeBurn 通过内置的roo-codeprovider 在本机直接读取 Roo Code 的任务存储按模型、项目与任务统计 token 消耗与费用。本文以 docs/providers/roo-code.md 为核心骨架结合 roo-code.ts、共享解析器 vscode-cline-parser.ts 及 roo-code.test.ts 源码完整讲解该集成的数据来源、存储格式、发现与解析流程、去重机制以及排障修复方法。读完你将清楚 Roo Code 用量是从哪里读、怎么读、怎么算钱也能在数据异常时准确定位问题属于 Roo Code 特有还是 Cline 家族共有。集成概览一个约 30 行的薄包装器CodeBurn 对 Roo Code 的集成非常轻量。完整的 provider 实现位于 src/providers/roo-code.ts全文仅 31 行核心逻辑几乎全部委托给共享的 Cline 家族解析器vscode-cline-parser扩展 IDrooveterinaryinc.roo-cline定义于roo-code.ts:4这是定位 Roo Code 在磁盘上任务数据的唯一钥匙Provider 标识name为roo-codedisplayName为Roo Coderoo-code.ts:8-9所有报告、CLI 过滤与去重键都以此为准加载方式eager随核心 Provider 一起加载。在 src/providers/index.ts 中静态导入rooCode并列入coreProviders数组index.ts:198与 Claude、Cline、Codex、Copilot 等 30 个核心 provider 同批注册无需按需动态加载模型与工具显示名modelDisplayName与toolDisplayName均为原样透传roo-code.ts:11-17不对模型名做任何美化或裁剪。从接口契约看rooCode实现了 types.ts 中Provider的全部核心方法probeRoots()向codeburn doctor报告扫描根目录types.ts:159discoverSessions()产出SessionSourcecreateSessionParser()产出逐次 API 调用的ParsedProviderCall。这三者全部由共享 helper 实现roo-code.ts自身只负责传入扩展 ID 与 provider 名。数据来源VS Code globalStorage 与三条平台路径Roo Code 是 VS Code 扩展其任务数据存放在 VS Code 的globalStorage/extensionId/目录下。roo-code.ts将实际目录解析委托给clineTaskRoots而后者最终调用 vscode-cline-parser.ts 的getVSCodeGlobalStoragePaths。这段实现有一个容易被忽略但很重要的细节每个平台都会扫描三种 VS Code 变体而不是只扫一个平台扫描路径home为主目录macOS~/Library/Application Support/Code/User/globalStorage/、~/Library/Application Support/Code - Insiders/User/globalStorage/、~/Library/Application Support/VSCodium/User/globalStorage/Windows%APPDATA%/Code/User/globalStorage/、%APPDATA%/Code - Insiders/User/globalStorage/、%APPDATA%/VSCodium/User/globalStorage/Linux~/.config/Code/User/globalStorage/、~/.config/Code - Insiders/User/globalStorage/、~/.config/VSCodium/User/globalStorage/路径拼接按平台选择posix.join或win32.joinvscode-cline-parser.ts:16。这意味着无论用户用的是 VS Code 稳定版、Insiders 预览版还是 VSCodiumCodeBurn 都能找到对应的rooveterinaryinc.roo-cline数据目录。三个变体目录会先做路径级去重discoverClineTasksInBaseDirs中的seenSetvscode-cline-parser.ts:61-69避免同一任务被多次发现。clineTaskRootsvscode-cline-parser.ts:49-53还支持覆盖目录roo-code.ts的工厂函数createRooCodeProvider(overrideDir?)接受单个路径或路径数组传入后probeRoots()与discoverSessions()就会放弃默认的 globalStorage 路径、只扫描覆盖目录。测试正是通过createRooCodeProvider(tmpDir)注入临时目录来验证发现逻辑roo-code.test.ts:209。存储格式每个任务一个目录、两个 JSON 文件Roo Code 在globalStorage/rooveterinaryinc.roo-cline/下按任务task组织数据每个任务一个子目录baseDir/tasks/taskId/ ui_messages.json # 事件流event stream api_conversation_history.json # 完整提示历史含模型标签ui_messages.json一个 JSON 数组记录任务的 UI 事件流。其中两类事件对统计至关重要{type:say, say:api_req_started, text:...}记录每次 API 请求的 token 数据text字段是 JSON 字符串{type:say, say:user_feedback|text, text:...}记录用户消息文本api_conversation_history.json一个 JSON 数组元素形如{role, content:[{type:text, text:...}]}内容块中携带model.../model标签与Current Workspace Directory (...)信息是模型名与项目名的主要来源。两个文件缺一不可发现阶段只把存在ui_messages.json的任务目录当作候选会话vscode-cline-parser.ts:88-92测试也明确验证了只有api_conversation_history.json而没有ui_messages.json的任务会被跳过roo-code.test.ts:216-225。发现流程逐目录扫描 tasks 子目录discoverSessions()走的是discoverClineTasks(EXTENSION_ID, roo-code, Roo Code, overrideDir)roo-code.ts:24底层逻辑在vscode-cline-parser.ts:72-96对每个根目录拼出baseDir/tasks/readdir列出所有任务 ID 子目录若目录不存在直接返回空数组测试用例不存在的目录返回空验证了这一点roo-code.test.ts:227-231逐个检查子目录是否为目录、是否包含ui_messages.json符合条件的任务生成一个SessionSource { path, project: Roo Code, provider: roo-code }。discoverClineTasksInBaseDirs会对多个根目录的结果做整体去重vscode-cline-parser.ts:61-69。另外CodeBurn 对每个 provider 的发现做了故障隔离即使某个 provider 的目录扫描抛异常如遇到构造损坏的文件index.ts 的discoverOne会捕获错误、对每个 provider 每次运行只告警一次并跳过绝不拖垮整轮扫描——Roo Code 的解析失败不会影响其他 30 provider 的统计。解析流程模型、项目、token 与成本的完整链路发现会话后createSessionParser(source, seenKeys, roo-code)roo-code.ts:27-29返回一个异步生成器逐任务产出ParsedProviderCall见 types.ts 的字段定义。核心步骤全部在vscode-cline-parser.ts的createClineParser135-232 行中模型与项目归属来自 api_conversation_history.jsonextractHistoryMetavscode-cline-parser.ts:103-129遍历历史消息的 user 内容块用两条正则提取model([^])/modelMODEL_TAG_RE98 行命中后取标签内文本若含/如带前缀的完整模型 ID则取最后一段。找不到模型标签时回退到cline-autocreateClineParser的fallbackModel默认值135 行测试roo-code.test.ts:105-120专门验证了这一回退Current Workspace Directory \(([^)])\)WORKSPACE_DIR_RE99 行提取工作区绝对路径workspaceToProject取其basename作为项目名131-133行并同时填充projectPath。token 与成本来自 ui_messages.json 的 api_req_started 事件解析器筛出所有api_req_started事件vscode-cline-parser.ts:170逐个将其text字段 JSON.parse得到字段含义落点tokensIn输入 tokeninputTokenstokensOut输出 tokenoutputTokenscacheReads缓存读取cacheReadInputTokens/cachedInputTokenscacheWrites缓存写入cacheCreationInputTokenscostRoo Code 自带成本可选costUSD关键成本逻辑vscode-cline-parser.ts:207如果事件里带了cost字段就原样采用否则调用 src/models.ts 的calculateCost(model, tokensIn, tokensOut, cacheWrites, cacheReads, 0)按模型单价推算。测试roo-code.test.ts:177-189验证了无 cost 字段时costUSD 0的兜底计算。此外还有两条健壮性规则零 token 事件跳过tokensIn与tokensOut都为 0 的条目不产出调用vscode-cline-parser.ts:200时间戳防御entry.ts只做真值检查若遇到垃圾字符串或越界数字会导致new Date(...).toISOString()抛RangeError从而中断整个会话解析因此解析器专门校验Number.isNaN(tsDate.getTime())204-206行非法时间戳输出空字符串而不是中断。用户消息与工具信息只取事件流中第一条user_feedback/text文本作为userMessage且截断到 500 字符vscode-cline-parser.ts:162-168后续用户轮次只计入用量、不展现在调用记录里。每次调用还输出speed: standard、reasoningTokens: 0、webSearchRequests: 0与空tools/bashCommands数组——Roo Code 的任务存储没有暴露这些维度CodeBurn 就不编造数据。缓存与去重全权委托给共享 helper缓存roo-code在 provider 层不设任何缓存直接委托给共享解析链路。这意味着增量刷新、会话缓存session cache等机制都由上层统一的 parse/cache 管线处理provider 无需感知去重每个api_req_started条目使用${providerName}:${taskId}:${index}作为去重键vscode-cline-parser.ts:173其中index是该条目在ui_messages.json中的数组下标。同一个任务多次解析例如重复运行统计时seenKeysSet 会拦下已见过的键。测试roo-code.test.ts:122-138用同一个seenKeys跑两遍解析第二遍结果为 0 条验证了去重生效。测试覆盖247 行测试锁定的行为契约roo-code的测试位于 tests/providers/roo-code.test.ts分三组解析组验证 token/cost 字段映射62-89 行、模型提取91-103 行、cline-auto回退105-120 行、跨次解析去重122-138 行、缺失ui_messages.json返回 0 条140-149 行、无效 JSON 优雅降级151-161 行、零 token 跳过163-175 行、无 cost 字段时的单价计算177-189 行发现组用createRooCodeProvider(tmpDir)注入临时目录验证能发现带ui_messages.json的任务201-214 行、跳过不带的任务216-225 行、不存在的目录返回空227-231 行元数据组name/displayName正确性、模型与工具显示名透传234-247 行。这些测试同时是共享解析器vscode-cline-parser的间接覆盖——因为 Roo Code、Cline、KiloCode、IBM Bob 共用同一解析器见 docs/providers/README.md 的共享 helper 表格改共享代码必须四份测试全部通过。与 Cline 家族其他成员的关系只差一个扩展 IDRoo Code 并非唯一复用该解析器的成员。从源码看Cline 家族的 VS Code 扩展包装器结构几乎相同唯一本质差异是扩展 IDProvider扩展 ID额外差异Clinesaoudrizwan.claude-dev额外扫描~/.cline/data数据根并按ui_messages.json的 mtime 对重复任务 ID 做最新优先去重Roo Coderooveterinaryinc.roo-cline无KiloCodekilocode.kilo-code任务树之外还并行扫描本地 SQLite 存储IBM Bobibm.bob-code非 VS Code 应用走discoverClineTasksInBaseDirs且模型回退名为ibm-bob-auto因此文档中反复强调的一个工程事实是凡是 Cline、Roo Code、KiloCode 共有的解析问题都应当修在共享的 vscode-cline-parser.ts 里而不是在某个 provider 包装器里打补丁若某个扩展的上游 JSON 形状确有不同则应利用发现函数已有的扩展 ID 参数分支处理而不是复制一份解析器。新增同家族 provider 时按cline.ts/roo-code.ts同构写一个薄包装文件并注册进 src/providers/index.ts 即可。使用方式与排障指南在终端中通过npx codeburn运行见 README.md统计默认扫描全部 provider只聚焦 Roo Code 时用--provider过滤npx codeburn --provider roo-code # 只看 Roo Code 的用量与成本 npx codeburn --provider roo-code --since 7d # 近 7 天roo-code实现了probeRoots()因此 src/doctor.ts 会在codeburn doctor中展示并检查它实际扫描的路径——当没统计到 Roo Code 用量时先运行codeburn doctor确认扫描根目录是否存在可区分扩展未安装/未使用与路径覆盖配置错误两种情况。遇到统计异常时的修复清单依 docs/providers/roo-code.md 的When fixing a bug here部分展开先在 Cline 与 KiloCode 上复现如果问题同样出现在这两个 provider 上几乎可以确定是共享解析器的缺陷应在 vscode-cline-parser.ts 修复并同步跑cline.test.ts、ibm-bob.test.ts、kilo-code.test.ts、roo-code.test.ts四份测试若仅 Roo Code 复现差异大概率来自上游 JSON 形状例如某个 Roo Code 版本在api_req_started.text中改了字段名、或在api_conversation_history.json的其他位置放置模型标签。此时应制作一个最小 fixture 放到tests/providers/下复现并考虑让共享解析器按扩展 ID 分支而不是重写正则或复制解析器动手前先读docs/providers/vscode-cline-parser.md那里记录了共享解析器的模型解析、token 提取、去重键与已知 quirks是修改共享代码的必读文档。小结Roo Code 集成是 CodeBurn provider 体系中薄包装 共享解析设计模式的典型样本roo-code.ts只负责声明扩展 ID 与 provider 身份任务发现、模型/项目提取、token 与成本计算、去重全部由 vscode-cline-parser.ts 统一承担并以 roo-code.test.ts 的 247 行测试锁定行为。理解这条链路既能解释为什么 Roo Code 用量不需要额外配置就能被统计也能在跨 provider 数据异常时快速判断问题归属——是共享解析器的锅还是 Roo Code 上游 JSON 特有的形状差异。赞分享【免费下载链接】codeburnFree, local tool to track AI coding token usage and cost across 37 tools and agents (Claude Code, Cursor, Codex, Gemini and more), by model, project, and task. npx codeburn项目地址https://gitcode.com/gh_mirrors/co/codeburn点击查看免费下载相关推荐codeburn 集成指南KiloCode VS Code 扩展的用量追踪实现与解析原理codeburn 集成指南KiloCode VS Code 扩展的用量追踪实现与解析原理 本指南聚焦 codeburn 如何接入 KiloCodeVS CoCodeBurn 的 Qwen Code CLI 集成JSONL 会话解析、Token 成本核算与去重机制全解析CodeBurn 的 Qwen Code CLI 集成JSONL 会话解析、Token 成本核算与去重机制全解析 CodeBurn 是一款本地运行、无需账号的为 Roo Code 接入 Hindsight 持久化长期记忆hindsight-roo-code 集成实战指南为 Roo Code 接入 Hindsight 持久化长期记忆hindsight roo code 集成实战指南 导读 本指南完整讲解 Hindsight 官人工智能AI AgentAgent 记忆MCP 服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考