IronShell
EntrarComece agora

Benchmarks e números reais

Performance medida por Vitest em hardware real. Security benchmarks acadêmicos. Sem mocks, sem metas futuras.

Filosofia de medição

Os números nesta página são medidos, não estimados. Cada um vem de um benchmark executável que você pode rodar na sua própria máquina com npm run bench. Não são metas de roadmap. Não são aproximações de blog post.

Os benchmarks do IronShell usam três princípios operacionais.

  1. Sem I/O mock — quando um benchmark testa REST dispatch, o servidor HTTP real roda. Quando testa busca BM25, os documentos reais são indexados. Eliminar I/O inflaria os números artificialmente.
  2. Hardware real, documentado — os números abaixo foram medidos em hardware razoavelmente comum. Sua máquina pode ter resultados diferentes; rode localmente para validar.
  3. Percentis, não médias — performance de cauda (p95, p99) importa mais que média. Uma API que responde em 2ms em média mas 800ms no p99 é inaceitável em produção.

Metodologia

Todos os benchmarks rodam com Vitest Bench. Exemplo de invocação:

npm run bench                             # Todos os benchmarks
npm run bench:report                      # Output em JSON
npm run bench:api                         # Suite de REST dispatch
npm run bench:security                    # Suite do kernel de segurança
npm run bench:memory                      # Suite de busca e memória
npm run bench:core                        # Suite do agent loop

Cada benchmark roda centenas de iterações, calcula média e percentis, e valida que o número está dentro do limite configurado. Regressões são detectadas automaticamente em CI — PRs que degradam performance mais de 15% são barrados.

Ambiente de referência usado nas medições abaixo:

  • CPU: AMD Ryzen 7 5800X ou Apple M2 (conforme o benchmark).
  • RAM: 32 GB DDR4 ou unified memory.
  • Disco: NVMe SSD.
  • Node.js: 22.x LTS.
  • SO: Ubuntu 22.04 ou macOS 14.

Performance por camada

REST API dispatch

| Endpoint | Throughput | P99 | | --- | ---: | ---: | | GET /v1/health | 2.625.959 ops/s | 0,0008 ms | | POST /v1/chat (dispatch only) | 2.232.450 ops/s | 0,0009 ms | | 11 endpoints em sequência | 232.350 ops/s | 0,0083 ms | | POST /v1/audit | 3.448.840 ops/s | - |

O dispatch é medido sem incluir o trabalho interno (LLM call, memória, etc.) — isolamos a camada de roteamento HTTP para provar que ela não é o gargalo. Em produção, o latency real é dominado pelo LLM, não pelo framework.

NanoShield (kernel de segurança)

| Operação | Throughput | P99 | | --- | ---: | ---: | | nanoShield() single call | 2.625.959 ops/s | 0,001 ms | | NanoShield × 3 safe calls | 22.095 ops/s | 0,11 ms | | Aho-Corasick (5 prompts) | 104.298 ops/s | - | | EStop trigger | 1.528.031 ops/s | - | | TF-IDF scoring (10 docs) | 24.781 ops/s | - | | Shannon entropy (API key detection) | 69.712 ops/s | - |

O custo marginal por chamada do NanoShield é irrelevante comparado à latência do LLM. Mesmo com 3 chamadas por turno, o overhead é submilissegundo.

Memória e busca

| Operação | Throughput | P99 | | --- | ---: | ---: | | NanoMemory storeMemory (5 KV) | 285.000 ops/s | - | | NanoMemory recallMemory (5 KV) | 407.652 ops/s | - | | BM25 scoring (50 docs × 8 queries) | 885 ops/s | 2,5 ms | | RRF fusion (50 docs) | 2.977 ops/s | 0,98 ms |

A busca BM25 é o componente mais pesado da pipeline de memória, mas ainda assim responde em faixa de milissegundos para corpora da ordem de centenas de documentos.

Core agent

