Pi Coding Agent

Operator Read

Pi is a deliberately minimal terminal coding harness maintained by Earendil Works (formerly Mario Zechner / badlogic). What's notable is what it refuses to ship: subagents, plan mode, approval popups, MCP, built-in governance. The core stays small; the platform grows via extensions. The provider list is deliberately volatile — treat it as "what Pi tests against today," not a forever-API.

Where Pi Is Useful

Use Pi when your own wrapper owns the product surface. TypeBox 1.x validation makes custom tools and SDK integrations portable to eval-restricted runtimes such as Cloudflare Workers — the previous validator couldn't run there. Custom tools can declare terminate: true to end the agent turn on a final tool call and skip the automatic follow-up LLM request — useful for tools with predictable terminal behavior. If you embed Pi inside your own UI or CI runner, capture stream transport as part of the run contract: stream configuration (SimpleStreamOptions, Transport) is exposed through the harness, but Pi will not record governance receipts for you.

Tune provider behavior in Pi when local inference or provider SDK behavior is part of the run contract; do not treat defaults as production policy. Timeout and retry controls (retry.provider.timeoutMs, retry.provider.maxRetries, retry.provider.maxRetryDelayMs) are available in /settings.

What Pi Refuses To Own

Pi's governance posture is explicit refusal: no approval dialogs, no plan mode, no permission popups, no MCP in the default surface. The refusal is the design statement: those concerns belong to the operator or a layer above the harness. No governance additions shipped in this window; the posture is stable.

Harness Receipts To Capture

Pi exposes the right inputs for an operator-owned governance layer to record: session identity through $PI_SESSION_DIR, provider retry/timeout metadata, provider selection, transport type, and extension TypeBox schema version. Pi exposes them cleanly and leaves their recording to the operator.

Migration Watch

Pin and audit Pi installs during the Earendil Works migration: the npm package is moving from @mariozechner/pi-coding-agent to @earendil-works/pi-coding-agent and the repo from badlogic/pi-mono to earendil-works/pi-mono. The pi update --self command handles global installs; CI references and infrastructure pins need manual updates.

Posture basis: 2026-05-06-pi-thin-harness-provider-churn, 2026-05-07-pi-thin-harness-churn, 2026-05-12-pi-earendil-migration-and-harness-sdk.

Open Questions

• When will @earendil-works/pi-coding-agent publish to npm? v0.74.0 updated internal references but the new package was not yet available as of 2026-05-12.
• Does the Earendil Works transition include any governance, pricing, cloud, or enterprise changes that would affect Pi's current "no governance in core" posture?
• The earendil-works/pi-mono repo already shows a bigrefactor branch with significant architectural changes to the harness. What does the refactored harness look like, and how does it change the extension and SDK contract?
• The $PI_SESSION_DIR env var is exposed to tools and extensions. Is it also exposed to the system prompt or context files, making it available for self-referential session logs?

What To Watch Next

• Source contract update: once earendil-works/pi-mono (or earendil-works/pi) is the canonical repo, update sources/pi-coding-agent.yml to point to the new URL.
• Earendil Works organizational posture: cloud offering, enterprise tier, or governance additions that would change Pi's minimalism claim.
• The bigrefactor branch: explicit harness resource invocation is a significant architectural change that may change the extension and SDK contract.
• Any plan mode or approval surface addition, which would signal a departure from Pi's core design stance.