Benchmarks
Zwei Benchmarks, die zwei verschiedene Fragen beantworten — echte API-Einsparungen und Korrektheit des Mechanismus im großen Maßstab.
Im Repository befinden sich zwei Benchmarks unter benchmarks/, und sie sind bewusst nicht dasselbe — betrachte keinen als Stellvertreter für den anderen.
openrouter-savings — echte API-Aufrufe, echte Tokenanzahlen
Führt echte Aufrufe an OpenRouter aus und erfasst die tatsächlichen total_tokens, die OpenRouter zurückgibt. Er ist absichtlich klein — eine Handvoll Entscheidungen, einige wiederholt — weil echte Aufrufe Geld kosten und auf Ratenlimits stoßen. Jede ausgegebene Zahl stammt aus einer tatsächlichen API-Antwort.
OPENROUTER_API_KEY=sk-... pnpm --filter @runic-labs/benchmarks run start
OPENROUTER_API_KEY=sk-... pnpm --filter @runic-labs/benchmarks run start -- --jsonErhöhe die Wiederholungsanzahl, um die Stichprobe zu vergrößern, ohne die Datei zu bearbeiten:
OPENROUTER_API_KEY=sk-... REPEATS_PER_DECISION=6 pnpm --filter @runic-labs/benchmarks run start -- --jsonEin tatsächlicher, unveränderter Durchlauf:
{
"model": "openai/gpt-oss-20b:free",
"decisions": 48,
"uniqueDecisions": 8,
"apiCalls": 8,
"cacheHits": 40,
"tokensSpent": 2582,
"tokensSaved": 12910,
"tokensWithoutRunic": 15492,
"savingsPercent": 83
}48 Entscheidungen wurden aufgelöst, nur 8 echte Aufrufe ausgeführt und 83 % weniger Token verbraucht als bei der normalen Auflösung aller 48 — gemessen anhand von OpenRouters eigenem usage.total_tokens, nicht geschätzt.
reuse-sweep — synthetisch, beweist den Mechanismus im großen Maßstab
Führt überhaupt keine Netzwerkaufrufe aus. Er soll eine engere, ehrliche Frage beantworten: Bei N Entscheidungen und einer Wiederholungsrate von R %, verwendet der Cache genau die Einträge wieder, die er sollte, und stimmt die Buchführung des Ledgers exakt? Er verwendet feste, eindeutig gekennzeichnete synthetische Kosten pro Entscheidung (320 Token) statt einer echten API-Antwort — dies ist ein Korrektheitsbeweis, keine Schätzung realer Einsparungen.
pnpm run benchmark # table
pnpm run benchmark -- --json # machine-readableÜberschreibe die Form des Sweeps, ohne die Datei zu bearbeiten:
SWEEP_DECISIONS=10,50 SWEEP_REUSE_PCTS=0,50,90 pnpm run benchmarkEin tatsächlicher Durchlauf:
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 90Dass die Spalte savings% die Spalte reuse% bei jedem Umfang im Verhältnis 1 abbildet, ist der eigentliche Punkt — sie bestätigt, dass der Cache genau das tut, was er behauptet, statt mit einer Zahl zu werben.
Welchem sollte ich für meinen Anwendungsfall vertrauen?
Keinem direkt — deine tatsächlichen Einsparungen hängen davon ab, wie oft dein Agent dieselbe Entscheidung erneut abfragt. Das modelliert die Spalte reuse% von reuse-sweep, kann es aber nicht für dich vorhersagen. Führe openrouter-savings mit deinem eigenen echten Entscheidungssatz aus, wenn du eine für deine Arbeitslast spezifische Zahl möchtest.
Nächste Schritte
- So funktioniert es — die Signatur- und Ledger-Mechanismen, die beide Benchmarks testen
- Schnellstart — binde dies in deinen eigenen Agenten ein, um deine eigenen echten Zahlen zu erhalten