Octomind vs Pi Coding Agent: A Minimal Agent Harness Against a Full Agent Runtime

The Pi coding agent describes itself in four words on its own homepage: "a minimal agent harness." That's not modesty — it's the entire design. Pi ships eight built-in tools, no MCP client, no sub-agents, no plan mode and no sandbox, then hands you a TypeScript extension system and says: build what you need. Its own words are "adapt Pi to your workflows, not the other way around."

Octomind starts from the opposite premise. The runtime should already contain the parts a serious agent needs — an MCP client in both directions, sub-agents, guardrails that run without a human at the keyboard, budget enforcement, and a cloud machine that survives your laptop closing — because most teams don't want to write and maintain that layer themselves.

Both are open source, both are terminal-first, both switch models mid-session. The real question is where the missing pieces come from: your TypeScript, or the runtime.

Quick verdict

Pi is the better harness if you want a small, legible core and intend to write the rest yourself. Octomind is the better runtime if you want the surrounding infrastructure to already exist and be configured rather than coded.

Choose Octomind if

• You want MCP as a first-class client and server, not an extension you install or write.
• Sub-agents, skills, taps and specialists should ship with the runtime.
• Policy needs to be deterministic and reviewable: guards, hooks and validators in a file, not a modal.
• Hard spending caps that stop a run before the bill matter more than raw flexibility.
• The agent needs a persistent Linux machine with Docker that outlives your terminal.
• Work should arrive from Telegram, Slack, WhatsApp, GitHub, a web panel, an API or a schedule.
• You would rather configure TOML than maintain TypeScript extensions.

Choose Pi if

• A small, auditable core is the feature. Eight tools is the whole tool surface.
• You write TypeScript and want to intercept tool calls, messages and system prompts directly.
• Branching session trees, HTML export and gist sharing fit how you work.
• You want one of the largest open-source agent communities behind the project.
• Local-only operation is a requirement, not a limitation.
• Embedding an agent loop in your own product via SDK or RPC is the actual goal.
• You already have containerization and CI policy and don't want the agent duplicating it.

What Pi does better

The core is genuinely small

Pi's built-in tool list is read, bash, powershell on Windows, edit, write, grep, find and ls. That's the entire surface the model sees before anything is added. You can read the tool set in one breath and predict what the agent can do.

Octomind's answer to context bloat is intent-driven activation: capabilities and skills stay dormant until your request matches them. That's a more sophisticated mechanism, and it does keep the loaded tool count low — but it's a mechanism you have to trust. Pi's answer is arithmetic: there's nothing to activate because there's nothing else there.

Extensions reach deeper than configuration

