// concepts · comparison
Okami vs other agents
Technical positioning for people comparing coding agents. Competitor capabilities change by release; this table focuses on public architecture and what Okami tries…
Quick read
Claude Code and Codex are strong provider-oriented development surfaces. Hermes, OpenHands, OpenClaw and similar projects explore agents, browsers, skills or remote workspaces. Okami sits on a different axis: a local-first, multi-channel, auditable harness with completion criteria, policy and gates built into the product.
When to choose what
| scenario | best fit | why |
|---|---|---|
| pair programming inside the editor | Codex / Claude Code | the provider-native surface has less friction and better IDE/terminal integration |
| verifiable automation outside the IDE | Okami | okami task requires exit criteria, audit, events and replay |
| bot/API/remote channel | Okami | the same runner serves CLI, gateway, Telegram, Paperclip and HTTP API |
| browser or remote workspace experiments | Hermes / OpenHands / OpenClaw | some projects prioritize web UI, browser control or hosted environments |
| local, auditable governance | Okami | ToolSpec, sandbox, approval, checkpoints and logs stay in the workspace |
| dimension | Okami | Claude Code / Codex | Hermes / OpenHands / OpenClaw |
|---|---|---|---|
| surface | CLI/TUI, task runner, gateway, API, Telegram and Paperclip | terminal/IDE plus provider workflows | varies: web, browser, remote workspace or agent UI |
| verifiable completion | task_complete is checked by exit criteria and gates | usually optimized for assisted execution and final answer | varies by project; often inferred from logs and UI state |
| skills | scanned SKILL.md, documented and loaded on demand | product instructions, commands and context | skills/plugins exist, but do not always become operational gates |
| governance | ToolSpec danger, approval, sandbox, checkpoints and audit | governance integrated into the provider product | often configurable, less centered on a local contract |
| channels | same runner for terminal, bot, API and issue heartbeat | primarily a development surface | depends on project and deployment |
| models | swappable provider and fallback by config | optimized for the native model/ecosystem | varies; often OpenAI-compatible or provider-specific |
| docs | editorial docs plus generated skills/tools/commands/config reference | extensive official product docs | good guide coverage, less tied to a local repo snapshot |
Honest tradeoffs
| decision | gain | cost |
|---|---|---|
| local-first | control over files, credentials, logs and sandbox | the user operates local dependencies such as Docker, provider CLIs and tokens |
| explicit harness | more predictable replay and completion criteria | more concepts to learn than a simple chat UI |
| skills as files | auditable, versionable and documentable | bad skills need scan, review and gates |
| multi-provider | workflows are not locked to one model | each provider needs correct auth and capability profile |
The difference must be provable
- Okami's promise is strongest when a task leaves evidence: events, audit, replay, exit criteria and final artifact.
- The docs should stay synchronized with the main repo, so generated references fail coverage when capabilities disappear.
- The best benchmark is not only answer quality: it is verifiable completion rate across different models using the same workflow.
Evaluate without marketing
okami task "create hello.txt with hi" -e file_exists:hello.txt -e "file_contains:hello.txt:hi"measure verifiable completionokami events -n 40confirm trajectory and final stateokami replay --jsonreconstruct the run for auditokami policy check --strictmeasure operational readiness before exposure