CodeBurn：8.4K星开源工具，精准追踪AI编程每一分钱

文章正文

当你同时用 Claude Code 写一段、Codex 跑一段、Cursor 改一段、Gemini 再问几句，月底账单越来越长，却说不清到底是哪个工具、哪个模型在疯狂烧钱——这正是一款在 GitHub 上斩获 8.4K 星的开源项目想要解决的问题。它是一个专门给 AI 编程工具算账的本地账本，把一笔笼统的支出彻底拆开，让每一分钱花在哪里都清清楚楚。

行业背景：多工具并用时代的成本困境

2024-2025年间，AI编程工具市场进入高度碎片化阶段。根据各方调研数据，专业开发者平均同时订阅2-4个AI编程工具已成常态。这一现象的成因在于：不同工具在代码补全、多文件重构、终端命令生成、代码审查等细分场景各有所长，且模型提供商（OpenAI、Anthropic、Google）与工具提供商（Cursor、GitHub等）形成了复杂的分层结构。这种碎片化带来了成本管理的真空地带——每个工具只展示自身的用量统计，跨工具的汇总视图几乎不存在。企业采购层面，AI Token费用在软件工程成本中的占比正在快速上升，Gartner等机构预测2025年AI API支出将成为中大型科技团队不可忽视的运营成本项，催生了CodeBurn这类横向聚合工具的市场需求。

值得注意的是，AI编程工具的计费结构往往比表面看起来复杂得多。以Cursor为例，用户支付的月费实际上包含两层：一层是给Cursor公司的订阅费，另一层是底层模型调用的API费用（通常以「快速请求」额度形式预付）。超出额度后，Cursor会直接代理调用OpenAI或Anthropic的API，费用按Token计入用户账单。这种「订阅+按量」的混合模式在行业内相当普遍，正是造成成本核算天然复杂性的根源之一。

这里所说的Token，是大语言模型处理文本的基本计量单位，不同于直觉上的「字数」——英文中一个单词大约对应1-2个Token，中文每个字符通常对应1-2个Token。主流模型的计费逻辑分为输入Token（你发给模型的内容）和输出Token（模型生成的回复），两者单价不同，输出Token通常更贵。以Claude 3.5 Sonnet为例，输入价格约$3/百万Token，输出约$15/百万Token。一次看似普通的「帮我重构这个函数」请求，实际上可能携带了整个文件的上下文，悄悄消耗数千Token。正因如此，成本感知的模糊性才会在多工具并用时被急剧放大。

大语言模型计费架构演变

大语言模型的Token计费模型并非从一开始就如此复杂。早期GPT-3 API仅按总Token数统一计费，不区分输入输出。随着模型推理成本结构逐渐被业界理解——生成Token需要逐步自回归解码（每生成一个词都需要完整运行一次前向传播），计算量远高于仅需处理一次的输入——OpenAI在GPT-3.5时代开始分离输入/输出定价，Anthropic、Google等后续跟进并普遍采用这一模式。如今，主流API的计费体系还在进一步细化：出现了「缓存写入Token」「缓存读取Token」「批处理折扣Token」「推理Token」等多个层级，使得精确核算成本需要解析多个维度的日志数据。这种计费体系的持续细化，正是CodeBurn这类专属账单工具存在价值的技术根基——人工核对如此复杂的计费结构几乎不现实，而对大多数开发者而言，这些计费层级也远超日常认知范围。

一个只做「算账」的本地工具

这个项目开源至今已迭代到 0.9.14 版本，定位非常明确：不接管你的请求，不做任何代理转发，只读取本机上已有的对话记录，然后按照「工具、模型、项目、任务」四个维度重新计算一遍。

这种设计带来一个关键好处——数据完全留在本地。你不需要额外填写一堆 API Key，也不用担心对话内容被上传到外部服务器。它只是把你电脑里已有的日志读出来，重新组织成一张清晰的账单。

在技术实现层面，CodeBurn选择完全本地化运行的架构，意味着它需要了解各AI编程工具将对话记录存放在本机的哪个路径。事实上，大多数AI编程工具都会在本地缓存对话历史以支持会话恢复功能——例如Claude Code将记录存储在用户目录的特定JSON文件中，Cursor则使用SQLite数据库。CodeBurn本质上是一个多格式日志解析器加可视化前端，整个计算过程在本地Node.js进程中完成，不依赖任何远程服务。这与市面上部分需要OAuth授权或API Key接入的同类工具形成鲜明对比，对于注重隐私、又想搞清楚 AI 编程成本结构的开发者来说，是相当克制且友好的技术选择。

本地日志解析的技术挑战

