Benchmarks
Dois benchmarks que respondem a duas perguntas diferentes — economia real de API e correção do mecanismo em escala.
Dois benchmarks estão em benchmarks/ no repositório, e deliberadamente não são do mesmo tipo — não interprete um como substituto do outro.
openrouter-savings — chamadas reais de API, contagens reais de tokens
Faz chamadas reais ao OpenRouter e registra o total_tokens real que o OpenRouter retorna. É intencionalmente pequeno — algumas decisões, algumas repetidas — porque chamadas reais custam dinheiro e encontram limites de taxa. Cada número impresso veio de uma resposta real da API.
OPENROUTER_API_KEY=sk-... pnpm --filter @runic-labs/benchmarks run start
OPENROUTER_API_KEY=sk-... pnpm --filter @runic-labs/benchmarks run start -- --jsonAumente a contagem de repetições para ampliar a amostra sem editar o arquivo:
OPENROUTER_API_KEY=sk-... REPEATS_PER_DECISION=6 pnpm --filter @runic-labs/benchmarks run start -- --jsonUma execução real, sem modificações:
{
"model": "openai/gpt-oss-20b:free",
"decisions": 48,
"uniqueDecisions": 8,
"apiCalls": 8,
"cacheHits": 40,
"tokensSpent": 2582,
"tokensSaved": 12910,
"tokensWithoutRunic": 15492,
"savingsPercent": 83
}48 decisões resolvidas, apenas 8 chamadas reais feitas e 83% menos tokens gastos do que ao resolver as 48 da forma normal — medido a partir do próprio usage.total_tokens do OpenRouter, não estimado.
reuse-sweep — sintético, comprova o mecanismo em escala
Não faz nenhuma chamada de rede. Ele existe para responder a uma pergunta mais específica e honesta: dadas N decisões e uma taxa de repetição de R%, o cache reutiliza exatamente as entradas que deveria, e a contabilidade do ledger fica exatamente correta? Ele usa um custo sintético fixo e claramente identificado por decisão (320 tokens) em vez de uma resposta real de API — esta é uma prova de correção, não uma estimativa de economia no mundo real.
pnpm run benchmark # table
pnpm run benchmark -- --json # machine-readableSubstitua a configuração da varredura sem editar o arquivo:
SWEEP_DECISIONS=10,50 SWEEP_REUSE_PCTS=0,50,90 pnpm run benchmarkUma execução real:
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 90O fato de a coluna savings% acompanhar a coluna reuse% em uma proporção de 1 em toda escala é o ponto principal — isso confirma que o cache faz exatamente o que afirma, não promove um número.
Em qual deles devo confiar para o meu caso de uso?
Em nenhum dos dois, diretamente — sua economia real depende de com que frequência seu agente repete a mesma decisão, algo que a coluna reuse% de reuse-sweep modela, mas não pode prever para você. Execute openrouter-savings com seu próprio conjunto de decisões reais se quiser um número específico para sua carga de trabalho.
Próximos passos
- Como funciona — as mecânicas de assinatura e ledger que ambos os benchmarks exercitam
- Início rápido — integre isto ao seu próprio agente para obter seus próprios números reais