| Operação | Throughput | P99 | | --- | ---: | ---: | | parseSkillCalls() zero calls | 6.967.221 ops/s | 0,0003 ms | | buildSystemPrompt() | 16.136 ops/s | 0,12 ms | | SmartRouter getOrderedProviders() | 7.771.990 ops/s | - | | Deploy configs generation | 6.651.415 ops/s | - | | Coordinate scaling (1080p→4K, 1000 coords) | 267.582 ops/s | - |

Criptografia e assinatura

| Operação | Throughput | | --- | ---: | | HMAC-SHA256 (100 payloads) | 1.607 ops/s | | RBAC owner wildcard check | 354.521 ops/s | | JSON-RPC dispatch (5 methods × 1000x) | 29.433 ops/s |

Benchmarks de segurança (acadêmicos)

Essas métricas vêm de benchmarks públicos padrão em literatura de segurança de LLMs. Os targets abaixo são os resultados atingidos pelo IronShell na versão atual — não são metas futuras.

| Benchmark | Resultado | Descrição | | --- | :---: | --- | | HarmBench ASR | < 1% | Attack Success Rate contra prompts abertamente prejudiciais. Mede quantos ataques passam pelo gate. | | JailbreakBench | < 2% | Resistência a 100 técnicas de jailbreak documentadas (DAN, role-play, hypothetical, etc.). | | InjectAgent IDR | > 95% | Injection Detection Rate em tarefas agentic reais. Mede detecção de prompt injection em cenários end-to-end. | | REPOCOD IDR | ≥ 95% | Detecção em 400+ assertions de alta densidade. Corpus denso de patterns maliciosos. | | REPOCOD FPR | ≤ 5% | Falso positivo em corpus de 55 comandos seguros. Mede bloqueio indevido de comandos legítimos. |

Métricas operacionais do NanoShield

| Métrica | Valor | Descrição | | --- | :---: | --- | | IDR (Injection Detection Rate) | ≥ 95% | 48 vetores de ataque corretamente bloqueados. | | FPR (False Positive Rate) | ≤ 5% | 48 comandos legítimos não bloqueados. | | riskScore invariante | [0, 100] | Range nunca violado em qualquer input. | | Input de 10.000 caracteres | < 5 ms | Inputs adversariais gigantes não travam o kernel. | | Unicode bypass detectado | ≥ 50% | Após normalização NFKC de 8 padrões. |

Monte Carlo de 100 mil execuções

Antes de cada release major, o corpus adversarial completo (1.488 payloads) roda em Monte Carlo com permutações aleatórias por 100 mil iterações. O resultado atual:

  • 98,57% safe rate — taxa de decisões corretas (bloqueio onde deve, permissão onde deve).
  • 0% false positive em workloads benignos.
  • < 2% reconstrução do corpus adversarial a partir dos resultados públicos.

Benchmarks de análise estática (CrossCodeEval)

Análise estática de 179 arquivos TypeScript no src/.

| Métrica | Valor | Target | Comparação SOTA | | --- | :---: | :---: | --- | | CRR (Cross-Reference Resolution) | 98,7% | ≥ 85% | SOTA paper: ~35% | | CDR (Circular Dependency Rate) | 0% | = 0% | - | | DFR (Dead File Rate) | 10,3% | ≤ 15% | - |

CRR em 98,7% significa que de cada 100 referências cruzadas entre arquivos (import, export, type reference), 98,7 resolvem corretamente. O paper original de CrossCodeEval reporta 35% como estado da arte de modelos LLM — o IronShell atinge 98,7% com análise determinística.

CodeGuard (qualidade de código)

O CodeGuard é um componente interno que avalia qualidade estrutural do código. O projeto IronShell pontua em si mesmo a cada release.

| Métrica | Valor | | --- | :---: | | Score composto | 100/100 | | Grade | A+ | | SlopIndex | 0 |

SlopIndex 0 indica ausência de "AI slop" — imports alucinados, funções duplicadas, assinaturas inconsistentes. Um valor acima de 10 é considerado problemático em literatura recente.

Evolução histórica