Pi extensions are TypeScript modules loaded from ~/.pi/agent/extensions/*.ts, .pi/extensions/*.ts, or npm and git packages, hot-reloadable with /reload. They subscribe to lifecycle events, register tools, add slash commands and keyboard shortcuts, intercept and modify tool calls and system prompts, persist custom session entries, and render their own TUI components.

That's a wider aperture than any declarative format. Octomind's roles, layers, workflows and guardrails cover the cases the project anticipated; if your case is outside them, you file an issue. In Pi you write forty lines of TypeScript. For a team with strong Node skills and unusual requirements, that trade is worth making.

Sessions branch

Pi stores history as a tree, and it's one of the nicest things about using it. /tree walks back to any earlier message so you can continue from there instead of from the end, and every branch lives in the same session file. You can bookmark entries, filter by message type, export the whole thing to HTML with /export, or push it to a GitHub gist with /share and hand someone a URL that renders it.

That turns "let me try this a different way" into a navigation step rather than a new session.

Octomind persists sessions and resumes them by name — octomind run --name my-feature, then --resume my-feature — with adaptive compaction keeping long sessions coherent. But it's a linear history, not a tree. If your workflow depends on exploring several branches from one point of context, Pi does something Octomind does not.

The community is much larger

The earendil-works/pi repository showed 101.6k GitHub stars in early September 2026. Octomind's is a fraction of that. Stars measure attention rather than fitness, but attention produces extensions, guides, bug reports and answers, and a smaller project cannot manufacture that.

What Octomind does better

MCP is in the runtime, in both directions

Pi's homepage lists what it deliberately leaves out: built-in MCP, sub-agents, permission popups, plan mode, to-dos and background bash. All of them are extension territory.

Octomind is an MCP client for any server over stdio, Streamable HTTP or OAuth, and it ships its own built-in servers. The mcp tool enables and disables servers mid-conversation, so an inactive server costs zero tokens until the agent decides it needs one. Filesystem tools come from octofs, memory and knowledge indexing from octobrain, both wired in by tap formulas.

This is the sharpest difference between the two projects. If your stack is already MCP-based, Pi asks you to bridge it and Octomind already speaks it.

Policy is code the runtime enforces, not a prompt you approve

Pi's security documentation is admirably direct: there's no built-in sandbox, and this is intentional. "A partial in-process sandbox would be easy to misunderstand as a security boundary." Project trust is described as "only an input-loading guard." Prompt injection from repository files is called expected local-agent risk that Pi cannot reliably prevent. For unattended work the docs tell you to run Pi in a container you provide.

Octomind takes the same view of approval modals and answers it differently. A .agents/guardrails.toml in the repository gives the runtime deterministic rules at three points in the loop:

[[guard]]
match   = "shell(command=^rm\\s+-rf?)"
message = "rm -rf blocked."

[[validator]]
name   = "tests-pass"
roles  = ["developer"]
script = ".agents/run-tests.sh"

Guards deny calls before they execute. Hooks run after a tool returns and inject non-zero-exit output back into the agent's inbox as a correction. Validators fire after a turn over only the new call slice. None of it requires a human present, which is the point: it's designed for CI, daemons and scheduled runs.

Pi extensions can implement permission gates and sandboxing — the project's own examples include both. The difference is who writes and maintains that layer.

Budgets stop the run, not the postmortem

Octomind enforces spending caps in the runtime:

max_request_spending_threshold = 0.50
max_session_spending_threshold = 5.00

A session cap prompts to continue in an interactive run and auto-stops in a non-interactive one. A request cap halts execution outright. Cost is tracked per request and per session, with cache reads and writes accounted separately from input and output tokens.

Pi gives you provider choice and mid-session switching, which is real cost control at the model level. It doesn't ship an enforced budget ceiling.

The runtime reaches past the terminal

Pi has four modes, all local: the interactive TUI, print and JSON (pi -p "query", --mode json), RPC, and an SDK for embedding. That covers scripting and embedding well.

Octomind runs the same session engine as an interactive CLI, a piped non-interactive run, a named daemon you inject messages into with octomind send, a WebSocket server, and an ACP sub-agent inside another agent's stack. On the cloud side, each agent gets a persistent Linux machine with Docker where repositories, installed tools and artifacts survive suspension, reachable from Telegram, Slack, WhatsApp, GitHub, the web panel and a Developer API. Scheduled Routines wake that machine, run a specialist and report the result with no local process involved.

Pi is not trying to do any of this. That's a legitimate scope decision, not a defect — but if the requirement is an agent that keeps working when the laptop closes, Pi is the wrong end of the trade.

Documented limitations of Pi

They're documented by Pi itself — the healthiest form this section can take.

No built-in sandbox, stated as a design choice with the reasoning given. No built-in MCP, sub-agents, plan mode or permission prompts, listed as omissions on the homepage. Extensions "run with your full system permissions and can execute arbitrary code" with no sandboxing, so the trust question moves to whoever wrote the extension. --approve exists for unattended runs, and the docs pair it with an explicit warning to contain untrusted work.

None of this makes Pi unsafe to use. It makes Pi honest about where the boundary sits: outside the tool, in the container and the CI policy you already run. Octomind's bet is that many teams would rather the runtime own part of that boundary.

Try both in fifteen minutes

Neither project asks much of you to evaluate it, so the fastest way through this decision is to install both and run the same task twice.

# Pi
curl -fsSL https://pi.dev/install.sh | sh
pi --model sonnet:high        # or npm install -g --ignore-scripts @earendil-works/pi-coding-agent

# Octomind
curl -fsSL https://raw.githubusercontent.com/muvon/octomind/master/install.sh | bash
octomind run developer:general

Pick a task you actually have — a flaky test, a small refactor, a dependency bump — and pay attention to three things. First, how much did you reach for something that wasn't there? In Pi that becomes an extension to write; in Octomind it becomes a config block or a tap. Second, what happened when the agent wanted to do something you would not have approved? Pi asks you to be present or to contain it; Octomind lets you write the rule down once. Third, did you want the work to keep going after you closed the terminal? That question only has one answer here.

If the honest result is "Pi was fine and I never missed the rest," use Pi. It's a good tool and its scope is deliberate.

FAQ

Is Pi more minimal than Octomind?

Yes, by design and by count. The Pi agent harness has eight built-in tools and no MCP client, sub-agents or sandbox. Octomind ships built-in MCP servers, sub-agents, guardrails and budgets. Pi keeps the core small and moves complexity into your TypeScript; Octomind keeps it in the runtime and moves your work into TOML.

Can Pi use MCP servers?

Not out of the box. pi.dev lists MCP among the things Pi deliberately does not build in, alongside sub-agents and plan mode, and points to the extension system for adding them. Octomind is an MCP client for stdio, Streamable HTTP and OAuth servers, and exposes its own.

Do both let me switch models mid-session?

Yes. Pi's /model opens a picker, Ctrl+P cycles through models passed with --models, and it supports 15-plus providers via API keys or OAuth. Octomind's /model changes the active provider:model inside the saved session, and its hosted catalog currently lists 36 models. Octomind additionally binds models per role and per workflow step.

Does Pi have a cloud or scheduled runs?

Pi's documentation covers local installation, containerization you provide, and platform setup for Windows, Termux and tmux. There's no first-party hosted machine or scheduler. Octomind's cloud provides persistent Linux machines with Docker and scheduled Routines that run without a local process.

Can I run both?

Yes, and it's a reasonable split. Use Pi locally where its small core and TypeScript extensions fit your machine and habits, and use Octomind where the work needs MCP servers, enforced policy, budgets, a durable machine or a schedule. Keep repository branches separate if both agents touch the same codebase.

Start with Pro — $20 your first month — and run one real task on a persistent machine before deciding which side of the harness-versus-runtime trade fits your team.