基准测试
两项基准测试回答两个不同的问题——真实 API 节省，以及大规模机制正确性。
仓库中的 benchmarks/ 目录包含两项基准测试，它们刻意不是同一种东西——不要把其中一项当作另一项的替代品。
openrouter-savings ——真实 API 调用，真实 token 计数
对 OpenRouter 发起真实调用，并记录 OpenRouter 返回的真实 total_tokens。它有意保持较小规模——少量决策，其中一些重复——因为真实调用要花钱，也会触及速率限制。它打印出的每个数字都来自实际 API 响应。
OPENROUTER_API_KEY=sk-... pnpm --filter @runic-labs/benchmarks run start
OPENROUTER_API_KEY=sk-... pnpm --filter @runic-labs/benchmarks run start -- --json无需编辑文件即可增加重复次数来扩大样本：
OPENROUTER_API_KEY=sk-... REPEATS_PER_DECISION=6 pnpm --filter @runic-labs/benchmarks run start -- --json一次未经修改的实际运行结果：
{
"model": "openai/gpt-oss-20b:free",
"decisions": 48,
"uniqueDecisions": 8,
"apiCalls": 8,
"cacheHits": 40,
"tokensSpent": 2582,
"tokensSaved": 12910,
"tokensWithoutRunic": 15492,
"savingsPercent": 83
}已解析 48 个决策，却只进行了 8 次真实调用；与按常规方式解析全部 48 个决策相比，token 消耗减少了 83%——该数据来自 OpenRouter 自身的 usage.total_tokens，并非估算值。
reuse-sweep ——合成数据，在大规模下证明机制
完全不发起网络调用。它旨在回答一个更狭窄但诚实的问题：给定 N 个决策和 R% 的重复率，缓存是否恰好复用了应当复用的条目，账本的记录是否恰好正确？ 它为每个决策使用固定且明确标注的合成成本（320 tokens），而非真实 API 响应——这是正确性证明，不是现实世界节省的估算。
pnpm run benchmark # table
pnpm run benchmark -- --json # machine-readable无需编辑文件即可覆盖扫描的形状：
SWEEP_DECISIONS=10,50 SWEEP_REUSE_PCTS=0,50,90 pnpm run benchmark一次实际运行结果：
Runic reuse-sweep (synthetic — proves the mechanism, not real-world savings)
Synthetic cost per unique decision: 320 tokens
decisions reuse% unique hits spent saved savings%
---------- ------- -------- -------- ---------- ---------- ---------
10 0 10 0 3200 0 0
10 25 7 3 2240 960 30
10 50 5 5 1600 1600 50
10 75 2 8 640 2560 80
10 90 1 9 320 2880 90
100 0 100 0 32000 0 0
100 25 75 25 24000 8000 25
100 50 50 50 16000 16000 50
100 75 25 75 8000 24000 75
100 90 10 90 3200 28800 90
1000 0 1000 0 320000 0 0
1000 25 750 250 240000 80000 25
1000 50 500 500 160000 160000 50
1000 75 250 750 80000 240000 75
1000 90 100 900 32000 288000 90
10000 0 10000 0 3200000 0 0
10000 25 7500 2500 2400000 800000 25
10000 50 5000 5000 1600000 1600000 50
10000 75 2500 7500 800000 2400000 75
10000 90 1000 9000 320000 2880000 90在每个规模下，savings% 列都与 reuse% 列一一对应才是真正的重点——这确认缓存完全如其所称地工作，而不是在营销一个数字。
我应该相信哪一项适用于我的用例？
两项都不能直接照搬——你的实际节省取决于你的代理多久会再次询问同一个决策；reuse-sweep 的 reuse% 列对此进行建模，却无法替你预测。如果你想要一个针对自己工作负载的数字，请使用你自己的真实决策集运行 openrouter-savings。