inferock/inferock-bench

# 你的 AI 账单可能悄无声息地出错了。

提供商不应该给自己开具的账单打分。
如今，向你收费的公司同时决定什么算作失败、什么可以获得退款，并保留着唯一的详细记录。inferock-bench 将每一次调用的独立账单回执（包括你被计费的内容以及失败的内容）交到你手中。

回执契约 · 快速开始 · 集成 · 测试你的损失 · 可能出现的问题 · 横向对比 · 密钥边界 · 文档

**示例展示，非实测运行。** 这张主图展示了当通过真实的基准测试流水线传入一个合成场景时，每月 `$49,673.82` 的 AI 支出可能会暴露出哪些可供审查的问题。非 Inferock 实测结果，非保证，亦非账单审计。 基准依据：独立的第三方账单审计输入以及公开的延迟吞吐量/SLA 阈值；来源链接和注意事项近在咫尺。 [查看依据 ->](./docs/projection-basis.md) · [查看最新实测运行 ->](./docs/public-run-2026-07-10.md) 当你需要审计 AI/LLM 账单、在本地衡量 Claude 或 GPT 的 token 使用量，或者想弄清楚“我是否为一次失败的 API 调用买了单？”时，就可以使用它。它是一个本地 LLM 成本追踪代理，适用于四个已实测的提供商通道：OpenAI、Anthropic、Gemini Developer API，以及在观察到的宿主上固定了 meta-llama、deepseek、mistral、moonshot/kimi、z-ai/glm 和 qwen 的 OpenRouter 端点。其他所有内容均为可扩展设计，目前尚未实测。 ## 回执契约 `inferock-bench` 是一个用于计量 API 流量的本地诊断代理。它使用你保存的提供商 API key 衡量通过 localhost 路由的调用，写入本地事件记录，并通过内置的 `@inferock/measure` 评分代码和 [The Inferock Standard](./spec/standard.md) 渲染回执。 **它衡量什么** - 针对本地代理实际看到的调用，衡量提供商报告的使用量、定价证据、请求/响应元数据、状态、时间、重试证据以及探测器信号。 - 可能影响账单或审计记录的交付失败，例如：计费但输出为空、拒绝回答、内容截断、token 重算不匹配、重复的请求 ID、缓存折扣风险证据，以及提供商侧错误导致的重试。 - 每个层面的覆盖状态：`watched-clean`（监视正常）、`signal`（有信号）或 `not-openable`（无法打开），这样未被检查的项目就会显露出来，而不是被直接宣称没问题。 **回执能证明什么** - 基准测试在本地观察到了列出的调用，并在标注的评分版本下，根据存储的事件记录计算出了回执。 - 标题区分了提供商支出、账单范围内的资金损失、时间损失和发票核查风险敞口，而不是将不同性质的数据加在一起。 - 本地基准测试不会将提供商密钥发送给 Inferock；代理仅将其附加到发往提供商的请求中，并且除非你主动分享，否则回执仅保留在本地。 **回执不能证明什么** - 它无法审计绕过本地代理的流量，无法限制在未见调用中的提供商支出，也无法在没有匹配发票的情况下解释每月账单。 - 它不是提供商排名，不是对提供商意图的证明，也不能证明某种失败模式在实测运行之外广泛存在。 - 它不会将所有不匹配的情况都定性为 OpenAI 多收费或 Anthropic 计费错误；它保留 token、成本、重试和失败证据，以便对计费完整性问题进行核查。 回执中出现的数字分为两类，它们都被如实标记： - **观测值** — 发生过的事实：状态码、测量的延迟、 提供商报告的 token 计数、探测器标记的调用。 - **解读值** — 根据公开假设（阈值、小时费率、全呼叫下限）从观测值计算出的美元金额。 这些是我们将真实事件进行数学处理后的结果，并非提供商的承认。 本项目的演进方向是将尽可能多的内容从第二列（解读值）移至第一列（观测值）。依然存在的局限性是有据可查的，绝不掩盖：参见 [MEASUREMENT-PHILOSOPHY.md](./MEASUREMENT-PHILOSOPHY.md)。 ## 回执标题 | 回执词汇 | 字面意义 | | --- | --- | | `spent` | 运行观察到的已定价调用的提供商支出。 | | `money loss` | The Inferock Standard 能够将其与观察到的支出或收费证据关联起来的、账单范围内的美元损失。 | | `time loss` | 以时间衡量的实际等待或停机时间，绝不折算为美元。 | | `invoice-check exposure` | 发票核查金额，例如处于风险中的缓存折扣；它被标记为“核查你的发票”，绝不会计入资金损失。 | **真实的实测流量，非测试数据。** 自 2026-07-09 起测量，截至 run15 的累计公共账本记录了 1,268 次实测调用，564 次失败/信号，观察到的提供商支出为 `$7.15`，账单范围内的资金损失为 `$0.03`（精确存储值：`$0.026464`；基于问题加权的自适应流量混合），`~2.9 min` 时间损失，以及跨越 202 个缓存折扣风险信号的 `$16.80` 发票核查风险敞口。失败/信号是回执的分析结果，而非独立的调用，且发票核查风险敞口与已记录的资金损失是分开的。当前代码的累计回执监视了 13 个层面中的 12 个。 运行详情：[2026-07-09 脱敏公共运行记录卡](./docs/public-run-2026-07-09.md) 以及 [查看最新实测运行 ->](./docs/public-run-2026-07-10.md)。 2026-07-06 的 0.1.7 记录卡作为历史产物予以保留；当前的公共回执呈现方式在 0.1.10 版本引入，并在当前的 0.2.3 候选版本中继续适用。 真实的实测仪表盘和回执截图记录在 [asset provenance](./assets/PROVENANCE.md) 中，但它们并非此处的首图。请使用上方的运行记录卡查看最新的实测证据。 ## 为什么会有这个项目 我们开发 `inferock-bench`，是因为我们总是在为那些说到一半就死掉的回答付费，却没人告诉我们钱去哪了。 你的 AI 账单计算了模型消耗了多少资源。但它从来没有计算过你是否真正得到了相应的回报。 模型推理拥有仪表盘、日志、使用量 API、token 估算器和成本工具，但很少有工具能够将每次调用的实际提供商账单与交付证据进行交叉核对。一次拒绝回答的收费可能与一次正常回答相同。一个模型可能会在同名下悄悄变差。当出现问题时，发现的压力依然主要落在你身上。 `inferock-bench` 正是为了填补这一空白而生的测量工具。它监视针对真实提供商 API 的实际流量，并保留审查账单所需的可靠性、延迟、支出和失败成本证据。关于类别的背景信息，请参阅 [横向对比](./docs/how-this-compares.md)。 ## 快速开始 在本地运行它。我们认为你应该能够精确看到每一次提供商故障让你花了多少钱，精确到美分。提供商密钥不会发送给 Inferock；仅附加到提供商请求中。 1. 前置条件：安装 Node.js 22+ 和 npm。 node --version npm --version 如果缺少任何命令，请先安装 Node.js 22 或更高版本。 2. 运行本地基准测试： npx inferock-bench 首次运行会下载软件包，在打印任何内容之前可能需要一两分钟。请保持其运行。你会看到如下内容： inferock-bench listening at http://127.0.0.1:4318 Dashboard: http://127.0.0.1:4318/ Config: ~/.inferock-bench/config 3. 在本地保存你的提供商密钥。 在步骤 2 的服务器仍在运行时的最简单路径：打开 `http://127.0.0.1:4318/` 并在仪表盘中保存提供商密钥。请先在你的提供商账户中创建该密钥；在评估期间请使用低限额或开发密钥。它会保存在本地的 `~/.inferock-bench/` 目录下，并以仅限所有者的文件权限保存，且只会以掩码形式回显。 CLI 路径（在启动服务器之前或停止之后）： npx inferock-bench setup 在输入密钥时，设置提示会将其隐藏。在无头机器上，请通过管道将密钥从你的密钥管理器传入同一命令。要查看当前支持的提供商名称，请运行 `npx inferock-bench status` 或 `npx inferock-bench --help`。运行中的服务器不会重新加载通过单独的 CLI 设置过程写入的提供商密钥；在 CLI 设置后请重启服务器。 你通过基准测试发送的任何流量都是真实的提供商使用记录。请从几个简短的 prompt 开始，并预计会产生少量评估费用，该费用由你的提供商账户限额控制。内置的 `npx inferock-bench test` 流程在进行任何提供商调用之前，会显示估算的 token、估算的美元金额和支出上限。 4. 获取你的本地基准测试 key： npx inferock-bench key reveal 这会将本地的 `ibl_` 基准测试 key 打印到标准输出，因此对管道操作很友好。这是一个仅限本地的凭证，不是你的提供商 key。如果想要将其复制到剪贴板，请运行： npx inferock-bench key copy 如果没有可用的剪贴板，copy 命令将回退为直接打印该密钥。你也可以从仪表盘复制本地基准测试 key。 随时检查已配置的内容： npx inferock-bench status 它会显示每个提供商的已配置/掩码状态、本地存储位置、服务器状态和版本。 如果不想启动服务器，只需查看快捷命令列表或软件包版本，请使用 `npx inferock-bench --help` 或 `npx inferock-bench --version`。 5. 将一些流量指向本地基准测试。 还没有应用？在步骤 3 中保存了相应的提供商密钥后，请使用这些同等的本地目标。 Claude Code（[完整指南](./docs/integrations/claude-code.md)）： npm i -g @anthropic-ai/claude-code ANTHROPIC_BASE_URL=http://127.0.0.1:4318 ANTHROPIC_API_KEY=ibl_your_local_bench_key claude -p "Draft a five-bullet checklist for reviewing an AI invoice." OpenAI SDK（[完整指南](./docs/integrations/openai-sdk.md)）： import OpenAI from "openai"; const openai = new OpenAI({ apiKey: process.env.INFEROCK_BENCH_KEY ?? "ibl_your_local_bench_key", baseURL: "http://127.0.0.1:4318/v1", }); await openai.chat.completions.create({ model: "gpt-4o-mini-2024-07-18", messages: [{ role: "user", content: "Draft a five-bullet checklist for reviewing an AI invoice." }], }); Gemini（[完整指南](./docs/integrations/gemini.md)）： await fetch("http://127.0.0.1:4318/v1beta/models/gemini-2.5-flash:generateContent", { method: "POST", headers: { authorization: "Bearer " + (process.env.INFEROCK_BENCH_KEY ?? "ibl_your_local_bench_key"), "content-type": "application/json", }, body: JSON.stringify({ contents: [{ role: "user", parts: [{ text: "Draft a five-bullet checklist for reviewing an AI invoice." }] }], }), }); 对于这些命令，SDK API key 即为步骤 4 中获取的本地 `ibl_` 基准测试 key。你的提供商 key 不会传递给 Claude Code 或你的应用；它不会发送给 Inferock，且仅附加到提供商请求中。如果你配置了 OpenRouter，请使用仪表盘的“本地应用连接”面板、包 README 或 [OpenRouter 完整指南](./docs/integrations/openrouter.md) 中特定于提供商的 SDK 代码片段。 注意：Claude 订阅 (OAuth) 登录不是衡量调用的受支持机制。`inferock-bench` 仅衡量计费 API 流量 —— 请在基准测试中保存提供商 API key，并如上所示使用本地 `ibl_` key 将你的 或 agent 指向它。 在首次成功的代理调用之后，运行 `inferock-bench` 的终端将打印： first call measured ✓ 6. 从另一个终端查看你的回执： npx inferock-bench receipt --compact 如果你全局安装了 `inferock-bench`，直接使用 `inferock-bench receipt --compact` 也可以。本 README 使用 `npx inferock-bench ` 的形式，以免一次性用户陷入困境。 ### 集成 | 层面 | 完整指南 | | --- | --- | | Claude Code | [docs/integrations/claude-code.md](./docs/integrations/claude-code.md) | | OpenAI SDK | [docs/integrations/openai-sdk.md](./docs/integrations/openai-sdk.md) | | Gemini Developer API | [docs/integrations/gemini.md](./docs/integrations/gemini.md) | | OpenRouter 固定端点 | [docs/integrations/openrouter.md](./docs/integrations/openrouter.md) | | CI/无头模式使用 | [docs/integrations/ci.md](./docs/integrations/ci.md) | ### 已经有应用了？ 只需更改确切的两个 SDK 设置：`apiKey` 和 `baseURL`。 ``` const client = new YourProviderSdk({ apiKey: process.env.INFEROCK_BENCH_KEY ?? "ibl_your_generated_local_key", baseURL: "http://127.0.0.1:4318", }); ``` 某些 SDK 在 base URL 中使用 `/v1`。仪表盘会显示每个已配置提供商的确切值；`npx inferock-bench init` 会打印 OpenAI 和 Anthropic 的构造函数代码片段。 运行 `npx inferock-bench init` 以检测 OpenAI 或 Anthropic SDK 的使用情况并打印确切的 SDK 更改。`npx inferock-bench init --patch path/to/client.ts --yes` 仅在能够同时更新 `apiKey` 和 `baseURL` 时才会修补简单的构造函数；否则它将拒绝执行并给出明确信息。对于 Gemini 或 OpenRouter，请使用仪表盘的“本地应用连接”代码片段或包 README 中的提供商示例。

