Oh My Pi vs Pi: the fork, the differences, and which to run

Oh My Pi is a hard fork of Pi, not a rival that grew up beside it — the code flowed Pi → Oh My Pi, both projects are alive today, and they now optimise for opposite things. Pi is a deliberately minimal terminal harness you extend in TypeScript. Oh My Pi is the same lineage rebuilt as a batteries-included coding surface with LSP, a debugger, subagents and a browser tool in the box. Both are MIT-licensed and cost $0 to install, so the decision is about workflow, execution model and configuration format — not about a licence fee.

Names first, because three of them collide. Pi here means the agent harness at pi.dev, published by Earendil Works from earendil-works/pi. It is not Pi by Inflection AI (pi.ai), not the Pi Network coin, and not Raspberry Pi. Oh My Pi means the agent at omp.sh from can1357/oh-my-pi, whose binary is omp — not the pie bakeries that dominate a search for that phrase, and not Oh My Zsh or Oh My Posh despite the naming echo. And pi-mono is not a third product: it is Pi's old repository name. github.com/badlogic/pi-mono now returns a 301 to earendil-works/pi, though third-party docs still use the old path — DeepSeek's official Pi integration page literally lives at /agent_integrations/pi_mono/.

The fork direction is worth pinning down, because searches run both ways and the answer is not symmetrical. Oh My Pi's README says in its own header that it is a "Fork of Pi by @mariozechner", linking to the pre-rename URL. GitHub reports fork: false and parent: null for it, because this is a source fork rather than the fork button — so the API will not tell you. The repository still carries docs/porting-from-pi-mono.md, a merge checklist whose recorded Last Sync Point is commit b21b42d, dated March 22, 2026. That marker is the only divergence evidence available from outside; whether a later, unrecorded sync has happened is not something this page can confirm.

Oh My Pi vs Pi: which should you pick?

Five axes decide this — whichever direction you came at it from — and only one of them is about features.

• Workflow. Pick Pi if you want a small core and intend to write the missing parts yourself. Its own usage docs state that it "intentionally does not include built-in MCP, sub-agents, permission popups, plan mode, to-dos, or background bash", and points you at extensions, packages, containers and tmux instead. Pick Oh My Pi if you want those in the box on day one and have no appetite for maintaining an extension.
• Permissions and execution model. Neither default is the safe one, so choose on which failure mode you can live with. Pi has no permission system and is explicit about it. Oh My Pi has a real three-tier one and ships it defaulted to yolo. If you need per-tool prompts, Oh My Pi can give them to you after one config line; Pi cannot give them to you at all without an extension.
• Protocol and plan limits. If your model route is a third-party OpenAI- or Anthropic-compatible endpoint, both can reach it, but Oh My Pi accepts nine wire dialects to Pi's four and adds an environment-variable route Pi does not have. If your route is an OAuth subscription — Claude Pro/Max, Codex, GitHub Copilot — both clients attach it through /login and store a vendor token, which a gateway in the middle would reject; Oh My Pi's own provider docs give that as the reason a models.yml key deliberately outranks stored OAuth. Do not fold the Chinese coding plans into that group: Pi lists ZAI/GLM, Kimi For Coding and the Qwen Token Plans in its API-key table (ZAI_API_KEY, KIMI_API_KEY, QWEN_TOKEN_PLAN_API_KEY), and Oh My Pi tags them plan rather than oauth, so they are ordinary keyed providers in both.
• Cost path. The client is free on both sides and neither changes your per-token rate. The asymmetry is that Pi has a first-party paid gateway (Radius, run by the same company) wired into its own /login, while Oh My Pi sells no hosted route of any kind — the one server it does operate is the relay behind /collab session links, which bills nothing.
• Migration cost. Roughly one provider block, retyped. Config formats and directories differ — JSON under ~/.pi, YAML under ~/.omp — and no import tool is documented in either repo. A couple of environment variable names are shared, with caveats below.

What should not decide it: the version numbers. Oh My Pi renumbered at the fork, so its 18.2.7 and Pi's 0.86.1 are different schemes, not eighteen versions of extra maturity.

What actually differs between them

Read from both repositories' own documentation on September 19, 2026: Pi's overview, security and models pages, and Oh My Pi's README, approval-mode and providers pages. The capability counts in the Oh My Pi row are that project's own claims; no methodology is published for them, and its README benchmark table is likewise a vendor claim this page does not reproduce.

Both are alive. Neither metric settles "which is bigger"

The single most common error about this pair is treating one of them as abandoned or superseded. Both pushed code on the day of this check.

