newtwilly
I agree with the author on a lot points about the joys of using low cost models. My work would pay much more, but I prefer to use cheap models usually. Assuming cost correlates somewhat closely with energy used, I feel good about spending as little as possible, and the cheap models are so capable.
One thing you can do in pi that you can't in Cursor: Have a 5-prompt conversation, jump back to prompt 3 and have a new conversation [call this convo2], then jump back to the original point 5, then jump back to convo2.
So fork is really only needed for when you need to interact with the conversation tree in two separate processes.
To me it's great how minimal the system prompt and tool set is, and I doubt those features are worth the tokens for every model. (Who knows if they improve performance for SOTA models, and they probably harm performance for small local models.)
I would add "better sandbox" support, which I think should be included out of the box. Not having a very simple way to get out of "yolo" mode is kinda crazy. Sure, there are plugins, but they do have some issues.
pi-bash-approval is good, but manual approval plus allowlist is a "bad" way to run coding agents.
The "best" way in my current opinion, is where commands run by default in a sandbox, but commands can be ran unsandboxed as needed, requiring approval or allow-list in that case. Cursor was pretty good at this (when I used it). For example I don't want to configure my sandbox with access to docker, which would present easy jailbreaks, but I do want to allowlist certain docker commands or approve them to run on my host as needed. pi-sandbox is good at allowing me to configure sandbox access, but this feature where somethings can run unsandboxed is missing. I write more about this and about (hacky, but productive enough) workaround here: https://github.com/carderne/pi-sandbox/issues/50
It starts up for me in under a second on my M4 mac. (Obviously could be faster, but doesn't bother me personally on my hardware)
My one main "issue" is with using the pi-sandbox extension. It's based on a forked claude code sandbox runtime. Not exactly sure why a fork was needed, and the fork is a bit behind now. I also wish the sandbox feature worked a bit more like how Cursor's sandboxing worked. Not familiar with Claude Code sandboxing, so can't compare that. I describe the issue and a (slightly hacky, but productive enough) workaround here: https://github.com/carderne/pi-sandbox/issues/50
Obviously the fact that I can fork a plugin for pi and customize it as needed is quite a plus too. Really all the other features work quite well for me!
You can install pi, then install pi-sandbox locked to the current version. Here it is described how pi-sandbox plus an additional extension allow you to have the experience where a sandbox is used, but you can fall back to unsandboxed with approval required. https://github.com/carderne/pi-sandbox/issues/50
* Perhaps could be solved with the right terminal software, but I like the GUI for seeing my running agents and viewing all my conversations
* Works with multiple model providers in the same tool. I probably worry about cost optimization more than my employer would care for me to, but I frequently switch between openai/anthropic and switch between model sizes to use the tool that I think can get the job done for the least money. Another thing I like is having a long conversation with an expensive model, then I can switch to 5.4-nano to cheaply extract some little piece of information or summary from the conversation. Really this is big being able to switch model providers throughout the months without having to change my interface.
* Good support for the various ways of providing context. Rules, AGENTs.MD/CLAUDE.md files (if you want it to automatically read those), skills. Good hook support.
* I think the agent diff review experience is pretty good, but maybe it works similarly when you hook the cli agents into an editor, IDK.
* The default shell sandbox behavior is quite good. Every shell command runs in some sort of sandbox so that read only commands work without approval. The model asks for more permissions when it tries to do something that needs more permissions like network access or writing outside of the workspace directory. I know Claude code has a similar feature you can use.
* Good fork / revert conversation to checkpoints, with the option of reverting the code or just reverting the conversation.
* Feels decent that I am an API customer through Cursor. I don't hit Claude limits. Cursor doesn't have an incentive to limit reasoning or token usage, although they do have an opposite incentive.
* They are reasonably responsive to bugs and feature requests through their forum.
* Works well with a lot of repos / folders added to your workspace. I probably should organize all my stuff under a single directory, but alas I have like 8 different folders added to my workspace and it handles this well. Perhaps Claude --add-dir support works fine too.
DOWNSIDES:
* They are not quickly adding the best open source models to Cursor. Like Kimi 2.6 or whatever. Possibly not incentivized to given their Composer models.
* Don't love the subagent support. I can define custom subagents although it is not easy to get models to use mine instead of the builtin ones. The builtin ones do not allow me to control what model they run, so they will always run something like composer-2-fast, which is a fine model for all I know, but I would like to control it. Also, I would like if you could optionally make the subagent experience more first class. Like browse all the subagents and continue conversations with them or switch their model etc, although that is probably tricky / weird.
> No human in the loop
If true, it's quite irresponsible. They are admitting to allowing a agent to autonomously execute code on the network. Autonomously perform hacking activities.
I like Sonnet 4.6 a lot too at medium reasoning effort, but at least in Cursor it is sometimes quite slow because it will start "thinking" for a long time.
So now I use a docker compose setup where I install Claude and run it in a container. I map source code volumes into the container. It uses a different container with dnsmasq with an allowlist.
I initially wanted to do HTTP proxying instead of DNS filtering since it would be more secure, but it was quite hard to set it up satisfactorily.
Running CLI programs with the dangerous full permissions is a lot more comfortable and fast, so I'm quite satisfied.
Do your rules count as frequent steering and lead to increased 'accuracy', or is that the 'accuracy' you're seeing with your current workflow, rules and all?