从源码运行

``` git clone https://github.com/inferock/inferock-bench.git cd inferock-bench pnpm install pnpm -r --workspace-concurrency=1 build node apps/inferock-bench/dist/index.js start ```

## 测试你的损失 `npx inferock-bench test` 会在你的提供商 key 下运行完整的覆盖测试套件，使回执能够显示你的提供商让你付出了什么代价，以及本次运行实际打开了哪些损失层面。签入的实测基准为估算提供支持，因此只需配置好提供商 key 和具备定价的兼容模型，即可到达确认步骤。 有关回执背后的确切公式，请参阅 [付费损失计算](./docs/loss-arithmetic.md)。 在进行任何提供商调用之前，你会看到估算的 token、估算的美元金额、模型、测试套件、基准、定价来源和支出上限。文案会明确说明价格：在所选提供商上运行完整测试集的费用大约为显示的金额。如果你在此停止，该命令将进行零次提供商调用。交互式运行需要你输入 `RUN`；自动化流程必须通过 `--accept-estimate ` 传入显示的哈希值，因为单凭 `--yes` 并不构成对已更改估算的确认。 在仪表盘中，打开“高级选项”，将“测试驱动”设置为“Agent 测试”，然后运行测试以使用真实的编码 agent。Agent 测试目前支持 OpenAI 和 Anthropic 运行；请使用内置生成器进行 Gemini 和 OpenRouter 覆盖测试。如果固定的本地 agent 未安装，仪表盘会在下载前明确列出 npm 软件包、版本、SRI 校验和、大小、来源 URL 和本地安装路径。该 agent 仅接收 localhost 和临时的本地 `ibl_` key，绝不会接收你的提供商 key。CLI 等效命令：`npx inferock-bench test --generator agent`。 回执的作用域限定于单次运行。它报告 `spent $X · money loss $Y · time loss Z · invoice-check exposure $E`（支出 $X · 资金损失 $Y · 时间损失 Z · 发票核查风险敞口 $E）、提供商认可的补偿、账单范围内的认知差距、（适用时的）独立的发票核查风险敞口明细行，以及诸如 `surfaces watched 10/12 | signals 3 | not-openable 2`（监视层面 10/12 | 信号 3 | 无法打开 2）的覆盖率行，每个层面都会标记为 `watched-clean`、`signal` 或 `not-openable`。只有当层面被监视过时，零才有效；未打开的层面会被列为覆盖盲区，而不是被悄然宣称为正常。对于未达到标准且与观察到支出或收费证据关联的已定价调用，资金损失是账单范围内的；提供商认可的部分仍可能为 `$0`，该差距即为账单范围内的资金账本内部的差额。 回执开头有一行简明的英文指南，解释了支出的美元、账单范围内的资金损失、时间损失和发票核查风险敞口。回执中的“失败”是一项测量结果，不一定代表你的应用崩溃了。`signal`（信号）是基准测试看到的一项分析结果，例如 token 交叉校验。`CACHE_DISCOUNT_AT_RISK` 会显示为发票核查风险敞口，并附带“核查你的发票”的指导；它不会计入资金损失或认知差距。`Provider-recognized`（提供商认可）是看起来符合提供商当前退款规则的部分；账单范围内的差距将保持可见，而不会被隐藏。 如果未配置提供商 key、定价未知，或者 token 基准缺失或仅有引导数据，CLI 和仪表盘将关闭并不进行任何提供商调用。基准降级状态报告为 ``baseline not measured yet: run `inferock-bench test --record-baseline` with explicit consent to produce a real per-task token baseline.``（基准尚未测量：在明确同意的情况下运行 `inferock-bench test --record-baseline` 以生成真实的每任务 token 基准。）方法详情请参见 [覆盖测试方法论](./docs/coverage-test-methodology.md)。 ## 你的提供商没有告诉你的事 这个盲区很简单：提供商只给你总数。他们通常不会提供你需要的那种每次调用的回执，以证明哪个回答中断了、哪个重试运行了，或者哪个 token 数量发生了变化。 我们不认为你应该仅仅信任一个每月的总数。我们认为每一个失败回答都应该留下痕迹：发生了什么，我们有多确定，以及提供商是否真的会认可这项索赔。  **说明性机制 — 非实测数据。** 这正是我们开发 `inferock-bench` 以在你自己的流量上捕捉的那种计费盲点。 | 可能出现的问题 | 提供商是否为你量化了它？ | inferock-bench 做了什么 | | --- | --- | --- | | 回答被截断，依然被扣费 | 提供商文档应说明部分流、超时和不完整回答何时会被计费。[披露附录](./spec/disclosure-annex.md#failed-partial-filtered-and-incomplete-billing) 记录了主流第一方 API 并未完全公开这些规则。 | 记录回答为何结束、收到了什么文本、提供商声称使用了多少 token 以及应该花费多少钱。我们会告诉你什么时候证据足够充分可以申请退款，什么时候只需保持关注。 | | 空回复，依然被扣费 | 提供商应将隐藏的已计费 token 与你能看到的文本分开，这样空回复就不会被误解。[附录](./spec/disclosure-annex.md#hidden-and-non-visible-token-classes) 指出客户需要这些细节来核对账单。 | 将可见的空内容与隐藏的计费 token、工具、安全和拒绝回答的解释进行核对。如果计费的输出没有文档化的解释，我们将其标记为退款候选。如果解释缺失或不明，我们将其保留为仅供关注的证据。 | | 计费的 token 多于收到的 | 如果混入了隐藏的已计费 token，可见的重算结果可能是错的。[附录](./spec/disclosure-annex.md#hidden-and-non-visible-token-classes) 将拒绝、拒绝预测、推理、思考和缓存 token 列为客户需要的细节。 | 重新计算可见的输出，同时兼顾额外隐藏 token 是合理的情况。在已知定价的情况下，超出公差范围的计数过多可成为退款候选。缺失的价格或 token 细节将保持仅供关注。 | | 隐形重试，双重扣费 | 提供商应该提供一个将重试联系在一起的操作 ID，但 [附录](./spec/disclosure-annex.md#idempotent-inference-apis) 记录了受检的第一方 API 在 AI 调用上并不一致地提供此功能。它还记录了没有每次调用收费证明的重试指令。 | 保持重试证据可见，并现在为非最终提供商故障尝试计算符合 Inferock 标准的重试损失。强证据使用提供商重试 header；较弱证据使用 body-hash 回退。提供商认可的补偿仍然需要收费证明。 | | 你花钱买单的服务中断 | 提供商文档应发布针对提供商错误和超时的计费规则。[附录](./spec/disclosure-annex.md#failed-partial-filtered-and-incomplete-billing) 记录了缺失的主流 API 计费规则，而 [可用性规则](./spec/disclosure-annex.md#availability-service-level-objective-parity) 在各个云合作伙伴中各不相同。 | 捕获响应代码、时间和提供商错误证明。只有当失败是由提供商造成、已计费、已定价且有发布规则涵盖的情况下，它才会成为退款候选。 | | 被拒绝并扣费 | 提供商应将拒绝计费规则放在响应中。[附录](./spec/disclosure-annex.md#refusal-billing-invariant) 记录了文档化的输出前规则和流中规则可能有何不同。 | 将输出前拒绝与流中拒绝分开。文档化的免费规则加上真实的收费记录将成为退款候选。其他较弱的证据则保持仅供关注。 | | 你全额买单的缓存 | 计费页面应使用与响应相同的缓存类别。[附录](./spec/disclosure-annex.md#usage-category-parity) 指出客户需要在这两处都包含缓存模式、token 类型、层级和地理信息。 | 将缓存使用量与预期的缓存定价进行比较。只有在提供商提供收费证明的情况下，它才会成为退款候选；否则保持仅供关注。 | | 质量或层级发生变化却无人通知 | 提供商应披露处理该调用的确切模型版本、服务等级和功能设置。[附录](./spec/disclosure-annex.md#served-model-and-backend-identity) 记录了当今缺失或不完整的部分。 | 在暴露的情况下记录模型版本和服务等级，并保留痕迹。在首个公开版本中，这是仅供关注的。我们不会为质量变化记录退款金额。 | 信任边界：在粘贴提供商 key 之前，请阅读[什么会离开你的机器](./docs/what-leaves-your-machine.md)以及[如何处理密钥](./docs/key-handling.md)。 ## 提供商密钥的使用方式 我们将 `inferock-bench` 设计为一个带有浏览器仪表盘的本地进程。你的应用将正常的开发流量发送到 localhost，`inferock-bench` 使用提供商 key 将其转发给提供商，`@inferock/measure` 将捕获的调用转化为实时的美元损失回执。提供商密钥不会发送给 Inferock；仅附加到提供商请求中。生成的本地基准测试 key 将保留在你的机器上，除非你将其复制到其他地方。 ``` flowchart LR A[Apps and SDKs] -->|localhost base URL + local ibl_ key| P[inferock-bench local proxy] P -->|measured call records + receipts| F[(local files)] D[Dashboard provider key setup] -. saved locally .-> P P --> L[adapter layer] L --> OAI[OpenAI plane] L --> ANT[Anthropic plane] L --> GEM[Gemini Developer API plane] L --> OR[OpenRouter pinned plane] OAI --> OAIM[OpenAI models] ANT --> ANTM[Claude models] GEM --> GEMM[Gemini models] OR --> LLAMA[meta-llama @ parasail/fp8] OR --> DS1[deepseek @ deepseek] OR --> DS2[deepseek @ deepinfra/fp4] OR --> QWEN[qwen @ deepinfra/fp8] OR --> MISTRAL[mistral @ mistral] OR --> KIMI[moonshot/kimi @ moonshotai/int4] OR --> GLM[z-ai/glm @ z-ai/fp8] ``` 当今实测指的是上述四个公共提供商通道。仅当请求的固定、服务的端点元数据和引用的定价证据相匹配时，才会对 OpenRouter 当前的固定端点集进行实测。在它们的适配器、定价、分类法、SLA 和覆盖率闸门存在之前，其他提供商均为可扩展设计。 ## 添加提供商 这是设计契约，而非路线图承诺。一个新提供商只有在满足以下所有条件后，才会成为受支持的实测对象： - 适配器：将请求、响应、流、错误和提供商身份映射到规范事件中。 - 引用定价：来源 URL、检索日期、生效日期、模型或通道及使用类别；缺失或部分行将发出 `pricing_unknown`，而不是 `$0`。 - 故障分类体系：提供商错误、完成原因、拒绝、安全/过滤字段、重试 header 和终端流状态，映射时不捏造可退款性。 - SLA 诚实查询：提供商认可的退款、停机或延迟规则是明确的；否则 provider-recognized 保持为 `$0 / 0s`。 - Oracle 或 not-openable 覆盖范围：每个信号都会声明提供商是否具备判断它所需的证据表面；不支持的表面保持为 `not-openable`。 在这些门槛达成之前，提供商处于设计上的可扩展状态，而非实测支持。 此代码库是本地诊断基准测试，而非 [hosted Inferock](https://inferock.opiusai.com)。需要安全密钥托管、路由/故障转移、恢复、支持、发票核对、提供商交涉或审计工作流程的生产环境使用，请移步 [hosted Inferock](https://inferock.opiusai.com)。 ## 为什么这很重要 Vaudit 在 2026 年 6 月报告称，其审查了约 3400 万美元的 AI 发票，发现了约 170 万美元的重复计费，并观察到提供商退还了大约 80% 的争议金额；该退款率的细节并未得到独立核实（[Business Wire](https://www.businesswire.com/news/home/20260630108235/en/Vaudit-Launches-TokenAudit-to-Recover-Millions-in-Enterprise-Token-Spend-Billing-Errors-From-Anthropic-OpenAI-and-AI-Providers)，[TechStartups/The Information 转载](https://techstartups.com/2026/06/25/anthropic-and-openai-customers-overcharged-by-1-7m-in-billing-errors-startup-audit-finds/)）。不对称性就在于此：相同的模型可以承载有退款保障的云端 SLA，而第一方 API 客户却只能获得更单薄甚至没有公开的 SLA 条款；详情请见 [规范附录](./spec/disclosure-annex.md)。提供商否认存在广泛的重复计费：Anthropic 表示它“不会对不完整的请求或错误信息向客户收费，不会将客户请求路由到较旧的模型也没有看到计费过多成为普遍问题的迹象”；OpenAI 表示“没有证据表明这些问题在其客户中存在”。包含这些提供商声明是为了明确否认和界定范围，而非承认；`inferock-bench` 将它们视为需要针对本地每次调用证据进行检验的主张。 这就是为什么我们要确立 [The Inferock Standard](./spec/standard.md)。我们不希望提供商成为唯一有权定义损失的一方。即使提供商尚未认可，一个中断的回答也可能导致账单范围内的资金损失、时间损失或两者兼有。回执优先展示观察到的支出、账单范围内的资金损失、时间损失和发票核查风险敞口；发票核查风险敞口绝不会计入资金损失。因此，我们将提供商可能退还的美元与你仍需核查的时间、账单范围内的资金损失和发票核查风险敞口分离开来。将它们混在一起只会制造一个更博眼球的标题，却会削弱回执的效力。 这是一个不断发展的基准测试标准，特意进行了版本化：每一次规则更改都会记录在 [标准更新日志](./spec/CHANGELOG.md) 中，由真实回执支持的反馈将塑造下一个版本。如果某个类别是错误的，请向我们展示，它将在公开场合得到修复。 链接的真实运行记录卡来自累计实测分类账，而非虚构的数据行：跨 OpenAI、Anthropic、Gemini 和固定 OpenRouter 覆盖范围的 1,268 次实测调用，观察到的提供商支出为 `$7.15`，账单范围内的资金损失为 `$0.03`（精确存储值 `$0.026464`；基于问题加权的自适应流量混合），`~2.9 min` 时间损失，以及排除在标题资金损失之外的 `CACHE_DISCOUNT_AT_RISK` 风险敞口 `$16.80`。失败/信号是回执的分析结果，而非独立的调用。不适用的特定于提供商的层面保持标记状态，而不是被虚假地声明为正常。如果你正常的流量是干净的，`inferock-bench` 就会这么说。如果不是，回执会告诉你发生了什么以及该主张有多强的证据支持。每次运行还会报告流量实际执行了哪些测量层面，例如 `surfaces watched 10/12 | signals 3 | not-openable 2`。只有被监视层面的零才有效，任何未被执行的层面都会被标记，绝不会悄然宣称正常。 ## 分享你的回执 当你想要通过自己实测的流量生成一张紧凑、可分享的证明卡片时，请导出回执： ``` npx inferock-bench receipt --compact ``` 回执以支出、账单范围内的资金损失、时间损失和发票核查风险敞口开头。提供商认可的补偿、认知差距和缓存折扣的发票核查风险敞口明细显示在标题下方。它不是提供商排名，也不是通过虚构数据生成的。 ## 文档 | 从这里开始 | 何时使用 | | --- | --- | | [The Inferock Standard](./spec/standard.md) | 规定什么算作损失、什么可挽回以及什么保持分离的公开规则手册。 | | [尖锐问题](./docs/hard-questions.md) | 直接回答怀疑者最可能提出的关于发布的问题。 | | [横向对比](./docs/how-this-compares.md) | 在可观测性、token、成本、延迟和发票审查工具层面进行对比。 | | [推演基准](./docs/projection-basis.md) | README 说明性主图的静态基准页面；支出作为前提、前向推导输出、引用和注意事项。 | | [Claude Code 集成](./docs/integrations/claude-code.md) | 将 Claude Code 计费的 Anthropic API 流量通过本地基准测试路由。 | | [OpenAI SDK 集成](./docs/integrations/openai-sdk.md) | 为本地实测调用设置 OpenAI SDK 的 `apiKey` 和 `baseURL`。 | | [Gemini 集成](./docs/integrations/gemini.md) | 通过本地基准测试发送 Gemini Developer API 的 `generateContent` 流量。 | | [OpenRouter 集成](./docs/integrations/openrouter.md) | 使用固定的 OpenRouter OpenAI 兼容端点通道。 | | [CI 集成](./docs/integrations/ci.md) | 在 CI 中运行无头冒烟测试或确认执行 `inferock-bench test` 测试套件。 | | [公共运行记录卡：2026-07-10](./docs/public-run-2026-07-10.md) | run15 的事实、累计存储核对，以及自适应问题加权分母披露。 | | [公共运行记录卡：2026-07-09](./docs/public-run-2026-07-09.md) | 第一个 0.1.10 公共实测流量组件的脱敏汇总回执事实。 | | [历史公共运行记录卡：2026-07-06](./docs/public-run-2026-07-06.md) | 拆分风险敞口之前的公共实测流量运行的历史脱敏汇总回执事实。 | | [什么会离开你的机器](./docs/what-leaves-your-machine.md) | 发布的基准测试代码的确切本地/网络边界。 | | [密钥处理](./docs/key-handling.md) | 提供商密钥、本地 `ibl_` key、掩码、轮换以及恶意分支风险。 | | [inferock-bench 应用 README](./apps/inferock-bench/README.md) | 软件包级别的快速开始和 CLI 命令摘要。 |

