I’m using pi much more for long-horizon tasks (>6h). it's simpler by design and easier to work programmatically. i rarely use pi tui, most of my work is driving it inside a bigger system/container/uiux. some takes:

- pi ships with a minimal toolset and it's enough for airgapped tasks. if you have enterprise customers who want everything airgapped, pi + open-weight models is the goto solution.

- pi extensions are mostly unnecessary. i only have pi-mcp-adapter and pi-vcc installed, because i need to maintain/use jina reader mcp. pi-vcc is a drop-in fix for pi's context compaction, which can bite you on long-horizon tasks (see screenshot last swimline where compaction takes more and more time in long-horizon task)

- no double-dip: if you program pi with an agent like CC/Codex, you'll likely end up building another harness layer on top of pi's own harness, completely redundant glue code. every now and then you need to steer CC/Codex back to pi's design principle: keep the wrapper lean and mean, use pi native features as much as possible.

- imo pi works best with open-weight and self-hosted models, or at least that's what makes pi fun to work with. But pay attention to pi/models.json: your coding agent probably doesn't know every attribute of those new open models. forget to declare image modality as an accepted input and pi suddenly starts shelling out to tesseract for ocr everything. Or leave max context length conservatively set at 65K and pi starts compacting frequently for no reason.

- in the end, the nudge prompt (the one that keeps pi going forever), and workspace isolation (for multi-task/multi-tenant systems) are where you'll actually spend your effort. Not too many but that’s fine and that’s the point, for the harness just trusts pi to do the work in a very first-principled way. You can just focus on the actual task.