senpi: an opinionated pi-mono fork that ships the coding-agent extensions upstream leaves out

What senpi adds to pi-mono, and who it is actually for

senpi is a fork of badlogic/pi-mono, the toolset for building AI agents and managing LLM deployments. The README is direct about the motivation: it is "an opinionated, in-flight fork" that reflects what one specific AI assistant needs from a coding-agent runtime. That assistant is Dori, from Sisyphus Labs, and senpi powers it under the hood. The fork is usable standalone, but the design decisions (intent gate phrasing, the builtin extension set, prompt presets per model family, branding) are tuned to what Dori needs when it executes code work.

The second influence is OMO (oh-my-openagent), the author's heavyweight opencode harness with discipline agents, hash-anchored edits, Team Mode, skill-embedded MCPs and a Ralph Loop. senpi reuses several OMO ideas, including the intent gate, dynamic prompt, per-model presets, parallel-tool routing and todo continuation, while keeping the surface as light as possible. The README describes it as "a light version of OMO" that runs as a single pi CLI binary instead of an opencode plugin.

So the audience is narrow by design. If you already run pi-mono and keep re-adding the same extensions, senpi is that work done for you. If you need OMO's full harness, the README says to keep using OMO. The project does not claim to be a general-purpose agent framework, and the naming is a pun on senpai, which tells you how seriously it takes its own positioning.

How the monorepo is laid out and where the fork touches upstream

senpi is a TypeScript monorepo built around five published packages, all under the @earendil-works scope rather than a senpi scope. pi-telemetry holds vendor-neutral telemetry contracts, a reference adapter, conformance tests and typed schemas. pi-ai is the unified multi-provider LLM API covering OpenAI, Anthropic, Google and others. pi-agent-core is the agent runtime with tool calling and state management. pi-coding-agent is the interactive coding agent CLI. pi-tui is a terminal UI library with differential rendering.

The fork strategy is the interesting part. Core source modifications are minimised and tracked in changes.md files alongside every modified subdirectory, so upstream merge commits stay reviewable. That is a deliberate maintenance posture: the diff against pi-mono is documented at the directory level rather than buried in a single changelog. There is a Cargo workspace too, with crates/senpi-pty and crates/senpi-grep, pinned to napi 3.12.1 and portable-pty 0.9.0, so parts of the terminal and search path are native rather than pure TypeScript.

The root also carries .agents/, .codex/, .cursor/, .factory/ and .omo/ directories, plus AGENTS.md, opencode.json and a bench/ folder. Those are configuration and tooling surfaces rather than runtime code, but they show the project is developed against several agent harnesses at once.

The builtin extensions that replace a pile of separate installs

The README's migration table is the clearest statement of what senpi actually does. Several capabilities that OMO users install piecemeal are builtin here and need no separate package.

Dynamic system prompt lives in packages/coding-agent/src/core/dynamic-prompt/AGENTS.md and opens every prompt with a forced intent gate before tool use. todowrite, in packages/coding-agent/src/core/extensions/builtin/todotools/, pairs with a continuation loop that re-engages idle agents, which is the todo enforcer idea. prompt-preset supplies per-model tuning for GPT-5.x, Claude Opus 4.5, 4.6 and 4.7, and Kimi K2.6. compaction handles session recovery with adaptive thresholds, a restoration tracker, emergency compaction and tool-result truncation. gpt-apply-patch brings Codex-style freeform apply_patch with a Lark grammar to GPT models. bash-timeout enforces default and maximum timeouts with the policy stated in the system prompt. tool-pair-guard strips orphan tool_result blocks so compaction cannot break tool pairing. permission-system provides opencode-style allow and deny rules, JSONL storage, TUI prompts and parser-aware patterns.

Anthropic and OpenAI native web search are builtin as anthropic-web-search and openai-web-search. Rules and nested AGENTS.md come from the rules and nested-agents-md builtins, and web search and fetch come from websearch and webfetch. The README is explicit that these overlap with standalone pi-* extensions and the OMO Senpi plugin, and warns against installing every standalone package when the capability is already provided. That warning is worth taking literally: double-registering a comment checker or an LSP tool is a configuration mistake, not a feature.

Installing senpi and running a first session

The README does not give a global install command, so the reliable path is from the repository. The root package.json defines the workspace and the build scripts, and workspaces include packages/* plus the session backends, pty and the coding-agent example extensions.

Clone the repository and install the workspace dependencies:

git clone https://github.com/code-yeongyu/senpi.git
cd senpi
npm install

Then build the monorepo. The build script delegates to scripts/build-all.mjs, and there are package-manager-specific variants if you are not on npm:

npm run build
# or: npm run build:pnpm
# or: npm run build:bun

For development against the agent and the AI package together, the dev script runs both workspaces concurrently with labelled output:

npm run dev

One caveat before you start: the README documents a senpi install command for pulling in the standalone pi-* extensions, but it does not spell out the full invocation, so check the coding-agent package for the exact subcommand. The same applies to model configuration. prompt-preset covers GPT-5.x, Claude Opus 4.5, 4.6 and 4.7, and Kimi K2.6; if your model family is not in that list, expect to supply your own preset rather than inherit one.

Where senpi is the wrong tool

The README's own warning is the first limitation: senpi is experimental, and it says to use it but not to bet a production pipeline on it. That is not boilerplate. An in-flight fork of an upstream project inherits upstream's release cadence while adding its own, and the recent releases show a rapid sequence of dated tags.

The second limitation is coverage. The README flags that some OMO concepts have no 1:1 senpi counterpart and names them: Discipline Agents, Team Mode, Skills, Hashline, Ralph Loop and /init-deep. If your workflow depends on any of those, senpi is the wrong choice and the README says so plainly. There is also overlap risk in the other direction. Installing standalone pi-lsp-client, pi-ast-grep or pi-comment-checker alongside the OMO Senpi plugin duplicates capability, and the README tells you not to. Getting that mapping wrong produces confusing behaviour rather than a clean error.

Third, the tuning is opinionated in a way that may not match you. The intent gate phrasing, the builtin set and the prompt presets are shaped by what Dori needs. A team with different model families or a different idea of when an agent should be re-engaged will be editing builtins, and edits to core are exactly what the changes.md tracking exists to make visible. If you want a stable, unopinionated agent runtime, upstream pi-mono is the safer base.

senpi versus staying on pi-mono or OMO

The real comparison is three-way, and the README frames it that way.

pi-mono is the upstream base: tools for building AI agents and managing LLM deployments, without senpi's branding, builtin extension set or per-model presets. Choosing pi-mono means you assemble the same capabilities yourself and control the versions. Choosing senpi means you accept the curated set and the fork's opinion about how prompts should open and when timeouts should fire. The maintenance trade is that senpi tracks upstream through changes.md files, so merges stay reviewable, but you are still on a fork.

OMO is the other direction. It is the heavyweight opencode harness with discipline agents, Team Mode, hash-anchored edits, skill-embedded MCPs and the Ralph Loop. senpi deliberately does not reproduce that surface. The distinction is architectural, not just about feature count: OMO runs as an opencode plugin, senpi runs as a single pi CLI binary. If you want the full harness and you are already on opencode, senpi is a downgrade in capability. If you want most of the ergonomics without the plugin architecture, senpi is the lighter path, and the README's migration table exists precisely to map one onto the other.

Licence, maintenance cost and what you are signing up for

senpi is MIT licensed, and the LICENSE file sits at the repository root next to a NOTICE.md. The Cargo workspace declares license = "MIT" for its crates as well, so the native pieces are under the same terms. MIT is permissive and imposes no copyleft obligation on your own code, but this is a description of the licence text, not legal advice; if you redistribute senpi or a modified fork, read LICENSE and NOTICE.md yourself, and note that NOTICE.md exists for a reason.

The maintenance picture is active rather than dormant. The last push was on 2026-09-10, and the releases in the days before it were v2026.9.9-2, v2026.9.10 and v2026.9.10-2, all within roughly two days. That cadence cuts both ways. You get fixes quickly, and you also get a moving target. The changes.md files are the mechanism that makes upgrading tractable: they record what the fork changed in each subdirectory, which is what you read before pulling an upstream merge commit.

Upgrade cost is therefore concentrated in two places. First, any builtin you have modified, because core modifications are the thing the fork strategy is trying to keep small and reviewable. Second, the extension overlap matrix, because a capability that moves from a standalone pi-* package into a builtin, or into the OMO Senpi plugin, changes what you should have installed. The README already documents that overlap for LSP, AST-grep, comment checking, rules, web search and persistent goals.

Editorial conclusion

Adopt senpi if you want pi-mono's agent runtime with todo enforcement, compaction and a permission system already wired in, and you can read the changes.md files before merging upstream. Do not adopt it for a production pipeline: the README calls it experimental and says not to bet one on it, and several OMO concepts have no 1:1 counterpart here. Before installing, confirm which capabilities are builtin versus which require the separate pi-* packages or the OMO Senpi plugin, and check whether your model family has a prompt preset.

Frequently asked questions

Official sources

1. code-yeongyu/senpi on GitHub
2. Issues
3. License: MIT
4. README
5. Releases