When it comes to coding harnesses capable of running autonomous programming agents, you’ve got plenty of options to choose from. Claude Code and OpenCode are among the most popular options, with the former meshing incredibly well with Anthropic’s powerful large language models. Likewise, Google’s Antigravity and Cursor include their own flavors of agent harnesses to orchestrate complex workflows from simple conversational prompts.
That said, I stray far away from the cloud LLM ecosystem, partly because I don’t want to deal with their privacy issues and subscription fees, and also since my local AI models are good enough for my coding needs. In fact, I’ve been using Pi with my local LLMs for a while, and while it has several perks that aid my self-hosted setup, I adore how I can extend its functionality using LLM-generated extensions instead of scrambling for MCP servers.
Pi’s ability to generate its TypeScript extensions makes it extremely customizable
Pairing it with local LLMs turned Pi into a self-evolving agent harness
Before you call me out for relying solely on Pi, let me add that I’m well aware that Claude Code and OpenCode can connect to locally-deployed LLMs. But here’s the thing: both agent harnesses tend to consume quite a bit of context width for their built-in workflows, examples, and tools. It may not be that big of a deal for cloud-based models featuring massive context widths, but on the self-hosting front, the thousands (and sometimes, even tens of thousands) of tokens hogging up the context length can be a bit of a problem.
Then there’s the fact that I’ll have to add MCP servers to these harnesses if I want to pair them with external tools. Even leaving aside the extra context width occupied by their tools, I’ve had my fair share of trouble connecting certain MCP servers with my agent harnesses.
Pi, on the other hand, is free from both problems. Instead of choking the context with extra tools that I probably won’t need for half my coding tasks, it has an extremely barebones design. Combine that with local LLMs, and I can easily have dozens of prompts in a single conversation before the context window even begins to get full.
But what really sets it apart from the group is its ability to build extensions on the fly using my prompts. Pi essentially has a self-evolving design, where I can ask the coding harness to build tools to extend its functionality, thereby getting rid of MCP servers altogether. If I want to hook it up to an external app, I can simply ask it to generate the right extension on the fly, making it significantly more customizable than its rivals.
Qwen3.6-35B-A3B is a beast of an LLM at creating TypeScript extensions for Pi
I use these custom extensions to connect Pi to my home lab services
Over the last couple of weeks, I’ve thrown all sorts of LLMs at Pi, including tiny models running off a Raspberry Pi. However, Qwen3.6-35B-A3B is the only model I use when I want to get some productivity work done, as its reasoning prowess is good enough to handle this agent harness. Since I use the MoE offloading flag (–n-cpu-moe) in llama.cpp, Qwen3.6-35B-A3B runs at a respectable token generation rate of 24-ish t/s on my RTX 3080 Ti.
As for the extensions, I’ve hooked my Pi agent up to everything from virtualization platforms to simple containerized tools. My custom Proxmox extension is the one I rely on the most, as many of my DevOps experiments require Pi to create a new virtual guest on my workstation. Now, it does have some limitations, like the inability to directly execute terminal commands on LXCs and the fact that switching between two standalone PVE nodes requires some back-and-forth with my LLM. However, it’s good enough for my Terraform and Ansible workflows.
Likewise, I’ve also created extensions for Docker and Podman so I can manage containers via conversational prompts. Thanks to Qwen3.6-35B-A3B’s reasoning capabilities, I haven’t run into any problems when managing containers using Pi, even when I purposefully toss vague commands its way just to gauge the LLM’s response. I’ve even paired it up to Home Assistant to generate automations alongside TrueNAS for simple monitoring tasks, and this setup works pretty well for my home server tasks.
On the coding front, I’ve also used extensions to pair it with Redis databases for web scripting, alongside another one that skims through log files on everything from virtual guests to bare-metal systems without granting Pi write access to them.
That said, I’ve added a permission enforcement extension to curb its YOLO tendencies
Since we’re on the subject of permissions, I can’t end this article without mentioning the pi-permission-system extension. Besides ditching conventional tools and examples, this barebones agent harness also doesn’t feature security methods, either, which is a recipe for disaster even with carefully written prompts and the likes of Qwen3.6-35B-A3B.
So, the pi-permission-system extension is the only third-party package in my Pi workflow. As you may have guessed from the name, this neat extension forces my Pi instance to ask for my approval before committing to any tasks requiring sudo privileges.
