Every week, another team signs a contract with an AI vendor. The pitch is familiar. One platform. One integration. One bill. It sounds clean until the team wants to switch models because costs went up, a competitor released something better, or a security review flagged an issue. Then they discover that their conversation histories, tool setups, custom workflows, and agent logic are all tied to that single vendor's system.

This is a strategy problem. And it is one that open source projects like Pi are built to address.

At its core, Pi is an open source framework for building AI agents. Think of it as the plumbing and wiring that lets software talk to large language models, use tools, remember context, and keep running over long tasks. It was built by a team that understands something simple.

The project is organized into several parts. There is a unified API that connects to language models, a runtime that manages agent state and tool calling, a coding agent that developers can use from the command line, and a package system that lets teams share extensions and skills. All of these parts work together, but you can use only the pieces you need.

Pi connects to nearly every major AI provider. OpenAI, Anthropic, Google, Azure, Mistral, Groq, Cerebras, Cloudflare, xAI, and many others all work through the same interface. Unlike most integration layers, Pi was designed so you can switch between these providers in the middle of a conversation without losing context. This is not a minor convenience.

Most companies today are building their AI tools on top of single-provider APIs. They write code that only works with OpenAI's format or only works with Anthropic's format. Their agents store memory in ways that cannot be moved. Their tooling logic is wrapped around one vendor's specific features.

When that vendor changes pricing, updates a model, or suffers an outage, the user has limited options. Accept the change, or rebuild everything from scratch. Neither option is attractive.

Pi approaches this differently. It treats the model provider as a replaceable part, not as the foundation. The foundation is the agent itself, its memory, its tools, and its goals. The provider is just the engine, and engines can be swapped.

This matters because the AI market is moving fast. The best model for coding today might not be the best model next quarter. The cheapest provider for routine tasks might raise prices once they have enough customers. If your entire stack is welded to one vendor, you lose the ability to react. You are stuck with their roadmap, their pricing, and their limitations.

One of the most practical features in Pi is cross-provider handoff. Here is what that means. Your AI agent could start a complex task using one model, realize it needs a different kind of reasoning, and switch to another model from a completely different company. The conversation history, the tool results, and the context all come along for the ride.

From a business perspective, this means you can use the best tool for each job. You might use a fast, cheap model for routine work, then hand off to a powerful reasoning model for complex analysis, then switch to a coding-specialized model for implementation. You do not need three separate systems. You need a one-agent harness that treats models as interchangeable resources.

This also protects your investment. If one provider raises prices or degrades quality, you can move traffic elsewhere with significantly reduced migration effort. Your team keeps the same tools, the same context, and the same workflows; only the engine underneath changes.

For a CTO, this is the difference between a configuration change and a months-long rewrite. For a CFO, it is the difference between a predictable budget line and an unexpected cost increase.

AI projects often struggle with context loss. An agent works on something for hours, builds up a detailed understanding of the problem, and then the session ends. The next day, or after a server restart, that context is gone. The team either starts over or spends expensive tokens re-explaining everything.

Pi addresses this with context serialization. The entire state of a conversation can be saved to a file or database as plain JSON. Later, it can be loaded back in and continued exactly where it left off. This works across different models and different providers.

The context includes not just the chat history, but also tool definitions, system prompts, and resource references. When you restore a session, the agent remembers what it was doing, what tools it had available, and what instructions it was following. You can even take a conversation that started with Claude from Anthropic, save it, and later resume it with GPT from OpenAI. Pi normalizes provider interfaces and message structures to handle the translation.

For a business, this means your agents can have real persistence. They can work on multi-day projects. They can survive server restarts. They can be transferred between teams or even between environments, from development to production, without losing their place. A customer support agent can pick up exactly where another left off. A coding agent can resume a complex refactoring task after the weekend.

Most software claims they are extensible. Usually, that means you can write plugins if you use their specific language, their specific API, and their specific deployment model. Pi takes a different approach.

Pi has a package system that works like npm or git. Teams can bundle extensions, skills, prompt templates, and themes into packages and share them internally or externally. These packages can come from a private npm registry, a git repository, or a local folder. They install with a single command.

What makes this matter is that these packages can define new capabilities for agents. A security team could write a package that gives every agent in the company the ability to scan code for vulnerabilities. A compliance team could write a package that ensures all agent outputs follow internal policy. A development team could share prompt templates that encode best practices for their specific codebase.

