Running Oh My Pi via standalone stdio translator shim (omp-t3)

[hashangit]

Summary

Many developers prefer running Oh My Pi (omp) for its in-process tool execution (Rust-linked ripgrep and bash) and broad provider support. However, pointing T3 Code's built-in Pi provider directly at the omp binary fails because OMP's RPC dialect differs from upstream Pi:

1. Turn settlement: OMP signals completion with session_settled rather than agent_settled, leaving turns active indefinitely ([Bug]: Pi provider turns never settle when the binary is oh-my-pi (omp) #19490).
2. Local commands: Commands like /context finish with data.agentInvoked:false on the RPC response without emitting settlement frames, causing the turn to hang.
3. Tool approvals: OMP suppresses interactive confirmation dialogs unless spawned with --mode rpc-ui instead of --mode rpc.
4. Catalog size: OMP returns its full catalog of 500+ models in one frame, exceeding the 1 MB transport ceiling and crashing the connection.
5. Subagents: OMP child agent events are attributed to the currently active tool rather than the spawning task, creating disconnected cards in T3's thread tree.
6. Compaction: OMP manual compact() calls emit no progress events, while skipped auto-compaction cascades trigger false failure cards in T3.

User-space solution: omp-t3

As noted in #19490, adding dialect handling for third-party forks directly into T3's core Pi adapter adds maintenance overhead to upstream T3.

To solve this without modifying either codebase, I built omp-t3 (https://github.com/hashangit/omp-t3). It runs as a lightweight stdio proxy configured as the Pi binaryPath:

• Spawns omp --mode rpc-ui and translates settlement frames, local command completions, and compaction events.
• Serves OMP skills in T3's $ menu and slash commands in T3's / menu, wrapping CLI output in fenced code blocks so monospace formatting is preserved.
• Re-parents child subagent progress events to their parent task calls so they display cleanly in T3's subagent tree.
• Prunes the model catalog to stay under 200 KB, normalizes model IDs, and caches the list to disk for offline fallback.
• Includes a drift watchdog that monitors frame timing and synthesizes missing settlements if OMP withholds them.
• Passes streaming tokens, diffs, approvals, and terminal signals through as raw bytes.

Proposal / Collaboration

I use this setup daily and actively maintain omp-t3 against new releases of both T3 Code and OMP.

I wanted to open this discussion for two reasons:

1. Point of reference: When community members ask about running OMP inside T3 Code, maintainers have a documented user-space option that requires zero code changes to T3 Code.
2. Upstream / Maintenance: If the T3 team wants to bring this shim into the official organization or documentation (similar to other provider bridges), I am happy to transfer the repository or collaborate on maintenance. If you prefer to keep it as an external community project, I will continue maintaining it in user space.

*PS: I'm using the nightly builds so this is mapping the current nightly build as of this post. Obviously as long as I use this setup (T3 Code + OMP) I will continue to fix any issues I run into with omp-t3, very selfishly for my own use. But I may not get to every issue immediately always as the contracts changes from either side. So feel free to, change this yourselves if you want. Its MIT anyway.