Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

And pi agent is even less.

The entire agent system prompt can be seen here:

https://github.com/earendil-works/pi/blob/main/packages%2Fco...



Maybe related to this minimalism, Pi doesn't come with most of the tools an LLM needs to function efficiently or effectively. I get that a blank slate is the paradigm, and you can add whatever you want, but it's too blank IMO.


I have a functional Pi config, mostly self-made (it has everything I want, incl. subagents, web search, a /btw command, and other misc. addons), and my system prompt is ~3k.


Would you mind sharing?


Exactly. It’s minimal to start but the sky is the limit at the other end. I love the plugability of Pi.


what tools are you talking about? Pi has ALL tools the LLM needs to function efficiently and effectively for coding tasks. It can read,write,edit files and can use any bash tool to search files, execute tests and so on.

Every time I read this comments I have the feeling you are talking about mcp or sub agents, otherwise this makes no sense at all.


That will increase the amount of initial tokens used, because the tools have to be described somewhere. Maybe not as much as Claude Code, but it could get more if you just randomly keep adding tools.


Oh-my-pi has more tools than claude and opencode, and uses them much more efficiently. my favorites are /collab and the gortex mcp


I tried using omp, and really like the interface, but I found it used tokens much much quicker than the Claude cli. Some simple tasks would use all the session tokens in less than an hour, as where I could get easily get 3-4 hours with Claude. Both set to use opus 4.8 auto effort. I tried tweaking the models for agents down to haiku and sonnet in omp, but didn't notice any real difference in the speed tokens were being used.


if the website is any indication, omp is just vibe coded AI slop as well. pi is awesome but it looks like omp is a step down including unnecessary stuff no one needs. it's kinda the opposite of pi


I've heard amazing things about pi and it's effectivenes but when I tried installing it I quickly found out it doesn't respect XDG_BASE_DIRECTORY at all, you need to set some environment variables and the author rejected both a proposal as "going full gpt", seemingly not even knowing about XDG_BASE_DIRECTORY, and even rejected a PR.

I've heard really good things but that being my first experience with pi didn't fill me with confidence about it's code quality either.

For now I stay with OpenCode I think - I was using zed editor and agent for the longest time anyway and think I will go back to that. CLI tools for me seem a bit too disconnected from the code.


Interesting! I wouldn't know, because I'm on mac. I love that it's very basic and I can basically do plug and play with the stuff I need. The load, complexity and system prompt overhang is quite minimal. But in the end, opencode is also fine I guess. I don't need to fiddle around with it too much and just need it to work. So if you're happy, why switch ;) I actually use zed as an editor w/o agents lol


It's easy to add using plugins.

What do you miss? I ask because I do some heavy work with pi + GLM 5.2 (using opencode Go subscription) and my workflow is plan -> implement.


> It's easy to add using plugins.

Sure, but you have to add almost everything, no? It deliberately only comes with read, write, edit, and bash. My point wasn't that you can't add stuff, but that I'd just rather use an harness that's a bit more full featured from the start.