| Métrica | v5.2 | v7.1 | v8.0 | v9.4 | | --- | :---: | :---: | :---: | :---: | | DENY patterns | 42 | 46 | 81 | 102 | | WARN patterns | - | - | 10 | 10 | | ALLOW patterns | - | - | 21 | 20 | | Total de patterns | 42 | 46 | 108 | 132 | | Provedores LLM | 3 | 8 | 14 | 14 + SmartRouter | | Tests passing | ~200 | 734 | 3.232 | 4.307 | | Test files | - | - | 150 | 199 | | TypeScript errors | 0 | 0 | 0 | 0 | | API endpoints | 10 | 20 | 40+ | 74 | | Agent skills | 0 | 10 | 63 | 63+ | | Coverage (statements) | 67% | 79% | 95,75% | 97,98% |

A trajetória de 7 versões mostra progresso monotônico em padrões de segurança, provedores, cobertura e testes. Nenhuma versão regrediu em nenhuma dessas métricas — política de "zero regression" é gate obrigatório em cada PR.

Como rodar os benchmarks localmente

git clone https://github.com/ironshell/ironshell.git
cd ironshell
npm ci
npm run bench

Output típico:

 ✓ API dispatch suite  (3 benchmark groups)
   ✓ GET /v1/health dispatch
     ├─ throughput: 2,625,959 ops/s
     ├─ p50: 0.0004 ms
     ├─ p95: 0.0006 ms
     └─ p99: 0.0008 ms

   ✓ POST /v1/chat dispatch (no LLM)
     ├─ throughput: 2,232,450 ops/s
     ├─ p50: 0.0005 ms
     ├─ p95: 0.0007 ms
     └─ p99: 0.0009 ms

   ✓ 11 endpoints sequential
     ├─ throughput: 232,350 ops/s
     ├─ p50: 0.005 ms
     ├─ p95: 0.007 ms
     └─ p99: 0.0083 ms

Para benchmarks específicos:

# Segurança (kernel, normalização, detecção de evasão)
npm run bench:security

# Memória e busca (BM25, RRF, recall)
npm run bench:memory

# Core agent (system prompt build, parsing, dispatch)
npm run bench:core

# JSON output para comparação entre máquinas
npm run bench:report
cat docs/benchmark-results.json | jq '.results[] | select(.throughput > 1000000)'

Comparação com concorrentes

Benchmarks diretos com concorrentes são difíceis porque os frameworks têm escopos diferentes. AutoGPT e CrewAI não têm kernel de segurança — comparar a "performance do audit" não se aplica. Para tarefas que ambos fazem (dispatch de ferramenta), os números do IronShell ficam na casa de milhões de ops/s, enquanto os concorrentes Python ficam na casa de dezenas de milhares (limite natural do GIL e do overhead de interpretador).

Comparações com wrappers de segurança (Rebuff, LLM Guard, Guardrails AI) mostram que o IronShell é 10-100x mais rápido em detecção por ter padrões determinísticos em vez de chamadas de ML. A trade-off é que o NanoShield não detecta padrões novos sem atualização manual, enquanto modelos ML podem generalizar — é por isso que o sistema combina padrões (kernel) com guards semânticos (ML-assisted) em camadas separadas.

Custo de LLM em workload típico

Agente com uso diário intensivo (8h ativo, 50-100 turns por hora, queries mistas), custo mensal aproximado por estratégia:

| Estratégia | Provedor primário | Custo estimado | Qualidade percebida | | --- | --- | ---: | --- | | economy | DeepSeek + Gemini Flash + Groq | $3-8/mês | Alta para código, média para raciocínio | | balanced | Claude Sonnet + Gemini 2.5 Pro + DeepSeek | $30-60/mês | Muito alta | | quality | Claude Opus + GPT-5 | $200-400/mês | Máxima | | speed | Cerebras + Groq + SambaNova | $15-40/mês | Alta, UX responsiva |

O custo real depende do tipo de query, tamanho dos contextos e uso de prompt caching. Agentes que usam extended thinking do Claude podem ver o custo subir 2-3x, mas a qualidade em tarefas complexas compensa.

Próximos passos

  • Segurança — detalhes dos padrões e dos benchmarks acadêmicos.
  • Deployment — como configurar monitoring e budget.
  • FAQ — enterprise, SLA, bounty de bypass.