Packages can declare their resources in a simple manifest inside package.json, or they can use conventional directories. If you put skills in a skills folder, extensions in an extensions folder, and prompts in a prompts folder, Pi will find them automatically. You can also filter what gets loaded, so you can install a large package but only enable the parts your team needs.

Because Pi is open source and self-hostable, these extensions run in your environment, under your control. You are not waiting for a vendor to add a feature. You are building it yourself and sharing it across your organization. If one team builds a useful tool, every other team can install it with a single command.

The pi coding agent is the most visible part of the stack, but it sits on top of a carefully layered architecture. Understanding this architecture helps explain why Pi is reliable, flexible, and suitable for use.

Pi is built as a monorepo with four core layers. Each layer has a specific job and can be used independently.

Layer One: The Unified LLM API (pi-ai)

This is the foundation. It is a single interface that talks to over twenty providers, including OpenAI, Anthropic, Google, Azure, Mistral, Groq, Cerebras, xAI, and many others. Instead of learning each provider's unique format, your team writes one type of request. The framework translates it automatically.

This layer handles streaming responses, tool calls, reasoning blocks, image input, and cost tracking. It also supports custom models and local endpoints through an OpenAI-compatible format, which means your developers learn one API, not twenty.

Layer Two: The Agent Runtime (pi-agent-core)

This layer manages the agent loop. It decides when to send a prompt to the model, when to execute a tool, when to wait for user input, and when to save state. It handles error recovery, abort signals, and retry logic.

The runtime also manages the harness, which is the orchestration layer above the raw agent. The harness owns session persistence, runtime configuration, resource resolution, and operation locking. It reduces unsafe concurrent mutations through operation-phase semantics, ensuring that when an agent is busy, structural changes are queued rather than applied immediately.

Layer Three: The Coding Agent (pi-coding-agent)

This is the interactive terminal application that developers use daily. It includes a tree-structured session history, context compaction, file references, and a full extension API. It ships with four default tools: read, write, edit, and bash.

The coding agent supports four modes of operation. Interactive mode gives you the full terminal UI experience. Print mode outputs text for scripts. JSON mode streams structured events for integrations. RPC mode uses a JSON protocol over standard input and output for non-Node integrations.

Layer Four: The User Interface Libraries (pi-tui and pi-web-ui)

These are the presentation layers. The terminal UI library handles differential rendering, which means it updates only the parts of the screen that change. This eliminates flicker and keeps the interface smooth, even during heavy streaming. The web UI library provides components for browser-based chat interfaces, including artifact rendering for HTML, SVG, and Markdown in sandboxed frames.

When a developer types a request into the coding agent, the message flows down through the layers. The coding agent adds it to the session history. The harness creates a turn snapshot, which includes the current model, tools, resources, and stream options. The runtime sends this snapshot to the unified LLM API, which translates it into the format the chosen provider expects.

When the model responds, the flow reverses. The API layer normalizes the response. The runtime decides whether the response contains text, a tool call, or reasoning content. If it is a tool call, the runtime executes the tool and sends the result back to the model. If it is text, it streams up to the UI layer for display.

This separation of concerns means you can replace any layer without breaking the others. You could use the API layer with a custom runtime. You could use the runtime with a custom UI. You could even embed just the coding agent in another application using the SDK.

The coding agent stores sessions as JSONL files with a tree structure. Each entry has an identifier and a parent identifier. This means you can branch a conversation at any point, try a different approach, and switch between branches without losing history.

A developer can try one solution, branch, try another, and compare results. The full history remains in the file, but the active context only includes the current branch. When the context window fills up, the system can compact older messages into summaries while preserving the full tree in storage.

Long conversations eventually exceed the model's context window. Pi handles this with automatic compaction. When the token count approaches the limit, the system summarizes older messages into a compact form. The full history stays in the JSONL file, but the in-memory context is reduced.

This is customizable through extensions. A team could implement topic-based compaction, code-aware summaries, or use a different model for summarization than for the main task. The default behavior is automatic and transparent to the user.

CFOs and CTOs care about unit economics. AI spending is often opaque. You pay per token, but tokens are hard to predict. Different providers charge wildly different rates. Some charge for input, some for output, some for caching, some for reasoning.

