Oh My Pi vs OpenCode: workflow, models and total cost

Both clients are free MIT software, so the choice is not price — it is whether you want the model bill to come from the same account as the client. OpenCode sells models directly: a $10-per-month subscription called OpenCode Go and a pay-as-you-go gateway called OpenCode Zen. Oh My Pi sells nothing at all, and expects you to bring a key. Pick Oh My Pi when you already know where you buy tokens and want deep routing control over them; pick OpenCode when you want a wider surface — terminal, IDE, server, SDK — and the option of buying models without leaving it.

Three name collisions have to be settled before any of that is useful, because two of them will send you to the wrong documentation.

Which project is which

Repository, release and package facts read from the GitHub and npm APIs on September 19, 2026. Oh My Pi is an explicit fork: its README says "omp is a fork of Pi by Mario Zechner, rewritten as a coding-first surface", and the repository still carries a checklist for porting changes forward from upstream. The OpenCode move was a company rebrand rather than a change of owner — the sst organization now reads "We've moved to https://github.com/anomalyco" and the anomalyco organization is named Anomaly. This page does not assert a date for that rename, because the public evidence for one does not reconcile.

Which one should you pick

Workflow. Oh My Pi is a terminal-first agent with an unusually explicit routing layer: its README describes nine roles that route work by intent — default for normal turns, smol for cheap subagent fan-out, slow for deep reasoning, plus plan, commit, vision, task, advisor and tiny — each of which can name a different model, with fallback chains under retry.fallbackChains when the primary hits a quota wall. OpenCode spreads out horizontally instead: two built-in agents you switch with Tab, and documented integrations across an IDE, a web surface, a server, an SDK and plugins. If your pain is "I want cheap models doing the cheap parts", that is omp's built-in shape. If your pain is "I want this agent reachable from more places", that is OpenCode's.

Permissions and execution. Neither is the cautious one by default. omp's approval-mode documentation names yolo as the default mode, auto-approving read, write and exec and prompting for nothing, with always-ask and write as the stricter settings. It does recognise a short list of critical bash patterns — rm -rf /, fork bombs, remote-fetch-then-execute and the like — but read omp's approval-mode page carefully before relying on that: the same document says that in yolo a bare critical override is ignored, and only an explicit tool or user prompt/deny policy still forces the stop. OpenCode's permissions page says most permissions default to "allow", with doom_loop and external_directory defaulting to "ask" and .env files denied on read. The shapes also differ, which matters when you port a policy: omp declares a read/write/exec tier per tool and overrides it with tools.approval.<toolName>, while OpenCode evaluates pattern rules where the last matching rule wins.

Plan and protocol limits. The only plan-shaped restriction here runs in a direction people do not expect. Neither client gates bring-your-own-key behind a plan. But OpenCode Go has expectations about which clients consume it: it says the plan is designed for OpenCode and other coding agents that produce similar requests, that "Traffic is monitored for abuse", and that your client "should" send typical coding-agent traffic, "Identify itself with its own user agent" and "Send a stable session ID in x-opencode-session" for each conversation. omp implements exactly that plumbing for its opencode-go provider. OpenCode's validated-client table lists a row named simply "Pi", which does not distinguish the upstream project from this fork, so whether it covers Oh My Pi is not determinable from the page — this guide does not claim Oh My Pi is a validated OpenCode Go client.

What each one costs

Checked September 19, 2026. The evidence that Oh My Pi sells nothing is indirect but strong: its sitemap publishes 36 URLs, the homepage plus 35 documentation pages, with no pricing, billing, checkout or sign-up route among them, and the repository is MIT. Its one hosted touchpoint is a session-collaboration relay that defaults to wss://my.omp.sh and seals every session payload before it reaches the socket — with no price and no sign-up attached. A custom relay URL is accepted, but the same page states the production relay is not currently distributed for self-hosting.

The $10 plan is a cap, not an allowance

OpenCode Go is worth understanding precisely, because third-party summaries of it are consistently wrong. The official page states that "Usage limits are defined as monthly dollar amounts", not request counts. Each model carries its own monthly dollar cap — $15, $30 or $60 depending on the model — and the shorter windows are percentages of that same per-model cap: the 5-hour window is 20% of it and the weekly window is 50%. So the widely repeated "$12 per 5 hours" figure is only true of a model whose monthly cap is $60. Two more rules change the arithmetic: "Only one member per workspace can subscribe to OpenCode Go", and hitting a cap is not a hard stop — the page says you can keep using the free models, or enable a balance fallback so requests draw on Zen credit instead of blocking. Read the roster table on the page itself rather than any summary. The page says the list may change, and it changes faster than a guide can track it: one model's cap read differently on two checks a day apart while a time-limited promotional multiplier was showing against it, so treat any cap quoted anywhere — including here — as a shape rather than a current number.