(Pi is a bit like old 3D printing where fettling the printer to work is a central part of the hobby. I'd rather just buy a Prusa.)


I'd like to understand what features you're referring to that are missing from base-install Pi CLI.


The main ones missed immediately were web access/search. Then the to-do list features (it was a nice surprise to try OpenCode and see this working immediately.). There were a couple of other niggles but it was a few months ago. Also, this may not be common, but it seemed to struggle to edit effectively (driven by Qwen 3.6 35b/27b) and often rewrote whole files instead.


Gotcha, I feel like model or provider-specific installs would be a nice QoL improvement in that case. Presumably, part of this issue (beyond the ethos of minimalism) is the aim of shipping shipping an agnostic toolset. For myself, im openai-first, and of course that pushes me to favor their hosted tools (in this case web search), and their native CPT/RL'd stuff (Ie apply-patch).

Though, imo, the fact that pi maintains its "we only include the bare minimum!" statement is part of the draw for me. Especially considering that im in an enterprise env; being able to internally share custom implementations of out-of-the-box Codex/CC stuff is really nice.

I do wonder how they'd go about shipping a default web search tool. Big problem there is the lethal trifecta. Shipping something that arbitrarily allows untrusted content to be retrieved non-deterministically I'm sure is a long conversation on Pi's end. Pushing it off to the user to decide is easy.


I know it's against the ethos of Pi, but I think a lot of people would consider a handful of things like a memory system, web search, subagents, and looping to be a basic/base thing they would add to every agent harness.


I use Pi and love it, but the base install is extremely minimal (a handful of tools, no subagents, etc.). That’s on purpose. Sure, you can add more with packages, but that’s not the base install.


You know, seeing a total of 3 replies on this topic, I think the lesson here is to, from now on, with comments like this, to clearly state

"Pi has *ALL* the tools, can you name one it does not".


It starts lean, yeah. Did you know you can prompt it to add the capability you feel you’re missing?


If you really want a minimal agent that you heavily customize, just skip pi (130+ transitive dependencies on the "minimal" pi-coder package) and write your own. You learn a bunch, and it's not hard. You can even ask another LLM to help you get started.


I wrote my own harness in Emacs and it’s completely ridiculous how well it works. Auto-compact is the only missing feature on my list. Claude‘s approach, if I understand it correctly, invalidates a lot of cached context, and I‘m thinking about a more cache-friendly strategy.


Claude is very cache friendly, however there have been some inconsistencies with non anthropic endpoints that led to cache breakages


Exactly! I just vibe coded (with GPT Sol and Claude whatever-number) my own agent, it's trivial to add now any feature I want - simply ask more powerful model to do it for you. I am happy with end result, however it looks indeed these tools are trained to increase token count - they do quite stupid token-spending steps while making code, but the code itself is also a bit weird - it's like they intentionally do code which is hard to modify on your own without using exactly those authoring models. Interestingly, when I am using DeepSeek with OpenCode, I don't see that - it understands my intent well enough and overall code quality is not bad. I recently switched to local Gemma 4, and I often switch (in opencode) to just that less powerful model, because it understands my intent and has enough skills to provide good quality solution although it's rather for small size projects, and for not coding from scratch, but it's also free and private. It feels slower than any big cloud model, so my model switching is probably most quickest path to robust end result :)


That’s certainly doable, but then you need to create all the add-ons you would have added to Pi. IMO, Pi stands in that sweet spot between being very minimal while still offering a catalog of pluggable functionality that you can add to it. Sure, you could vibe code all those things for your custom agent as well, but why recreate what is essentially Pi all over again (the main loop with all the extension hooks, etc.)? Pi is the “standard” batteries-not-included agent, where you can add from a catalog of pre-defined batteries. I recommend starting with Pi and then using an LLM to code custom extensions where the catalog doesn’t have something you want.


Pi has way too many batteries included, including a bunch I don't want, and lacked the batteries I did want. Pi is a bit like the movie Idiocracy in that the idea is much better than the execution.

Incidentally, I also have zero supply chain attack surface as I have zero dependencies in my agent, just go stdlib. Pi, again, has 130+ transitive dependencies asking me to trust the security of my system to 150+ additional people I've never met in exchange for a bunch of bloat I do not want.


Agreed that the node cesspool is a risk. That said, what batteries does Pi have that you don’t want?


Bloated TUI library, unified multi-provider LLM layer, bloated RPC and SDK modes, the entire plugin framework, the list goes on and on.

For reference, pi-coding-agent, by itself (not including dependencies, tests, or pi-ai, pi-tui, pi-agent-core, etc), is ~41,653 SLOC taking up ~1658.9 KiB across 163 files.

My agent, excluding dependencies (all go stdlib) and tests, is 3 files, 946 SLOC, taking up 36.3 KiB, and includes a basic TUI and an XMPP transport channel (including TLS for XMPP), with dynamically configurable delivery to and receipt from either or both, including allowlists for XMPP message partners. It has tool calling, a permission model with whitelisting and interactive permission querying on a per-tool basis, full thinking support, including the ability to toggle hiding or showing it across either or both transports repeatedly throughout an individual session, the same tools as pi comes with out of the box, plus web search, and a tool to vet, build, and git commit golang projects all in one go, stopping if errors are observed. Configurable model and endpoint, too.

Incidentally, the open source xmpp server (prosody) and metasearch engine (SearXNG) are both self-hosted, too.


Sure, if your fundamental issue is “bloat,” you can always write a less general-purpose system that is smaller. No doubt about that.


I guess better phrasing would be auditability, ease of codebase comprehension, coverage of just the features I want. My agent isn't meant to be for X users across Y providers with Z extensible plugins, it's meant for exactly one user, with exactly one provider, and to minimize the amount of trust granted to third parties.


Got it. Yea, if those are your priorities then it certainly makes sense to write your own.


This is a truly underrated approach IMO


Any tips on how to get started?


I have written a few myself to get an understanding.

To learn yourself:

<$20 on a cloud AI api for a chunk of tokens and have the AI teach you. "help me write an AI Agent using (language) and walk me through the steps"

Realize that these agent are REPL/while loops that maintain a conversation state and then based upon the tagging syntax like <TOOL:bash:uptime>uptime for system run time</TOOL> and the agent extracts the tool and then does sub commands.


The build your own Claude Code track on Codecrafters is free while in beta.

https://app.codecrafters.io/catalog


At a minimum, you need an inference endpoint: either cloud or local.

If going local, llama.cpp is going to be the more beginner friendly local inference engine that supports more processor types (AMD GPUs, Intel GPUs, CPUs, anything that supports Vulkan, not just Nvidia). LM Studio is a nice wrapper for this if you'd rather avoid cloning repo and compiling yourself, provided you don't mind closed source software; it's much less enshittified than Ollama.

If going local, you will also need model weights in the right format for your inference engine, and with a model that can fit on your hardware. This is going to be .GGUF files if you're using llama.cpp or a wrapper for it like LM Studio.

From there, pick a language, go look up the OpenAI /chat/completions API format (or Anthropic's "Responses" API format), create a DS or array or slice to store messages, and build a loop that accepts user input, formats it according to the API format, sends it to the inference server, retrieves and parses the response, adds the response to the DS/array/slice, and repeat.

There's a lot more beyond this - tool calling, other API formats (optionally), MCP servers, transport layers besides terminal stdin/stdout, permission models, starting with a system message, clearing your message stack correctly (hint: don't reset it mid tool-call), message compaction, web searching and page fetching, semantic search RAG over embeddings, memory layers - way too much to cover exhaustively in a single message.


Quick self-correction: "Responses" is a newer OpenAI API format, "Messages" is the Anthropic format.


I was here looking for this comment = )


Read through it an I'm curious whether setting the date and cmd on every system prompt call will cause the cache to invalidate.

I guess the cache would only be invalid if the day changed or the root directory, which would technically happen infrequently enough.


I get 95% or more cache hit rate with pi and DeepSeek or MiMo so it doesn't invalidate.

But I'll investigate how that works in a session. You got me curious.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: