senpi: an opinionated pi-mono fork with the extensions baked in
pi had nothing (nothing), so I made something (something) — sorry mariozechner-senpai, I went ahead and lovingly soiled your pure pi for you. opinionated fork of badlogic/pi-mono with extension-first additions. ganbare ganbare senpi 頑張れ頑張れ先輩
At a glance
- What is it?
- senpi rebrands badlogic/pi-mono's coding agent as a single TypeScript monorepo CLI and folds a set of agent behaviours (intent gate, todo continuation, compaction, permissions) into builtin extensions. It is explicitly experimental, tuned for one assistant, and lighter than the OMO harness it borrows from.
- Who is it for?
- Adopt senpi if you want pi-mono's coding agent with a curated extension set already wired in and you accept the README's own framing that it is experimental and not something to bet a production pipeline on. Do not adopt it if you depend on OMO's Discipline Agents, Team Mode, Skills, Hashline or Ralph Loop, because the README states those have no one-to-one counterpart and points you back to OMO.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap senpi fills: a lighter OMO that runs as one binary
The README is unusually direct about the problem. OMO (oh-my-openagent) is described as a heavyweight opencode harness carrying discipline agents, IntentGate, hash-anchored edits, Team Mode, skill-embedded MCPs, the Ralph Loop and todo enforcers. senpi takes several of those ideas (intent gate, dynamic prompt, per-model presets, parallel-tool routing, todo continuation) and keeps the surface as light as possible so it can stay close to upstream pi-mono. The stated framing is a light version of OMO that runs as a single pi CLI binary rather than an opencode plugin.
The audience is narrower than the feature list suggests. senpi is the coding-agent runtime for Dori, Sisyphus Labs' AI assistant, and the README says the design decisions (intent gate phrasing, builtin extension set, prompt presets per model family, branding) are tuned for what Dori needs when it executes code work. It is usable standalone, but you are adopting someone else's defaults. That is the trade: less assembly work, less control over the shape of the agent loop. The repository name itself is a pun on senpai, and the description is written in that register, which tells you how much the project cares about presenting itself as infrastructure rather than a product.
Monorepo layout: five packages, one CLI at the end
The repository is a TypeScript monorepo with five published packages under the @earendil-works 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 and Google among 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.
That layering matters if you intend to build on parts rather than run the CLI. The multi-provider abstraction sits below the agent runtime, and the runtime sits below the CLI, so swapping a provider or embedding the agent loop does not require touching the TUI. The TUI's differential rendering is the mechanism behind redrawing a live terminal session without repainting everything, which is the kind of detail that becomes visible only when a session holds a long transcript. The README does not document the public API surface of these packages, so treat the package table as a map of the codebase rather than a compatibility promise.
What the builtin extensions actually change in the agent loop
This is where the fork diverges from upstream, and the README maps each builtin to the OMO feature it echoes. The dynamic system prompt in packages/coding-agent/src/core/dynamic-prompt/AGENTS.md is described as opening every prompt with a forced intent gate before tool use. That is a prompt-level constraint, not a runtime sandbox: it shapes what the model is asked to do first, and a model that ignores the instruction is not stopped by anything described here.
The todowrite extension plus a continuation loop re-engages idle agents, which is the todo-enforcer pattern. prompt-preset carries separate presets for GPT-5.x, Claude Opus 4.5 through 4.7, and Kimi K2.6, so the system prompt changes with the model family rather than staying fixed. compaction handles context management with adaptive thresholds, a restoration tracker, emergency compaction and tool-result truncation. tool-pair-guard strips orphan tool_result blocks, which is the failure you get when compaction removes a tool call but leaves its result behind and the next request is rejected as malformed. bash-timeout enforces a default and a maximum timeout with the policy stated in the system prompt. permission-system implements opencode-style allow and deny rules with JSONL storage, TUI prompts and parser-aware patterns. gpt-apply-patch gives Codex-style freeform apply_patch with a Lark grammar, and anthropic-web-search and openai-web-search are listed as native builtins.
Read together, these are mostly guardrails around the messy parts of long agent sessions: context overflow, orphaned tool results, runaway shell commands, and permission decisions. None of them is exotic, and that is the point. The value is that they ship enabled rather than as a list of plugins to discover.
Getting it running, and the install decisions the README pushes onto you
The README does not give a full quickstart in the material available here, but it does name the mechanics. Extensions are installed with senpi install, and the migration section is built around the question of which standalone pi-* packages to add. The explicit instruction is not to install every standalone package when the capability is already provided by senpi or by the OMO Senpi plugin.
The overlap table is the practical config guide. LSP: install pi-lsp-client when running senpi without the OMO plugin, but with the plugin, which registers six LSP tools through its packaged daemon, install pi-lsp-client only if you specifically need its /lsp inspector. AST-grep: pi-ast-grep is optional when you want the native ast_grep_search and ast_grep_replace tools, since the plugin already ships an AST-grep skill, helper and installer scripts. Comment checking: install pi-comment-checker standalone, or use the plugin's comment-checker component, but not both. Rules and nested AGENTS.md come from the rules and nested-agents-md builtins, web search and fetch from the websearch and webfetch builtins, and persistent goals from the goal builtin, so none of those needs a standalone extension.
If you are migrating from OMO, the README flags that Discipline Agents, Team Mode, Skills, Hashline, Ralph Loop and /init-deep have no one-to-one senpi counterpart and tells you to keep using OMO if you need them. That is the honest boundary of the fork, stated by its own author.
Where senpi is the wrong tool
The README opens with an experimental warning and the sentence that you should use it but not bet a production pipeline on it. Take that literally. Release tags like v2026.9.10-2, v2026.9.10 and v2026.9.9-2 land on consecutive days, and the fork tracks an upstream that is itself moving, so pinning a version and reading the diff is the only way to know what changed under you.
The second limitation is the fork strategy itself. Core source modifications are described as minimised and tracked in changes.md files alongside every modified subdirectory so upstream merge commits stay reviewable. That is a maintenance practice, not a guarantee. Every builtin that patches prompt construction, compaction or tool pairing is a place where an upstream change can conflict, and the changes.md files are the audit trail you have to read to judge the risk. If you cannot commit to that reading, you are depending on the fork author's merge cadence.
The third is fit. The prompt presets, intent gate phrasing and builtin set are tuned for Dori. If your workflow depends on the OMO features listed as having no counterpart, senpi is not a lighter substitute; it is a different product, and the README says so. The fourth is that the material here documents no API stability policy for the five @earendil-works packages, so embedding pi-agent-core or pi-ai in your own service means tracking a moving target without a stated contract.
The real alternative, and where the approaches split
The alternative named by the project itself is OMO (oh-my-openagent), and the difference is architectural rather than a matter of feature count. OMO is an opencode plugin harness; senpi is a single pi CLI binary. In OMO, the discipline agents, Team Mode, skill-embedded MCPs and the Ralph Loop are part of the harness you install into opencode. In senpi, a subset of the same ideas is compiled into the CLI as builtins, and the rest is either a separate pi-* extension or absent.
That split has consequences. A plugin harness can be extended in place without forking the host, which is why OMO can carry more machinery without owning a runtime. A fork owns the runtime, so it can change prompt construction, compaction thresholds and tool pairing directly, but it also inherits the merge burden against upstream pi-mono. senpi's answer to that burden is the changes.md convention, which is a documentation discipline rather than a technical one.
The other fork in the road is upstream pi-mono itself. If you want the coding agent without the opinionated builtins, the presets and the Dori tuning, upstream is the smaller dependency and the one senpi rebases onto. Choosing senpi means choosing the builtins as defaults, and the README's own migration table exists because those defaults overlap with standalone extensions in ways that are easy to get wrong.
Licence, upgrades and what the fork costs to keep
senpi is MIT licensed, and it is a fork of pi-mono, so the upstream licence and attribution obligations travel with the code you redistribute. This is not legal advice; if you ship senpi inside a product, check the licence files in the repository and in upstream pi-mono rather than relying on the repository metadata alone.
The upgrade cost is the part the README is most candid about. Core modifications are minimised and tracked per subdirectory in changes.md, which means each upstream merge is a review of those files rather than a blind rebase. The builtins that touch the request path, compaction, tool-pair-guard, the dynamic prompt and the per-model presets, are the ones most likely to collide with upstream changes, because they sit where upstream is also active. The release cadence visible in the tags suggests the author merges and ships frequently, which helps, but it also means the surface you tested is not the surface you get next week.
Practically, the maintenance question is whether you are willing to read changes.md on upgrade and to keep your installed extension set from duplicating what the builtins already do. The README's overlap table is the checklist for that second job, and it is the one piece of documentation here that saves real time.
Editorial conclusion
Adopt senpi if you want pi-mono's coding agent with a curated extension set already wired in and you accept the README's own framing that it is experimental and not something to bet a production pipeline on. Do not adopt it if you depend on OMO's Discipline Agents, Team Mode, Skills, Hashline or Ralph Loop, because the README states those have no one-to-one counterpart and points you back to OMO. Before installing, read the changes.md files next to each modified subdirectory to see how far the fork has drifted from upstream, and confirm which builtins are already active so you do not install a standalone pi-* extension that duplicates them.
Community notes