ベンチマーク
異なる2つの問いに答える2種類のベンチマーク — 実際のAPI節約量と、大規模環境における仕組みの正しさ。
リポジトリ内の benchmarks/ には2つのベンチマークがあります。意図的に異なる種類のものなので、片方をもう片方の代替として解釈しないでください。
openrouter-savings — 実際のAPI呼び出し、実際のトークン数
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件すべてを解決する場合と比べてトークン消費量は83%少なくなっています。これは推定値ではなく、OpenRouter 自身の usage.total_tokens から測定した結果です。
reuse-sweep — 合成データで、仕組みを大規模に検証
ネットワーク呼び出しは一切行いません。これは、より限定的で率直な問いに答えるためのものです。N 件の決定と R% の再利用率が与えられた場合、キャッシュは再利用すべきエントリを正確に再利用し、台帳の記録処理は完全に正しい結果になるか？ 実際のAPIレスポンスの代わりに、決定ごとに固定かつ明示された合成コスト（320トークン）を使用します。これは正しさの証明であり、実世界での節約額の見積もりではありません。
pnpm run benchmark # 表
pnpm run benchmark -- --json # 機械可読形式ファイルを編集せずにスイープの形状を上書きするには、次のようにします。
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% 列を1対1で追跡していることこそが重要です。これは数値を売り込むためではなく、キャッシュが主張どおりに正確に動作することを確認しています。
自分のユースケースでは、どちらを信頼すべきですか？
直接的には、どちらも信頼すべきではありません。実際の節約量は、あなたの エージェントが同じ決定をどれほど頻繁に再度問い合わせるかに依存します。これは reuse-sweep の reuse% 列でモデル化されていますが、あなた向けに予測することはできません。ワークロード固有の数値が必要な場合は、自身の実際の決定セットに対して openrouter-savings を実行してください。