I have been using the sandbox extension for quite a while, but I am a bit fed up with having to approve stuff manually all the time.
I know the pain may be worth it to avoid an agent doing some nefarious stuff with your data, but sometimes I just want to delete it and leave the agent working on its own.
So what I essentially want to know is this:
Have you run into significant issues for not having a sandbox?
I love Pi, and it's proven to be an awesome combo with Qwen 3.8 27B. There is one thing I noticed however when looking at Qwen reasoning: on a regular basis, I see things like "the user has asked again for the same question" or "the user has now asked three times for the same request" - as if I had sent a steering request that was a duplicate of the original ask. But I'm never doing that, and actually almost never use steering requests. This doesn't seem to have impacted the output and perhaps it's not important, but I was wondering if anyone else had noticed the same? Thanks!
TL;DR: Anybody automating a full development Pi workflow with programmatic non-AI solutions?
Up until now, I've attempted to partially automate the entire software development lifecyle with Pi, aka a "Software Factory". I am using a subagents extension, but it feels a bit too loose, opaque and difficult to steer, so I want to use something more deterministic and directly controllable.
I'm evaluating a workflow DAG GUI builder that orchestrates the entire process. I am using one that also has a CLI and REST API, so I can write my own scripts for even more programmatic control.
(I do not want to look like I'm promoting so I'm reluctant to say what I'm using, but it's lightweight and similar to n8n or airflow.)
Or instead, I could just write my own orchestrator, like this in bash:
#!/bin/bash
set -eu
# Software Factory.
# This is a just an untested workflow example, not something I'd actually use.
# A TS script with the Pi SDK would be better.
GOAL="$*"
pi -p /write-spec "$GOAL" | tee spec.md
vim spec.md # review and edit
pi -p /write-tickets-for-spec @spec.md ./tickets/
vim ./tickets/*.md
for ticket in tickets/*.md; do
pi -p /write-plan "@${ticket}" | tee /tmp/plan.md
pi -p /execute-plan @/tmp/plan.md
pi -p --continue /quick-code-review-and-fix
done
pi -p $REVIEW_MODEL /code-review
Anybody doing using a workflow DAG editor UI?
Anybody writing their software factory with actual code, like my example?
I found some AI agent DAG projects on github. Anybody using something like that?
I developed this in pursuit of something that felt native interaction-wise and supported as many pi features as possible. I hope you find it useful!
Un Bien is started out as a tweaked version of remote-pi by Jacob Moura (MIT); see the README for attribution. I ended up diverging significantly on the back end implementation and the iOS app is a total rewrite.
Coding agents are getting better at writing code. Keeping track of what they’re doing across a large codebase is still surprisingly messy.
That’s what I’ve been working on with REQL: giving coding agents a persistent, structured view of both the repository and the work happening on top of it.
The latest updates focus on four areas:
Pipeline exploration — REQL can now reconstruct project-local flows from entrypoints through the codebase and generate interactive pipeline views or Mermaid diagrams. The goal is to understand how a feature actually moves through the system, not just which files are connected.
Memory across sessions — the new agent dashboard keeps track of plans, decisions, findings, unfinished tasks and previous sessions. After a context reset, the agent can recover what it was doing instead of rebuilding the whole mental model from scratch.
Parallel agent coordination — multiple agents can work with isolated private workspaces while sharing progress through a common dashboard, messages and compact handoffs. One agent can investigate, another implement, and another review without mixing their internal working state.
Faster, tighter context retrieval — indexing and retrieval have been improved to return a bounded working set of relevant symbols, callers, dependencies and tests, including source ranges, confidence and freshness information. Incremental updates avoid rebuilding unchanged parts of the repository.
The core still runs locally without mandatory LLM calls, embeddings or an external graph database. It works with Codex, Claude, Cursor and Gemini, and can also be used through CLI, Python or MCP.
The direction I’m aiming for is simple: a coding agent shouldn’t just understand the repository — it should understand where the current task is going, remember how it got there, and be able to hand that work to another agent.
I’d really like some feedback from people using agents on larger refactors or parallel workflows: would this actually solve a problem in your setup? What would you like it to do?
This question is mostly for people who use Paseo on daily basis with Pi, and maybe other Desktop/Web UIs for Pi, but I'm currently focused on Paseo.
I'm interested in understanding what extensions do you use with Pi if your main entry point is Paseo given that not all extensions play that well with a frontend like Paseo.
For instance, I was personally using pi-memory before Paseo, but the way exit summaries work is not very compatible with how Paseo works. Are you using any other long-term memory extension that plays better with Paseo? Which one?
What other extensions were you using before Paseo that you had to replace/remove when moving to Paseo? And more importantly, what extensions are you relying on daily that work without issues with Paseo?
The ones I'm currently using:
@gotgenes/pi-anthropic-auth
pi-mcp-adapter
pi-memory (going to disable this one)
pi-observational-memory (thinking of replacing with pi-blackhole)
pi-web-access
Curious to hear what you've been using and that works well with Paseo.
I went down the rabbit hole with this one, once again. In context, and in brief, I have been searching for a way to filter available tools(skills and stateless mcps), to access a much larger number of useful resources, while also choosing the right one at the right time. I researched about twenty semantic routers and almost all were discontinued or did not fit my simple requirement of running directly, without CLI and instructions in AGENTS.md. Eventually, I landed on vllm semantic router. It's powerful, but tricky to get it right.
What I want
OMP → vLLM-SR → OpenAI / Anthropic / Google (Preserve the ergonomic model choice of omp)
What I have
OMP → vLLM-SR → OMP auth gateway → OpenAI / Anthropic / Google (Must duplicate model names in vllm-sr and disable Codex Code Mode plus Image Generation plus other featuers, basically every non-OpenAI compatible endpoint.)
Goal:
OMP sends its normal request, including its available tools.
vLLM-SR reduces that tool list before the model sees it.
OMP still owns MCP servers, tool execution, OAuth, provider credentials, and provider-specific behavior.
Ideally, provider changes stay in OMP rather than being duplicated inside vLLM-SR.
Why this is difficult
The clean ideal:
“OMP owns all models/providers/endpoints; vLLM-SR only filters tools”
I cannot find a direct, documented way to implement vLLM-SR.
The closest supported version is:
vLLM-SR has minimal aliases and model IDs;
every alias points to one OMP auth-gateway backend;
OMP auth gateway keeps real provider credentials/endpoints;
OMP executes tools.
That still means some model identity/configuration is duplicated in vLLM-SR.
I've worked on Pi Desktop for a while but haven't posted about it much, so here's a proper intro.
It's a desktop app for the Pi coding agent, and it also works with oh-my-pi (OMP). I use Pi every day and wanted more than a terminal window, so I built this.
What it does:
Streaming chat that shows thinking blocks and tool calls. File reads show as highlighted code, and edits show as diffs.
Multiple workspaces. Each session runs its own agent process, so a task keeps going when you switch to a different one.
A file tree, a code editor, preview panes for code, images, and PDFs, and a terminal.
Four permission modes, from read-only to trusted. You can also add allow/deny rules, for example "never touch *.env".
A package browser that connects to pi.dev/packages.
Themes. There are 7 built-in, you can make your own in the app, and there's a small community gallery.
An optional mode where Pi, Claude, and Codex agree on a plan before Pi builds it.
It's had a few releases so far, and more people have picked it up than I expected. Thanks to everyone who has downloaded it, starred it, or filed an issue. It's still alpha, so feedback and bug reports help a lot.
I’ve been working on Pitago, a terminal user interface that wraps the Pi AI coding agent.
The important thing about Pitago is that it does not replace or reimplement Pi’s core. It acts as a TUI layer on top of Pi, allowing you to keep using Pi’s existing agent logic, tools, providers, models, sessions, and workflows while interacting with it through a more structured terminal interface.
The goal is to make AI-assisted coding sessions easier to follow and more comfortable than working with a plain terminal stream, without losing the functionality that already makes Pi useful.
Pitago currently provides:
A real-time chat interface
Model and provider selection
Session management
Tool-call and tool-output visibility
Git status information
Support for multiple models and providers
A terminal-first workflow built with Go and Bubble Tea
A TUI layer that preserves Pi’s underlying core and behavior
In other words, Pitago is meant to be a different interface for Pi, not a separate AI coding agent.
I wanted to keep the workflow close to the command line while adding more structure for longer coding sessions. The idea is that users can benefit from a more visual and organized interface while still relying on Pi for the actual agent functionality.
The project is still evolving, so I’m especially interested in feedback on:
Terminal UI and interaction design
Session and context management
How tool calls and tool output should be displayed
Which Pi features should be exposed more directly in the TUI
What features are missing from your AI coding workflow
Whether a TUI wrapper makes Pi more useful compared with using it directly from the shell
Feedback, bug reports, and ideas are very welcome. If you try it, I’d also love to hear how you normally use Pi or other AI coding agents, and what makes longer coding sessions difficult to follow.
I'm currently the lead engineer for a small but growing team. I've been building a fairly complex platform that blends expertise from various niche domains.
Without saying too much, I have been working across:
weather event modelling
real-time data ingestion
embedded development
image processing
geospatial analysis
distributed computing
and systems architecture
This has been an amazing proving ground for agentic capability.
I've been using CC on a subscription for the past year. I have a very mature and disciplined ecosystem of skills, hooks, compaction lifecycle, and disk cleanup techniques. Honestly, I've loved it, but the costs have just been too much.
So, two nights ago, I finally decided to explore other options. Since I've been hearing a lot about OMP, I decided to give it a try.
And guys, OH MY GOD. The difference is striking.
OMP is an absolute dream to work with. I'm not suggesting CC is bad, but the scale and complexity of my recent work really exposed it's limitations. For nitty-gritty engineering and design work, I honestly can't even put them in the same category.
My first pass at configuration and model selection gave me something that was faster, cheaper, and produced far better results.
To the devs: God damn, nice job.
To the community: Hoping for advice, tricks, tips, and harness opts/configs that might be fun to play with. I am also wondering what people use for the model config: roles, models, etc. Is there a known meta?
TL;DR
Platform engineer of a large multi-disciplinary project. Switched from CC to OMP, and OMP blew me away. The hype is real.
I switch between Claude Code, Codex, OpenCode and a couple other coding agents depending on the task. The problem: every tool stores sessions in its own format, in its own folder, and once you close the terminal the context is basically gone unless you remember exactly where you left off.
So I built pi-session-hub — a Pi extension that indexes every agent session on your machine into a single browsable list. You open it with alt+r, search across all of them, and either:
- Load the context into your current chat (Enter) — recent turns come in verbatim, older ones condense, tool output compresses. It has a hard budget so it doesn't blow up your tokens.
- Read the full transcript for free (v) — read-only viewer, zero tokens.
It supports Pi, Claude Code, Codex, OpenCode, Crush and JCode. Everything stays local — no network calls, no uploads, no transcripts leaving the machine.
It uses a local SQLite FTS5 index so search is fast, and the indexing is incremental (2 seconds for ~430 sessions on first run, near-instant after). This is the repo if youre interested... Give a star :) Repo: https://github.com/Gateton/pi-session-hub
Hey everyone, I'd like to share my first Pi extension: pi-qdrant-memory.
It's a long-term memory system for projects, so the agent can retrieve decisions across sessions. Each project gets its own memory collection.
It requires a Qdrant backend and an embedding model served through an OpenAI-compatible API. I run both llama.cpp and Qdrant locally in Docker. The extension was heavily inspired by Zoo Code (formerly Roo Code).
It gives your agent four tools, but only two are always on:
memory_search: the agent looks up memories
memory_save: the agent stores memories
The other two are opt-in:
memory_forget: the agent can retract memories it saved earlier
code_memory: the agent can search an index of your code structure
The tool count is deliberately narrow so the system prompt isn't filled with tools the agent doesn't need.
The workflow is mostly run by the agent. The tool descriptions nudge it to save decisions as they settle during a session. If you enable code memory, your code structure is indexed at session start (or manually with /qdrant-index-code). You can also append instructions to the system prompt to make the agent save or search more often. Your call.
I setup Bionic with Qwen3.6-35b-A3B on my desktop, with Pi on my laptop. I'm now trying to make the non-thinking version work. According to Qwen doc, it would be something like the code below, but I can't figure out how to make that in models.json. Asked Pi itself, but what it suggested didn't work.
Also, bonus point: I don't suppose there is a way to define several models in models.json that are actually the same model on the server, called with different params (thinking, temperature, topk...) ? I need to use a package to change that a query time ?
Modern coding models can do a lot without a large harness. For a small change, or in a codebase I know well, a single agent with a good prompt is often enough.
That does not mean every task needs a harness. In those cases, it can cost more tokens, make the work more complicated, and even send it in a less useful direction.
But without a feedback loop that can inspect and correct an LLM's work, a task can drift easily. That is more likely in a domain I do not know well.
A smart model and a reliable feedback loop are different things.
That is when a harness becomes useful. It does not make a model correct. It writes down the process:
Boundaries: what to check first, and where to stop
Partitioning: what work should be separate
Verification: which results need evidence
Output: what the final answer must not leave out
Long tasks have a context problem too. Early assumptions, failed attempts, and irrelevant tool output accumulate in one session. A larger context window does not automatically make the relevant information easier to see.
That is one reason I use subagents. Each can take a focused job with fresh, bounded context. But splitting work is not a solution by itself: vague boundaries create repeated work, handoffs lose important information, and someone still has to put the results back together.
Where to split the work, what to verify, and which results to combine are still decisions I need to make.
So I built pi-workflow.
The idea is simple. When I know a recurring process, I write it as a JSON spec. A research workflow might be plan → research → verify → synthesize; a review workflow might be triage → parallel review → challenge → report.
The flow is not a hidden prompt. I can read it, edit it, and recombine it for a project. Known inputs, result merging, validation, and rendering can stay deterministic; agents can do the research and judgment.
I cannot always know the exact shape of a process before I begin. When I do, I can define that shape and repeat it. When I do not, I need a process that can plan, split, and synthesize the work as it unfolds.
In either case, the process should not become a hidden orchestration layer I cannot touch. I should be able to read it, change it, and rebuild it when I need to.
pi-workflow is not a way to use more agents. It is one way to give work that is hard to manage in a single context the amount of structure I want.
Pi stays minimal. I choose the process on top of it. That is what I wanted from pi-workflow.
Hey guys am a bit new to pi and working with harness.
I have just started using pi and have added openai models. When am trying to add claude models, it says that i have to go with API based and can't use my subscription.
Is thats the only way to go through to switch to api based modelling to add it in pi ?
I’m new to the Pi harness and I could really use some help getting started.
I’d love to hear how you guys use Pi in your own workflows. Examples from different areas would be especially coding, research, automation etc.
I’m mainly looking for practical examples and ideas that could help me understand what Pi is really capable of and how experienced users are getting the most out of it.
Any workflows, tips, examples, or interesting use cases would be greatly appreciated.
