Números completos do benchmark
Atualizado em 02/10/2026Tudo que sustenta os números da página do produto: como foram medidos, os quatro cenários nos dois conjuntos de tarefas, a evolução da busca e todas as ressalvas.
Sumário
Metodologia
Medido num monorepo real operado ao mesmo tempo por várias ferramentas de IA, com cerca de 690 documentos markdown e uma base de conhecimento mantida desde 06/09/2026.
Régua de tokens: caracteres ÷ 3,7, razão medida no próprio protótipo do produto (245 KB ≈ 66 mil tokens). A mesma régua em todos os cenários; o que importa são as proporções entre eles. Quem preferir, pode trocar por um tokenizer real (--tokenizer cl100k via tiktoken, se instalado).
Teto de leitura: 2.000 linhas por arquivo lido em qualquer cenário, o mesmo padrão da ferramenta de leitura de arquivo do Claude Code. A saída de grep mostrada ao agente simulado é limitada a 200 linhas.
Como os cenários foram simulados: para cada tarefa, o benchmark roda os quatro cenários e verifica se o(s) arquivo(s)-gabarito (tirados da própria tabela do router.md) aparecem entre os lidos:
- nada: sem base navegável: grep pelos termos da pergunta, lê os 3 arquivos mais relevantes.
- grafo de código: consulta a um grafo de código e lê o arquivo certo se ele aparecer; senão, cai no grep.
- router: lê o router e o(s) arquivo(s) que ele indica.
- GuardianContext:
guardian index search(top-5) e lê o arquivo certo se aparecer; senão, cai no router.
Os cenários nada e grafo de código simulam uma passada determinística de busca, sem o comportamento iterativo de um modelo real. Ver ressalvas.
Custo fixo por sessão
Tudo que o agente lê em toda sessão, antes de abrir um arquivo de código, é pago de novo a cada sessão de cada ferramenta. A série histórica do quadro de trabalho no repositório de referência:
| Data | Estado do quadro | Tokens por sessão |
|---|---|---|
| 14/09/2026 | Diário dentro do quadro de trabalho | ~66.000 |
| 14/09/2026 | Reestruturado como stub | ~5.600 |
| 25/09/2026 | Voltou a crescer (307 linhas) | ~12.000 |
| 26/09/2026 | Stub de novo, histórico em pasta própria | ~4.000 |
| 26/09/2026 | Regras do quadro movidas para a wiki | ~3.500 |
Custo fixo total medido hoje (router + quadro + arquivos de instrução da raiz): ~7.800 tokens por sessão. O auditor acompanha isso: quadro acima do orçamento é aviso, acima de 3× é erro, com a estimativa de tokens na própria mensagem. Foi assim que o crescimento de 25/09 foi detectado.
Os quatro cenários, nos dois conjuntos de tarefas
Dois conjuntos de tarefas testam o mesmo repositório: um escrito como um agente perguntaria (sem as palavras do router; mede busca de verdade) e outro reutilizando as palavras do próprio router (viés lexical, favorece qualquer busca; mostra o teto).
12 tarefas parafraseadas
| Cenário | Tokens totais | Por tarefa | Acerto em 1º | Acerto no top-5 |
|---|---|---|---|---|
| Sem base de conhecimento (grep e leitura) | 2.489.961 | 207.497 | 0/12 | 1/12 |
| Só um grafo de código | 1.399.811 | 116.651 | 5/12 | 5/12 |
| Wiki com router bem mantido | 58.595 | 4.883 | 12/12 | 12/12 |
| GuardianContext | 56.390 | 4.699 | 5/12 | 7/12 |
13 tarefas com as palavras do router
| Cenário | Tokens totais | Por tarefa | Acerto em 1º | Acerto no top-5 |
|---|---|---|---|---|
| Sem base de conhecimento (grep e leitura) | 465.770 | 35.829 | 2/13 | 4/13 |
| Só um grafo de código | 422.366 | 32.490 | 3/13 | 3/13 |
| Wiki com router bem mantido | 68.935 | 5.303 | 13/13 | 13/13 |
| GuardianContext | 56.381 | 4.337 | 6/13 | 9/13 |
Contra não ter nada, o GuardianContext custou 8 a 12 vezes menos por tarefa. Contra só um grafo de código, cerca de 7 vezes menos, mas essas tarefas são de processo e regra, não de código. Um grafo de código é feito para a outra pergunta ("quem chama esta função?"), e no mesmo repositório ele mediu 144,3× de redução por consulta de código. As duas ferramentas respondem a perguntas diferentes e se somam. Contra um router já bem mantido, o ganho é pequeno (4% a 18%); o valor do GuardianContext aparece onde o router não existe ou envelhece.
Acerto top-1/top-5 e evolução da busca
Nas 12 tarefas parafraseadas, a mesma busca evoluiu entre duas versões da ferramenta:
| Versão | Acerto em 1º | Acerto no top-5 | Tokens da busca | Custo realista |
|---|---|---|---|---|
| 0.1.3: embedding por página | 3/12 | 6/12 | 3.896 | 58.281 |
| 0.1.4: trechos + arquivos de instrução | 5/12 | 7/12 | 3.690 | 57.233 |
"Tokens da busca" é só o custo do índice (trechos retornados); "custo realista" soma a leitura do arquivo encontrado. A versão 0.1.4 (trechos + arquivos de instrução) acertou mais no top-5 gastando um pouco menos de tokens de busca. O ganho veio de indexar em unidades menores, sem aumentar o top-k.
Detalhe por tarefa
As 12 tarefas parafraseadas, descritas de forma genérica (sem nomes de arquivo do repositório medido), com os tokens gastos em cada cenário até achar a resposta:
| Tarefa | Nada | Grafo | Router | GuardianContext | Achou em 1º |
|---|---|---|---|---|---|
| Regras de git antes de um commit em árvore compartilhada | 269.768 | 8.590 | 7.634 | 7.123 | Sim |
| Por que a branch principal diverge do que roda em produção | 269.376 | 271.144 | 7.634 | 7.980 | Não |
| Alterar regras de segurança do banco de dados e permissões de administrador | 181.691 | 183.480 | 7.847 | 8.128 | Não |
| Publicar funções serverless com segurança, cuidados de deploy | 252.600 | 3.738 | 2.820 | 2.254 | Sim |
| Gerar builds de release mobile e publicar a versão web | 162.745 | 164.532 | 3.743 | 3.230 | Sim |
| Editar o site institucional e sincronizar com o servidor | 176.412 | 2.853 | 1.879 | 1.320 | Sim |
| Por que uma tela funciona de determinado jeito, qual decisão explica | 45.950 | 47.718 | 7.453 | 6.876 | Sim |
| Saber se outra sessão está editando o mesmo arquivo agora | 263.037 | 264.796 | 4.404 | 4.752 | Não |
| Qual nome mostrar ao usuário para cada agente de IA do produto | 275.819 | 277.612 | 1.945 | 1.373 | Sim |
| Onde fica cada subprojeto do monorepo e quem hospeda o quê | 161.941 | 2.350 | 1.379 | 819 | Sim |
| Como registrar uma decisão nova de feature, qual modelo usar | 268.755 | 8.378 | 7.453 | 7.771 | Não |
| Como registrar que comecei ou terminei uma tarefa | 161.867 | 164.620 | 4.404 | 4.764 | Não |
Conciliação entre ferramentas
No repositório medido, guardian instrucoes status encontrou 5 lacunas: regras de segurança e da janela de push (210 linhas) ficavam invisíveis para uma família de ferramentas, e regras de contratos (266 linhas) ficavam invisíveis para a outra, já que cada família só lê o próprio arquivo de instrução. Uma regra que o agente não carrega pode custar o incidente que ela existia para evitar. guardian instrucoes sync concilia com um bloco de ponteiro em cada arquivo, sem copiar conteúdo e sem mudar nenhuma ferramenta.
Ressalvas
- Os cenários nada e grafo de código simulam uma passada determinística de busca; um agente real pode buscar de forma iterativa, com outros termos, ou desistir antes. Os números são uma estimativa de ordem de grandeza, não uma medição do comportamento de um modelo.
- Tarefas derivadas do router carregam as palavras do router (viés lexical); por isso existem os dois conjuntos nesta página, e o
--gerar-casospara cada usuário escrever o próprio conjunto. - Um único repositório de referência. Os números do seu repositório vêm do seu próprio
guardian benchmark. - Contra um router já bem mantido, o ganho medido é pequeno (4% a 18%): o valor do GuardianContext aparece onde não existe wiki organizada ou onde ela envelhece, e não substitui uma wiki que já funciona.
Reproduza com guardian benchmark
Todo número desta página sai de um comando que roda no seu próprio repositório. Nada é enviado a lugar nenhum além dos arquivos que você pedir:
guardian index rebuild --semantic
guardian benchmark --markdown relatorio.md --json relatorio.json
guardian benchmark --gerar-casos casos.json # edite as perguntas com suas próprias palavras
guardian benchmark --casos casos.json --markdown relatorio.mdDetalhes de cada flag na seção "Medir economia" do manual.
MCP local e atualização segura
Versão publicada · 0.1.9 · 2026-10-02
Sessões de diferentes clientes podem descobrir pares e trocar mensagens no mesmo repositório. O desktop reúne configuração MCP, sessões, envio humano e estado da atualização.
Metas de operação
A recuperação deve preservar as mensagens. Envios incertos aguardam uma decisão humana, e a atualização espera os clientes fecharem. Ainda faltam medições de produção para estimar uma taxa de sucesso fora destes cenários.
Resultados medidos na simulação local
20 amostras de entrega · Windows · 0.1.9 · Data UTC: 2026-10-02T14:23:42.104847+00:00
| Cenário | Passaram / total |
|---|---|
| Entrega, idempotência e confirmação de leitura | 20 / 20 |
| Recusa de aprovação com ID coincidente | 1 / 1 |
| Resposta RPC malformada | 1 / 1 |
| Adiamento com runtime em uso | 1 / 1 |
| Falha no journal antes de instalar | 1 / 1 |
| Rollback e restauração do SQLite | 1 / 1 |
SQLite local: p50 49.082 ms · p95 68.97 ms.
A simulação usa SQLite, protocolo RPC e locks reais, com modelo e instalação/probe simulados. Os resultados cobrem esses caminhos locais. Qualidade das respostas, rede, SLA e upgrade nativo precisam de testes próprios.
Canário com modelos reais
Em 2 de outubro de 2026, o canário local da 0.1.9 usou GPT-6 Astra e Claude no mesmo repositório: 10 mensagens, seis confirmações pelos modelos e quatro pelo coordenador após ler as respostas. A comunicação nos dois sentidos, a idempotência, a entrega após reinício do broker e a retomada de uma sessão offline passaram nas etapas executadas.
Criação até confirmação pelos modelos: mínimo 2,85 s, mediana 8,40 s e máximo 74,20 s, em seis amostras. Os tempos incluem espera offline e turnos ocupados. Esses dados não estimam qualidade das respostas, latência típica ou SLA de produção. Não houve nova indução de revogação ou timeout nos modelos reais; esses casos ficaram nos testes dirigidos.
Fonte: relatório do canário e limites da execuçãoReproduzir no aplicativo ou desktop
guardian simulate --samples 20 --json result.jsonNo desktop, abra Operação e clique em Executar simulação. Consulte o último resultado também em Métricas. Você escolhe quando exportar o JSON; o aplicativo não o envia automaticamente.
