Pi spent a year wearing its refusal as a badge. The pi.dev landing page said it plainly: Pi does not support MCP. Creator Mario Zechner wrote a whole post in November 2025 arguing you probably do not need the protocol at all. Then on October 1, 2026, Pi 1.0 shipped with MCP support built into the core, and Earendil (the company Armin Ronacher and Colin Daymond Hanna formed, which acquired Pi in April) published an explainer titled "You Said No, MCP!". The Register called it a 180, and the Hacker News release thread drew 1,632 points and 567 comments.
I care about this story for one reason: it is the cleanest public test yet of where tool composition belongs in an agent harness, and the answer affects your rules file regardless of which agent you run.
What actually shipped
The 1.0 announcement lists what landed in the core:
- Codemode, described as native support for MCP plus non-LLM models like Jev and image models
- Extension support for virtual models
- Deferred tool loading
- Cache warming for Anthropic models
- Mid-conversation system messages, meaning transcript-aware prompt and tool changes
- A new TUI theme and full-screen mode by default
Alongside it sits Pi Durable, an experimental package for long-running agentic applications, deliberately kept out of the coding agent so Pi stays small. Install is the usual one-liner, curl -fsSL https://pi.dev/install.sh | sh, MIT licensed, code on GitHub.
None of that screams "minimal agent betrays its ethos", which is roughly how the angrier half of the HN thread read it. The interesting engineering is in why MCP moved from extension to core.
Codemode runs where the harness runs
Earendil's explanation is more specific than "MCP got better". A harness has two sides: the trusted agent loop, and the sandbox where tools execute. Most tool orchestration happens on the tool side, in places you do not fully trust. Codemode is a JavaScript sandbox that runs on the harness side instead, and its state lives in the session transcript rather than the filesystem.
The practical consequence: the model can issue and combine tool calls as a script instead of as a long chain of round trips. Their demo post shows Pi pulling 250 open issues from the Linear MCP server, classifying comment tone with the Jev model four calls at a time, and returning a ranked list of frustrated threads, all inside one codemode script. The transcript shows hundreds of MCP calls collapsed into a single result the context window actually sees.
JavaScript is the chosen language because small versions ship as WASM binaries with reasonable isolation. Codemode loads automatically when MCP is configured, or you can ask Pi to reconfigure itself and add it as a default tool.
The problem Codemode does not solve
Here is the part I respect most: Earendil concedes the weak half of its own argument in the same post. MCP is still hard to compose, and codemode does not fully fix that, because the fault lies largely with MCP servers themselves. Many are still built for harnesses that dump every tool schema into the context and optimize for token efficiency by returning text blobs instead of structured data. Their framing is that MCP should look much closer to OpenAPI with intelligent tool discovery: tools return structured data, tools are discoverable by their documentation.
If you have measured what MCP servers cost before the first prompt, this is not news. When I counted the token cost of nine MCP servers, the schema dump before any work started was the headline number. A harness-side sandbox changes where composition executes. It does not change what the server puts in your context when the harness asks for tools.
Why the metadata forced the issue
The technical reason MCP could not stay an extension is mundane and worth knowing. Pi recently added support for deferred tool loading and mid-conversation system messages, so a tool now needs metadata saying whether it is exposed to the LLM directly, deferred, or available only inside codemode. A normal MCP extension cannot see enough of the tool loadout to make that decision. Wiring the metadata through for extensions would have been most of the work of core support anyway.
In other words, the reversal was less a change of heart about the protocol and more a collision between two feature sets that both needed the same plumbing.
What this means for your config
Two takeaways if you maintain rules files or agent configs.
First, the exposure decision moved closer to you. Deferred tool loading and codemode-only tools mean "which tools does the model see" is now a per-tool configuration question, not a protocol given. That is the same class of decision as choosing what lives in AGENTS.md versus CLAUDE.md versus .cursorrules: the format does not decide, you do, and the harness enforces what you declare.
Second, a protocol adoption does not retire your guardrails. Codemode orchestrates calls, it does not judge them. Whether a tool may run, what it may touch, and what it must never do still live in your config, exactly as enforcement belongs in config files rather than vibes. Pi's own trust model is famously barebones and expects you to customize it, which is the extreme end of that spectrum.
Minimal harnesses are converging
Zoom out one week and the pattern is hard to miss. Claude Code 2.1.287 shipped Mods on October 1, plugins that hook tool calls and prompts inside the tool itself. Cursor is routing agent tool calls through self-hosted runners while keeping the loop in the cloud. JetBrains opened the Air EAP on October 1, a conduit layer that runs multiple agents inside one IDE. Everyone is moving orchestration into the harness and competing on how the harness treats your instructions.
Pi's answer is the most explicit about the trade: adopt the protocol, shape it from inside, keep the agent small. The Skills-over-MCP argument lands in the same place from the other direction.
What I would watch
The HN thread raised three checkable questions and no release note answers them. Does the codemode prompt cut hold outside Earendil's chosen example? Does MCP on by default change the context budget for the local-model users Pi courted? And does the extension ecosystem keep carrying users who liked Pi precisely because features arrived unpreinstalled?
Those get answered in the issue tracker over the next months, not in the announcement. Meanwhile the reversal itself is the signal: even the most ideological minimal harness decided the composition problem is worth solving inside the tool. Your config still owns what the composed tools are allowed to do.
If you maintain agent configs across tools, that division of labor is the whole game: harnesses compete on orchestration, your files define the contract. I keep mine versioned and validated, which is exactly what AgentConfig Studio packages for Next.js, Python, Go and Rust stacks, and the free Next.js sample shows the same structure for $0.
Top comments (0)