Zen is the metered side of the same account. Its documentation says you are charged per request against a credit balance, auto-reloads $20 when the balance falls below $5 unless you change or disable that, and passes card fees through at cost, quoted as 4.4% plus $0.30 per transaction. Its stated posture is to "Pass along any price drops by selling at cost; so the only markup is to cover our processing fees." Two things there are explicitly temporary and will rot: the models listed at $0 are each described as free "for a limited time", most of them with a note that the team is using that time to collect feedback and improve the model, and team workspaces are free only as part of a beta. How many free models are listed changes — count them on the page rather than trusting any figure here. Both statements were on the page on September 19, 2026 and should be re-read before you budget on them. For the full Go and Zen rate card, OpenCode pricing already tracks it.

A like-for-like token estimate

This is token arithmetic, not a measured task cost and not a bill ceiling. Assume one session of 200,000 uncached input tokens and 15,000 output tokens, and compare only the two model names that appear on both price lists. Kunavo rates come from the live catalog; Zen rates were read from its own documentation on September 19, 2026.

Read this narrowly. Under these assumptions the two price lists land on the same estimate for Claude Sonnet 5 and on different ones for Claude Opus 5; that is a statement about two published rates on one date, not a general claim that either gateway is cheaper. Zen publishes rates for models Kunavo does not sell, and Kunavo's catalog carries models Zen does not list, so most of each rate card has no counterpart to compare. Cheapest listed rate and lowest cost to finish a task are also different questions — a cheaper model that needs three attempts can cost more than a dearer one that needs a single pass.

The $10 figures are not comparable either, despite looking it. OpenCode Go's $10 is a recurring monthly subscription whose value depends on you actually consuming toward the per-model cap. Kunavo's $10 minimum is a top-up of prepaid credit — a funding floor, not a monthly fee and not a task price. Kunavo's 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. Cache charges and external tools sit outside this example; see billing details.

Pointing either client at your own key

This is where the two clients diverge most, and where a migration actually costs you time. Both accept a custom OpenAI-compatible endpoint without any plan gate. The differences are the file, the wire formats each will speak, and one auto-detection trap.

Both tables above are read from the projects' own documentation on September 19, 2026 — omp's docs/models.md and OpenCode's providers page.

Oh My Pi, and the discovery trap

# Derived from omp's documented schema in docs/models.md.
# Not runtime-tested by Kunavo against a running omp.
providers:
  # OpenAI wire. baseUrl ENDS IN /v1 here.
  kunavo:
    baseUrl: https://api.kunavo.com/v1
    apiKey: KUNAVO_API_KEY      # an env var name, or a literal key
    api: openai-completions     # required whenever discovery is set
    authHeader: true            # sends Authorization: Bearer <key>
    discovery:
      type: openai-models-list  # reads /v1/models, picks up context_length

  # Anthropic wire. Written without /v1, matching omp's own proxy examples;
  # omp's docs say its Anthropic SDK strips a trailing /v1 either way.
  kunavo-anthropic:
    baseUrl: https://api.kunavo.com
    apiKey: KUNAVO_API_KEY
    api: anthropic-messages
    authHeader: true
    # disableStrictTools: true  # only if strict tool schemas are rejected
    models:
      - id: claude-sonnet-5
        name: Claude Sonnet 5

One detail is worth the whole section. omp documents a discovery.type: proxy mode built for gateways that expose both /v1/messages and /v1/chat/completions behind one host — exactly Kunavo's shape. But it derives each model's wire from a supported_endpoint_types field in GET /v1/models, and models without it "fall back to provider-level api if set, else dropped". Kunavo's /v1/models does not emit that field, so discovery.type: proxy alone would drop the catalog. The snippet above avoids it: discovery.type: openai-models-list reads max_model_len first and then context_length, and Kunavo does publish context_length. omp's own validation rule makes the provider-level api: mandatory whenever discovery is set, except in proxy mode.