Pi includes automatic token and cost tracking across every provider. Because it normalizes the interface, it also normalizes the cost data. You can see exactly which models cost what, which tools use the most tokens, and where the money is going.

This visibility is uncommon. Most people receive one bill from one vendor and hope it is reasonable. With pi, you can route traffic to the cheapest adequate model for each task, measure the savings, and make data-driven decisions about where to spend your AI budget.

You can also set up the system to use local models for sensitive work, which costs nothing in API fees, while routing public or less sensitive work to cloud providers. This kind of fine-grained cost control is substantially harder in tightly coupled provider architectures.

Teams in regulated industries cannot always send data to third-party APIs. Pi supports local inference through tools like Ollama and vLLM. You can run models on your own hardware, entirely offline, and still use the same agent framework. Your sensitive data never leaves your network, but your agents still have access to the same tools and context management.

For cloud-based providers, Pi supports OAuth authentication and automatic token refresh. It also supports environment-based configuration, so secrets and keys can be managed through your existing infrastructure rather than hard-coded into applications.

The package system includes security warnings for a reason. Extensions run with full system access because they need to do real work. This means you should review internal packages the same way they review any other code. The difference is that you can review it. With closed-source platforms, you cannot see what the extensions are doing, and you cannot control what data they access.

There are many AI frameworks available today. Some are tied to a single cloud provider. Some are academic research tools. Some are thin wrappers around one API.

Pi is different in three specific ways.

First, it treats multi-provider support as a first-class feature, not an afterthought. You do not write separate code paths for OpenAI and Anthropic. You write one agent, and the framework handles the translation. Switching providers is a configuration change, not a development project. The framework normalizes differences in how providers stream data, format tool calls, and report reasoning.

Second, it owns the full lifecycle of an agent session. From the first prompt through tool calls, reasoning steps, error recovery, and context compaction, pi manages state explicitly. Most frameworks leave state management to the application developer, which leads to bugs and data loss. Pi knows when a turn starts, when it ends, when to save, and when to retry. This is the kind of reliability that you need when agents are handling real work.

Third, it is built for extension by the people who use it. The package system, the hook system, and the self-extensible coding agent all assume that your team will want to customize the behavior. It is not a finished product that you configure. It is a platform that you extend.

Moving to Pi does not require throwing away your existing AI projects. Because it speaks the same APIs as the major providers, you can adopt it gradually. Start with one internal tool. Route some traffic through pi while keeping the old path as a fallback. Measure costs, reliability, and output quality.

Over time, you can move more workloads onto the platform. Your team will build internal packages that encode your specific business logic. You will develop a library of skills and prompts that belong to your company, not to a vendor.

Eventually, your AI infrastructure looks less like a collection of separate vendor integrations and more like a unified platform. Different teams use different models, but they all use the same tooling, the same context management, and the same extension system. When a new model comes out, you can evaluate it in hours, not months. When a provider has an outage, you can route around it automatically.

Installing Pi is straightforward for IT teams and developers.

For a standard install, run:

Or install through npm:

For developers who want to work with the source code:

Once you are inside the app, these commands help you move fast:

Table

You can also run Pi without the interactive interface, which is useful for automation:

Internal tools and extensions install the same way as public packages:

This means your platform team can publish a private npm package with company-specific skills, and every developer gets them with one command.

CEOs and CTOs should think of AI infrastructure the same way they think about cloud infrastructure. You would not build your entire company on a single cloud provider without an exit strategy. You want portability, interoperability, and the ability to move workloads where they make the most sense.

AI should be the same. The models will keep changing. New providers will emerge. Prices will shift. Capabilities will evolve. The only way to navigate that change without constant rebuilding is to own the layer that sits between your business logic and the models.

Pi is that layer. It is open source, so you are not dependent on a vendor's roadmap. It is multi-provider, so you keep your options open. It is extensible, so it grows with your needs. And it is built by a team that understands that AI is not about having the flashiest demo. It is about having infrastructure you can trust, control, and adapt over the long term.

The companies that get this right will treat AI as a capability they own. The companies that get it wrong will find themselves renegotiating contracts, rewriting integrations, and explaining to their boards why they are stuck with last year's model.

The choice is not between using AI and not using AI. The choice is between renting your AI capabilities and owning them. Pi gives you a path to ownership.