现在不少团队已经把 Claude Code 当成日常编码工具来用了代码审查、重构、写测试、跑脚本都能交给它。但一个很现实的问题随之而来整个团队共用一套 Claude 账号或 API Key月底对账的时候根本分不清每个成员到底花了多少钱。传统做法是让开发自己截图上报既不准确又难核验。这次我们看到一个很有意思的 Show HN 项目叫Aimeterly它的思路很直接不用额外埋点直接读取 Claude Code 内置的 OpenTelemetryOTel数据生成按用户维度统计的成本仪表盘。项目定位一句话就能说清楚Aimeterly 是一个从 Claude Code 内置 OTel 数据中提取用量并按用户维度展示 AI 编码成本的仪表盘工具。它解决的痛点是“钱花在哪个人身上、哪个项目上、哪个模型上”。从 Show HN 里的信息看它强调几个点利用 Claude Code 自带的 OTel 能力、按用户统计、以仪表盘方式呈现。这意味着接入方基本不需要改动 Claude Code 本身只要把 OTel 数据导出来剩下的聚合、计算、展示交给 Aimeterly 处理。这个项目不需要 GPU不需要本地大模型也不涉及传统意义上的“推理性能”。它更接近开发者工具链里的可观测性与成本分析组件。如果你正在用 Claude Code并且团队成员多于 3 人或者你们正在评估 AI 编程工具的投入产出比这篇文章可以直接收藏。下面我会从核心能力、适用场景、OTel 前置知识、部署思路、验证流程、API 集成、常见问题几个角度完整拆解。1. 核心能力速览能力项说明项目类型Claude Code 成本可观测性 / 用量仪表盘工具数据来源Claude Code 内置的 OpenTelemetryOTel追踪数据核心功能按用户、按时间、按模型维度统计 AI 编码费用硬件需求无需 GPU普通 CPU 服务器 / 本地开发机即可依赖环境需已部署 Claude Code 并开启 OTel 导出Aimeterly 自身环境以 README 为准启动方式从项目定位看属于服务型应用需启动后端并访问 Web 仪表盘是否支持 API大概率提供查询接口具体端点需看项目文档是否支持批量任务成本数据的批量聚合是核心场景支持按时间段批量统计适合场景团队成本分摊、AI 编码花费审计、模型用量趋势分析当前状态Show HN 展示项目建议验证后用于测试环境这里要先说清楚一个边界Aimeterly 不负责“限流”、不负责“拦截请求”它是事后分析工具。它告诉你的是一段时间内每个用户消耗了多少 token、估算花了多少钱而不是在你费用超标时直接切断调用。这个定位决定了它适合成本核算与趋势分析不适合做实时预算阀门。2. 适用场景与使用边界2.1 适合谁从产品逻辑看Aimeterly 主要面向这几类用户小团队管理者团队用同一套 Claude Code 账号需要知道谁在用、用了多少、花在哪里。研发效能/基础设施团队负责 AI 工具引入的评估和成本控制需要可量化的数据。预算敏感的自由开发者自己跑多个项目想区分每个项目的 AI 花费。自动化审计场景把成本数据按天/按周导出对接内部财务或监控系统。它的典型价值是把“凭感觉估算”变成“有数据可查”。团队管理员不用再一个个问成员“这个月你跑了多少任务”直接在仪表盘上筛选用户、时间段、模型类型就能看到聚合结果。2.2 不适合什么场景实时计费系统如果业务要求精确到单次请求的实时扣费Aimeterly 的工具属性可能不够更适合用 API 网关级别的计量方案。尚未启用 OTel 的 Claude Code 环境Claude Code 没有输出 OTel 数据时Aimeterly 拿不到输入数据这个前提必须先满足。对数据极度敏感的内部环境OTel 追踪数据会包含 session、模型调用细节如果团队不允许这类数据离开本地或进入第三方服务需要考虑自托管方案并确认数据链路。2.3 合规与安全边界这里要特别提醒三点第一成本数据虽然不属于核心业务数据但它是内部运营信息。仪表盘如果部署在公网必须加访问控制避免未授权访问。第二如果 Claude Code 的 OTel 追踪数据里包含代码片段、文件路径、prompt 信息这些内容可能涉及商业机密或个人数据。接入 Aimeterly 前要确认数据会被存储在哪里是否需要脱敏。第三费用信息要与官方账单核对以官方计费为准。Aimeterly 这种工具对费用是“根据 token 数和模型单价估算”只能作为参考不能替代官方账单。涉及财务入账时最终依据必须是 Claude 官方消费记录。3. OpenTelemetry 前置知识Claude Code 的 OTel 数据从哪来在部署 Aimeterly 之前先理解它的数据底座。Claude Code 本身是一个 AI 编码代理运行在和模型交互的会话中。为了支持可观测性它内置了 OpenTelemetry 追踪能力。简单说Claude Code 在每次模型调用、工具调用时会产生 trace 和 span这些结构化的日志里包含请求耗时、模型名称、token 使用量等信息。OpenTelemetry 是一个开源的可观测性标准框架通常包含三个部分Trace追踪记录一次请求从开始到结束的完整链路。Span跨度一次请求中的一个环节比如“调用 Claude 模型”“执行工具”。Exporter导出器把 trace 数据发送到指定后端常见协议是 OTLP。Aimeterly 做的事就是接收这些 OTel 数据解析出每次会话的模型信息和 token 数再根据模型单价换算成费用最后按用户维度聚合展示。从项目名称和 Show HN 描述看它很可能是通过 OTLP 端口接收 Claude Code 推送的数据或者读取本地导出的 trace 文件具体接入方式以项目 README 为准。这里的核心收益在于你不需要在 Claude Code 里安装任何额外插件也不需要改代码。Claude Code 本身就支持 OTel只要把导出端点配置好数据就会送到 Aimeterly 或 OTel Collector。这个“零埋点”的设计让接入成本大大降低。4. 环境准备与前置条件4.1 基础环境检查清单这部分按照“通用验证流程”来准备具体版本以实际项目文档为准。检查项建议Claude Code 已安装确认claude --version能正常输出Claude Code 可正常发起会话能完成一次简单对话确认账号权限正常OTel 导出能力确认 Claude Code 运行日志或文档中包含 telemetry 配置Aimeterly 运行环境Node.js 18 或 Python 3.10以项目 README 为准数据存储建议准备 SQLite本地测试或 PostgreSQL团队使用端口占用确认 OTLP 接收端口和仪表盘端口未被占用4.2 Claude Code 安装确认虽然 Claude Code 已经比较普及但为了不打断部署流程这里列一下常见的安装方式# 通过 npm 全局安装 npm install -g anthropic-ai/claude-code # 验证版本 claude --version如果你是第一次使用还需要完成账号登录授权。后面的步骤建立在“Claude Code 能正常运行”这个前提上。如果连基本会话都跑不通先解决 Claude Code 本身的登录、网络、订阅权限问题再继续配置 OTel。4.3 OTel 导出的常见配置思路为了让 Claude Code 把追踪数据发送出去通常会设置环境变量指定 OTLP 端点。下面是一个通用示例# 方式一通过环境变量指定 OTLP 端点 export OTEL_EXPORTER_OTLP_ENDPOINThttp://127.0.0.1:4317 export OTEL_SERVICE_NAMEclaude-code-local # 是否启用 trace按实际项目说明配置 export OTEL_TRACES_EXPORTERotlp另一种思路是使用 OTel Collector 作为中转# Collector 接收 Claude Code 的 trace再统一转发给 Aimeterly otelcol-contrib --config ./otel-collector-config.yaml# otel-collector-config.yaml 通用示例 receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 http: endpoint: 0.0.0.0:4318 exporters: otlp: endpoint: http://127.0.0.1:5555 service: pipelines: traces: receivers: [otlp] exporters: [otlp]这里需要注意Claude Code 的 OTel 具体支持哪些环境变量、导出格式、字段含义要以官方文档和 Aimeterly 项目 README 为准。上面的配置是 OTel 生态的通用模板目的是帮助你理解链路不要照抄后直接部署请先确认项目要求的字段名和端口。5. 安装部署与启动方式5.1 下载 Aimeterly先获取项目源码git clone Aimeterly 仓库地址 cd aimeterly如果项目发布到了 npm 或 PyPI也可以直接通过包管理器安装。以 npm 为例项目可能提供这样的启动入口# 示意命令实际以 package.json scripts 为准 npm install npm run build npm start如果项目是基于 Python 的则可能类似pip install -r requirements.txt python -m aimeterly --config config.yaml这些命令只是常见形态请不要当成 Aimeterly 的真实启动命令。正确做法是clone 后先看 README、Makefile、package.json 或 pyproject.toml找到官方推荐的启动方式。5.2 启动服务启动后Aimeterly 一般会做三件事启动 OTLP 接收端点等待 Claude Code 推送 trace。解析 trace 中的用户信息、模型信息、token 用量。启动 Web 仪表盘提供费用查询页面。# 通用启动命令示例实际请根据项目 README 调整 npm run dev启动成功后终端通常会出现“listening on”之类的输出标记 Web 仪表盘地址和 OTLP 接收地址。常见端口可能是 8080、3000 或 4318实际以日志为准。5.3 接入 Claude Code服务启动后需要让 Claude Code 把数据送到 Aimeterly。如果你已经在环境变量里设置了OTEL_EXPORTER_OTLP_ENDPOINT那么 Claude Code 启动时会自动向该端点推送 trace。验证方式很简单保持 Aimeterly 运行。打开一个新的终端。执行claude并发起一次会话比如让它写一个 Python 冒泡排序函数。观察 Aimeterly 终端日志是否出现新的 trace 接收记录。如果出现“trace received”“span processed”类似输出说明链路已经打通。5.4 避免端口冲突端口冲突是最常见的问题。如果 4317 或仪表盘端口被占用可以选择# 在启动命令中指定新端口示例 npm start -- --port 8081或者在配置文件里修改端口然后重启服务。判断端口是否被占用# Linux / macOS lsof -i :4317 # Windows PowerShell netstat -ano | findstr 43176. 功能测试与效果验证部署完成后重点看 Aimeterly 是否正确按用户维度统计成本。下面是一套可执行的验证流程。6.1 测试 1单用户单次会话测试目的确认基础链路是否打通。操作步骤启动 Aimeterly确认 OTLP 接收端在监听。配置 Claude Code 指向 Aimeterly 的 OTLP 端点。在 Claude Code 中发起一次任务例如“帮我写一个 Fibonacci 算法并解释复杂度”。等待任务结束。打开 Aimeterly Web 仪表盘查看最新记录。预期结果仪表盘中出现一条或多条会话记录。记录包含用户标识、模型名称、输入 token 数、输出 token 数。系统根据 token 数计算出一个估算费用。判断标准这条记录的 token 数应该和 Claude Code 会话中显示的 token 用量基本吻合。如果完全对不上说明解析逻辑可能有问题或者拿到的是采样数据。6.2 测试 2多用户多会话聚合测试目的验证“按用户维度统计”的核心能力。操作步骤在终端 A以用户 user1 身份运行 Claude Code执行 2 个任务。在终端 B以用户 user2 身份运行 Claude Code执行 1 个任务。在 Aimeterly 仪表盘按用户维度筛选。预期结果user1 下有 2 次会话的费用总和。user2 下有 1 次会话的费用总和。两个用户的数据互不混淆。判断标准仪表盘能正确区分不同用户并且合计数与各用户之和一致。如果用户信息丢失或全部落在“unknown”用户下优先检查 Claude Code 是否正确传入了 user 属性。6.3 测试 3时间范围筛选测试目的验证成本分析的实用性。操作步骤在 Aimeterly 仪表盘选择“今日”“近 7 天”“本月”等时间范围。对比不同时间段的费用数据。预期结果时间范围切换后聚合数据只包含对应时间段的 trace。判断标准数据边界正确没有把昨天或上周的数据算进“今日”。如果时间不准检查系统时区和 trace 时间戳。6.4 测试 4模型维度拆分测试目的验证能不能看到不同模型的费用分布。操作步骤在仪表盘看是否有按模型如 sonnet、opus 等分组的数据视图。预期结果可以区分不同模型产生的费用。判断标准如果 Claude Code 内置 OTel 的 span 属性里包含模型名称Aimeterly 应该可以解析出来。没有模型维度时至少应该保留原始 span 日志供排查。6.5 常见失败原因现象可能原因排查重点仪表盘没有任何数据OTel 端点未联通查看 Claude Code 启动日志、Aimeterly 接收日志数据有但用户都是 unknown用户属性未传递检查 trace 中的 user 字段token 数与会话显示不一致采样或聚合逻辑不同对比单条 span 的 token 值费用估算明显偏高/偏低单价配置不对检查模型单价配置数据延迟很大接收端点积压检查 OTLP 接收频率和数据库写入速度7. 接口 API 与批量任务成本仪表盘如果只停留在页面上价值会大打折扣。Aimeterly 这类工具通常会提供查询接口方便你把它接到自己的报表系统、企业微信机器人、Slack 通知或内部财务平台上。下面给出一个通用 API 调用模板实际路径和参数请以 Aimeterly 文档为准。7.1 通用查询接口一个典型的“按用户查询费用”接口可能长这样curl -X GET http://127.0.0.1:8080/api/v1/costs/by-user \ -H Authorization: Bearer your_token \ -G \ --data-urlencode from2025-01-01 \ --data-urlencode to2025-01-07返回结果可能是 JSON 数组[ { user: user1, model: claude-sonnet-4-20250514, input_tokens: 123456, output_tokens: 23456, estimated_cost_usd: 3.72, session_count: 18 } ]7.2 Python 调用示例如果你想把成本数据定期拉到自己的系统里Python 脚本是比较方便的方式import requests API_BASE http://127.0.0.1:8080/api/v1 TOKEN your_token headers { Authorization: fBearer {TOKEN} } params { from: 2025-06-01, to: 2025-06-30 } resp requests.get(f{API_BASE}/costs/by-user, headersheaders, paramsparams, timeout30) resp.raise_for_status() data resp.json() for row in data: print(f用户: {row[user]}, 模型: {row[model]}, 费用: ${row[estimated_cost_usd]})7.3 批量任务与定时汇总批量成本汇总大多数情况下不需要实时可以按天/按周跑一次。推荐用 cron 或者系统定时任务实现# 每天凌晨 2 点拉取昨天数据并追加到成本汇总表 30 2 * * * cd /opt/scripts python daily_cost_report.py /var/log/aimeterly-report.log 21# daily_cost_report.py 骨架 import requests from datetime import date, timedelta yesterday date.today() - timedelta(days1) url http://127.0.0.1:8080/api/v1/costs/by-user params { from: yesterday.isoformat(), to: yesterday.isoformat(), } # 拉到数据后写入数据库或发送通知这里要特别提醒批量任务一定要设计失败重试和日志输出。一旦 Aimeterly 服务重启或者数据库暂时不可用定时任务应该能自动跳过本次并记录错误而不是静默失败。7.4 接口安全Aimeterly 如果暴露在局域网或公网API 必须做鉴权启用 Token 或者 Basic Auth。使用反向代理如 Nginx统一管理 TSL 和访问控制。对/api路径做 IP 白名单限制。避免把成本数据接口暴露到无需鉴权的公网地址。8. 资源占用与性能观察Aimeterly 不是 AI 推理服务所以这里不用讨论显存占用和 GPU。它更关注的是数据接收吞吐量、存储空间和查询性能。8.1 观察指标指标观察方法常见影响因素接收吞吐量查看 OTLP 接收端点的日志速率团队使用频次、并发会话数数据库增长查看数据目录或数据库文件大小trace 保留周期查询响应时间仪表盘切换时间范围时的耗时trace 总量、索引设计内存占用htop、任务管理器接收缓冲区、聚合计算任务如果团队人不多比如 5 人以内Aimeterly 的资源占用基本可以忽略普通 2 核 4G 的服务器就足够。如果团队规模几十人并发 trace 量大建议关注数据库性能必要时做定时清理。8.2 采样与保留策略OTel 数据如果长期全量保存存储量和查询速度都会变差。建议从接入第一天就确定保留策略原始 trace仅保留 7 到 30 天。聚合结果按天聚合的用户费用数据可以长期保留。采样如果数据量特别大可以只保存一定比例 trace但需要知道采样会降低费用估算精度。8.3 降低开销的通用思路就像前面提到的成本统计是趋势分析工具不需要对所有 trace 做实时校验。可以用“先接入 → 观察一周 → 再决定采样率”的路径逐步优化。9. 常见问题与排查方法问题现象可能原因排查方式解决方案仪表盘没有数据Claude Code 未正确配置 OTel 导出检查 Claude Code 环境变量和启动日志确认 OTLP 端点可达重新启动 Claude Code数据全部落在 unknown 用户Claude Code 未传递用户属性查看原始 trace 中的 user 字段在 Claude Code 侧配置用户标识或在 Aimeterly 映射规则中补充费用估算与官方账单不一致模型单价配置或 token 统计口径不同对比一次会话的 token 数和费用明细切换为官方计价参数或使用官方账单为准API 调用返回 401无鉴权 Token 或 Token 失效检查请求头重新生成 Token仪表盘页面打不开端口被占用或服务未启动查看进程与端口更换端口或重启服务定时批量任务没有输出cron 脚本路径错误或 Python 环境变量缺失手动执行脚本看报错使用绝对路径补充环境变量trace 数据延迟高OTel Collector 积压查看 Collector 日志增加队列长度或调高导出并发数据库增长过快trace 保留时间过长查看数据量设置定时清理或聚合降采样用户看到别人的费用仪表盘无权限隔离检查前端鉴权与接口鉴权按用户/角色做数据行级权限控制9.1 排查原则遇到问题先按链路分段排查Claude Code 有没有产生 trace—— 看 Claude Code 日志和终端输出。trace 有没有到达 Aimeterly—— 看 Aimeterly 接收日志、端口连通性。Aimeterly 有没有正确解析—— 看数据库里有没有新增记录。前端有没有展示—— 看 Web 仪表盘接口返回。按照“源头 → 传输 → 存储 → 展示”的顺序定位通常几分钟就能找到问题。10. 最佳实践与使用建议10.1 先小范围跑通再推广建议不要第一天就全团队接入。先自己一个人用一周验证数据质量和费用口径是否准确。重点确认OTel 数据能否稳定送达。用户维度是否准确。费用估算和官方账单的偏差在可接受范围内。10.2 保留最小可运行配置把 Claude Code 的 OTel 环境变量、Aimeterly 的启动命令、数据库连接串整理成一份可复现的配置文件放到团队内部文档里。这样新成员加入时按步骤执行即可不用再猜。# 最小环境变量示例 export OTEL_EXPORTER_OTLP_ENDPOINThttp://127.0.0.1:4317 export OTEL_SERVICE_NAMEclaude-code-team10.3 目录与数据管理建议把 Aimeterly 的数据目录、日志目录、配置文件分开存放/opt/aimeterly/ ├── config/ │ └── config.yaml ├── data/ │ └── aimeterly.db ├── logs/ │ └── aimeterly.log └── bin/ └── start.sh10.4 每月账单核对成本估算工具不能替代官方账单。建议每月把 Aimeterly 统计的总费用与 Claude 官方账单核对一次。如果偏差持续大于 5%检查模型单价配置是否过期或者 trace 采样比例是否调低了。10.5 隐私与权限控制如果团队有严格的权限管理要求仪表盘不要做“所有用户可见”的匿名访问。普通成员只能看自己的用量管理员看全量。导出报表时对敏感字段做脱敏。如果收到安全审计要求提前确认 OTel 追踪数据中是否包含代码内容。11. 总结与下一步Aimeterly 这类工具的价值不在于它有多复杂的算法而在于它把 Claude Code 已有的 OTel 数据变成了管理层能看懂的成本报表。对于正在推进 AI 编程工具落地的团队来说它补上了“账单分摊”这一环不需要逐个问成员“你用了多少”打开仪表盘就能看到 user、时间、模型、费用四个维度。最值得先验证的功能是单用户单会话能否正确计入仪表盘。只要这一条能跑通后续的多用户聚合、按天汇总、API 集成都是水到渠成。最容易踩的坑有两个一个是 OTel 端点配置不通另一个是用户属性没有正确传递导致数据全部落在 unknown。如果你所在的团队正好在苦恼“AI 编程工具费用分不清”可以按上面的流程在自己环境里试一遍。后续还可以考虑把 Aimeterly 的 API 接到成本报表、企业微信机器人或者夜间预算检查任务里让 AI 编程成本从“黑盒”变成“可审计的日常数据”。建议先收藏等团队把 Claude Code 用量跑起来后再对照着部署。