Updated May 20, 2026.
oh-my-pi
is a terminal coding agent shipped as omp. It started as a fork of Mario Zechner’s Pi
, then grew into a much heavier harness: terminal UI, model routing, hash-anchored edits, LSP, debugger control, browser automation, subagents, provider auth, local execution, and project memory.
The short version: this is not another thin chat wrapper around grep and sed. omp is trying to make the terminal agent feel closer to an IDE that can read, edit, search, debug, browse, and split work without leaving the same session.
That is also why it deserves more caution than a toy CLI. If you point it at a real repo with shell, browser, GitHub, memory, and subagents enabled, you are giving it a lot of surface area. Good. Dangerous. Useful. Pick two, then add permissions.
Should you use it?
| You want | oh-my-pi fit | Why |
|---|---|---|
| A terminal-first coding agent | Strong | omp is built around the CLI/TUI, not an IDE extension pretending to be a terminal. |
| Better edits than line-number patches | Strong | Hashline anchors point at content, so stale or drifting edits can be rejected before corrupting a file. |
| Real code intelligence | Strong | LSP operations let the agent use diagnostics, references, symbols, renames, and code actions. |
| Debugger-driven repair | Strong, if configured | The debug tool speaks DAP, so it can inspect stack frames and variables instead of guessing from logs. |
| Cheap background workers | Strong | task can fan out subagents into isolated worktrees and return structured findings. |
| A quiet, locked-down assistant | Mixed | It can be scoped, but the point of the project is a powerful harness. You need to configure the blast radius. |
| A polished SaaS product | Weak | This is fast-moving open source infra. Expect churn, sharp edges, and frequent releases. |
If your baseline is Claude Code, Codex, Cursor, or OpenCode, the useful comparison is not “which model is smarter?” It is “which harness gives the model better tools and fewer ways to mess up the file system?” That is where omp is interesting.
Install paths
The README lists four install paths.
curl -fsSL https://omp.sh/install | sh
Or with Bun:
bun install -g @oh-my-pi/pi-coding-agent
Windows uses PowerShell:
irm https://omp.sh/install.ps1 | iex
There is also a mise path for pinned versions:
mise use -g github:can1357/oh-my-pi
The npm package is @oh-my-pi/pi-coding-agent
, with omp as the CLI binary. The project currently targets macOS, Linux, and Windows, with Bun as the recommended runtime. The official docs live at omp.sh
, including the tools reference
and provider routing reference
.
Use the install script if you want the shortest path. Use Bun or mise if you care about reproducible agent environments across machines.
The README links the benchmark discussion to the harness problem : same model, better tool format, fewer retries. That is the right place to look if you want the detailed numbers instead of the marketing line.
What makes it different
Most terminal agents have the same failure mode: the model gets a shell, a file reader, and a brittle edit command, then spends half the task recovering from bad patches and missing context.
omp attacks that harness problem directly.
1. hashline edits instead of line-number surgery
The headline feature is hash-anchored editing. The model points at content anchors instead of guessing line numbers or reprinting entire blocks. If the file changed under it, anchors diverge and the edit can fail safely.
That matters because agentic coding usually dies from boring mechanical errors: wrong hunk, whitespace mismatch, stale file, partial replacement, retry loop, then a giant diff nobody wants to review.
Hashline does not make the model wise. It just removes one of the stupidest ways for it to break things.
2. LSP is part of the write path
omp wires language-server operations into the agent surface. That means references, symbols, diagnostics, rename, code actions, and raw LSP requests are available from the same tool system as read and edit.
This is the difference between:
search for oldName, replace all matches, pray
and:
ask the language server what oldName means, rename it, then verify no references are left
For typed codebases, that is a big deal. It moves the agent away from text-only hacking and closer to how a decent IDE already understands a project.
3. the debugger is not decorative
The project exposes DAP debugger operations through a debug tool. The README shows lldb, dlv, and debugpy examples: native binaries, Go services, Python processes.
That gives an agent a much better loop for runtime bugs:
- reproduce the failure,
- attach or launch a debugger,
- inspect stack and variables,
- patch the cause,
- run the test again.
Most coding agents still simulate that with print statements and vibes. Debugger control is the right direction.
4. subagents return structured work
The task tool can split work across subagents, optionally in isolated worktrees. The useful part is not “parallel agents”, because everyone can spawn chaos now. The useful part is typed, schema-validated results that the parent can read without scraping prose.
Use that for jobs like:
- one worker audits API behavior,
- one worker checks UI routes,
- one worker reviews tests,
- parent merges only the findings that survived verification.
That is the shape autonomous coding should have: parallel search, narrow writes, explicit receipts.
5. the tool surface is broad
The README claims 32 built-in tools and lists the important families:
| Area | Tools / behavior |
|---|---|
| Files and search | read, write, edit, ast_edit, ast_grep, search, find |
| Runtime | bash, eval, recipe, ssh |
| Code intelligence | lsp, debug |
| Coordination | task, irc, todo_write, job, ask |
| Outside apps | browser, web_search, github, image generation/inspection, Mermaid render |
| Memory and state | retain, recall, reflect, checkpoints, rewind |
The design choice is smart: GitHub PRs, issues, skills, rules, and other internal resources are treated like filesystem-shaped paths where possible. Fewer bespoke tool schemas means fewer chances for the model to learn the wrong interface.
Provider routing
omp is model-provider agnostic. The README lists direct APIs, OAuth/provider-plan routes, local OpenAI-compatible endpoints, fallback chains, path-scoped model roles, and round-robin credentials.
The practical version:
| Need | Route |
|---|---|
| normal coding | default role |
| cheap parallel workers | smol role |
| deeper reasoning | slow role |
| planning before edits | plan role |
| commit messages / changelogs | commit role |
| local/private experiments | Ollama, LM Studio, llama.cpp, vLLM, or LiteLLM |
This is where omp fits the Personal AI OS thesis better than most agent CLIs. The model is not the product. The routing, permissions, tools, memory, and receipts are the product.
Good first smoke test
Do not throw omp at your main repo and ask it to refactor auth. That is how you get modern art in git diff.
Create a scratch branch and run a tiny, reviewable task:
git checkout -b test/omp-smoke
omp
Then ask:
Read the project instructions and summarize the active rules. Find one small lint, type, or docs issue. Propose the change first. If you edit, keep it to one file. After the edit, show the diff and explain how you verified it.
Pass criteria:
- It reads project instructions before touching code.
- It can explain which tools are available and which ones it will use.
- It proposes before editing if the task is ambiguous.
- The diff is small enough to review in one screen.
- It uses tests, typecheck, lint, LSP diagnostics, or another concrete verification step.
- It does not invent a huge cleanup because it got bored.
If it fails this smoke test, fix configuration before giving it a real task.
Configuration decisions that matter
The exact config surface moves quickly, so treat the official docs as source of truth. But the operational questions are stable:
| Question | Why it matters |
|---|---|
| Which tools are enabled by default? | A coding agent with shell, browser, GitHub, and memory is powerful enough to make expensive mistakes. |
| Which model role handles edits? | Cheap models can inspect and summarize. Risky writes deserve a better model or stricter approval. |
| Are subagents isolated? | Parallel workers should not stomp the same checkout. Isolated worktrees make review sane. |
| Where does memory live? | Project memory should not leak across clients, jobs, or private repos by accident. |
| What requires approval? | File deletes, shell commands, browser actions, GitHub writes, and secrets-adjacent reads should not be silent. |
| How are receipts kept? | You want diffs, tests, logs, PR links, and task results, not “done” from a black box. |
My default stance: start with read/search/LSP on, edits gated, shell gated, browser off, GitHub write actions off, memory explicit. Then loosen only after the agent proves it can work cleanly.
Where it fits in the agent stack
Think of omp as a coding-workspace layer inside a broader Personal AI OS stack.
It does not replace:
- your repo instructions,
- your review process,
- CI,
- secret hygiene,
- human judgment around architecture.
It can replace or compete with:
- a thin terminal chat wrapper,
- an IDE-only coding agent when you mostly live in tmux/ssh,
- ad hoc shell scripts around PR review,
- manual “search, inspect, patch, test” loops for routine repo work.
The strongest use case is not “make me an app”. The strongest use case is controlled repo work with receipts: inspect this branch, find the regression, split the commit, run the test, explain the diff.
Caveats
- The repo is moving fast. The public README and package version can change weekly or faster.
- Install scripts are convenient, but teams should pin versions before standardizing on it.
- Browser and Electron-app automation are high-risk surfaces. Keep them off until you need them.
- Memory is useful only if it stays scoped. Cross-project memory leakage is a footgun.
- Provider-plan routing can hide cost/account boundaries. Know whether a turn uses API billing, OAuth, a coding plan, or a local model.
- Debugger and LSP support depend on the target language and workspace setup. Broken local tooling means a weaker agent.
- A better harness still cannot save a vague task. Bad instructions produce bad diffs with better ergonomics.
Related self.md pages
| Page | Why it matters |
|---|---|
| Best Claude Code plugins | Useful comparison point for agent-extension ecosystems. |
| Agent config files compared | Decide what belongs in AGENTS.md, CLAUDE.md, local memory, or tool-specific rules. |
| Personal AI OS tools | Places omp inside the larger stack: memory, tools, workflows, receipts, and custody. |
| AI coding assistants | Broader category page for coding agents and assistant surfaces. |
| Skills library | Adjacent layer: reusable agent instructions and task packs. |