One more omp behaviour is useful with a gateway: its documented key-resolution order puts a models.yml apiKey above stored OAuth, and says this is deliberate, "so a key supplied for a custom baseUrl or gateway is honored instead of forwarding an upstream OAuth token the proxy would reject". That removes the most common class of gateway authentication failure before it happens.

OpenCode, and the Anthropic wrinkle

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "kunavo": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Kunavo",
      "options": {
        "baseURL": "https://api.kunavo.com/v1",
        "apiKey": "{env:KUNAVO_API_KEY}"
      },
      "models": {
        "claude-sonnet-5": {
          "name": "Claude Sonnet 5",
          "limit": { "context": 1000000, "output": 128000 }
        }
      }
    }
  },
  "model": "kunavo/claude-sonnet-5"
}

The chat-completions path above follows OpenCode's documented custom-provider shape directly. The Anthropic-compatible path does not have one: OpenCode documents reaching an Anthropic endpoint by overriding the built-in provider — "You can customize the base URL for any provider by setting the baseURL option" — which means you inherit that provider's model ids and give up the models served from the vendor's own host in the same config. A custom provider declaring "npm": "@ai-sdk/anthropic" is permitted by OpenCode's published JSON schema, where npm is an unconstrained string, but it appears nowhere in the providers documentation — treat that route as unverified.

Watch the base URL spelling, but check each client's own rule rather than carrying one convention across both. The OpenAI-compatible surface wants https://api.kunavo.com/v1 in both. On the Anthropic wire they document different handling: omp's docs say its Anthropic SDK "strips a trailing /v1 from baseUrl before appending /v1/messages", and omp's own Anthropic-proxy examples use a base URL without /v1; OpenCode documents the Anthropic route as overriding the built-in provider's baseURL, and its example for that override ends in /v1. The origin-only form — https://api.kunavo.com, with the client appending /v1/messages — is the rule for ANTHROPIC_BASE_URL itself, where a trailing /v1 does produce /v1/v1/messages; see the base URL reference. Kunavo accepts both Authorization: Bearer and x-api-key, so omp's authHeader: true and the AI SDK's own default both have a valid path.

What the migration actually costs

Moving between these two clients is a config rewrite, not a copy. omp's context-file discovery registry does include an opencode source, but its documentation scopes that source to a single user-level file, ~/.config/opencode/AGENTS.md, with no project-level equivalent — so your project instructions transfer only if they already live in a file both clients discover, such as a repository-root AGENTS.md. Nothing in omp's documentation reads opencode.json provider blocks, so base URLs, keys, model entries and context limits are declared again from scratch.

One difference is worth a deliberate decision rather than a shrug. OpenCode's providers page carries a caution that previous versions bundled plugins for using a Claude Pro or Max subscription and that "this is no longer the case as of 1.3.0", on the grounds that the vendor prohibits it; the same page still lists ChatGPT Plus, GitHub Copilot and GitLab Duo as subscriptions usable with zero setup. omp, by contrast, still ships OAuth logins with multi-account rotation for several coding-plan providers. If a subscription rather than a per-token key is how you intend to pay, that difference decides the client for you — and it is a policy question, so check the subscription's own current terms rather than either client's documentation. Note also that OpenCode's own Anthropic section reads inconsistently as published: prose describing a Pro/Max sign-in option sits above the caution that removed it, and this guide quotes the caution because it is the dated, specific statement.

Finally, if you are only changing where the tokens are bought and not which client you use, do that first — it is the cheaper experiment. Compare providers with the best API for OpenCode, or how an LLM gateway works if the gateway concept itself is the new part. If you are weighing other clients entirely, OpenCode alternatives covers the wider field.

Try it on one bounded task

Kunavo publishes a setup guide for OpenCode and none yet for Oh My Pi, and a published configuration reference is not a compatibility test: neither client has been runtime-tested here against Kunavo's endpoint, and the omp snippet above is the first Kunavo has published, derived from omp's documented schema. Keep a working route available while you try either one, run a single bounded task, then read the charge your account actually recorded for it. Start at the OpenCode integration guide, and create a Kunavo account when you are ready to fund a key.

FAQ

Repository, release and package facts checked against the GitHub and npm APIs on September 19, 2026; OpenCode's Go, Zen, permissions, providers and enterprise pages and Oh My Pi's docs/ tree and sitemap read the same day. Neither client was runtime-tested against Kunavo. Kunavo token rates come from the live catalog, and every dollar figure on this page is illustrative token arithmetic rather than a measured task cost.