今天这两个工具能接成一条线。OpenRouter 把各家模型收成一个接口,Langfuse 把每次调用的 token 与成本记成可查明细。
选它们是因为账能算清:前者的抽成不在调用上,在充值上;后者的计费单位不是请求数,是三个计数相加。两个主角本期均未在你的账号部署或实测。
它替你把接模型收成一次配置。你只维护一个 base_url 和一份模型 slug,换模型不用换 SDK,也不用在十几个控制台各开一个 key。
省掉的动作很具体:上游某家机房抖动时,它在同一个请求里换 provider 重试,你的代码不用写重试分支。
全球统一美元标价,核验日期 2026-10-07。官方原话是推理不加价,只转发上游定价。
它稳定收的钱在充值环节:
| 项目 | 费率 | 说明 ||---|---|---|| 充值手续费 | 5.5%,最低 $0.80 | 按充值额收,不按调用收 || 加密货币充值 | 5% | USDC || 自带 key(BYOK)超额度后 | 5% | 按同模型同 provider 在 OpenRouter 上本应付的价计,从余额扣 || 推理本身 | 0% | 转发上游标价 |
免费额度要把 FAQ 与限速文档拼起来读:
:free 结尾,也有 openrouter/free 自动选免费模型的路由。新账号有一点免费额度可先试,但免费模型档不适合放进生产。坑逐条写:
limit 与 limit_reset,超了返回 402。只固定用一个模型、每月调用几百次,直接找官方开 key 更省事。
max_tokens 先预扣估算,并发多处就可能凑不满。没设 max_tokens 时按固定上限估,更容易被拒。error.metadata.limit_source 为 openrouter_in_flight_budget 就等 Retry-After 重试;为 openrouter_credits 是单个请求太贵,重试没用。finish_reason: "error" 送达,按 429 抓抓不到。https://openrouter.ai/api/v1,协议与 OpenAI 一致,model 传它的 slug,形如 openai/gpt-oss-20b。GET /api/v1/key 挂进监控。它返回 limit_remaining、usage_daily、byok_usage_monthly 与 free_model_daily_requests.remaining。:floor 按价格排序,:nitro 按吞吐排序,:exacto 按工具调用可靠性排序。
它替你把每次模型调用的花费记成结构化明细。你在代码里打点,它把输入输出、token 数、耗时、成本按 trace 归好,可以逐条翻。
省掉的动作是不用自己写调用日志表,也不用从供应商后台导 CSV 再拼。它还带提示词版本管理,改一版提示词跑同一批数据集,结果并排看。
Cloud 版按美元标价,核验日期 2026-10-07,官方定价页不按地区切币种:
| 方案 | 月费 | 包含 units | 超出单价 | 数据保留 | 摄取吞吐 | 用户数 ||---|---|---|---|---|---|---|| Hobby | $0 | 50k / 月 | 定制 | 30 天 | 1,000 请求/分钟 | 2 || Core | $29 | 100k / 月 | $8 / 100k | 90 天 | 4,000 请求/分钟 | 不限 || Pro | $199 | 100k / 月 | $8 / 100k | 3 年 | 20,000 请求/分钟 | 不限 || Enterprise | $2,499 | 100k / 月 | 定制 | 3 年 | 定制 | 不限 |
超量单价是阶梯的:0 到 100k units 免费,100k 到 1M 是 $8/100k,1M 到 10M 是 $7/100k,10M 到 50M 是 $6.5/100k,50M 以上 $6/100k。Teams 可加购,$300/月。
自托管是另一套逻辑。核心是 MIT 许可,官方原话是核心功能全部免费自托管,不计量不收费;需 license key 的只剩 SCIM、审计日志、保留策略、组织级 RBAC 与 SSO 强制等企业功能。企业版为定制报价,且官方页写明价格叠加在你的 ClickHouse 商业订阅之上。
unit 的定义是全文最值钱的一条。官方计费单位文档原话:units 等于 trace 数加 observation 数加 score 数。还补了一句,由 Langfuse 自身功能生成的 trace、observation、score 同样计费,包括模型裁判的自动评分和标注队列的标注。官方样例:20,070 个 trace 加 119,500 个 observation 加 561 个 score,等于月度 140,131 units。
只做单次调用、不回溯历史,现有日志加一张表就够了。

输入是一批真实调用,产出是按模型、按天、按项目分好的成本台账。
https://openrouter.ai/api/v1,散落的 base_url 与 key 全删掉。:floor,实时接口用 :nitro,需要工具调用用 :exacto,同时配一份 fallback 模型列表。GET /api/v1/key 拿 usage_daily 与 byok_usage_monthly,和 Langfuse 当天成本汇总做差,两条对上才算可信。error.metadata.limit_source 再决定重试还是加钱,429 先看 error.metadata.provider_code。第 5、6 步是关键:两边数不对上,说明有调用没打点。

你是 LLM 成本对账器。我给你两组数据:Langfuse 的某月用量(trace 数、observation 数、score 数),以及 OpenRouter 的某月用量(usage_monthly、byok_usage_monthly、充值金额)。 只输出一个 Markdown 表格加三行结论,不要引言,不要建议清单。 表格列固定为:项目、数值、来源、口径说明。数据里没有的项,数值列填 null,不要估算,不要编造。 三行结论分别回答:一,Langfuse 的 units 与请求数换算比率,算式写出来;二,OpenRouter 的 credited 用量与 BYOK 用量各占多少;三,两组数据是否对不上,对不上就指出可能漏记的那一类调用。 所有数字必须与输入完全一致,不得改写或换算单位。
怎么判断这次输出合格:抽三条逐项回原始数据核对。一是三个计数相加等于 units 合计;二是所有数字与原始导出一字不差;三是「对不上」那条结论具体到调用类型。三项都满足才算过。