这次我们来看一个比较有意思的开源工具Aimeterly。它本身不生成代码也不直接跑模型解决的问题非常具体——Claude Code 用起来很爽但费用到底花在哪、每个用户消耗了多少 token、哪些项目最烧钱很多人是说不清楚的。Aimeterly 的思路是直接吃掉 Claude Code 内置的 OpenTelemetryOTel遥测数据把模型调用、token 消耗、用户信息这些零散字段聚合起来变成一个按用户维度展示的成本仪表盘。从项目命名和定位来看Aimeterly 最值得关注的几个点可以先列出来第一它依赖 Claude Code 内置 OTel 能力不需要改 Claude Code 源码第二它做的是 per-user 成本统计也就是按人头拆账天然适合团队多人协作场景第三它大概率会提供一个 Web Dashboard 和查询接口方便把成本数据接到自己的内部系统里。当然由于项目刚发布具体功能边界、支持的数据库类型、安装方式都要以实际仓库文档为准本文会给出一个可以照着跑的通用流程。这篇文章会带你把整个链路走通先解释 Claude Code 内置 OTel 的数据长什么样Aimeterly 怎么接收和解析然后完成环境准备、安装部署、启动验证接着按功能测试的方式确认 OTel 数据链路、用户维度聚合、成本计算和接口查询都能工作最后给出资源占用观察方法、常见问题排查清单和工程化使用建议。如果你正在用 Claude Code 写代码或者你负责一个团队的 Claude Code 费用管理这篇文章可以直接收藏。1. 核心能力速览先给一份规格表快速判断 Aimeterly 是否符合你的场景。需要说明的是项目当前资料不多表格里带有“按项目文档确认”字样的部分是建议你实际部署时重点核对的地方。能力项说明项目类型基于 Claude Code 内置 OTel 数据的成本可视化工具解决的核心问题按用户、按会话、按模型维度统计 Claude Code 的 token 消耗和估算成本数据来源Claude Code 内置 OpenTelemetry 导出数据主要功能OTel 数据接收、解析存储、成本聚合、Web Dashboard、查询接口推荐部署方式本地单机部署或容器部署依赖环境Python 或 Node.js具体技术栈以项目文档为准数据库小规模可用 SQLite 起步多人规模建议 PostgreSQL/ClickHouse 等时序存储是否支持 API从项目定位看大概率有成本查询接口具体路径按文档确认是否支持批量任务不直接执行 Claude Code 批量任务但会持续采集批量调用产生的 OTel 数据适合场景个人 token 消耗分析、团队成本分摊、模型成本对比、自动化成本报表不适合场景实时计费系统、跨编程工具统一成本管理、不产生 OTel 数据的场景2. 适用场景与使用边界2.1 适合谁Aimeterly 最适合的是三类人。第一类是 Claude Code 的重度个人用户。每天几十上百次调用订阅套餐或者按量付费月底看账单只知道自己花了钱不知道钱花在哪些会话、哪些模型上。Aimeterly 能把长尾消耗拉平让你看到单次调用成本分布。第二类是团队技术负责人或开发经理。多人同时用 Claude Code 写代码成本是合并结算的。想要按成员拆分预算、做成本分摊就需要一个 per-user 的视图Aimeterly 正好覆盖这个需求。第三类是做 AI 工具集成或内部平台的人。团队里有内部工具想让 Claude Code 成本数据进入公司已有的监控系统或报表平台Aimeterly 的接口能力可以用来搭桥。2.2 能解决什么问题这个工具解决的是从“混沌花费”到“可观测花费”的问题。Claude Code 每次调用模型OTel 遥测数据里会携带模型名称、输入 token、输出 token、缓存命中 token、用户标识等字段。Aimeterly 把这些数据接收下来按用户、按时间、按模型聚合再套用模型单价计算出估算成本。这样做的好处是成本数据不需要手动记录Claude Code 自动就会吐出来Aimeterly 只是负责接收和加工。2.3 不能解决什么Aimeterly 不是实时计费系统。OTel 导出、数据入库、页面展示之间存在延迟如果团队需要精确到秒的计费它不合适。它也不负责告诉你“怎么省钱”。它呈现的是成本结构和趋势优化提示词、切换模型、压缩上下文这些动作还是要人来决定。它更不是跨平台工具。如果团队同时用 Claude Code、其他命令行编程工具或者其他商业产品Aimeterly 只能覆盖 Claude Code 生成的那部分数据。2.4 合规与安全边界使用 Aimeterly 过程中需要特别留意隐私和数据边界。Claude Code 生成的 OTel 数据里可能包含代码片段摘要、文件路径、用户身份、提示词内容等敏感信息。在多人团队部署时这些数据会落到 Aimeterly 的存储里。如果公司对代码内容外发有严格要求部署前必须跟安全团队确认数据存储在哪里、谁能访问、是否需要脱敏。另外按用户维度统计成本本质上是在跟踪成员行为。这个动作在部分国家或地区可能涉及员工数据保护规定。上线前要确保有明确的内部授权和管理制度。还有一个非常实际的提醒如果项目中涉及他人声音克隆、人脸图片、版权代码或隐私文档请务必确认合法授权后再使用任何 AI 工具处理。3. Claude Code 内置 OTel 与 Aimeterly 的采集思路3.1 Claude Code 和 OTel 是什么关系OpenTelemetry 是当前主流的可观测性标准包含 Trace、Metric、Log 三类信号。Claude Code 内置 OTel 支持意味着它可以把一次模型调用记录成一条 TraceTrace 里带有多个 Span每个 Span 记录关键操作和属性字段。通常来说一次 Claude Code 的模型调用会产生类似下面的字段模型名称比如 Claude 系列模型的具体版本token 用量包括输入 token、输出 token、缓存读取 token、缓存写入 token用户标识可能是登录用户、项目路径、或者自定义属性时间戳与会话 ID调用的目标 URL 或工具名。这些字段一旦导出就可以被任意兼容 OTLP 的服务接收。Aimeterly 做的就是那个“任意服务”。3.2 Aimeterly 怎么接收数据从 Kubernetes 生态和可观测性工具的常见实现来看Aimeterly 大概率是这样工作的它运行一个兼容 OTLP 的 HTTP/gRPC 接收端点Claude Code 通过环境变量或者配置文件把 OTel 数据发送到这个端点。Aimeterly 拿到数据后做字段解析把 Claude Code 自定义的属性映射成标准化的客户字段然后写入数据库。接下来通过定时任务或者实时聚合生成按用户、按天、按型号的成本汇总交给 Web Dashboard 展示。这里的核心设计点有两个。第一是 OTLP 接收端点的兼容性如果 Claude Code 用的是 OTLP/HTTP那么 Aimeterly 就必须监听对应的 HTTP 路径第二是成本计算依赖价格表Aimeterly 需要维护一套“模型版本 - 每百万 token 单价”的映射关系。3.3 关键环境变量配置Claude Code 的 OTel 导出配置以官方文档为准。常见做法是设置 OTLP endpoint 和必要的请求头让 Claude Code 知道数据往哪里发。# 通用示例具体变量名和取值以 Claude Code 官方 OTel 配置文档为准 export ANTHROPIC_OTLP_ENDPOINThttp://127.0.0.1:4318 export ANTHROPIC_OTLP_HEADERSAuthorizationBearer your-token如果 Aimeterly 和 Claude Code 在同一台机器上endpoint 通常指向本机端口。如果分开部署则指向 Aimeterly 所在服务器的 IP 和端口。更稳妥的判断是先把 Aimeterly 的接收端点启动起来再启动 Claude Code 执行一次简单对话观察 Aimeterly 那边是否收到了数据。这条链路通了后面所有统计才有意义。4. 本地部署环境准备Aimeterly 本身不依赖重型 GPU它是一个数据处理和可视化服务理论上普通开发机、2C4G 的小型云主机都能跑。下面给一套通用检查清单具体版本以项目文档为准。4.1 系统与运行环境操作系统Linux / macOS / WindowsWindows 建议用 WSL2 或 Docker 跑服务端Python 3.10或 Node.js 18取决于项目技术栈包管理工具pip 或 npm / yarnDocker 可选如果项目提供 compose 文件容器部署最省事数据库SQLite 起步如果团队规模较大建议提前准备 PostgreSQL 或 ClickHouse。4.2 Claude Code 环境部署 Aimeterly 前确保 Claude Code 已经安装并且至少跑通过一次对话。检查 Claude Code 是否可用的方式是在终端执行一个最简单的调用claude print hello如果 Claude Code 能正常返回说明账号、网络和模型权限都没问题。之后再做 OTel 导出配置才有意义。4.3 端口与资源规划Aimeterly 的 Web Dashboard 和 OTLP 接收端点通常占用两个端口。默认端口不确定建议部署时查看启动日志端口冲突了就改端口。# 查看端口占用以 4318 为例 lsof -i :4318 netstat -tlnp | grep 4318如果 4318 被占用要么停掉旧进程要么给 Aimeterly 换一个端口。4.4 依赖安装检查如果是 Python 项目安装依赖之前先确认 pip 可用python --version pip --version如果是 Node.js 项目node --version npm --version依赖安装失败的最常见原因是网络源不稳定。使用国内源可以提升成功率pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple5. 安装部署与启动方式5.1 从仓库拉取代码Aimeterly 的安装包形态可能是源码仓库也有可能是预构建镜像。下面按源码部署写一套通用流程实际命令以项目 README 为准。# 以源码方式部署的通用模板实际仓库地址以项目文档为准 git clone project-repo-url cd aimeterly5.2 安装依赖# Python 项目 python -m venv .venv source .venv/bin/activate pip install -r requirements.txt如果项目提供的是 Node.js 版本npm install5.3 配置文件通常需要一份配置文件指定数据库连接、OTLP 接收端口、监听地址和用户字段映射。下面是一个通用示例字段名需要按实际项目调整。server: host: 127.0.0.1 port: 8080 otlp: endpoint: 127.0.0.1:4318 database: type: sqlite path: ./data/aimeterly.db pricing: # 按模型版本配置每百万 token 单价 # 具体价格以官方价格页或项目文档表格为准 claude-model-a: input: 3.0 output: 15.0 cache_read: 0.5 cache_write: 3.0如果你只有项目代码没有参考配置就先从“没有价格表”的模式跑起来让 Aimeterly 先统计 token 量再往数据表里补单价。5.4 启动服务# 启动 Aimeterly 服务端具体命令按项目 README 调整 python main.py --config config.yaml启动后看日志确认 OTLP 接收端点和 Web Dashboard 都绑定成功。5.5 使用 Docker Compose 启动如果项目提供 docker-compose 文件这是最省心的方式version: 3.8 services: aimeterly: build: . ports: - 8080:8080 - 4318:4318 volumes: - ./data:/app/data restart: unless-stoppeddocker-compose up -d容器化部署的好处是依赖隔离、端口管理方便也不会污染本机 Python/Node 环境。缺点是需要额外占用一些磁盘和内存但对这种体量的工具来说可以忽略。6. 功能测试与效果验证部署完成后需要按功能分步验证。核心是验证四个链路OTel 数据能不能进来、用户维度能不能正确解析、成本能不能算出来、页面和接口能不能查询。6.1 链路一确认 OTel 数据到达 Aimeterly测试目的确认 Claude Code 确实把遥测数据发到了 Aimeterly。操作步骤确保 Aimeterly 服务端正在运行确认 Claude Code 的 OTel endpoint 指向 Aimeterly打开 Aimeterly 的日志输出在另一个终端执行一次最简单的 Claude Code 调用claude hello, reply in one sentence预期结果Aimeterly 日志中出现收到新数据的记录数据库表新增一条或几条 span/trace 记录。判断是否成功日志中能看到数据接收且数据库中有数据写入。常见失败原因OTel endpoint 地址写错Aimeterly 监听地址不是 0.0.0.0Claude Code 连不上防火墙或安全组拦截了 4318 端口。6.2 链路二验证用户维度解析测试目的确认 per-user 字段被正确解析和存储。操作步骤使用两个不同的 Claude Code 账号或用户身份各调用一次在 Aimeterly Dashboard 中查看用户列表检查两个用户是否被区分开。如果做过代码级调试可以更直接地在数据库里查sqlite3 ./data/aimeterly.db select user_id, model, sum(input_tokens), sum(output_tokens) from usage group by user_id;这个示例查询不一定完全匹配 Aimeterly 实际表结构但思路是对的按 user_id 聚合。判断是否成功至少出现两个不同的用户标识且数据归属正确。常见失败原因Claude Code 没有配置用户标识字段Aimeterly 的用户字段映射没对上多个调用使用了同一个默认用户。6.3 链路三成本计算验证测试目的确认 token 消耗能被单价换算成估算成本。操作步骤在配置文件或数据库里维护正确的模型单价表执行一次消耗量较大的 Claude Code 调用比如让 Claude 总结一篇长文档到 Dashboard 查看本次调用的估算成本。这里必须强调成本是估算值不是账单金额。Claude Code 的实际计费可能包含折扣、促销、订阅套餐抵扣等因素Aimeterly 算出来的是“按公开单价估算的参考成本”。判断是否成功能看到成本随 token 量增加而增加数值在合理范围。常见失败原因价格表为空所有成本都是 0模型版本和价格表里的 key 不一致缓存 token 和输入 token 的单价被混用。6.4 链路四Web Dashboard 查看效果测试目的确认可视化层可以正常渲染。操作步骤浏览器打开 Aimeterly Dashboard 地址例如 http://127.0.0.1:8080查看总消耗、用户排名、按天趋势三个基础视图切换时间范围确认图表跟随变化。预期结果页面能正常显示聚合后的 token 和成本数据。判断是否成功数据图表与数据库查询结果一致。常见失败原因Dashboard 端口和服务端口混淆浏览器缓存了旧页面数据库数据量太大聚合查询超时。7. 接口 API 与批量任务7.1 API 查询成本汇总从项目定位看Aimeterly 大概率提供 HTTP API 供外部查询成本数据。具体路径以项目文档为准这里给一个通用的查询模板。典型的接口大概长这样curl -X GET http://127.0.0.1:8080/api/v1/costs/summary?user_idalicestart_time2025-06-01end_time2025-06-30 \ -H Authorization: Bearer your-api-token返回 JSON 大概结构是{ user_id: alice, period: { start: 2025-06-01, end: 2025-06-30 }, total_cost_cents: 12345, total_tokens: 890000, breakdown_by_model: [ { model: claude-model-a, cost_cents: 10000, tokens: 700000 } ] }需要用 Python 脚本批量拉取时可以参考下面的模板注意按实际接口路径和鉴权方式调整。import requests API_BASE http://127.0.0.1:8080 TOKEN your-api-token def fetch_user_cost(user_id: str, start: str, end: str) - dict: url f{API_BASE}/api/v1/costs/summary headers {Authorization: fBearer {TOKEN}} params { user_id: user_id, start_time: start, end_time: end, } resp requests.get(url, headersheaders, paramsparams, timeout30) resp.raise_for_status() return resp.json() if __name__ __main__: data fetch_user_cost(alice, 2025-06-01, 2025-06-30) print(data[total_cost_cents], data[total_tokens])7.2 定时导出成本报表如果团队需要每周或每月发一次成本报表可以写一个定时任务调用 API把结果汇总成 CSV。# crontab 每周一早上 9 点导出上周成本 0 9 * * 1 cd /opt/aimeterly_scripts python export_weekly_cost.py导出脚本可以使用 pandas也可以直接写原生 CSV核心逻辑是先拉取全部用户列表再逐个查成本汇总。import csv import requests API_BASE http://127.0.0.1:8080 TOKEN your-api-token HEADERS {Authorization: fBearer {TOKEN}} users requests.get(f{API_BASE}/api/v1/users, headersHEADERS, timeout30).json() with open(weekly_cost_report.csv, w, newline) as f: writer csv.writer(f) writer.writerow([user_id, total_tokens, total_cost_cents]) for user in users: uid user[user_id] summary requests.get( f{API_BASE}/api/v1/costs/summary, headersHEADERS, params{user_id: uid, start_time: 2025-06-01, end_time: 2025-06-07}, timeout30, ).json() writer.writerow([uid, summary[total_tokens], summary[total_cost_cents]])对于定时任务建议加上日志和异常处理。数据拉取失败时把错误写入日志文件而不是让整个任务静默失败。7.3 批量任务与持续采集Aimeterly 不直接执行批量任务但它适合配合批量任务使用。比如你写了一个脚本循环调用 Claude Code 处理 100 个文件。每个调用都会产生 OTel 数据Aimeterly 会把这些数据持续采集进来。当批量任务跑完之后你可以在 Dashboard 上看这次批量任务的消耗并按文件维度拆解成本。为了做文件维度的拆分建议在调用 Claude Code 时把文件路径或任务名写入自定义属性。这样 Aimeterly 采集到的数据里就能保留这个字段后续查询成本时可以直接按任务维度拉取。8. 资源占用与性能观察8.1 本地部署资源占用Aimeterly 不是重计算服务正常情况下 CPU 和内存占用都不高。数据接收、写入数据库、页面查询是主要消耗点。推荐观察方式使用top或htop查看进程 CPU 和内存如果是 Docker 部署使用docker stats实时观察容器资源数据库文件或表的大小决定磁盘增长是否正常。docker stats aimeterly8.2 存储增长趋势Aimeterly 的存储增长和 Claude Code 调用量直接挂钩。单次调用产生的 OTel span 数量不大但长期高频使用后数据库体积会持续增长。更稳妥的做法是从第一天就规划数据保留策略。比如原始 span 数据保留 30 天聚合数据保留 12 个月。这样既能保证近期问题排查又不会让磁盘无限膨胀。8.3 影响性能的因素影响 Aimeterly 性能的主要有三个因素Claude Code 调用频率。多人同时高频调用OTLP 接收端点会成为瓶颈数据库类型。SQLite 在数据量达到几万条以后聚合查询会变慢此时建议切到 PostgreSQL 或 ClickHouseDashboard 时间范围。查询全量数据的时间跨度越大聚合越慢。如果发现查询变慢优先缩小时间范围再考虑加索引最后再迁移数据库。8.4 端口冲突与进程残留服务启动失败最常见的原因就是端口被占。修改端口后要同步修改 Claude Code 的 OTLP endpoint否则数据进不来。进程残留也会导致“改了配置但没生效”的假象。重启前先杀掉旧进程pkill -f main.py或者docker-compose down9. 常见问题与排查方法问题现象可能原因排查方式解决方案Aimeterly 收不到 Claude Code 数据OTel endpoint 配置错误或未配置查看 Claude Code 环境变量配置检查 Aimeterly 日志确认 endpoint 地址和端口检查监听地址是否为 0.0.0.0Dashboard 访问不了端口被占用或服务没启动检查启动日志查看监听端口换端口重启或用 netstat/lsof 确认绑定状态所有用户都显示为 defaultClaude Code 用户标识字段未配置查看数据库中的 user_id 字段值在 Claude Code 侧配置用户标识或调整 Aimeterly 字段映射成本全部为 0价格表为空或模型名不匹配查看数据库 price 表对比模型版本字段补全模型单价确认模型 key 和 Claude Code 输出值一致数据有延迟OTel 导出有间隔或聚合任务定时执行查看采集和聚合任务日志调整聚合频率或检查网络链路延迟磁盘增长过快没有数据保留策略检查数据库表数量和体积配置数据保留周期定期清理原始 spanAPI 返回 401Token 无效或 Header 错误对比 API 文档中的鉴权方式更新 API Token检查 Header 名批量任务跑完后没有数据Claude Code 异常退出OTel 没来得及导出查看任务日志确认每条调用是否正常返回增加错误重试确保进程正常结束9.1 Claude Code 本身的问题如果你最近才开始折腾 Claude Code可能遇到下面这些报错它们不是 Aimeterly 的问题但会直接影响数据链路问题现象常见原因排查方向Claude Code 安装失败Node.js 版本过低或网络安装源问题升级 Node.js切换 npm 镜像源“Claude Code process exited with code 3”运行时依赖缺失或启动异常查看完整日志定位是权限、模型还是网络问题组织订阅无法使用 Claude Code企业账号禁用或权限未开通联系组织管理员确认订阅策略不要绕行模型版本识别不了本地模型名配置错误或版本不匹配按官方文档确认模型名称检查模型来源合法性提示 “Claude Code might not be available in your country”账号区域限制联系官方客服确认可用范围这里不讨论任何绕过限制的方法遇到区域或权限限制最重要的是和官方渠道确认合法使用范围。9.2 从 Claude Code 到 Aimeterly 的链路自查如果 Aimeterly 始终收不到数据按顺序排查确认 Claude Code 能正常完成一次对话确认 Aimeterly 服务启动且 log 无异常确认 Claude Code 的 OTLP endpoint 指向 Aimeterly确认本机防火墙没拦截 OTLP 端口用 curl 直接往 OTLP 端点发一个最小 payload验证端点本身是否可用curl -X POST http://127.0.0.1:4318/v1/traces \ -H content-type: application/json \ -d {}返回 200 说明端点活着问题大概率在 Claude Code 配置侧。10. 最佳实践与使用建议10.1 第一次部署先最小化验证不要一上来就让整个团队切换到 Aimeterly。先在个人机器上跑通链路Aimeterly 启动、Claude Code 配置好 endpoint、跑一次对话、看数据是否入库。链路通了再考虑扩展到团队。10.2 保留一套最小可运行配置把“能跑起来”的配置单独存一份。比如 Docker Compose 文件、模型价格表、OTLP endpoint 配置放在同一个目录里。这样换机器、出问题时能快速恢复环境。10.3 用户标识必须规范化多人使用时用户标识如果不统一成本聚合就是一团乱麻。建议用公司邮箱前缀或统一身份系统的 ID 作为 user_id并在 Claude Code 侧配置固定值。避免出现同名用户、空用户、default 用户混在一起的情况。10.4 模型价格表要跟上版本更新Claude Code 使用的模型版本可能会随着订阅或模型升级而变化。一旦模型版本变了Aimeterly 价格表里的 key 对不上成本就会算成 0 或错误。建议在 Aimeterly 升级和 Claude Code 版本更新的时间点同步检查价格表。10.5 批量任务必须加日志和重试如果你是用 Claude Code 跑批量任务比如批量处理上百个文件要让每次调用都输出日志。任务失败时能确认是 Claude Code 本身失败还是 OTel 数据没导出。定时导出报表也同理脚本里要捕获异常写入日志文件。10.6 接口服务要限制访问范围Aimeterly 的 API 如果暴露在内网也要做访问控制。最低要求是设置 API Token不要裸奔。如果有条件只允许内网网段访问把 Dashboard 和 OTLP 接收端点都放到受控环境里。10.7 涉及数据和版权素材要谨慎如果 Claude Code 的使用场景涉及商业代码、客户数据、受版权保护的内容要把“是否允许进入遥测系统”作为一个正式问题评估。Aimeterly 采集到的 OTel 数据里可能含有片段必须控制在授权范围内。涉及人脸、声音、版权素材的 AI 处理更是要提前确认合法授权不能假设工具只是“统计一下”就没风险。11. 总结与下一步Aimeterly 最值得尝试的点在于它把 Claude Code 成本和用户维度打通了。只要 Claude Code 内置 OTel 数据能顺畅导出你就能获得一套按用户、按模型、按时间段拆分的成本视图。对个人用户来说它帮你搞清楚 token 到底花在哪对团队负责人来说它是成本分摊和预算监控的实用底座。最先应该验证的功能是 OTel 数据链路。这个链路通了后面的用户聚合、成本计算、接口报表都是水到渠成。最容易踩的坑有两个一个是 OTel endpoint 配置不对数据进不来另一个是模型价格表没配好成本算出来全是 0。把这两点解决掉Aimeterly 基本就能稳定工作了。后续可以继续扩展的方向包括把成本数据推送到企业微信、钉钉或 Slack定时生成周报月报和其他 AI 编程工具的成本数据合并把聚合结果接入 Prometheus 或 Grafana做长周期趋势分析。如果你已经跑通了 Aimeterly建议下一步做一次连续一周的完整采集。一周后回看数据你对 Claude Code 的使用习惯和成本分布会有一个非常直观的认知。