
I spent the weekend reading Caleb’s post on his move from Claude Code to Pi and it resonated with my setup more than I expected. If you are running your own dev environment, you likely feel the friction he describes. It is a stark reminder that our tools are not just utilities. They are partners that need to respect our workflow. The shift away from the big players toward open source alternatives is accelerating, and for good reason.
The Cost of Convenience
Caleb spent over a year using Claude Code. He admits it was a giddy experience when it first arrived. But the accumulation of small frustrations finally broke the camel's back. He found himself copying and symlinking between CLAUDE.md and AGENTS.md files. That is just noise. It is bureaucratic overhead that adds nothing to the actual code writing. For people who like to keep their repos clean, this kind of friction is a dealbreaker. I feel the same way. I want my configuration to be transparent and simple. Hiding instructions in multiple file formats with different names is annoying. It forces you to manage two parallel worlds of context. That is not how I want to spend my energy. I want to focus on the logic, not the metadata.
Broken Multi-Tasking
One of the biggest complaints in the post is the IDE integration. Caleb uses Claude Code inside VSCode. He likes highlighting text to add it to the context. But the harness only allows one session to be connected to the IDE at a time. If you open a second tab to work on a different task, it cannot receive text selection events. This bug has been reported since December 2025. It was closed as a duplicate of an unrelated issue. That is infuriating. I run multiple terminals in my daily workflow. I often have one task running in the background while I tweak something else in the foreground. Being locked into a single context window for IDE interactions is a severe limitation. It forces you to choose between parallelism and convenience. You cannot have both. That is a fundamental flaw in the design. It tells you that the product team is not thinking about how real developers actually work. They are thinking about how to show off features in a demo. There is a difference. I value my ability to switch contexts quickly. If my tool fights me on that, I am done with it.
Bloat and Instability
The post highlights a terrifying release cadence. There have been 244 releases of Claude Code this year. Over three quarters of those changed the system prompt or tool descriptions. That is a lot of churn. Each change can subtly alter how the LLM performs. It can contradict your user prompts or repo conventions. Caleb notes that the default Bash tool description is almost 3,000 tokens long. Most of it is random advice about git and GitHub. The models already know how to use git. They do not need a manual. This bloat adds overhead for no benefit. It wastes tokens. It wastes money. For those of us running local models or watching our API bills, this inefficiency is painful. I prefer tools that are lean. I prefer tools that do exactly what I ask and nothing more. The constant feature additions in Claude Code feel like a race to the bottom. They are chasing enterprise customers. They are trying to sell more tokens. That is not a vision for individual developers. It is a vision for revenue. And I have no interest in supporting that. I want a harness that respects my autonomy. I want one that stays out of the way. Pi seems to offer exactly that. It is minimalist. It is stable. It lets you customize what you need without forcing bloat on the rest of us.
The Case for Open Source
Caleb’s move to Pi is a signal. It shows that the open source community is building viable alternatives. He wrote an extension to handle multi-tab functionality in twenty minutes. That is the power of an open harness. You are not stuck waiting for a corporate release cycle. You are not stuck with a product that ignores your needs because they are not profitable enough. You can build what you need. You can shape the tool to fit your life. I am not ready to fully commit to Pi just yet. I am still evaluating the ecosystem. But I am paying attention. The stability and customizability he describes are exactly what I look for in my homelab gear. I want control. I want transparency. I want tools that do not sneak changes into my system prompt every week. The era of trusting big tech to build the best coding assistant is ending. We are taking that role back for ourselves. Give Pi a try if you are feeling the fatigue. It might be the breath of fresh air you need. The future of coding is open. And it looks a lot cleaner than the alternatives.