Vanilla Pi vs Oh My Pi — the Decision Guide

Lesson 10: Vanilla Pi vs Oh My Pi — the Decision Guide

You now know both harnesses. The honest answer to "which should I use?" is: it depends on what you optimize for. Here is the comparison and a practical decision path.

Dimension	Vanilla Pi (pi.dev)	Oh My Pi (omp.sh)
Engine	TypeScript/Node core, Earendil-maintained	Fork with ~80k-line native Rust engine, Bun runtime
Default tool surface	4 tools (read/write/edit/bash) + optional read-only helpers	31 built-in tools across files, runtime, LSP, DAP, subagents, browser
Extension model	TypeScript extensions: events, tools, commands, UI, state	Same lineage, plus its own tool/devices surface (xd://), magic keywords, roles
Skills	Agent Skills standard, on-demand SKILL.md	Agent Skills + managed skills via learn/manage_skill
Packages	First-class: npm/git packages bundling all resource types	Not the focus; config is ~/.omp/agent/*.yml + rules import
IDE wiring	Terminal-first	LSP + DAP built in; ACP for editor (Zed) integration
Memory	Session tree + compaction + branch summaries	That plus agent-curated memory banks (retain/learn/recall, pluggable backends)
Model routing	/model + /scoped-models + thinking levels	Ten named roles (smol/slow/plan/advisor/…) with per-role fallback chains
Config	settings.json + models.json (JSON)	config.yml + models.yml (YAML)
Team rules	AGENTS.md context files	Reads Cursor MDC, Cline, Codex AGENTS.md, Copilot applyTo natively
Update cadence	Stable, documented releases	Fast-moving community fork

Reach for vanilla pi when…

You want a minimal, predictable core — you'd rather add exactly what you need than disable what you don't.
You want to build your own agent surface on the TypeScript extension API, SDK, RPC, or JSON modes.
You care about the packages ecosystem — sharing skills/templates/extensions via npm/git and the pi.dev gallery.
You trust Earendil's direction and want a stable, well-documented target.
You're on a constrained environment where a lean binary and a small prompt surface matter (e.g. a container, a work laptop).

Reach for omp when…

You want IDE-grade capability out of the box — LSP renames, real debugger sessions, code intelligence without setup.
You're doing token-sensitive heavy work and want the aggressive edit efficiency (hashline anchors), summarized reads, and role-based routing.
You need subagent fan-out, an advisor model, agent-curated memory, or live collaboration (/collab).
You already live in Cursor/Cline/Codex conventions and want those rule files read as-is.
You want native performance (in-process ripgrep/glob/shell, no fork/exec, real Windows support).

Token-efficiency, head to head

Pi's wins: on-demand skills, prompt-cache-aware compaction, thinking budgets, per-model cost fields, and a four-tool default surface (tiny system prompt). You control the economics with knobs, not defaults.
omp's wins: hashline edits (−61% output tokens claimed on Grok 4 Fast), summarized reads, stream rules that inject only on violation, an advisor on separate context, and role-routed models (cheap smol fan-out, expensive slow reserved for deep reasoning).
The catch: omp's 31 declared tools are a larger standing system prompt than pi's four — you can pin the surface with --tools read,edit,bash,…. Pi's package/skill ecosystem can grow your prompt too if you install everything; enable only what you use.

Practical advice: Install both. They coexist (different config dirs: ~/.pi/ vs ~/.omp/). Use vanilla pi as your everyday driver and reach for omp when a session needs debugging, refactoring across files, or heavy multi-agent work. The skills and habits transfer in both directions.

📺 Watch:

This Free Terminal Agent Made Me Delete Claude Code (Oh-My-Pi Full Test) — AI Stack Engineer — see omp do real work before you commit to it.

🧠 Knowledge Check

1. Which scenario points clearly to vanilla pi?

2. Why does omp carry a larger standing token cost than vanilla pi?

3. Can pi and omp be installed side by side?