// conceitos · comparação
Okami vs outros agentes
Posicionamento técnico para quem está comparando agentes de código. As capacidades dos concorrentes mudam por versão; a tabela foca no desenho arquitetural público…
Leitura rápida
Claude Code e Codex são excelentes superfícies de desenvolvimento orientadas por provider. Hermes, OpenHands, OpenClaw e projetos similares exploram agentes, browser, skills ou ambientes remotos. O Okami entra em outro eixo: harness local-first, multi-canal e auditável, com critérios de término, policy e gates como parte do produto.
Quando escolher cada um
| cenário | melhor encaixe | por quê |
|---|---|---|
| pair programming dentro do editor | Codex / Claude Code | a superfície nativa do provider reduz atrito e integra melhor com IDE/terminal |
| automação verificável fora da IDE | Okami | okami task exige exitCriteria, audit, events e replay |
| bot/API/canal remoto | Okami | mesmo runner serve CLI, gateway, Telegram, Paperclip e HTTP API |
| experimentos com browser/workspace remoto | Hermes / OpenHands / OpenClaw | alguns projetos priorizam UI web, browser ou ambientes hospedados |
| governança local e auditável | Okami | ToolSpec, sandbox, approval, checkpoints e logs ficam no workspace |
| dimensão | Okami | Claude Code / Codex | Hermes / OpenHands / OpenClaw |
|---|---|---|---|
| superfície | CLI/TUI, task runner, gateway, API, Telegram e Paperclip | terminal/IDE e workflows do provider | varia: web, browser, workspace remoto ou agent UI |
| conclusão verificável | task_complete passa por exitCriteria e gates | normalmente focado em execução assistida e resposta final | varia por projeto; muitas vezes depende de logs e estado da UI |
| skills | SKILL.md escaneado, documentado e carregado sob demanda | instruções/comandos e contexto do produto | skills/plugins existem, mas nem sempre viram gate operacional |
| governança | ToolSpec com danger, aprovação, sandbox, checkpoint e audit | governança integrada ao produto do provider | frequentemente configurável, mas menos centrada em contrato local |
| canais | mesmo runner para terminal, bot, API e issue heartbeat | principalmente superfície de desenvolvimento | depende do projeto e da implantação |
| modelos | provider trocável e fallback por config | otimizado para o modelo/ecossistema nativo | varia; muitas vezes OpenAI-compatible ou provider específico |
| documentação | editorial + referência gerada de skills/tools/commands/config | docs oficiais extensas do produto | boa cobertura em guias, menos ligada ao repo local |
Tradeoffs honestos
| decisão | ganho | custo |
|---|---|---|
| local-first | controle de arquivos, credenciais, logs e sandbox | o usuário opera dependências locais como Docker, provider CLI e tokens |
| harness explícito | mais previsibilidade, replay e critério de término | mais conceitos para aprender do que uma UI de chat simples |
| skills como arquivos | auditável, versionável e documentável | skill ruim precisa de scan, revisão e gate |
| multi-provider | não prende workflow em um único modelo | cada provider precisa de capability profile e auth corretos |
Diferencial que precisa ser provado
- A promessa do Okami só é forte quando a task deixa evidência: events, audit, replay, exitCriteria e artefato final.
- A documentação deve continuar sincronizada com o repo principal, por isso as referências geradas falham cobertura quando algo some.
- O melhor benchmark não é só qualidade da resposta: é taxa de conclusão verificável com o mesmo workflow em modelos diferentes.
Como avaliar sem marketing
okami task "crie hello.txt com oi" -e file_exists:hello.txt -e "file_contains:hello.txt:oi"mede conclusão verificávelokami events -n 40confirma trajetória e estado finalokami replay --jsonreconstrói a execução para auditoriaokami policy check --strictmede prontidão operacional antes de expor