Aimeterly 是一个从 Claude Code 内置 OpenTelemetry 数据里生成按用户成本仪表盘的工具。它的使用场景很具体当你不只想看 Claude Code 这个月的总账单还想知道团队里谁在用、哪个项目在烧 token、哪些人只是偶尔试一下时它会帮你把散落在遥测日志里的 usage 数据整理成一块可看的面板。如果你是技术负责人、DevOps 或预算管理角色并且团队已经在用 Claude Code这篇文章会顺着实际落地顺序讲清楚它适合解决什么问题、接入链路怎么搭、数据准不准、以及有哪些坑。先说结论Aimeterly 这种思路真正有价值的点不是“做一个好看的图表”而是把 Claude Code 自带的 OpenTelemetryOTel数据变成团队可解释的成本事实。Claude Code 在运行时会输出链路追踪和指标数据Aimeterly 看起来就是做一层采集、聚合和展示把这些数据按用户、按项目、按时间维度换算成成本。这个方向对团队特别实用因为 AI 编码助手的成本不是按人头买了 License 就固定的它更多是 token 消耗型支出不看使用量根本不知道钱花在哪。不过也要提醒一句这是一个偏早期、偏实验性的工程方向。你可能会遇到文档不全、字段不稳定、版本兼容问题。下面我按自己处理这类可观测性工具的习惯从需求拆到排查完整过一遍。1. 先说清楚团队到底需要一个什么样的成本仪表盘1.1 成本迷雾为什么只看总账单不够很多团队第一次看 Claude Code 费用时只会直接打开账单后台看一眼本月总额。这个数字只能回答“花了多少”回答不了“谁花的”“花在什么场景”“哪些是必要的、哪些是浪费的”。举个例子。一个 10 人开发组A 成员每天都用 Claude Code 做代码审查和测试用例生成用量大但产出明显。B 成员只是偶尔复制一段代码进去问两句用量小但可能用的是更贵的模型。只看总账单你既不知道 A 的投入值不值得也看不到 B 的模型选择是否合理。更现实的问题是预算分摊。如果团队内部有项目核算或者要给不同业务线回填成本那你必须知道每个用户、每个项目各自消耗了多少 token。手工去日志里翻是不可持续的因为 Claude Code 一天的调用量很容易超过几百次哪怕只有几个人在用数据量也会很快超过手工处理能力。所以按用户拆成本本质上不是“多一个统计维度”而是把 AI 编码助手从“工具支出”变成“可管理的资源支出”。你只有能看到明细才能谈优化、谈配额、谈预算预警。1.2 按用户拆成本之后你能回答什么问题按用户和项目拆完成本后仪表盘至少应该能回答下面几类问题成本分布最近 7 天、30 天里每个成员花了多少钱是集中在某一个人还是均匀分摊。项目归因这些 token 消耗发生在哪个仓库、哪个项目目录下方便按项目核算。模型使用不同模型默认模型、更强推理模型、本地模型分别占多少成本是否存在大材小用的情况。时间趋势每天、每周的成本曲线能帮助发现“是不是某个版本发布前夕突然用量暴涨”。异常波动某天成本突然翻倍是某个用户跑了批量任务还是出现重复请求、失败重试。这些问题的答案最早都能从 OTel 遥测数据里找到线索。Claude Code 内置的 OTel 导出原则上能把每次调用的关键上下文、关联 ID、用量信息发送到可观测性后端。Aimeterly 做的事就是把这些原始信号翻译成成本。2. Claude Code 内置 OTel 到底能导出哪些数据2.1 OTel 在这里扮演什么角色OpenTelemetry 是一个可观测性标准它定义了一整套链路追踪、指标、日志的数据格式和导出协议。Claude Code 内置 OTel 支持意味着它不需要你改代码只需要做配置就能把运行时行为以标准格式吐出来。这对成本仪表盘是很有优势的。你不需要逆向解析终端输出也不需要去翻某个平台特有的 API 日志。只要 OTel 数据能导出到统一端点后面接什么都顺。Aimeterly 选择消费 OTel 而不是自己做埋点说明它更愿意站在标准协议上工作而不是绑定某个具体账号或平台。在实际使用中你需要关心的 OTel 数据大概分两类Trace一次 Claude Code 调用的完整链路里面会携带操作类型、耗时、关系上下文以及可能的 usage 属性。Metric可以直接聚合的数值型指标例如请求次数、token 输入输出量、延迟等。成本计算最依赖的是 usage 类数据。一次调用里输入了多少 token、输出了多少 token再乘上对应模型单价就能得到一次调用的成本。如果 OTel span 里带了 user、project、model 这类属性那成本归因就有了基础。2.2 接入前需要确认的几件事我把第一次接入当侦探工作来处理先确认几件事再动手。第一确认 Claude Code 版本支持 OTel 导出。内置 OTel 是逐步开放的不同版本的行为可能有差异。建议先查你现在安装的版本再看官方 changelog 或配置文档里有没有 OTel exporter 相关说明。第二确认 OTLP 端点怎么配置。OTLP 是 OpenTelemetry 的传输协议常见接收端点包括本地 Collector、可观测性平台、或者自建服务。你需要在 Claude Code 启动环境里配置 endpoint、headers、可能还有 service name。由于原始项目介绍没有给出 Aimeterly 的具体配置项这里不要凭记忆硬填环境变量最稳妥的方式是打开 Claude Code 的配置说明找到 OTel 或 telemetry 相关的段落按那个变量名来。第三确认你能否从遥测数据里识别出“用户”和“项目”。如果 OTel 导出里没有自动带 user 属性Aimeterly 或你的 Collector 层就需要通过环境变量、会话 ID、工作目录等维度来补全。这个不做per-user 仪表盘就名存实亡。第四确认采集链路是否合规。团队成员不一定愿意自己的工作行为全部被记录。如果团队有隐私要求你需要提前说明采集范围、用途和保留周期。这个不是技术问题但比技术问题更容易让项目夭折。3. 把 Aimeterly 接到 Claude Code 的成本链路里3.1 最小链路Claude Code、OTLP 出口、Aimeterly、仪表盘我建议先按最小链路跑通不要一上来就上生产集群。最小链路大概是Claude Code启用 OTel 导出 ↓ OTLP OpenTelemetry Collector 或 Aimeterly 接收端 ↓ 聚合、映射、计算成本 Aimeterly 存储与查询层 ↓ Dashboard按用户/项目/时间展示这个链路里Claude Code 是数据源OTLP 是传输协议Aimeterly 是处理层和展示层。如果 Aimeterly 本身可以直接接收 OTLP那 Collector 可以省略如果 Aimeterly 只读某种后端数据你就得先让 OTLP 落到那个后端再接 Aimeterly。实际落地时我更建议中间加一个 OpenTelemetry Collector。原因很简单Collector 可以做数据清洗、属性补齐、批量和重试。Claude Code 的每次调用都要经过网络发送如果直接发到 Aimeterly一旦 Aimeterly 短暂不可用数据可能丢。而 Collector 能缓冲和重试对长期运行很重要。3.2 示例配置先跑通一条用户记录下面给的是通用示例不是某个具体版本的完整清单。你在实际配置时需要把变量名和 endpoint 替换成你当前环境对应的值。假设你的 Claude Code 支持通过环境变量或配置文件声明 OTLP exporter一个常见形状大约是这样# 以环境变量方式启用 OTLP 导出 export CLAUDE_CODE_OTEL_ENABLEDtrue export CLAUDE_CODE_OTEL_EXPORTER_OTLP_ENDPOINThttp://localhost:4318 export CLAUDE_CODE_OTEL_SERVICE_NAMEclaude-code export CLAUDE_CODE_OTEL_HEADERSAuthorizationBearer your-token # 或者把配置写进 Claude Code 的配置文件 # 具体格式以官方文档为准需要注意的是Aimeterly 如果和 Collector 部署在同一台机器上面 endpoint 填localhost没问题如果 Collector 在远程服务器就要填正确的服务地址并提前处理网络连通、认证、防火墙规则。接着在 Collector 侧准备一个简单的 OTLP Receiver。很多 OpenTelemetry Collector 默认配置文件都有 otlp 协议常见端口是 4317gRPC和 4318HTTP。Claude Code 使用 HTTP 常见一点但不同版本可能默认不同。配置示例receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 http: endpoint: 0.0.0.0:4318 cors: allowed_origins: - * processors: batch: exporters: otlphttp/aimeterly: endpoint: http://aimeterly-service:4318 tls: insecure: true service: pipelines: traces: receivers: [otlp] processors: [batch] exporters: [otlphttp/aimeterly] metrics: receivers: [otlp] processors: [batch] exporters: [otlphttp/aimeterly]这段配置不代表 Aimeterly 一定支持这种写入方式只是告诉你“Collector 到目标服务”这种转发关系可以怎么描述。如果你的 Aimeterly 有标准 OTLP 接收端点上面这种管道就能成立如果没有就需要调整 exporter。3.3 单用户单任务验证和多人批量验证配置完成后不要急着看完整仪表盘。先做两个阶段验证。阶段一单用户单任务。只保留一个测试用户打开 Claude Code。随便发起一次调用例如让它生成一个简单函数。等几秒去 Aimeterly 或后端查询最近数据。确认能查到 trace 或 metric确认里面带有用户标识、模型标识、token 用量。这个阶段如果失败后续不要继续。先查采集链路别查成本计算。阶段二多人批量验证。让两三个成员各自跑几个任务尽量覆盖不同项目目录。确认仪表盘能按用户区分每个人只能看到自己的数据如果有权限控制。确认同一项目目录下的任务能归到同一个项目 ID。比对账单后台或账号页面里的用量看数字是否在一个合理范围内。批量验证时最容易出现的是“用户属性丢失”。有时候你在本地明明能看到 user_id但经过 Collector 转发后属性被过滤了。这往往不是 Claude Code 的问题而是 Collector 处理器中 drop 或 filter 规则把 span 属性干掉了。遇到这种情况先进 Collector 的 debug exporter看原始 span 到底带了哪些属性。4. 仪表盘上哪些指标值得做哪些要小心4.1 成本指标和费用口径一个成本仪表盘如果只有“总费用”一个数价值很低。我建议至少维护三类指标。第一类用量指标。包括输入 token 数、输出 token 数、每次调用的 token 总量、请求次数。这些是基础所有成本计算都从它们推导。第二类成本指标。这里要特别注意“模型单价”的来源。OTel 数据里通常包含 token 数量但单价往往需要在 Aimeterly 配置层维护一份模型价格表。不同模型、不同时段、不同账号套餐单价可能不一样。如果价格表错了仪表盘上的预估成本就是错的。建议把成本计算拆成两个层级原始用量层保存所有 trace、span、usage 字段不做价格换算。成本视图层按天、按用户、按项目聚合再把 token 用量乘上模型单价得出预估成本。这样即使价格调整也不需要重新处理历史原始数据只要重建成本视图即可。第三类效率指标。例如“每次成功调用平均消耗多少 token”“输出 token 占比”“失败重试消耗了多少 token”。这类指标能帮你发现一个用户是不是反复触发长输出、或者同一个请求因为失败被重试了很多次。表格里展示常见指标和它的业务含义大概是这样指标计算方式业务含义输入 token 总量所有成功调用的输入 token 求和代码上下文、提示词消耗规模输出 token 总量所有成功调用的输出 token 求和生成结果规模对成本影响更大单次调用平均成本总成本 / 调用次数单次交互的消耗水平用户成本占比用户成本 / 总成本成本分布找出用量大户失败重试损耗失败请求的 token 消耗之和配置问题或系统波动造成的浪费项目成本项目维度聚合按业务线核算成本4.2 覆盖率、归因和权限边界成本仪表盘最容易踩的坑是覆盖率。你看到的数字可能只是“能采集到的部分”而不是“实际发生的全部”。Claude Code 在某些情况下可能不发送 OTel 数据。例如网络中断、OTLP 端点不可用、用户手动关闭了遥测、某些命令模式不产生 span。如果一个用户长期处于离线环境他的成本就可能完全不出现在仪表盘里。不要默认“Aimeterly 显示的总成本 账单总额”。你需要在页面上留一个“数据覆盖率”或“采集失败率”指标或者在接入文档里明确说明这个仪表盘是近似估算。归因也容易出问题。用户属性来自哪一层如果 Aimeterly 只能拿到进程启动时的系统用户名那么多个用户共用一台开发机时成本会被错误地归到同一人。正确做法是尽量从 Claude Code 会话、登录账号、环境变量里读取用户标识而不是依赖操作系统用户。权限边界也要提前设计。既然是 per-user 成本仪表盘就会涉及个人使用细节。如果公司没有全员公开预算的习惯页面需要支持按角色控制可见范围。比如普通成员只看自己的成本团队负责人看整个小组管理员看全量。如果不能做权限控制至少要把导出和分享链接控制住不要让人无意间把全团队的成本明细贴在公开群聊里。5. 常见坑和排查顺序5.1 看不到数据时先按什么顺序查Aimeterly 仪表盘一片空白时很多人第一反应是“工具坏了”。我通常不会直接怀疑核心工具而是按下面顺序一层层排掉先确认 Claude Code 侧有没有真的产生 OTel 请求。可以看 Claude Code 日志里有没有输出 exporter 相关的错误或者在 Collector 端观察是否收到 OTLP 请求。这一步能快速区分“没发出”和“发了但没收到”。再看网络连通。Claude Code 到 CollectorCollector 到 Aimeterly两个网段都必须通。认证 headers 不对、证书过期、端口没监听都会导致请求失败。排除时可以直接用 curl 模拟发一个 OTLP 请求比反复重启 Claude Code 快得多。再看 Collector 配置。确认 pipeline 里 traces、metrics 都配了对应的 receiver 和 exporter。有时候 traces 能过来metrics 没过来是因为 pipeline 里写漏了。再看 Aimeterly 是否支持对应接口。如果它只接收某个特定端口或特定格式请你按它的 README 调整而不是在 Collector 里猜。最后才检查数据处理逻辑。比如 Aimeterly 里有没有按用户过滤、有没有按日期过滤、是否覆盖了今天的数据。排查时不要同时改多个变量。一次只改一处然后重放一次 Claude Code 调用看数据有没有进来。这个习惯能省很多时间。5.2 成本数字偏大偏小的几个原因成本数字对不上是第二个高频问题。如果仪表盘成本明显偏小先查覆盖率。可能有一批用户没走 OTel 导出或者 Collector 对某些 span 做了采样。OTel 链路默认可能采样如果你的 Collector 里配了采样策略只保留 10% 的 trace那成本仪表盘自然只剩 10%。成本统计不应该按 trace 采样率推导除非你显式接入采样率补偿逻辑。如果成本偏大可能原因包括模型单价配置错误、某些重试请求被重复计数、或者把非 Claude Code 的 OTLP 数据也汇总了进来。遇到这种情况可以在 Aimeterly 里增加一个属性过滤只统计 service.name 为 claude-code 的 span。另外token 用量口径也要统一。有的平台按“输入 token 输出 token”展示有的展示“总 token”。如果 Aimeterly 的成本计算模型只乘了输出 token而账单统计的是总 token那数字也会对不上。我一般会建议团队在落地第一周做一次人工抽检拿三个用户的成本明细和账号后台的实际用量逐一对比。如果差异在 10% 以内说明口径基本合理如果差异很大不要急着调单价先把采集覆盖率和重复计数排查干净。6. 生产落地建议6.1 先实验后推广Aimeterly 这种新工具我不建议第一天就全团队强制接入。更合理的路径是先用一个测试项目或少量用户部署一条最小链路跑一周。验证 OTel 采集的稳定性哪天突然没数据了能不能及时发现。验证成本估算的准确性是否和账单大体一致。验证用户体验会不会因为要配置环境变量、启动额外服务影响开发者日常工作。再逐步把更多用户、更多项目接进来。推广时最容易遇到的阻力是“又要配环境变量”或者“我的终端多了个后台服务”。如果你能做成一个团队级配置模板让大家拉下来就能用而不是要求每个人手动导出各种环境变量推广会顺很多。新版本 Claude Code 更新时建议先在一台测试机器上验证 OTel 导出没有被破坏再让全员更新。可观测性链路最怕的就是“客户端升级后不再发数据但没人发现”。6.2 长期运行要关注的资源、保留周期和团队协作长期运行时Aimeterly 的数据量会涨得很快。几十个人每天跑几百次调用一个月下来的 span 数量可达几十万甚至上百万。你需要提前关注存储原始 OTel span 是否要全量保留如果只关心成本可以定期聚合只保留明细 30 天历史数据转成天级聚合。查询性能仪表盘查询如果按用户、项目、时间过滤后面的存储和索引是否能撑住。资源占用Collector 和 Aimeterly 服务占多少内存、CPU是否适合放在你现有的服务器上。备份成本数据会计入预算和分摊如果纯靠工具内页面积累没有导出机制后续换工具会很痛苦。建议每天做一次日终聚合生成一个user_project_daily_cost表或指标集合。即使原始 span 被删掉历史成本趋势仍然能保留下来。6.3 什么时候不需要自建什么时候该自建如果你们团队只有两三个人每月账单一眼能看完完全不需要 Aimeterly 这种仪表盘。直接定期导出账单给财务就行。这个工具的价值来自团队规模和成本可见性需求人少的时候管理成本比实际成本还高。但如果满足下面任意一条自建或引入这类 OTel 成本仪表盘就是值得的团队超过 5 人且都在高频使用 Claude Code。公司需要按项目或业务线回填研发费用。你想设置预算上限但缺少可信的数据支撑。你发现有人用量异常却无法定位是谁、在哪类任务上消耗。你想对比不同模型方案的成本差异为选型找依据。最后再说一句Aimeterly 本身是不是已经做到生产级、是否完全支持 Claude Code 当前版本我无法替你验证。你真正该做的是拿最小样例跑一遍确认 OTel 数据能出来、能看到用户标识、成本估算能对上账单。这条链路通了工具叫什么名字反而不重要你已经拥有了一套可以解释 AI 编码助手成本的基础设施。 Aimeterly：OTel数据驱动的Claude Code成本仪表盘实践
Aimeterly 是一个从 Claude Code 内置 OpenTelemetry 数据里生成按用户成本仪表盘的工具。它的使用场景很具体当你不只想看 Claude Code 这个月的总账单还想知道团队里谁在用、哪个项目在烧 token、哪些人只是偶尔试一下时它会帮你把散落在遥测日志里的 usage 数据整理成一块可看的面板。如果你是技术负责人、DevOps 或预算管理角色并且团队已经在用 Claude Code这篇文章会顺着实际落地顺序讲清楚它适合解决什么问题、接入链路怎么搭、数据准不准、以及有哪些坑。先说结论Aimeterly 这种思路真正有价值的点不是“做一个好看的图表”而是把 Claude Code 自带的 OpenTelemetryOTel数据变成团队可解释的成本事实。Claude Code 在运行时会输出链路追踪和指标数据Aimeterly 看起来就是做一层采集、聚合和展示把这些数据按用户、按项目、按时间维度换算成成本。这个方向对团队特别实用因为 AI 编码助手的成本不是按人头买了 License 就固定的它更多是 token 消耗型支出不看使用量根本不知道钱花在哪。不过也要提醒一句这是一个偏早期、偏实验性的工程方向。你可能会遇到文档不全、字段不稳定、版本兼容问题。下面我按自己处理这类可观测性工具的习惯从需求拆到排查完整过一遍。1. 先说清楚团队到底需要一个什么样的成本仪表盘1.1 成本迷雾为什么只看总账单不够很多团队第一次看 Claude Code 费用时只会直接打开账单后台看一眼本月总额。这个数字只能回答“花了多少”回答不了“谁花的”“花在什么场景”“哪些是必要的、哪些是浪费的”。举个例子。一个 10 人开发组A 成员每天都用 Claude Code 做代码审查和测试用例生成用量大但产出明显。B 成员只是偶尔复制一段代码进去问两句用量小但可能用的是更贵的模型。只看总账单你既不知道 A 的投入值不值得也看不到 B 的模型选择是否合理。更现实的问题是预算分摊。如果团队内部有项目核算或者要给不同业务线回填成本那你必须知道每个用户、每个项目各自消耗了多少 token。手工去日志里翻是不可持续的因为 Claude Code 一天的调用量很容易超过几百次哪怕只有几个人在用数据量也会很快超过手工处理能力。所以按用户拆成本本质上不是“多一个统计维度”而是把 AI 编码助手从“工具支出”变成“可管理的资源支出”。你只有能看到明细才能谈优化、谈配额、谈预算预警。1.2 按用户拆成本之后你能回答什么问题按用户和项目拆完成本后仪表盘至少应该能回答下面几类问题成本分布最近 7 天、30 天里每个成员花了多少钱是集中在某一个人还是均匀分摊。项目归因这些 token 消耗发生在哪个仓库、哪个项目目录下方便按项目核算。模型使用不同模型默认模型、更强推理模型、本地模型分别占多少成本是否存在大材小用的情况。时间趋势每天、每周的成本曲线能帮助发现“是不是某个版本发布前夕突然用量暴涨”。异常波动某天成本突然翻倍是某个用户跑了批量任务还是出现重复请求、失败重试。这些问题的答案最早都能从 OTel 遥测数据里找到线索。Claude Code 内置的 OTel 导出原则上能把每次调用的关键上下文、关联 ID、用量信息发送到可观测性后端。Aimeterly 做的事就是把这些原始信号翻译成成本。2. Claude Code 内置 OTel 到底能导出哪些数据2.1 OTel 在这里扮演什么角色OpenTelemetry 是一个可观测性标准它定义了一整套链路追踪、指标、日志的数据格式和导出协议。Claude Code 内置 OTel 支持意味着它不需要你改代码只需要做配置就能把运行时行为以标准格式吐出来。这对成本仪表盘是很有优势的。你不需要逆向解析终端输出也不需要去翻某个平台特有的 API 日志。只要 OTel 数据能导出到统一端点后面接什么都顺。Aimeterly 选择消费 OTel 而不是自己做埋点说明它更愿意站在标准协议上工作而不是绑定某个具体账号或平台。在实际使用中你需要关心的 OTel 数据大概分两类Trace一次 Claude Code 调用的完整链路里面会携带操作类型、耗时、关系上下文以及可能的 usage 属性。Metric可以直接聚合的数值型指标例如请求次数、token 输入输出量、延迟等。成本计算最依赖的是 usage 类数据。一次调用里输入了多少 token、输出了多少 token再乘上对应模型单价就能得到一次调用的成本。如果 OTel span 里带了 user、project、model 这类属性那成本归因就有了基础。2.2 接入前需要确认的几件事我把第一次接入当侦探工作来处理先确认几件事再动手。第一确认 Claude Code 版本支持 OTel 导出。内置 OTel 是逐步开放的不同版本的行为可能有差异。建议先查你现在安装的版本再看官方 changelog 或配置文档里有没有 OTel exporter 相关说明。第二确认 OTLP 端点怎么配置。OTLP 是 OpenTelemetry 的传输协议常见接收端点包括本地 Collector、可观测性平台、或者自建服务。你需要在 Claude Code 启动环境里配置 endpoint、headers、可能还有 service name。由于原始项目介绍没有给出 Aimeterly 的具体配置项这里不要凭记忆硬填环境变量最稳妥的方式是打开 Claude Code 的配置说明找到 OTel 或 telemetry 相关的段落按那个变量名来。第三确认你能否从遥测数据里识别出“用户”和“项目”。如果 OTel 导出里没有自动带 user 属性Aimeterly 或你的 Collector 层就需要通过环境变量、会话 ID、工作目录等维度来补全。这个不做per-user 仪表盘就名存实亡。第四确认采集链路是否合规。团队成员不一定愿意自己的工作行为全部被记录。如果团队有隐私要求你需要提前说明采集范围、用途和保留周期。这个不是技术问题但比技术问题更容易让项目夭折。3. 把 Aimeterly 接到 Claude Code 的成本链路里3.1 最小链路Claude Code、OTLP 出口、Aimeterly、仪表盘我建议先按最小链路跑通不要一上来就上生产集群。最小链路大概是Claude Code启用 OTel 导出 ↓ OTLP OpenTelemetry Collector 或 Aimeterly 接收端 ↓ 聚合、映射、计算成本 Aimeterly 存储与查询层 ↓ Dashboard按用户/项目/时间展示这个链路里Claude Code 是数据源OTLP 是传输协议Aimeterly 是处理层和展示层。如果 Aimeterly 本身可以直接接收 OTLP那 Collector 可以省略如果 Aimeterly 只读某种后端数据你就得先让 OTLP 落到那个后端再接 Aimeterly。实际落地时我更建议中间加一个 OpenTelemetry Collector。原因很简单Collector 可以做数据清洗、属性补齐、批量和重试。Claude Code 的每次调用都要经过网络发送如果直接发到 Aimeterly一旦 Aimeterly 短暂不可用数据可能丢。而 Collector 能缓冲和重试对长期运行很重要。3.2 示例配置先跑通一条用户记录下面给的是通用示例不是某个具体版本的完整清单。你在实际配置时需要把变量名和 endpoint 替换成你当前环境对应的值。假设你的 Claude Code 支持通过环境变量或配置文件声明 OTLP exporter一个常见形状大约是这样# 以环境变量方式启用 OTLP 导出 export CLAUDE_CODE_OTEL_ENABLEDtrue export CLAUDE_CODE_OTEL_EXPORTER_OTLP_ENDPOINThttp://localhost:4318 export CLAUDE_CODE_OTEL_SERVICE_NAMEclaude-code export CLAUDE_CODE_OTEL_HEADERSAuthorizationBearer your-token # 或者把配置写进 Claude Code 的配置文件 # 具体格式以官方文档为准需要注意的是Aimeterly 如果和 Collector 部署在同一台机器上面 endpoint 填localhost没问题如果 Collector 在远程服务器就要填正确的服务地址并提前处理网络连通、认证、防火墙规则。接着在 Collector 侧准备一个简单的 OTLP Receiver。很多 OpenTelemetry Collector 默认配置文件都有 otlp 协议常见端口是 4317gRPC和 4318HTTP。Claude Code 使用 HTTP 常见一点但不同版本可能默认不同。配置示例receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 http: endpoint: 0.0.0.0:4318 cors: allowed_origins: - * processors: batch: exporters: otlphttp/aimeterly: endpoint: http://aimeterly-service:4318 tls: insecure: true service: pipelines: traces: receivers: [otlp] processors: [batch] exporters: [otlphttp/aimeterly] metrics: receivers: [otlp] processors: [batch] exporters: [otlphttp/aimeterly]这段配置不代表 Aimeterly 一定支持这种写入方式只是告诉你“Collector 到目标服务”这种转发关系可以怎么描述。如果你的 Aimeterly 有标准 OTLP 接收端点上面这种管道就能成立如果没有就需要调整 exporter。3.3 单用户单任务验证和多人批量验证配置完成后不要急着看完整仪表盘。先做两个阶段验证。阶段一单用户单任务。只保留一个测试用户打开 Claude Code。随便发起一次调用例如让它生成一个简单函数。等几秒去 Aimeterly 或后端查询最近数据。确认能查到 trace 或 metric确认里面带有用户标识、模型标识、token 用量。这个阶段如果失败后续不要继续。先查采集链路别查成本计算。阶段二多人批量验证。让两三个成员各自跑几个任务尽量覆盖不同项目目录。确认仪表盘能按用户区分每个人只能看到自己的数据如果有权限控制。确认同一项目目录下的任务能归到同一个项目 ID。比对账单后台或账号页面里的用量看数字是否在一个合理范围内。批量验证时最容易出现的是“用户属性丢失”。有时候你在本地明明能看到 user_id但经过 Collector 转发后属性被过滤了。这往往不是 Claude Code 的问题而是 Collector 处理器中 drop 或 filter 规则把 span 属性干掉了。遇到这种情况先进 Collector 的 debug exporter看原始 span 到底带了哪些属性。4. 仪表盘上哪些指标值得做哪些要小心4.1 成本指标和费用口径一个成本仪表盘如果只有“总费用”一个数价值很低。我建议至少维护三类指标。第一类用量指标。包括输入 token 数、输出 token 数、每次调用的 token 总量、请求次数。这些是基础所有成本计算都从它们推导。第二类成本指标。这里要特别注意“模型单价”的来源。OTel 数据里通常包含 token 数量但单价往往需要在 Aimeterly 配置层维护一份模型价格表。不同模型、不同时段、不同账号套餐单价可能不一样。如果价格表错了仪表盘上的预估成本就是错的。建议把成本计算拆成两个层级原始用量层保存所有 trace、span、usage 字段不做价格换算。成本视图层按天、按用户、按项目聚合再把 token 用量乘上模型单价得出预估成本。这样即使价格调整也不需要重新处理历史原始数据只要重建成本视图即可。第三类效率指标。例如“每次成功调用平均消耗多少 token”“输出 token 占比”“失败重试消耗了多少 token”。这类指标能帮你发现一个用户是不是反复触发长输出、或者同一个请求因为失败被重试了很多次。表格里展示常见指标和它的业务含义大概是这样指标计算方式业务含义输入 token 总量所有成功调用的输入 token 求和代码上下文、提示词消耗规模输出 token 总量所有成功调用的输出 token 求和生成结果规模对成本影响更大单次调用平均成本总成本 / 调用次数单次交互的消耗水平用户成本占比用户成本 / 总成本成本分布找出用量大户失败重试损耗失败请求的 token 消耗之和配置问题或系统波动造成的浪费项目成本项目维度聚合按业务线核算成本4.2 覆盖率、归因和权限边界成本仪表盘最容易踩的坑是覆盖率。你看到的数字可能只是“能采集到的部分”而不是“实际发生的全部”。Claude Code 在某些情况下可能不发送 OTel 数据。例如网络中断、OTLP 端点不可用、用户手动关闭了遥测、某些命令模式不产生 span。如果一个用户长期处于离线环境他的成本就可能完全不出现在仪表盘里。不要默认“Aimeterly 显示的总成本 账单总额”。你需要在页面上留一个“数据覆盖率”或“采集失败率”指标或者在接入文档里明确说明这个仪表盘是近似估算。归因也容易出问题。用户属性来自哪一层如果 Aimeterly 只能拿到进程启动时的系统用户名那么多个用户共用一台开发机时成本会被错误地归到同一人。正确做法是尽量从 Claude Code 会话、登录账号、环境变量里读取用户标识而不是依赖操作系统用户。权限边界也要提前设计。既然是 per-user 成本仪表盘就会涉及个人使用细节。如果公司没有全员公开预算的习惯页面需要支持按角色控制可见范围。比如普通成员只看自己的成本团队负责人看整个小组管理员看全量。如果不能做权限控制至少要把导出和分享链接控制住不要让人无意间把全团队的成本明细贴在公开群聊里。5. 常见坑和排查顺序5.1 看不到数据时先按什么顺序查Aimeterly 仪表盘一片空白时很多人第一反应是“工具坏了”。我通常不会直接怀疑核心工具而是按下面顺序一层层排掉先确认 Claude Code 侧有没有真的产生 OTel 请求。可以看 Claude Code 日志里有没有输出 exporter 相关的错误或者在 Collector 端观察是否收到 OTLP 请求。这一步能快速区分“没发出”和“发了但没收到”。再看网络连通。Claude Code 到 CollectorCollector 到 Aimeterly两个网段都必须通。认证 headers 不对、证书过期、端口没监听都会导致请求失败。排除时可以直接用 curl 模拟发一个 OTLP 请求比反复重启 Claude Code 快得多。再看 Collector 配置。确认 pipeline 里 traces、metrics 都配了对应的 receiver 和 exporter。有时候 traces 能过来metrics 没过来是因为 pipeline 里写漏了。再看 Aimeterly 是否支持对应接口。如果它只接收某个特定端口或特定格式请你按它的 README 调整而不是在 Collector 里猜。最后才检查数据处理逻辑。比如 Aimeterly 里有没有按用户过滤、有没有按日期过滤、是否覆盖了今天的数据。排查时不要同时改多个变量。一次只改一处然后重放一次 Claude Code 调用看数据有没有进来。这个习惯能省很多时间。5.2 成本数字偏大偏小的几个原因成本数字对不上是第二个高频问题。如果仪表盘成本明显偏小先查覆盖率。可能有一批用户没走 OTel 导出或者 Collector 对某些 span 做了采样。OTel 链路默认可能采样如果你的 Collector 里配了采样策略只保留 10% 的 trace那成本仪表盘自然只剩 10%。成本统计不应该按 trace 采样率推导除非你显式接入采样率补偿逻辑。如果成本偏大可能原因包括模型单价配置错误、某些重试请求被重复计数、或者把非 Claude Code 的 OTLP 数据也汇总了进来。遇到这种情况可以在 Aimeterly 里增加一个属性过滤只统计 service.name 为 claude-code 的 span。另外token 用量口径也要统一。有的平台按“输入 token 输出 token”展示有的展示“总 token”。如果 Aimeterly 的成本计算模型只乘了输出 token而账单统计的是总 token那数字也会对不上。我一般会建议团队在落地第一周做一次人工抽检拿三个用户的成本明细和账号后台的实际用量逐一对比。如果差异在 10% 以内说明口径基本合理如果差异很大不要急着调单价先把采集覆盖率和重复计数排查干净。6. 生产落地建议6.1 先实验后推广Aimeterly 这种新工具我不建议第一天就全团队强制接入。更合理的路径是先用一个测试项目或少量用户部署一条最小链路跑一周。验证 OTel 采集的稳定性哪天突然没数据了能不能及时发现。验证成本估算的准确性是否和账单大体一致。验证用户体验会不会因为要配置环境变量、启动额外服务影响开发者日常工作。再逐步把更多用户、更多项目接进来。推广时最容易遇到的阻力是“又要配环境变量”或者“我的终端多了个后台服务”。如果你能做成一个团队级配置模板让大家拉下来就能用而不是要求每个人手动导出各种环境变量推广会顺很多。新版本 Claude Code 更新时建议先在一台测试机器上验证 OTel 导出没有被破坏再让全员更新。可观测性链路最怕的就是“客户端升级后不再发数据但没人发现”。6.2 长期运行要关注的资源、保留周期和团队协作长期运行时Aimeterly 的数据量会涨得很快。几十个人每天跑几百次调用一个月下来的 span 数量可达几十万甚至上百万。你需要提前关注存储原始 OTel span 是否要全量保留如果只关心成本可以定期聚合只保留明细 30 天历史数据转成天级聚合。查询性能仪表盘查询如果按用户、项目、时间过滤后面的存储和索引是否能撑住。资源占用Collector 和 Aimeterly 服务占多少内存、CPU是否适合放在你现有的服务器上。备份成本数据会计入预算和分摊如果纯靠工具内页面积累没有导出机制后续换工具会很痛苦。建议每天做一次日终聚合生成一个user_project_daily_cost表或指标集合。即使原始 span 被删掉历史成本趋势仍然能保留下来。6.3 什么时候不需要自建什么时候该自建如果你们团队只有两三个人每月账单一眼能看完完全不需要 Aimeterly 这种仪表盘。直接定期导出账单给财务就行。这个工具的价值来自团队规模和成本可见性需求人少的时候管理成本比实际成本还高。但如果满足下面任意一条自建或引入这类 OTel 成本仪表盘就是值得的团队超过 5 人且都在高频使用 Claude Code。公司需要按项目或业务线回填研发费用。你想设置预算上限但缺少可信的数据支撑。你发现有人用量异常却无法定位是谁、在哪类任务上消耗。你想对比不同模型方案的成本差异为选型找依据。最后再说一句Aimeterly 本身是不是已经做到生产级、是否完全支持 Claude Code 当前版本我无法替你验证。你真正该做的是拿最小样例跑一遍确认 OTel 数据能出来、能看到用户标识、成本估算能对上账单。这条链路通了工具叫什么名字反而不重要你已经拥有了一套可以解释 AI 编码助手成本的基础设施。