不同AI编程工具在本地存储对话记录时，采用的格式和存储策略差异极大。Cursor将会话数据存入SQLite数据库（通常位于~/.cursor/目录），表结构随版本更新可能发生变动；Claude Code采用按会话分目录的JSON文件格式，每条消息含有详细的Token用量元数据；GitHub Copilot的本地日志则更为分散，分布在VSCode扩展的缓存目录中。这种「碎片化存储标准」意味着CodeBurn必须为每款工具实现独立的解析适配层，类似于数据工程领域的ETL（Extract-Transform-Load）管道——先从各自的原始格式中提取数据（Extract），转换为统一的Token消耗数据模型（Transform），再汇总加载进可视化层（Load）。随着AI工具频繁更新，解析器也面临持续维护的压力：一次工具版本升级就可能改变日志的字段结构，导致解析失败。这也是开源社区协作维护此类项目的关键优势——社区贡献者往往能在官方发布更新后，在数天内跟进适配层的修复，而闭源商业工具则可能滞后数周。

从总览到明细：四层维度看清 AI 编程支出

打开工具后，首先看到的是总览页面：最近一段时间花了多少钱、跑了多少次调用、消耗了多少上下文额度。如果你同时使用了 Claude Code、Codex 和 Cursor，它会把这几项分开列出，让你一眼看清钱是集中烧在某一个工具上，还是几个工具同时在消耗。

按模型对比性价比

更有价值的是模型维度的分析。现实中经常出现两种浪费：贵模型被拿去做简单的活，或者一件小事反复跑了好几轮。CodeBurn 会把不同模型放在同一张账上比较——每个模型的成功率、重试次数、每次编辑的花费、缓存命中情况全都一目了然。

这意味着你不再需要凭感觉猜「哪个模型更划算」，而是有实打实的数据支撑决策。有时候贵模型确实省时间，但有时候它只是在被低效使用——这张账单帮你分辨两者。

模型分层选择策略

AI编程领域正在形成一套「模型分层使用」的最佳实践，其背后逻辑与云计算中的实例类型选择高度相似。通常将任务粗分为三层：简单的单行补全、变量命名等任务适合用轻量快速模型（如GPT-4o mini、Claude Haiku），这类模型延迟低、成本仅为旗舰模型的1/10到1/20；中等复杂度的函数级重构、单元测试生成适合中档模型；跨文件架构设计、复杂调试才值得动用旗舰模型（如Claude Opus、GPT-4o）。然而，大多数AI编程工具在默认配置下倾向于对所有请求调用同一个模型（通常是旗舰模型），导致大量简单任务被「过度供给」。这种错配的规模在无数据支撑时往往难以察觉——一次补全0.002美元看似微不足道，但当每天发生数百次时，累积效应便相当可观。CodeBurn的模型维度账单，正是帮助开发者识别这种错配的定量依据——当你发现某个旗舰模型处理了大量低成功率、高重试次数的简单请求时，往往意味着存在切换到轻量模型的优化空间，可在几乎不影响体验的前提下将相关成本削减数倍。

Token计费原理

Token是大语言模型处理文本的基本计量单位，不同于直觉上的「字数」——英文中一个单词大约对应1-2个Token，中文每个字符通常对应1-2个Token。主流模型的计费逻辑分为输入Token（你发给模型的内容）和输出Token（模型生成的回复），两者单价不同，输出Token通常更贵。以Claude 3.5 Sonnet为例，输入价格约$3/百万Token，输出约$15/百万Token。一次看似普通的「帮我重构这个函数」请求，实际上可能携带了整个文件的上下文，悄悄消耗数千Token——这也是为什么在账单分析中，输入/输出Token的比例往往比总量更能说明问题。

帮你揪出隐藏的 Token 浪费

除了记账，CodeBurn 还会主动帮你查找浪费环节。它会识别几类常见的成本黑洞：

• 同一批文件被 AI 反复读取，重复消耗上下文
• 某个命令输出大量无用内容，白白占用 Token
• 配置里写着的 MCP 服务、Agent、Skill 几乎没用到，却持续占据资源

MCP协议：AI工具连接外部世界的标准接口

MCP（Model Context Protocol）是Anthropic于2024年底推出并开源的标准化协议，旨在解决AI模型与外部工具、数据源之间的连接标准化问题。可以将其理解为AI领域的「USB接口」——在MCP出现之前，每个AI工具连接数据库、代码仓库、文件系统都需要各自实现一套定制化集成，维护成本极高且生态高度碎片化。MCP将这一过程抽象为统一的服务器-客户端架构：MCP Server负责暴露工具能力（如读取文件、执行Shell命令、查询数据库），MCP Client（即AI编程工具）按标准协议调用这些能力。Claude Code、Cursor、Windsurf等主流工具均已宣布支持MCP，围绕MCP的第三方服务器生态也在快速扩张，已涵盖GitHub、Notion、Slack、PostgreSQL等数十种集成。然而，MCP的便利性带来了一个隐性成本问题：部分MCP Server在后台持续运行时会持续向上下文注入工具描述和状态信息，即便从未被实际调用也会占用输入Token额度。若开发者出于「以备不时之需」的心理配置了大量实际使用频率极低的MCP服务，便形成了典型的「躺着占地方」成本黑洞——在高频使用场景下，这部分固定的上下文开销可能比实际的工具调用消耗还要高。

