跪拜 Guibai
← Back to the summary

Pi's 200-Token Agent Prompt Beats Claude Code's 14,000 on Speed and Cost

Last week on Juejin, the top trending post was titled "Why More and More People Are Using Pi," with 13,000 reads. After clicking through, I was honestly a bit shocked by the numbers: Pi's GitHub repository already has 94.8K stars, growing nearly fivefold this year.

The comments section was full of "Switched from Claude Code and never going back." My initial judgment was: another overhyped tool. But after looking closely at Pi's architecture and community discussions, I found it indeed takes a different path from Claude Code and Cursor—not by stacking features, but by subtracting from the fundamental question of "How should an Agent be designed?"

So I installed Pi and ran some daily development tasks. Here are my honest impressions.

What I Used Before and Why I Switched

I was a heavy Claude Code user, using it as my main tool since last year. For daily coding, refactoring, debugging, and writing tests, it worked fine in most scenarios.

But the pain points were obvious: slow response on complex tasks. When the context got long—opening a dozen files simultaneously, conversations exceeding 30 turns—the wait time often exceeded 30 seconds. A few times I stared at the spinning terminal cursor questioning my life choices.

Even more annoying was Claude Code's overly long system prompt (about 14,000 tokens). Sometimes the model would get tangled in its own constraints, producing code that looked professional but threw errors when run. You'd ask it why, and it would say "Sorry, I overlooked constraint XX," regenerate a version, and it would still be wrong.

The more complex the tool, the more easily the model gets disrupted by its own harness logic—I've seen more and more people in the community complaining about this.

Pi's Minimalist Philosophy: Only 4 Tools

The core argument of that Juejin article resonated with me: Pi's design philosophy is "minimalist core + user-extensible."

It has only 4 core tools:

No plan mode, no sub-agents, no built-in web search, no code search tools (grep/find etc. you have to invoke via bash yourself).

I was genuinely taken aback the first time I opened Pi—it was so bare. Claude Code greets you with various feature prompts, built-in tool lists, and documentation links. Pi just gives you a blank prompt waiting for input.

But after running tasks, I found that most tasks really only need these 4 tools. The workflow is simply: read files → modify code → run tests → check results. If the model is smart enough, the number of tools isn't the bottleneck.

What truly determines the experience is the model's own reasoning ability and how much effective context you give it—not cramming 14,000 tokens of system prompts to make it remember 100 rules, but precisely describing the current project's structure and constraints through AGENTS.md.

Real-World Comparison: Speed and Token Consumption

My main model is DeepSeek-V4-Flash. I chose it mainly because it's cheap, and Pi supports 15+ model providers—Anthropic, OpenAI, Google, Mistral, local Ollama, etc. can all be connected. This is something Claude Code simply cannot do. Claude Code basically only works with Anthropic's own models; although it recently added some extension support, the flexibility is far inferior.

In Pi, I can use GPT-4o-mini for simple tasks, Claude Opus for complex refactoring, and local Qwen for sensitive code. Switch in real-time with the /model command, no session restart needed.

Here's a speed comparison. The task was refactoring Class components in a medium-sized React project into Hooks + custom Hooks:

Metric Claude Code (Sonnet 4) Pi (DeepSeek-V4-Flash)
Task Duration ~45 seconds ~9 seconds
Token Consumption ~8500 ~1500
Output Quality Reasonable structure, but 2 lint warnings Basically the same, lint passed

Speed differed by 5x, token consumption by over 5x. Of course, this test scenario is relatively narrow and can't serve as a comprehensive evaluation, but the gap is genuinely palpable.

Additionally, Pi has a feature I really like that Claude Code lacks: tree-structured conversation history. You can fork within a conversation, create branches, try different approaches, and roll back. This is especially useful for multi-branch tasks like "a component needs to consider both performance optimization and code readability."

Extension System: From "Shell" to "Finished Home"

If the minimalist core is Pi's skeleton, the extension system is its soul.

Pi's extensions are written in TypeScript and can add new tools, register hooks, and define custom commands. I wrote a simple extension that automatically runs npx eslint --fix after every code modification, saving the step of manually running lint:

// extensions/auto-lint/index.ts
import { defineExtension } from '@earendil-works/pi-extension';

export default defineExtension({
  name: 'auto-lint',
  hooks: {
    afterWrite: async ({ filePath, bash }) => {
      if (filePath.endsWith('.ts') || filePath.endsWith('.tsx')) {
        await bash(`npx eslint --fix "${filePath}" 2>/dev/null`);
      }
    },
  },
});

Just register it in the config file. The entire extension code is under 15 lines, but it saves me a ton of repetitive operations.