标准和方法论参考资料

- [事件 schema](./spec/event-schema.md) - 允许回执追溯至真实提供商流量的确切调用记录结构。 - [每个信号的含义](./spec/signals.md) - 公开的信号列表，以及防止将薄弱主张变成退款主张的护栏机制。 - [提供商应该披露什么](./spec/disclosure-annex.md) - 缺口列表：客户需要的字段、计费规则和服务承诺。 - [标准更新日志](./spec/CHANGELOG.md) - 公开标准包的版本历史。 - [标准测试数据示例](./spec/examples/README.md) - 规范示例的测试数据警告和示例文件范围。 - [SLA 默认值](./spec/sla-defaults.md) - 标准数学运算使用的生成阈值和时间价值默认值。 - [覆盖率测试方法论](./docs/coverage-test-methodology.md) - `npx inferock-bench test` 发送的内容、为什么它是常规用法，以及回执覆盖率状态如何工作。 - [证据等级方法论](./docs/evidence-grade-methodology.md) - 探测器姿态如何在没有人工维护者打分的情况下转化为证据等级。 - [定价方法论](./docs/pricing-methodology.md) - 静态价格行、来源日期和 `pricing_unknown` 处理如何运作。 - [威胁模型](./docs/threat-model.md) - 本地基准测试能防范什么，不能防范什么。 - [安全策略](./SECURITY.md) - 如何报告漏洞以及切实可行的支持预期。 - [资产出处](./assets/README.md) - 截图、GIF、回执图片和说明性图表的严禁模拟策略。 - [npm 上的 @inferock/measure](https://www.npmjs.com/package/@inferock/measure) - 回执背后的测量数学库；源码位于 [packages/measure](./packages/measure/README.md)。 - [CONTRIBUTING](./CONTRIBUTING.md) - 如何运行检查、更改基准测试并保持公开主张的可靠性。 - [MAINTAINERS](./MAINTAINERS.md) - 代码库的公开所有权和维护者预期。

## 创始人 由 Bharath Koneti（[LinkedIn](https://www.linkedin.com/in/bharathkoneti/)，[X](https://x.com/bharathakoneti)）和 Himashwetha Gowda（[LinkedIn](https://www.linkedin.com/in/himashwethagowda/)）构建，他们在 [OpiusAI](https://opiusai.com) 致力于构建 Inferock —— AI 提供商问责制标准。 运行它。把你的回执发给我们。对我们的分类法提出质疑。如果某个类别错了，请带上示例告诉 [Bharath](https://x.com/bharathakoneti) 或 [Himashwetha](https://www.linkedin.com/in/himashwethagowda/)，以便让标准变得更加犀利，而不是仅仅博取眼球。 ## 可靠性指数 可靠性指数处于预发布阶段。你可以在本地选择启用，以预览匿名化的有效负载；在公共后端上线之前不会发送任何内容，并保留审查/撤销控制。 ``` npx inferock-bench index on ``` 规则：仅限自主选择加入，无第三方介入，公共汇总数据，一条命令关闭，并在首次发送前展示数据。每个指数数字仅包含真实的测量数据；绝不包含预置或捏造的指数统计。 状态：公共指数后端处于预发布阶段。今天选择加入会在本地记录你的同意，并向你展示确切的有效负载；目前不会发送任何内容。当公共指数上线时，已选择加入的基准测试将能够贡献到记分牌，你可以在数据离开你的机器之前审查或撤销该授权。 ## FSL 协议说明 - 免费的本地基准测试使用。 - 源代码可见，防止被当作托管生产环境的替代品。 - 2 年后转换为 Apache-2.0。 `inferock-bench` 采用 FSL-1.1-ALv2 协议，并包含 2 年后向 Apache-2.0 转换的条款。`@inferock/measure` 采用 Apache-2.0 协议。The Inferock Standard 采用 CC-BY-4.0 协议。

标签：API代理, DLL 劫持, MITM代理, 人工智能, 大语言模型, 成本追踪, 暗色界面, 用户模式Hook绕过, 自动化攻击, 计费审计