oh-my-pi on Claude Code

The features, in plain words

What each feature does in omp, as this proposal understands it. If a description is off, the verdict is too, so this table is the first thing to agree on. Names link to the section that covers each one.

Where each feature plugs in

A Claude Code turn passes through a fixed set of engine events. A mod hooks an event with on(event, hook) and can watch it, rewrite it, or answer it instead of the engine. Each omp feature hooks one or two of them. The bottom row shows the services a mod calls through $; there is no Node inside a mod, so everything outside it goes through these.

Fit against size

Columns are how natural the fit is. Rows are rough size: S is a single hook and a few hundred lines at most, M is a small mod with its own state, L is a subsystem. Top-left is cheap and safe. Right-hand columns are where upgrades will hurt.

Other vendors, roles and fallback

omp talks to 88 providers and assigns models to roles (smol, slow, tiny, task, advisor, judge and more). Claude Code's own client speaks only the Anthropic Messages API, and a mod can't change its base URL. That leaves two routes, and the choice between them shapes everything else.

Route B without the user noticing

omp already ships the gateway. omp auth-gateway serve answers the Anthropic Messages format on /v1/messages, plus OpenAI Chat Completions, Responses and Jev decisions. It translates each request for the target vendor and signs it with your omp logins. It gets those logins from a second omp process, omp auth-broker serve, which holds the tokens and refreshes them. Nobody needs to write a translation layer.

A mod can't change Claude Code's base URL while a session runs, and a mod can't listen on a port. So the design fixes the address once and keeps a small helper always running, with the mod in charge of both:

The eval kernel with full programmatic tool calling

omp's eval tool runs a cell in a JavaScript (Bun) or Python kernel that keeps its variables between calls. Inside a cell, await tool.grep(...) calls any session tool, and completion(), agent(), judge() and workpool() reach models and subagents. This is programmatic tool calling (PTC): the model writes a program that calls tools, instead of making one tool call per turn.

In Claude Code the tool side is natural: $.tool.register adds eval, and $.tool.call runs any built-in or MCP tool with the normal permission check. The kernel is the awkward part. $.process.spawn writes stdin once and closes it, so you can't keep a REPL open over stdin. The kernel serves HTTP on a Unix socket instead, and the mod talks to it with $.http.fetch({socketPath}).

Prewalk and Jev-judged decisions

Prewalk plans on a strong model, then switches to a cheap one for the edits. In the mod it's a small state machine kept in $.state (session values that survive a hot reload): turn.complete moves it forward and turn.step rewrites the model once it flips.

Jev is TypeSafe's judgment model (served through OpenRouter's decisions API). omp asks it typed questions instead of using a chat model: which effort level a prompt deserves, whether a turn promised an action and then stopped, whether an answer breaks a question-style rule. Each one maps to a hook:

• Pick effort: at prompt.submit, one choice question over the prompt; then turn.step rewrites effort.
• Unexpected stop: at turn.complete, a yes/no question on the last answer; if yes, $.prompt.submit queues "continue". It arrives as a new turn, not a continuation of the old one.
• Question rules: at turn.complete, all candidate questions in one judge request (covered under TTSR).

TTSR: rules that fire while the model writes

omp's time-traveling stream rules watch the model's output as it streams. When a regex, an ast-grep pattern or a judge question matches, omp aborts the response, throws the partial output away, injects the rule as a hidden interrupt and lets the model try again. Rules are Markdown files with a frontmatter condition, scope and globs. omp's rule format can be reused as is.

Three kinds of rule, three different fits:

• Tool rules (on edit or write arguments): tool.call returns {deny} with the rule body before anything touches disk. Natural, and arguably better than omp's, because the deny happens before any side effect.
• Question rules: one judge request at turn.complete, and the verdict comes back as a note. Natural.
• Stream rules (on prose or thinking): a workaround, shown below.

Custom compaction

Here Claude Code is more open than expected. When the engine compacts, the session.compact event lets a hook return any list of messages instead of the engine's summary. omp walks a method order and falls through on failure. The same chain fits inside one hook.

The catch is timing. $.session.compact rejects while a turn is running. omp's notes-backed context (a context_notes tool plus new_context to roll over to a fresh window) wants to roll over in the middle of a tool loop. In Claude Code the mod has to do it in four steps:

1. The model calls new_context.
2. The tool replies "rolling over" and the turn ends.
3. A turn.complete hook compacts down to the notebook and the recent tool calls.
4. $.prompt.submit sends "continue", which starts a new turn.

Advisors that are always on

omp's advisor reviews each new stretch of the transcript as the primary works, in its own context, and speaks only through an advise tool with a severity: nit, concern or blocker. Blockers steer the live turn. With syncBacklog: 1 (your setting), the primary waits up to 30 seconds whenever a review is pending.

Every piece has a direct hook here. The review runs in the background with $.agent.spawn (or over $.http for a non-Claude advisor). $.session.append adds a note that a running turn reads at its next step. The wait is a turn.step hook that awaits the review before letting the next request through, and waiting inside $ calls doesn't count against the 10-second budget.

Commands and settings to drive all of this

omp puts each feature behind a slash command and a settings key (/advisor on, /prewalk restart, /handoff, /omfg, /model → Roles). Mods get the same three controls, and all of them are native:

• Slash commands: $.command.register at session start, answered by a command.run hook. A command marked immediate runs even while a turn is in progress.
• Settings: fields declared in the mod's manifest (userConfig) appear as rows in Claude Code's own /config menu. A field with a fixed list of values becomes a picker. Changing one reloads the mod with the new value.
• A control pane: $.ui.open opens a side pane with buttons and pickers, redrawn from $.state whenever a value changes. Status-line text and toasts show what is running.

Subagents: omp against Claude Code

Both tools let the main agent hand work to child agents with their own prompt, tools and model, running in parallel or in the background. omp goes further on orchestration: structured results, a model from any vendor, workspaces that merge back automatically, nesting, and live control. Claude Code is stronger on context and safety: a child can be forked with the whole conversation, can run in the cloud, and stays under your permission settings.

Open questions, each settled by one test

Each one is a single mod written as a test file run with claude plugin test, or a single curl call. Together they decide eight of the verdicts above.

Order of work

Small mods, not one big one. A roles mod adds a $.roles noun to $ (published as a typed contract), and the others list it as a dependency. Each mod reloads on its own while being built.