There's a community fork called oh-my-pi that adds Hashline editing (eliminating the nightmare of trailing whitespace), LSP-driven smart renaming, lldb/dlv/debugpy debugger integration, and 40+ model provider support. Many people use oh-my-pi directly instead of the original, saying it's "what Pi should have been."

There's also an analogy I find very apt: Pi is the Arch Linux of the programming world—gives you the most basic stuff, and you figure out the rest yourself.

But honestly, not everyone has the patience to tinker from scratch.

Pitfalls Encountered: 3 Real Pain Points

After using it for a while, I hit a few issues that almost made me give up.

Pitfall 1: Without AGENTS.md, the model goes completely off the rails

Pi's context is highly dependent on the AGENTS.md file—defining project structure, tech stack standards, and coding conventions. Used to the out-of-the-box experience in Claude Code, I really struggled when first switching to Pi: without AGENTS.md, Pi is an amnesiac genius, knowing everything but unaware of your project's rules.

The first time I ran it, I was lazy and didn't write one. Pi generated code using Jest—the project clearly used Vitest. All tests failed, a screen full of red errors, and I stared at the terminal for five seconds before realizing what went wrong.

Later, I honestly spent 40 minutes writing an AGENTS.md, defining the tech stack, directory structure, naming conventions, testing framework, and prohibited actions. The effect was immediate.

Here's a core snippet from my AGENTS.md:

## Tech Stack
- React 19 + TypeScript 5.8
- State Management: Zustand (Redux prohibited)
- Testing: Vitest + Testing Library (Jest prohibited)
- Styling: TailwindCSS 4.x

## Directory Conventions
- Components go in src/components/, one folder per component
- Custom Hooks go in src/hooks/
- Utility functions go in src/utils/, must have unit tests

## Prohibited Actions
- Do not introduce new npm dependencies unless explicitly discussed
- Do not modify interface definitions under src/api/
- Do not use the any type; at minimum use unknown

After writing this, the quality of every subsequent conversation stabilized significantly. The time spent upfront was definitely worth it.

Pitfall 2: Viewing diffs during large-scale refactoring makes you want to smash your keyboard

Pi is a pure terminal interface, displaying file diffs as text. A few lines of changes are fine, but during large-scale refactoring involving a dozen files, scrolling up and down in the terminal to view diffs is torture.

Cursor has a graphical diff view, letting you see at a glance which line changed. Pi is an order of magnitude worse in this regard. Some in the community suggest using --diff-external to call an external diff tool; I tinkered for half an hour and couldn't get it configured, so I gave up.

If you're used to graphical tools, this might be the biggest dealbreaker.

Pitfall 3: Some extensions are not actively maintained

Pi itself updates very quickly (basically a new version every week), but the quality of community extensions varies. I installed 3 extensions, and 1 couldn't run on the latest Pi version, throwing a compatibility error about the RPC interface. I filed an issue, and the author didn't respond for three days.

This is common in rapidly growing open-source projects: the core project is hot, but the ecosystem hasn't caught up yet.

How I See Pi's Positioning

I think I understand why Pi attracts so many people.

It's not trying to be a "better Claude Code," but answering a more fundamental question: when models are smart enough, does the Agent framework still need to be that complex?

Pi's answer is no. Claude Code's system prompt is 14,000 tokens; Pi's is just 200. This isn't just about saving a few tokens—it means less "noise" in each round of model conversation, more reasoning space, and more predictable behavior.

But this logic has a prerequisite: you must be capable of managing context yourself. If you don't write AGENTS.md, don't install extensions, and don't spend time configuring workflows, Pi is just a bare terminal where everything has to be built from scratch.

So who is Pi suitable for?

Who is it not suitable for?

Conclusion: Pi Has Become My Default Tool

Here's the conclusion. After this week of use, Pi has replaced Claude Code as my first choice when opening the terminal. For daily coding, refactoring, debugging, and running tests, Pi is my go-to.

I haven't completely uninstalled Claude Code—for complex multi-file planning tasks, like needing to simultaneously understand the relationships between 5+ files and perform cross-module refactoring, I still switch back because its contextual coherence is indeed stronger.

But for 80% of daily development scenarios, Pi is faster, cheaper, and more controllable. The "minimalist + controllable" logic appeals to me more than "feature-rich + out-of-the-box."

If you're hesitating about whether to switch, my advice is simple: install Pi, run it on a small project for two days. Don't rush to "migrate"; keep it if it works, delete it if it doesn't. No cost involved.

Finally, I'll share a quote I saw in the Pi community, which fits perfectly as an ending:

When you feel an AI programming tool is getting increasingly "heavy," the problem might not be that it's not powerful enough, but that the complexity itself is dragging you down.