Oh My Pi: The Power-Tool Fork
Oh My Pi starts from Pi Mono's stripped-down terminal agent and then adds a much larger platform around it: hashline editing as the default mutation surface, a Rust native engine, MCP and plugin plumbing, swarm-style subagents, LSP, Python, browser automation, model roles, and a benchmark harness dedicated to measuring edit reliability.
What Oh My Pi Actually Is
The first thing to correct is category drift. Oh My Pi is not just the
old Pi Mono repo with a new changelog. The root README explicitly
calls it a fork of badlogic/pi-mono, but the current
workspace is much broader: the root package.json is a Bun
monorepo, the root Cargo.toml pins a matching Rust
workspace version, and the repo ships both JavaScript packages and a
native Rust engine.
At the moment the interesting question is not whether it stays as philosophically pure as Pi Mono. It does not. The question is whether the added surface still hangs together as a coherent coding agent. In practice, it mostly does because the repo keeps the center of gravity on one CLI while making the surrounding power-user systems explicit.
| Layer | Current workspace pieces | Why it matters |
|---|---|---|
| Core runtime |
packages/agent, packages/ai,
packages/coding-agent
|
Agent loop, provider adapters, tools, prompts, CLI |
| UI and UX | packages/tui, packages/stats |
TUI, session UX, stats dashboard, tool rendering |
| Delegation and evaluation |
packages/swarm-extension,
packages/typescript-edit-benchmark
|
Subagents, isolated runs, and edit-benchmark tooling |
| Native acceleration |
packages/natives, crates/pi-natives
|
Rust-backed grep, shell, text, keys, glob, image, process, clipboard, and HTML helpers |
| Shared support | packages/utils |
Dirs, logging, process control, discovery helpers |
Why People Rave About It
The repo's appeal is not one single breakthrough feature. It is that a lot of serious agent ergonomics sit in one place without hiding the machinery. The README backs that up with a very broad, very concrete feature list: LSP integration, a persistent Python tool, TTSR time-travel rules, structured review mode, role-based model routing, a todo tool, MCP support, plugin loading, browser automation, web search, image generation, and a TUI that clearly gets a lot of engineering attention.
The repo also looks unusually self-instrumented. It includes a full
typescript-edit-benchmark package, benchmark scripts for
hashline variants, native profiling support, and enough changelog
detail to show the team is iterating on editing failures at a very low
level instead of waving them away as "model issues."
Power-user surface
It exposes lots of real levers instead of pretending every feature should collapse into one magic command.
Editing obsession
Hashline is not a README gimmick. The repo contains dedicated edit modes, prompt helpers, diff previews, settings, and benchmarks.
Native fast path
The Rust addon means grep, shell, text processing, and key parsing do not all route through slower shell-outs.
How The Agent Is Put Together
The architecture is easiest to read as three layers. The provider and
session logic live in packages/agent and
packages/ai. The product glue lives in
packages/coding-agent, which owns prompts, tool
registration, edit-mode routing, config, discovery, and the CLI. Then
packages/tui and the Rust native modules make the
terminal experience faster and richer.
This matters because it explains why Oh My Pi can keep growing without becoming obviously incoherent. It is not one giant script. The bigger systems are split into packages that can still be reasoned about.
Provider layer
packages/ai handles model/provider conversions,
tool-schema adaptation, auth storage, and response plumbing.
Product layer
packages/coding-agent owns tool construction, config,
prompts, edit routing, discovery, MCP config, and session
behavior.
Delegation layer
packages/swarm-extension runs subagents as real OMP
subprocesses with full tool access against the swarm workspace.
Native layer
crates/pi-natives supplies Rust-backed performance
primitives for common tool-heavy paths.
Hashline Is the Signature Idea
The sharpest engineering difference versus older Pi Mono is the edit
system. In packages/coding-agent/src/utils/edit-mode.ts,
the default edit mode is explicitly hashline, and the
settings schema enables readHashLines by default so the
model sees line anchors in normal read output.
Those anchors are not arbitrary. In
edit/line-hash.ts, each line becomes
LINE+HASH, where the hash is a two-letter bigram chosen
from a stable set of 647 single-token BPE bigrams. Significant lines
hash independently of line number so they remain identifiable across
small shifts, while punctuation-only lines mix in the line number to
avoid collisions.
| Piece | Where it lives | Effect |
|---|---|---|
| Default mode | src/utils/edit-mode.ts |
Hashline is the normal path, not an obscure option |
| Anchor format | src/edit/line-hash.ts |
Compact line-number-plus-hash references that are friendly to model tokenization |
| Edit grammar | src/edit/modes/hashline.ts |
Explicit insert, delete, and modify blocks over anchored lines |
| Prompt helpers | src/config/prompt-templates.ts |
Template helpers compute real anchor examples instead of fake placeholder text |
Not the same as Dirac
Dirac pushes harder toward pure hash-anchored editing. Oh My Pi's hashlines still keep the line number in the address and treat hash anchors as the default dialect inside a multi-mode edit system. That makes it less singular than Dirac, but more adaptable inside one general-purpose agent.
Why Hashline Feels Different From Search/Replace
The important part is not just the anchor format. The execution path
in hashline.ts validates multi-section edits up front,
merges same-path sections so earlier sub-edits do not invalidate later
anchors, and can auto-rebase a stale anchor within a small window when
the same hash uniquely appears nearby.
That is a different failure model than Cline or OpenCode. Instead of building a long ladder of whitespace and substring fallbacks, Oh My Pi keeps the model on anchored operations and then adds narrowly-targeted recovery logic for stale references, duplicate boundaries, and preview rendering.
What it avoids
Literal old/new text reproduction, whitespace drift, and ambiguous repeated snippets.
What it accepts
A more specialized edit language, explicit read formatting, and a need to keep anchor semantics consistent across prompts and tools.
It Is Bigger Than Editing
If you only describe Oh My Pi as "the hashline editor," you miss why
the repo gets so much attention. The README and docs show a much wider
platform: project and user .omp/mcp.json config, HTTP and
stdio MCP transports with OAuth support, plugin loading under
~/.omp/plugins, browser automation, multi-provider web
search, TTSR rule injection, and a dedicated task tool with isolated
backends including git worktrees and Windows ProjFS.
That makes Oh My Pi feel much closer to a power-user operating environment than to the older minimalist Pi pitch.
MCP and discovery
The repo supports OMP-native MCP config and also discovers config from other AI tool ecosystems.
Subagents
The task tool and swarm extension make delegation a first-class capability rather than a hand-wavy future feature.
Benchmark culture
The repo ships edit-benchmark infrastructure and explicitly uses it to compare hashline against other edit variants.
Verdict
Pi Mono was interesting because it was austere. Oh My Pi is interesting because it kept that terminal-agent core and then grew a much more ambitious platform around it without abandoning concrete, debuggable engineering surfaces.
The standout contribution is still hashline: not because hashes are magical, but because the repo treats edit reliability as a systems problem with prompt helpers, grammar design, preview rendering, rebasing rules, and benchmarks all pulling in the same direction. That makes it one of the few repos here where the file-editing story genuinely changes how you should compare it to Dirac, OpenCode, Cline, and plain exact-replace tools.
Most serious edit-lab fork
Oh My Pi is the repo to study when you want a terminal agent that treats editing, tooling, and agent ergonomics as one connected design problem instead of three unrelated features.