Repository, release and star figures from the GitHub API, read September 21, 2026; download counts from the npm downloads API for the week ending September 16, 2026. Do not turn either column into an adoption verdict. The npm comparison in particular is not like-for-like: Pi's own documentation opens with npm install -g, while Oh My Pi's README documents curl-to-shell, Homebrew, Bun, Nix, PowerShell and mise and never gives an npm command at all, so npm materially undercounts it by an amount nothing here can measure. Stars favour Pi; release cadence favours Oh My Pi; any one-metric sentence about popularity will be wrong in at least one direction.

Neutral third-party evidence that both are current, if you want it without the metrics: Ollama publishes an integration page for Oh My Pi and for Pi, and DeepSeek publishes an agent-integration guide for each as well — its Pi guide being the one still filed under the old pi_mono path. All four pages answered on September 21, 2026.

Pointing either one at your own endpoint

This is where the fork is most visible, and where a wrong /v1 costs you an afternoon. Both clients can reach a third-party OpenAI- or Anthropic-compatible endpoint, but by different mechanisms and opposite URL conventions.

Oh My Pi has an environment-variable route Pi does not. Its Anthropic provider resolves the base URL through normalizeAnthropicBaseUrl($env.ANTHROPIC_BASE_URL), ahead of the official default, and that normaliser strips a trailing /v1 — so both https://api.kunavo.com and https://api.kunavo.com/v1 land on the same host. Read from packages/ai/src/providers/anthropic-state.ts, where resolveDirectAnthropicBaseUrl() and the normaliser are defined, on September 19, 2026 — from source, not from a request we made.

# Oh My Pi honours ANTHROPIC_BASE_URL for its built-in anthropic provider.
# normalizeAnthropicBaseUrl() strips a trailing /v1, so both forms resolve
# to the same host here. Pi ships no equivalent gateway base-URL variable.
export ANTHROPIC_API_KEY="$KUNAVO_API_KEY"
export ANTHROPIC_BASE_URL="https://api.kunavo.com"
omp

One precedence trap comes with that route. Oh My Pi's documented order puts a models.yml apiKey at position 2, above stored OAuth at position 3, but a provider environment variable at position 5, below it. So if you are already /login-ed into Anthropic, the subscription token wins over ANTHROPIC_API_KEY and your gateway key is never used. Pin the key in config, or log out of that provider first.

For a named provider, Oh My Pi uses YAML — and here the /v1 goes back on, because its OpenAI path appends /chat/completions to the trimmed base URL verbatim.

providers:
  kunavo:
    baseUrl: https://api.kunavo.com/v1   # /v1 REQUIRED: omp appends /chat/completions
    api: openai-completions              # use anthropic-messages, and then drop /v1
    apiKey: KUNAVO_API_KEY               # env var name, a literal, or "!cmd"
    authHeader: true                     # send Authorization: Bearer <key>
    models:
      - id: claude-sonnet-5
        contextWindow: 200000
        maxTokens: 64000

To point Pi at a gateway you have one route: ~/.pi/agent/models.json. Pi reads no ANTHROPIC_BASE_URL — a code search across the repository on September 19, 2026 returns two hits for that exact string, both non-override (a Cloudflare AI Gateway constant and a model-generation script) — and there is no bare OPENAI_BASE_URL either. One base-URL variable does exist and it is not a general escape hatch: AZURE_OPENAI_BASE_URL, listed in Pi's provider docs, points the Azure OpenAI provider at your own Azure resource and nothing else.

{
  "providers": {
    "kunavo": {
      "baseUrl": "https://api.kunavo.com",
      "api": "anthropic-messages",
      "apiKey": "$KUNAVO_API_KEY",
      "models": [
        {
          "id": "claude-sonnet-5",
          "contextWindow": 200000,
          "maxTokens": 64000
        }
      ]
    }
  }
}

On the suffix, Pi's own documentation contradicts itself and you should know that rather than trust one example. Its models page shows an anthropic-messages proxy as https://proxy.example.com/v1 in one place and as https://proxy.example.com with no suffix in another. The no-suffix form is the one to follow, and the reasoning is derived from source rather than runtime-tested: Pi ships nothing like Oh My Pi's /v1-stripping normaliser on the anthropic-messages path — the one normalisation its docs describe is Azure-specific, folding a root Azure endpoint into /openai/v1 — its built-in Anthropic default is https://api.anthropic.com without /v1 while its OpenAI default is https://api.openai.com/v1, and for anthropic-messages it hands model.baseUrl straight to the official Anthropic SDK, which appends /v1/messages itself. A /v1 there would produce /v1/v1/messages. Kunavo documents the same convention on its base-URL page: origin only for Anthropic-style clients, /v1 for OpenAI-style ones.

