Why I Chose `oh-my-pi` (`omp`) as my ai harness

There are so much harnesses out in the wild and every day new ones coming out, all with different philosophies. As I do not have a subscription like Claude or OpenAI, I want to keep my options open and be able to use different providers. During my AI journey I looked and tried different ones, where I also pi [pi], which champions a strict “Bash is all you need” minimalist ethos. Based on pi, there is [poh-my-pi][omp] (omp), a feature-heavy fork maintained by can1357 that turns terminal operations into a full-fledged, IDE-grade application runtime.

pi vs. oh-my-pi

Vanilla pi focuses on maintaining a small footprint, relying on straightforward file operations, simple execution loops, and minimal prompts (SYSTEM.md / AGENTS.md). While great for quick text manipulation or simple bash tasks, it falls short when you need deep workspace orchestration across large codebases.

omp expands the core system prompt to give the AI agent rich IDE features natively:

Key Reasons I Chose omp

A. Hash-Anchored Edits (Preventing Stale Context Rewrites)

In standard AI CLI tools, if a file changes locally while the agent is generating a response, broad search-and-replace edits will often fail or overwrite code blindly. omp embeds content-hash anchors directly into patch operations. If the source code diverges, the edit aborts gracefully before corrupting your codebase—saving up to 60%+ in wasted token correction loops.

B. Dual-Layer Memory Architecture (AGENTS.md vs. DESIGN.md)

Instead of dumping every project instruction into a single, massive system prompt on every turn, omp splits responsibilities:

• AGENTS.md (System Rules): Located at the root to govern build commands, test patterns, and strict execution rules.
• DESIGN.md (Presentation Layer): Visual guidelines, design tokens, and CSS variables. omp uses its Hindsight memory subsystem to cache this file into a persistent “mental model” rather than re-reading it on every prompt turn.

C. Native Neovim Integration via Headless RPC

Many terminal AI tools require clunky terminal-split bridges (like carderne/pi-nvim) that choke on Neovim’s terminal mode and hijack your keymaps.

The proper setup relies on alex35mil/pi.nvim running omp as a headless background daemon (omp --mode rpc). This gives you:

• Zero Keymap Conflicts: Chatting occurs inside a native Neovim prompt buffer.
• Rich Syntax Rendering: Native Tree-sitter markdown highlighting.
• Fuzzy @file Mentions: Attach files directly into context using native telescope/fzf triggers.

{
  "alex35mil/pi.nvim",
  dependencies = {
    "nvim-treesitter/nvim-treesitter",
  },
  config = function()
    require("pi").setup({
      cli = {
        command = "omp",
        args = { "--approve" },
      },
      layout = "sidebar",
    })

    local map = vim.keymap.set
    map("n", "cc", "<cmd>Pi<CR>", { desc = "OMP: Open Native Chat" })
    map("n", "cr", "<cmd>PiResume<CR>", { desc = "OMP: Resume Previous Session" })
    map("n", "ch", "<cmd>PiHistory<CR>", { desc = "OMP: View Session History" })
  end
}

Conclusion

For me omp is a nice tool and I have very good experience. Is it the one for others? Maybe, maybe not, probably depends what u need. Are there better ones? Probably yes also this depends on your use case. I primarily work on the cli, so for the omp works fine, but there are a lot of very good and powerful harnesses out there.