上下文窗口与Agent模式下的Token膨胀

上下文窗口（Context Window）是指模型在单次请求中能够处理的最大Token数量。主流旗舰模型的上下文窗口已达到100K至200K Token（约相当于一本中等篇幅小说），但这并不意味着填满上下文窗口是免费的——输入Token按量计费，填入越多内容成本越高。AI编程场景中存在一种常见的「上下文污染」现象：工具为了提供更好的代码感知能力，会将整个代码仓库的索引、所有已打开文件、终端历史、项目文档等内容一并注入上下文，其中大量内容与当前具体问题无关。这种现象在使用Agent模式（让AI自主规划并多步骤执行任务）时尤为突出：Agent的每一步工具调用结果都会作为新的输入累积进下一步请求的上下文，导致Token消耗随对话轮数呈线性乃至超线性增长。一个原本预计花费0.05美元的「帮我调查这个Bug」指令，在Agent经过10轮工具调用后，实际成本可能超过0.5美元。CodeBurn识别的「同一批文件被AI反复读取」问题，正是这类上下文膨胀的典型症状，在长会话中可能造成数十倍于正常水平的Token消耗，是最值得优先审查的成本黑洞类型。

这些问题单次看往往不明显，但时间一长会悄悄吃掉大量上下文额度和费用。工具会逐一列出，告诉你该优先清理哪一块。

Prompt缓存：被忽视的省钱机制

缓存命中率是账单分析中容易被忽视的关键指标。Prompt缓存（Prompt Caching）是近年主流AI API服务商推出的成本优化机制：当连续多次请求携带相同的前缀内容（如系统提示词、固定的代码库上下文），服务商会将这部分内容的KV缓存（Key-Value Cache，即注意力机制中间状态的存储）保存在服务器端，后续请求命中缓存时只需支付极低的缓存读取费用，无需重新计算这部分内容。Anthropic的Prompt Caching可将命中部分的输入成本降低约90%，OpenAI也在其API中引入类似机制。缓存的命中条件通常要求请求前缀与缓存内容完全一致，且在缓存有效期内（通常为5分钟至1小时不等）发起请求。对于AI编程工具而言，代码库上下文往往占据每次请求的绝大部分Token，如果工具能合理利用Prompt缓存，实际账单金额可能仅为理论上限的10%-30%。CodeBurn追踪各模型的缓存命中情况，正是在帮助开发者判断其工具配置是否充分利用了这一节省机制——低缓存命中率往往意味着工具每次请求都在重复发送大量相同内容，存在可优化的空间。

花的钱最后有没有变成代码？

对团队而言，还有一个更本质的问题：投入的 AI 成本最终有没有转化为有效代码产出？CodeBurn 提供了一个巧妙的关联分析——把 AI 对话记录和代码提交按时间轴对齐。

如果某段对话之后紧跟着提交，而提交又合入了主分支，那么这段花费更像是「有效支出」；反之，如果对话附近没有对应提交，或者代码后来被回滚，你至少能意识到——这笔钱花得有点悬。

在技术实现上，将AI对话记录与Git提交历史对齐需要解决时间戳匹配、会话归属和分支追踪等问题。CodeBurn的做法是读取本地Git仓库的提交日志，与各工具缓存的对话记录按时间窗口（通常为数分钟到数小时）进行模糊匹配。这种方法无需修改开发者的工作流，但精度受限于AI工具的日志格式是否包含足够的元数据（如项目路径、会话ID）。不同工具的日志标准差异很大——Cursor的SQLite日志结构与Claude Code的JSON日志截然不同，这也是CodeBurn需要为31个工具分别实现专属解析器的根本原因。

AI辅助编程的ROI量化挑战