Two more boundaries worth planning around. Pi's documented table lists four dialects for custom providers even though the repository ships extra handlers for its own built-ins, so treat four as the supported surface. And on Oh My Pi, disabledProviders is checked before credentials — a provider ID caught by that list silently disappears no matter what key you supply — while settings arrays are replaced wholesale by the higher-precedence layer rather than merged, so a project-level list quietly discards the global one. Both projects also ship compatibility escape hatches you may genuinely need on a gateway: Oh My Pi's disableStrictTools, Pi's supportsEagerToolInputStreaming and allowEmptySignature. Whether Kunavo accepts either client's default strict schemas, cache markers or eager tool-input streaming has not been tested here.

What switching actually costs

Less than the version-number gap suggests, and more than a file copy. There is no documented import command, session converter or config migrator in either repository's docs tree, so plan to retype the provider block in the other format — JSON to YAML, or back. Credentials do not move either: Pi stores them in ~/.pi/agent/auth.json, while Oh My Pi keeps a SQLite auth store at ~/.omp/agent/agent.db.

Environment variables carry less far than the shared ancestry suggests, so read this one carefully. Oh My Pi does still read the PI_-prefixed names — PI_CONFIG_DIR and PI_CODING_AGENT_DIR among them — but they relocate Oh My Pi's directories, so exporting one in a shell profile shared with Pi points both clients at the same path rather than making a config portable. The OMP_-to-PI_ mirroring described in its environment-variable reference is narrower still: that doc states the rule applies inside each parsed .env file and explicitly "not arbitrary variables inherited from the parent process". What will not carry at all is anything built against the harness: a Pi TypeScript extension is written against Pi's API, and roughly six months of separately maintained development since the March 22, 2026 sync marker is exactly where those APIs drift. Test an extension rather than assuming it ports.

The money is the same on both sides

Neither client bills you, so switching between them changes your model spend by zero. The variable is which route you buy tokens through, and on that the two differ in one way: Pi has a first-party paid gateway and Oh My Pi does not. Radius is operated by Earendil, closed source, reached through Pi's own /login, and its FAQ states it charges "the fees we have with our payment processor on top of the list prices" — a percentage it does not publish, so a Radius total cannot be computed from outside. Oh My Pi's only gateway is omp auth-gateway serve, software you host, with transport security delegated to the operator.

One thing to kill before it enters a budget: a Claude Pro or Max subscription signed into either harness is not free usage. Pi's provider docs say third-party harness usage "draws from extra usage and is billed per token, not against Claude plan limits". No equivalent statement was found in Oh My Pi's docs, so do not assume it behaves differently — check your own account.

For the gateway route, here is the arithmetic on the workload rather than on the client. Assume one month of steady agent work: 5,000,000 uncached input tokens and 400,000 output tokens, no cache reads or writes, no image or tool charges. Rates are live Kunavo catalog prices per million tokens.

These are illustrative token estimates under the assumptions above, not measured task costs and not a ceiling on a bill. The column is identical for both clients because the client is not a pricing variable — but the workload can be: Oh My Pi's task tool fans out subagents in parallel, and parallel agents each carry their own context, which is an input-token multiplier no table here can size for you. Measure it on one bounded change before scaling the estimate.

Two Kunavo-side caveats belong in the same number. The catalog amount is a billing floor rather than a cap: when the upstream reports its charge, the bill is the greater of catalog cost and upstream cost times the applicable markup, as the billing guide explains. And the minimum top-up is $10 of prepaid credit — the cash needed to fund an account, not a task fee or a subscription.

Kunavo publishes no setup guide for either client and has not runtime-tested either against its endpoint, so both configurations above are written from published documentation and source and should be verified on your own machine. Keep a working route available while you try one. When you want to price a real task rather than a model, create a Kunavo account, fund it, and run one bounded change against the model you shortlisted. If you are still choosing a harness rather than a provider, Pi coding agent pricing breaks down Pi's four billing routes, and Pi vs OpenCode compares Pi against a client that does have a published Kunavo setup guide.

FAQ

Both repositories' documentation trees and npm packages were checked September 19, 2026, and the base-URL and credential-order claims read from the source files named inline on the same date; the repository metrics and release histories were re-read September 21, 2026. Kunavo rates are rendered from the live catalog and every dollar figure here is illustrative token arithmetic. Neither client has been runtime-tested against Kunavo, and no performance or benchmark comparison between the two projects is implied — none exists that this page could cite.