Benchmarks
Deux benchmarks qui répondent à deux questions différentes — économies réelles d’API et exactitude du mécanisme à grande échelle.
Deux benchmarks se trouvent dans benchmarks/ du dépôt, et ils ne sont délibérément pas de même nature — ne considérez pas l’un comme représentatif de l’autre.
openrouter-savings — appels API réels, comptages de jetons réels
Effectue de vrais appels à OpenRouter et enregistre les véritables total_tokens renvoyés par OpenRouter. Il est volontairement réduit — une poignée de décisions, dont certaines répétées — car les appels réels coûtent de l’argent et atteignent les limites de débit. Chaque nombre affiché provient d’une réponse API réelle.
OPENROUTER_API_KEY=sk-... pnpm --filter @runic-labs/benchmarks run start
OPENROUTER_API_KEY=sk-... pnpm --filter @runic-labs/benchmarks run start -- --jsonAugmentez le nombre de répétitions pour élargir l’échantillon sans modifier le fichier :
OPENROUTER_API_KEY=sk-... REPEATS_PER_DECISION=6 pnpm --filter @runic-labs/benchmarks run start -- --jsonUne exécution réelle, non modifiée :
{
"model": "openai/gpt-oss-20b:free",
"decisions": 48,
"uniqueDecisions": 8,
"apiCalls": 8,
"cacheHits": 40,
"tokensSpent": 2582,
"tokensSaved": 12910,
"tokensWithoutRunic": 15492,
"savingsPercent": 83
}48 décisions résolues, seulement 8 appels réels effectués, et 83 % de jetons dépensés en moins que pour résoudre les 48 de manière habituelle — mesuré à partir du propre usage.total_tokens d’OpenRouter, sans estimation.
reuse-sweep — synthétique, prouve le mécanisme à grande échelle
N’effectue aucun appel réseau. Il sert à répondre à une question plus restreinte et honnête : pour N décisions et un taux de répétition de R %, le cache réutilise-t-il exactement les entrées qu’il doit réutiliser, et la comptabilité du registre est-elle parfaitement correcte ? Il utilise un coût synthétique fixe et clairement indiqué par décision (320 jetons) au lieu d’une réponse API réelle — il s’agit d’une preuve de correction, pas d’une estimation des économies réelles.
pnpm run benchmark # table
pnpm run benchmark -- --json # machine-readableModifiez la forme du balayage sans éditer le fichier :
SWEEP_DECISIONS=10,50 SWEEP_REUSE_PCTS=0,50,90 pnpm run benchmarkUne exécution réelle :
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 90Le fait que la colonne savings% suive la colonne reuse% à l’identique, à chaque échelle, est précisément l’objectif — cela confirme que le cache fait exactement ce qu’il prétend faire, sans promouvoir un chiffre.
Lequel dois-je utiliser pour mon cas d’usage ?
Aucun, directement — vos économies réelles dépendent de la fréquence à laquelle votre agent repose la même décision, ce que la colonne reuse% de reuse-sweep modélise sans pouvoir le prédire pour vous. Exécutez openrouter-savings sur votre propre ensemble de décisions réelles si vous souhaitez un chiffre spécifique à votre charge de travail.
Suite
- Fonctionnement — les mécanismes de signature et de registre que les deux benchmarks exercent
- Démarrage rapide — intégrez ceci à votre propre agent pour obtenir vos propres chiffres réels