Oh My Pi — The Open-Source Coding Agent I Actually Use Every Day

I've been building AI-assisted workflows into my daily development practice for long enough that "which model should I use?" is no longer the interesting question. The interesting question is what sits between the model and my codebase — the harness. And for the past while, that harness has been oh-my-pi.

This post is my honest accounting of why I use it, what it does differently, and what that means for the kind of work I do as a freelance developer.

What Is Oh My Pi

Oh-my-pi is a fork of Pi, an open-source coding agent written by Mario Zechner. The original Pi is a clean, minimal agent: it gives a language model a small set of tools (read, write, bash, edit), orchestrates the conversation, and gets out of the way. No proprietary API lock-in, no subscription tier determining which features you get.

The fork — maintained by a security/systems engineer who goes by @_can1357 — has accumulated around 1,300 commits of incremental improvement. Not rewrites, not architectural pivots. Small, empirical changes that fix pain points as they surface. That's the part I find most interesting about the project: it evolves the way a codebase that's actually being used evolves.

I run it against multiple models depending on the task. That model-agnostic posture is deliberate, and it ends up being one of the most practically valuable properties it has.

The Edit Tool Problem

The single change that made me take oh-my-pi seriously was the hashline edit format. To understand why it matters, you need to understand how most agents express edits today.

The dominant approach — used by Claude Code and most alternatives — is str_replace: the model provides the exact old text it wants to replace, plus the new text. Simple to reason about. But the model must reproduce the old content character-for-character, including indentation and whitespace. On a file it read 4,000 tokens ago, with a 400-line context, that's a meaningful failure surface. The "String to replace not found in file" error has its own GitHub issues megathread.

The oh-my-pi hashline format works differently. When the model reads a file, every line comes back tagged with a short content hash:

11:a3|function hello() {
22:f1|  return "world";
33:0e|}

When the model edits, it references those tags — "replace line 22:f1" — rather than reproducing the old content. If the file changed since the last read, the hashes won't match and the edit is rejected before anything gets corrupted. The model demonstrates it knows what it's editing by recalling the tag, not by parroting back whitespace.

The practical effect on benchmarks across sixteen models: the format matched or beat str_replace for most models, and the weakest models gained the most, because their failures were almost entirely mechanical rather than conceptual. Grok Code Fast went from 6.7% to 68.3% success rate. Grok 4 Fast's output tokens dropped 61% because it stopped burning context on retry loops.

I wrote about the broader implications in my post on harness vs model. The short version: the gap between "cool demo" and "reliable tool" is in the harness, not the model tier.

What Else It Gets Right

Beyond the edit tool, a few other things distinguish day-to-day use:

Structured subagent output. Claude Code leaks raw JSONL from subagent communication into the main context, wasting tokens on content the orchestrating model doesn't need to see. Oh-my-pi treats subagent output as structured data, so what gets surfaced is the result, not the process log. Over a long session this is a meaningful difference.

Model as a parameter. The harness doesn't care which model you point it at. In practice I use different models for different contexts — a faster model for scaffolding and quick lookups, a more capable one for architectural changes. The tooling adapts rather than requiring me to context-switch between products.

Incremental, empirical improvement. Because it's maintained by someone who uses it as their primary tool, the improvements target real friction points. There's no product manager deciding which features ship based on marketing priorities. When a particular error pattern is annoying, someone fixes it.

Why Not Claude Code

Claude Code is a well-built product. But it's built to optimize for Anthropic's models, on Anthropic's terms. That's fine and reasonable — it's their product. The constraints it imposes are:

• Edit format tuned for Claude, which degrades on other models
• Locked to subscription tiers that determine capability access
• Subagent communication leaks tokens at scale
• No way to fix any of this — it's closed source

When Anthropic blocked OpenCode (a widely-used open-source agent) from accessing Claude through Claude Code subscriptions, the stated reason was "reverse-engineered private API." The practical signal was: build on our harness, not yours.

I understand the business logic. I don't think it serves developers well. An open harness can be tuned by contributors using Grok who fix Grok-specific failures, by contributors using Gemini who fix Gemini-specific failures, by anyone with enough skin in the game to send a PR. That kind of community optimization doesn't happen in private, vendor-controlled infrastructure.

How I Use It in Practice

For the work I do — building and maintaining Shopware storefronts, Vue/Nuxt applications, integration layers — the agent's most frequent jobs are:

• Scaffolding new components to spec when the pattern is known and I just don't want to type it
• Writing and iterating on migration scripts
• Refactoring across multiple files when a data structure changes
• Generating boilerplate that doesn't require creative judgment

The hashline format is most noticeable on the multi-file refactoring tasks. Previously, str_replace edits on large service files failed often enough that I'd given up and was doing those by hand. With hashline-based editing, the same tasks complete reliably.

I still review every change before it lands. The agent is for leverage, not for running unsupervised. But "leverage I can trust" is a different category from "leverage that sometimes works."

The Broader Point

The AI coding tools conversation is almost entirely about models. Which one scores highest on SWE-bench, which one handles function calling better, which one is cheapest per million tokens. That's a legitimate conversation, but it's incomplete.

The harness determines what context the model sees. The harness determines what tools the model can call and how their outputs are formatted. The harness determines how edit failures are handled and whether the model can recover. A 5-point improvement from a harness change is indistinguishable in output quality from a 5-point improvement from a model upgrade — and costs zero training compute.

Oh-my-pi isn't a finished product and isn't marketed as one. It's a codebase that someone is actively using and improving, in public, for free. For my purposes that's exactly what I want: visible code, fixable problems, no vendor lock-in.

If you're thinking about what AI tooling makes sense for your development workflow, let's talk.

References

• oh-my-pi on GitHub
• Pi — original agent by Mario Zechner
• The Harness Problem — @_can1357's benchmark research
• My post on harness vs model reliability
• AI-Driven Product Search — how I apply agents in client projects