---
title: Benchmarks
description: >-
  Dois benchmarks que respondem a duas perguntas diferentes — economia real de
  API e correção do mecanismo em escala.
sidebar:
  order: 7
---
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.

```bash
OPENROUTER_API_KEY=sk-... pnpm --filter @runic-labs/benchmarks run start
OPENROUTER_API_KEY=sk-... pnpm --filter @runic-labs/benchmarks run start -- --json
```

Aumente a contagem de repetições para ampliar a amostra sem editar o arquivo:

```bash
OPENROUTER_API_KEY=sk-... REPEATS_PER_DECISION=6 pnpm --filter @runic-labs/benchmarks run start -- --json
```

Uma execução real, sem modificações:

```json
{
  "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.

:::tip
Nunca faça commit de uma chave de API real no repositório. Mantenha `OPENROUTER_API_KEY` apenas como uma variável de ambiente — ela é lida de `process.env` em `benchmarks/openrouter-savings/index.ts` e em nenhum outro lugar.
:::

## `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.

```bash
pnpm run benchmark            # table
pnpm run benchmark -- --json  # machine-readable
```

Substitua a configuração da varredura sem editar o arquivo:

```bash
SWEEP_DECISIONS=10,50 SWEEP_REUSE_PCTS=0,50,90 pnpm run benchmark
```

Uma execução real:

```txt
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
```

O fato de a coluna `savings%` acompanhar a coluna `reuse%` em uma proporção de 1: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](/how-it-works) — as mecânicas de assinatura e ledger que ambos os benchmarks exercitam
- [Início rápido](/quickstart) — integre isto ao seu próprio agente para obter seus próprios números reais
