When a coding agent is a fork, should an integration treat it as an alias?
That is the tempting shortcut. If two tools share lineage, maybe the provider adapter can share a name, a path layout, and a set of assumptions.
For Oh My Pi, that would be the wrong boundary.
AIWG now has experimental support for Oh My Pi, usually called OMP. The integration uses the AIWG provider id omp, with oh-my-pi as an alias, and keeps original Pi support separate. That distinction matters because OMP is not just Pi with a different package name. It has its own native directories, profile behavior, task-agent surface, MCP configuration, model discovery, runtime modes, and session details.
The useful announcement is not “another provider was added.” The useful announcement is this: AIWG can move governed workflow resources into OMP while keeping credentials, model backend choices, executable extensions, sessions, and trust decisions under the operator’s control.
What Oh My Pi is
Oh My Pi describes itself as “a coding agent with the IDE wired in.” It is a terminal-first coding-agent harness and a fork of Mario Zechner’s Pi project, maintained in the open at can1357/oh-my-pi and surfaced through omp.sh.
Where original Pi emphasizes a smaller harness, OMP takes a batteries-included path. Its public README currently highlights a large built-in surface: many LLM providers, built-in tools, LSP operations, debugger operations, a Rust native layer, subagents, prompt controls, slash commands, and multiple runtime entry points.
That makes OMP interesting for AIWG. A provider with more native surfaces creates more places where project-owned workflow material can land. It also creates more places where an adapter can be wrong if it assumes too much.
Who makes it
OMP is developed in the can1357/oh-my-pi repository. The repository credits OMP as a fork of Pi by Mario Zechner, and its license section lists copyright notices for Mario Zechner, Can Bölük, and Stencil Labs, Inc. The repository is MIT licensed, with third-party notices preserved separately.
For AIWG’s announcement language, the safe attribution is narrow:
- OMP is the Oh My Pi project in
can1357/oh-my-pi. - It is a fork of Pi.
- It is open source under MIT, subject to its third-party notices.
- AIWG is not announcing a partnership or endorsement. This is provider support built against public behavior and reviewed interfaces.
That distinction is intentional. Provider support means AIWG can target a tool. It does not mean the tool’s maintainers reviewed, sponsored, or approved our adapter.
Why OMP stands out
OMP stands out because it turns the coding harness into a richer programmable surface.
The upstream project highlights native subagents, persistent Python and Bun execution, LSP-aware editing, debugger integration, stream rules, model roles, slash commands, plugin-style extensibility, a Node/TypeScript SDK, RPC mode, and ACP support. It also documents discovery of project resources from several existing coding-agent ecosystems.
That breadth is useful, but it changes the integration problem. A shallow compatibility shim can make the demo work while still lying about the contract. AIWG’s adapter has to answer more concrete questions:
- Which directory is OMP actually reading?
- Which profile is active?
- Which files are AIWG-owned and safe to refresh or remove?
- Which native surfaces can be used without changing operator trust policy?
- Which capabilities are verified, bridged, unsupported, or merely upstream-adjacent?
Those answers are why OMP gets a distinct AIWG provider identity.
Try the alias test
Before looking at the resource map, ask one question:
If OMP is a Pi fork, can AIWG safely map omp to the existing pi provider?
The answer is no.
AIWG’s OMP assessment found enough divergence to reject a simple alias. OMP uses .omp roots and profile-aware path resolution. It has native task-agent discovery, native MCP configuration, a distinct model-listing path, negotiated RPC behavior, and session details that should not be parsed as ordinary Pi sessions without tests.
Fork ancestry is not an integration contract. Shared primitives are useful only where they are tested. The provider identity still has to match the tool the user is running.
What AIWG deploys for OMP
The first useful path is native resource deployment.
Preview before writing:
aiwg use sdlc --provider omp --dry-run
Then deploy and inspect:
aiwg use sdlc --provider omp
aiwg doctor --provider omp
aiwg steward capabilities --provider omp
The provider maps AIWG material into OMP-aware locations:
- project bootstrap through
.omp/AGENTS.md, with explicit imports back to shared project context; - native skills through
.agents/skills/<name>/SKILL.md; - optional full skill copy when requested with
--copy-all; - OMP-specific prompts, rules, native agents, and MCP configuration under
.omp/; - receipt-owned lifecycle tracking so refresh and removal do not erase operator files.
This is the same portability principle AIWG applies elsewhere: workflow material should be inspectable, local, and removable. The provider adapter’s job is to translate that material into the target harness without hiding the boundary.
What AIWG does not do
AIWG does not install OMP. It does not choose your LLM backend. It does not write credentials. It does not turn OMP trust into AIWG trust. It does not claim every upstream feature is an AIWG-supported feature.
That last point matters. OMP has a wide native surface. AIWG can report a capability as native, bridged, unsupported, or unverified. Skipped conformance is not the same thing as support. A local Linux smoke result is not the same thing as verified behavior on every operating system.
The experimental label is not decoration. It tells the operator how much confidence to place in the adapter today and where to look before relying on it in a critical workflow.
The naming trap
There are two separate layers:
aiwg ... --provider ompselects AIWG’s Oh My Pi provider adapter.- OMP’s own model/provider selectors choose the LLM backend inside OMP.
Do not merge those namespaces. AIWG selects the coding harness target. OMP selects and runs its own model stack.
Where OMP appears to be going
OMP is moving quickly. Its release feed shows frequent updates across model handling, terminal UX, plugin discovery, native tooling, session behavior, subagent behavior, and runtime integration. The README also frames the project as extensible: users can shape it through config, plugins, commands, tools, and local packages.
For AIWG users, the roadmap implication is practical rather than speculative. OMP’s native contracts may keep changing. That is why the adapter needs pinned source baselines, conformance tests, live smoke evidence, and clear capability states.
The direction worth watching is not one feature. It is the combination of terminal-first workflow, IDE-aware operations, task orchestration, MCP, and runtime embedding. If those surfaces stay active, OMP will remain a useful provider target. If they drift, AIWG needs tests to catch the drift before a deployment silently writes the wrong shape.
Why this matters
Provider portability is easy to market badly. The sloppy version says every tool is the same once the right files are copied.
That is false.
The useful version says a workflow can be portable when the boundary is explicit: what moves, where it lands, what can execute, who owns trust, and how it is removed.
OMP support extends AIWG into a fast-moving Pi-family harness without collapsing OMP into Pi. That is the actual value. The shared workflow stays portable. The provider adapter stays honest about the tool it targets.
Connect and verify
Start with the upstream Oh My Pi repository, omp.sh, and the AIWG OMP provider guide once the release branch is public. Then run the dry-run and inspect what would change:
aiwg use sdlc --provider omp --dry-run
If the resource map looks right, deploy intentionally and verify:
aiwg use sdlc --provider omp
aiwg doctor --provider omp
aiwg steward capabilities --provider omp
Then tell us the concrete workflow you want to carry into OMP first: SDLC planning, research notes, provider audits, release marketing, incident response, or something stranger.