Pi Explained: A Coding Agent Harness Built as Composable Packages

Most coding agent CLIs ship as one monolithic tool — the model API, the agent loop, and the terminal interface are bundled together, take it or leave it. Pi, from earendil-works, is built the opposite way: five separate, independently usable packages — a unified multi-provider LLM API, an agent runtime, a terminal UI library, a telemetry layer, and the coding agent CLI that ties them together. It's already established enough in the ecosystem that it shows up as a comparison point in other agent tooling's own benchmarks and supported-agent lists — jcode measures its RAM usage directly against Pi, and Orca lists it as one of its natively supported agents.

Five Packages, Not One Monolith

The architecture is the most distinctive thing about Pi, and it's worth understanding on its own terms:

Splitting the unified LLM API and the agent runtime out as their own packages means a team can build a completely different interface — a chat automation tool, a custom agent product, a Slack integration — on the same underlying provider abstraction and tool-calling runtime that powers Pi's own CLI, without inheriting the CLI itself. That's exactly what earendil-works has done with a companion project, pi-chat, for Slack and chat-based automation built on the same core packages.

Self-Extensible by Design

The project describes itself as a "self extensible coding agent" — the CLI isn't just configurable, it's built to be extended, including through a tool_call event system that lets an extension terminate an all-terminating batch of tool calls without triggering another model call, a detail that matters for anyone building extensions that need tight control over when the agent loop actually continues versus stops. Recent releases show this extensibility being actively used and refined, not just documented as a theoretical capability.

No Built-In Sandbox — By Explicit Design Choice

Pi's documentation is direct about something a lot of agent CLIs leave implicit: it does not include a built-in permission system restricting filesystem, process, network, or credential access, and runs with the full permissions of whatever launched it by default. Rather than bolting on a partial, easy-to-misconfigure sandbox, the project points to three explicit containerization patterns instead — a "Gondolin" extension that routes tool calls and shell commands into a local Linux micro-VM while keeping pi and provider auth on the host, a plain Docker container for simpler isolation, and a policy-controlled sandbox option called OpenShell. That's a meaningfully more honest stance than a tool that implies safety it doesn't actually enforce — the security boundary is explicitly your responsibility to add, with concrete, documented options for doing it rather than a false sense of built-in protection.

Multi-Provider by Default, Not by Afterthought

Because the LLM API layer is unified across providers from the ground up rather than added on top of an Anthropic-specific or OpenAI-specific core, Pi supports a genuinely broad provider list, including subscription-model providers like Qwen's Token Plan alongside the usual API-key-based options. A recent addition — pi auth check — lets you verify provider or model credentials are actually valid before you're mid-task and hit an auth failure, a small but practical piece of operational polish that comes from treating multi-provider support as core functionality rather than a bolted-on feature.

Supply-Chain Hardening Most Agent CLIs Don't Bother With

Pi's dependency management is unusually strict for an open-source CLI, and the project documents it in enough detail that it reads as a genuine practice rather than a compliance checkbox. Direct external dependencies are pinned to exact versions rather than ranges; internal workspace packages stay version-ranged, since those are reviewed within the same repo. .npmrc sets save-exact=true and min-release-age=2, so a same-day npm release can't get pulled into a build during dependency resolution — a real defense against a specific class of supply-chain attack where a compromised package version ships and gets adopted within hours. package-lock.json is treated as ground truth, and a pre-commit hook blocks accidental lockfile changes unless you explicitly set PI_ALLOW_LOCKFILE_CHANGE=1. The published CLI package ships its own shrinkwrap file, generated from the root lockfile, to pin transitive dependencies for npm users specifically — and new dependencies that introduce lifecycle scripts fail checks until a maintainer explicitly reviews and allowlists them. CI installs with --ignore-scripts, and a scheduled workflow runs npm audit plus npm audit signatures against production dependencies. None of this is exotic tooling — it's disciplined use of features npm already provides, applied consistently rather than left as defaults.

Releases Ship as Reproducible, Checksum-Verified Source

Standalone binaries aren't just built and uploaded on faith. GitHub releases include a versioned source archive covered by a SHA256SUMS file, and the exact script used to build the official binaries — scripts/build-binaries.sh — is included and runnable against that archive, with an --offline-model-data flag to rebuild using the release's pinned provider-model snapshot instead of refreshing it live. A package maintainer or a security-conscious team can independently rebuild what Pi shipped and confirm it matches, rather than trusting the binary a maintainer uploaded is what the source actually produces.