将AI编程成本与代码产出挂钩，触及了软件工程效能领域长期存在的ROI（投资回报率）量化难题。传统软件工程度量框架（如DORA指标体系，涵盖部署频率、变更前置时间、变更失败率、服务恢复时间四个维度）并未专门设计用于衡量AI工具的边际贡献，难以将AI辅助带来的效率提升从其他因素中剥离出来。业界目前存在几种实验性量化方法：一是受控对比实验，让同等水平的开发者分别在有/无AI辅助条件下完成同类任务，统计完成时间与代码质量差异（GitHub曾通过此方法得出Copilot可提升约55%编码速度的结论，但该数字因实验设计被广泛质疑）；二是代码留存率分析，追踪AI生成代码在产品若干个版本后的留存比例，频繁被修改或删除的AI代码往往意味着质量较低或方向错误；三是与CodeBurn类似的时间轴关联法。这些方法都面临混杂变量多、难以精确归因的共同困境。CodeBurn的关联分析属于第三类方法的轻量实现，其真实价值更多在于触发开发者对自身AI使用习惯的主动反思——「这段对话附近没有提交」的提示，往往能唤起对某次低效AI交互的具体记忆，形成行为层面的闭环改进，而非提供可用于正式绩效评估的精确数据。

需要说明的是，这种判断并不严谨，不能当作正式审计报告使用，但对于团队内部复盘、优化 AI 使用习惯来说，已经足够有参考价值。

多种查看方式与广泛的工具支持

在使用体验上，CodeBurn 提供本地网页版，可在浏览器里查看图表、项目排行、模型排行。macOS 用户还能使用菜单栏版本，随手查看今天、本周、本月各花了多少钱，非常适合日常监控。

工具兼容性方面，官方宣称支持 31 个 AI 编程工具，包括 Claude Code、Codex、Cursor、Gemini、Goose、OpenCode、Kilo Code、Roo Code、GitHub Copilot、Gemini CLI 等主流方案。支持如此多工具并非易事——每种工具的本地日志格式各异，CodeBurn为每一款工具单独实现了解析适配层，使其能从格式各异的本地存储中提取出统一的Token消耗数据结构。可以说，你使用的工具越分散，这款账本派上用场的场景就越多。

AI编程工具生态格局

截至2025年，AI编程工具市场已形成三个层次的竞争格局。第一层是「平台型」工具，依托大型代码托管平台或云服务商背书，如GitHub Copilot（微软/GitHub）、Gemini Code Assist（Google）、Amazon CodeWhisperer；这类工具的优势在于与CI/CD流程、代码仓库的深度集成，以及企业级合规与数据隔离保证。第二层是「独立IDE增强型」工具，以Cursor为代表，通过深度改造VSCode编辑器提供Tab键多行补全、Composer多文件编辑等差异化体验，月活开发者数量已达数百万级，并孕育出Windsurf（原Codeium）等跟进者。第三层是「终端/CLI型」工具，如Claude Code、Codex CLI、Gemini CLI，专注于命令行工作流集成，支持直接操作文件系统和执行Shell命令，在后端工程师和DevOps群体中渗透率快速上升。值得注意的是，同一家基础模型提供商往往在多个层次都有布局（例如Anthropic同时提供Claude API给Cursor使用，又自研Claude Code与之竞争），造成了工具与模型之间复杂的竞合关系。这一生态的复杂性，正是开发者在没有专用工具辅助的情况下难以清晰核算AI编程成本的结构性原因。

边界感很重要：只算账，不替你做决定

值得称道的是这个工具的克制。它不会自动修改你的任何配置——把账摊开之后，剩下的决定留给你自己：哪一块花得最多、哪个模型总在重试、哪些配置一直躺着占地方。看完这张账单，你会对自己的 AI 使用方式清楚很多，但改不改、怎么改，主动权始终在你手里。

谁适合用，谁暂时不用急

从使用门槛看，命令行可以直接运行安装，前提是电脑上装有 Node.js，并且已经使用过支持的 AI 工具、留下了对话记录。如果你刚装完工具还没真正使用，这个账本暂时算不出任何东西。

因此它的最佳目标用户很明确：已经把 AI 当作日常开发工具、每天都在用、月底账单越来越长的开发者。对这类重度用户来说，一份清晰的 AI 编程成本账单能带来实实在在的优化空间。反之，如果你只是偶尔问 AI 两句话，暂时不必急着安装。

结语

随着 AI 编程工具进入多工具、多模型并用的时代，成本管理正在从「模糊感知」走向「精细核算」。Token计费架构的持续细化、Prompt缓存命中率的高低、MCP服务的上下文占用、Agent模式下的Token膨胀——这些曾经只有平台工程师才关心的技术细节，正在逐渐成为每一位日常使用AI编程工具的开发者都需要理解的基础知识。CodeBurn 的价值不在于花哨的功能，而在于它用一种本地、隐私友好且克制的方式，回答了一个越来越迫切的问题——你的 AI 编程预算到底花得值不值。对于认真对待 AI 开发成本的工程师和团队来说，这样的工具正变得不可或缺。

核心要点