The Project Wants Your Agent Sessions, Not Just Your Code

One detail that says something about how earendil-works thinks about improving coding agents: the README actively asks users to publish their real Pi (and other agent) sessions publicly, arguing that real-world session data — actual tasks, tool calls, failures, and fixes — improves agent tooling more than toy benchmarks do. The maintainer publishes their own sessions to a public Hugging Face dataset and points to a companion tool, pi-share-hf, for anyone who wants to do the same with just a Hugging Face account and its CLI. It's a small ask, but it's a concrete bet that the field's benchmarks are a poor substitute for messy, real usage data — worth noting if you're weighing whether to contribute your own session logs back.

Practical Implications

• The package split is the real reason to look at Pi even if you don't use its CLI. A team building a custom agent product can adopt the LLM API and agent-core packages directly, skipping the CLI and TUI layers entirely — a more modular starting point than most agent frameworks offer.
• Containerize deliberately, not as an afterthought. Given there's no built-in permission system, decide on Gondolin, Docker, or OpenShell — or an equivalent of your own — before running Pi against anything you wouldn't want a fully-permissioned process touching.
• The contribution model is worth knowing before opening a PR. New issues and PRs from new contributors are auto-closed by default, with maintainers reviewing auto-closed items daily — a deliberate triage mechanism, not a sign the project is unmaintained.
• Telemetry is vendor-neutral and typed, which matters if you're instrumenting agent behavior across a fleet — worth checking the pi-telemetry package's contracts before building custom monitoring on top of Pi.

Practical Takeaway

Pi's real differentiator isn't a single flashy feature — it's the decision to build a coding agent CLI as a byproduct of a genuinely modular agent toolkit, rather than the toolkit as a byproduct of the CLI. For teams that need multi-provider LLM access and a real agent runtime as building blocks for something custom, not just an interactive terminal tool, that architecture is worth evaluating directly — independent of whether Pi's own CLI ends up being the interface you actually use day to day.

Teams building custom agent products, evaluating coding agent CLIs, or designing containerized agent deployments can get hands-on architecture help from Woyce Technologies.

FAQ

What is Pi?

Pi is an open-source AI agent toolkit from earendil-works, split into five independently usable packages: a unified multi-provider LLM API, an agent runtime, a terminal UI library, a telemetry layer, and an interactive coding agent CLI built on top of them.

Is Pi free to use?

Yes, it's MIT-licensed and open source, distributed as npm packages and standalone binaries built from versioned, checksum-verified release source.

Does Pi include a sandbox or permission system?

No — by design, Pi runs with the full permissions of the process that launched it and doesn't restrict filesystem, network, or credential access on its own. The project documents three containerization patterns (a Linux micro-VM extension, plain Docker, or a policy-controlled sandbox) for teams that need stronger isolation.

Which AI providers does Pi support?

A broad, unified set including OpenAI, Anthropic, Google, and subscription-model providers like Qwen's Token Plan, all accessed through one consistent API layer rather than provider-specific integrations bolted on separately.

Can I use Pi's packages without its CLI?

Yes — the LLM API and agent runtime packages are usable independently. A companion project, pi-chat, uses the same core packages to build Slack and chat-based automation rather than the interactive terminal CLI.

How does Pi compare to jcode or Orca?

Pi is referenced directly by both — jcode benchmarks its own RAM usage against Pi's, and Orca lists Pi as one of its natively supported coding agents — reflecting that Pi is an established, independently-usable agent harness other tools already build around or compare themselves to.

How seriously does Pi take dependency and supply-chain security?

Seriously enough to document it as its own practice: pinned exact versions for direct dependencies, a minimum release-age delay before new npm packages can be pulled in, a pre-commit hook that blocks accidental lockfile changes, a dedicated shrinkwrap file for npm users, and a scheduled npm audit / npm audit signatures workflow in CI.

Can I verify that a Pi release binary matches its published source?

Yes — GitHub releases include a versioned, checksum-verified source archive along with the actual build script used for the official binaries, so you can rebuild a release yourself and confirm it matches what was published.

Does Pi expect users to share their agent session data?

It asks, but doesn't require it. The README encourages publishing real Pi and other agent sessions to help improve agent tooling with real-world usage rather than benchmarks, and points to a companion tool, pi-share-hf, for publishing sessions to Hugging Face.