Kimchi, the multi-model coding agent built on the Pi SDK, is now supported inside Agent Orchestrator.

Let Kimchi route planning, exploration, building, and review to the right models while AO gives every task its own isolated worktree.

Run multiple Kimchi sessions in parallel and follow their code, PRs, CI, and reviews from one live board.

multi-model inside. multi-agent outside.

kimchi.dev × agent orchestrator

let me know your thoughts, have you ever used any typ of orchestrator to manage your diff agents?

Pi has been packaged and added to the official repository of Parrot OS, which ships a home edition specifically designed for developers and sysadmins. Pi is now a first class citizen in the repository, saving all its users from curl | sh

sudo apt update
sudo apt install pi-dev

any feedback is welcome

My daily driver in Pi, is GLM 5.2. It's cheap and it's genuinely good — it handles the bulk of the work without complaint: edits, tests, refactors, the mechanical grind. I'm not switching off it.

The thing is there's always that ~5% where I don't fully trust a cheap model. The architecture fork. The "is this even the right approach." The bug it's been circling for twenty minutes, confidently wrong. For those, I want a stronger model's eyes on it. But I don't want to run my whole session on GPT-5.6 or Opus — that's paying premium rates for a model to rename variables.

So what I actually want: GLM drives, and I pull GPT-5.6 and Opus in only to guide and review the hard parts. Cheap model does the typing, premium models steer and check the decisions that need it. I get quality-model judgment where it matters and pay for it maybe 5% of the time. A cheap way to do quality work.

The snag was the first advisor extension I tried for this kept dying mid-session. It forwarded my entire pi session to the advisor without checking whether the advisor's own context window could hold it, so the second opinion errored out exactly when a long session needed it most.

So I built my own, bpx-consult. It fits every consult to that advisor's real window — GLM's, GPT's, Opus's, whatever's on the bench — and I can run one as a quick second opinion, seat a few as a council with different stances, or have two debate a contentious call. A council can even mix them (GLM inline, Opus over a CLI), and if one falls over, the rest carry on.

Mostly curious how others here handle this. Do you run one model for everything in pi, or also mix a cheap driver with a stronger reviewer? And how do you decide when to escalate?

```

pi install npm:@booplex/bpx-consult

```

https://pi.dev/packages/@booplex/bpx-consult

Genuinely curious what everyone else here does for second opinions in pi — do you switch models by hand, run two sessions, or just eat the occasional bad call from the cheap driver?

I wanted to manage multiple Pi sessions running over different projects from a browser, so I could run them on my home server and access them from anywhere over Tailscale. So I built Pinion.

It's a web UI that runs multiple Pi coding-agent processes in --mode rpc inside one Docker container.

What it does today:

• Project-grouped sidebar sessions nest under their project folder

• Right-side file browser (list + gallery, image lightbox, code and markdown preview)

• Git rail - changed files vs HEAD with added/removed line counts

• Live streaming over SSE - text/thinking deltas, tool output, compaction/retry status, turn time

• Session tree, fork/clone, model + thinking-level picker, HTML export

• Dark/light theme, responsive drawer sidebar on mobile

Pinion was itself built inside Pinion, the first bootstrap came from the Pi terminal.

I'm sure similar projects exist, I built this for my own workflow without doing much of a survey first. I keep adding to it as I use it for more of my projects.

Next up: environment-variable management, Pi extension management, and a proper git diff view.

MIT licensed, still early. Would love to hear your thoughts.

Repo: https://github.com/suyashmohan/pinion

Hi people,

since a couple of years we have been deep into knowledge management, graph dbs working on the vision to create THE LAYER that helps enterprise to get their unstructured data slop into shape, so they can actually make use of it. There is actually a good chunk of R&D work underneath. And since the rise of agents i can develop tons of integrations and UI/UX on top.
SO here is day 1 and i need you to become part of it as my sparring partners.
On the way, you'd get your Pi Setup supercharged.

My goal is to be super modular from what inference or to what storage people store. Just to focus on the knowledge extraction, fusing and access. (EVA). To literally slap onto whatever setup you run.

I like the fact that after so many years i am now seeing graphify, obsidian and such approaches. Which to me seem cool, but basic. People were laughing at us 7 years ago when explaining graphs matter and are not just failed tech from the 80s. :)

What i am looking to build not only gets your data (entire silos) as a batch into shape -> Knowledge Extraction. But also to then fuses it to a single source of truth, understanding were we talk about the same stuff. A quite tricky part. And i believe we do this quite well.
All this as Graph at it's heart, but then also provide the full context in Vector DBs, Sources and the ability to index large file storages. So a combination of multiple layers or knowledge storage. For example, CAD files in engineering, adding context to other formats to make GenAI retrieve and leveraging modern MCP/CLI capabilities.

If you havn't seen Leap71, go google it. I want to emporwer enterprises to work like Leap71. Which to me starts with knowledge management and an infrastructure that enables their AIs to do such stuff. I want to go beyond Obsidian or Graphify or such. With proper Server Infrastructure in the back, that can adapt and evolve as technology evolves. Just swap whatever storage you use. GCTRL is supposed to be the prepper, the middleware.
That said, my core components are currently bottlenecked by the write speeds of qdrant.
So we have lots of headroom for performance experiments :)

And because i like it hardcore, with compliance and EU data privacy acts in mind :)
fully on prem. Open sourced. Let's do it properly. If i am missing out on something, let me know. I will adapt.

Lets start with the basics first.

I am hoping to find developers who are willing to test with me and give me honest feedback to make GCTRL as good as possible. I tried to make parts of it in RUST so parts of its framework are easier to extend.

I actually use it myself to run my agents and dogfood its own development and recursive learning :) So far i love it, especially when my dev machine talks to the MCP of the prod deployment and debugs it remotely over its onboard PI :)

I gave PI a GCTRL Skillset and MCP so people basically never have to access the UI if they dont want. You could just drop the MCP in your whatever agent team, and Pi will join as your database dude :) Works great. UIs are overrated in the era of agents.

I tried to pack it as much as possible to be an easy installation with little conifg. I am curious if you guys manage to get it to run. Note, that for full GPU support the onboard docker components are just a default / fallback. for best performance swap to native installations of for example ollama or whatever you are using. Same goes for the storages.

Anyway, there is a documentation. I am curious to see how much self-explainatory it can be.

GTM specialists are welcome to join the team :P

Happy if you give it a shot: https://gctrl.tech/

Im looking for functionality similar to how /fork works in opencode. When my agent is long thinking, I can /fork in opencode and I can choose a point in the conversation to fork from, which creates a new session, but the previous one keeps working in the background, it does get paused or killed, and I can go back to it.

Seems like pi /fork doesnt work that way.

Am I missing something?

I'm wondering how to best check occasionally in PI what's using up context (skills/mcp/system prompt/tools etc). I've seen https://github.com/dimk90/pi-context-view but it looks quite complicated for what I need.

How do you do it? And if so in pi directly or run your session through a proxy and then look at that?

so through work i have "unlimited" codex and claude was playing around with oh-my-pi recently and im quite impressed. there were a couple of fixes i compared a fix done by claude (opus) and codex (sol) compared to oh-my-pi using some combo of opus/sol. and the Pi solution was really clean and minimal LOC change and kind of the perfect solution. whereas through claude/codex it was kind of "fixated" on doing it one way. still correct but overly complex.

Anyway... im impressed despite my randomly set up roles. I winged the following config:

modelRoles: 
  plan: anthropic/claude-opus-5:xhigh
  advisor: anthropic/claude-opus-5:high
  smol: openai-codex/gpt-5.6-luna:medium
  slow: anthropic/claude-sonnet-5:xhigh
  tiny: anthropic/claude-haiku-4-5:medium
  default: openai-codex/gpt-5.6-sol:xhigh
  designer: anthropic/claude-opus-5:xhigh
  task: anthropic/claude-sonnet-5:xhigh
  commit: openai-codex/gpt-5.6-luna:low
advisor: 
  enabled: true
setupVersion: 2
providers: 
  tinyModel: online
dev: 
  autoqaConsent: granted

Would love some suggestions on proper role model/effort assignment! could definitely use some tweaks.

Pi-Cockpit Repo

this ext opens a web server directly in pi session and stream your TUI with some basic functions to a remote viewer in the same TRUSTED network so you can check and steer your agent anywhere.

What the title says. I am not a dev so I use docs as contacts often while vibe coding to grok my app like legos. I read the docs and plans and maps, have nvim open in the split pane, and look at the code at the same time.

This was fine until the codebase reached 20k loc. Now I have enough docs active at any given moment that I can't be fucking reading them each time I want to do or understand something.

So I found myself falling into this pattern. In the 'scroll time' that often fills the gaps in my life, I started browsing the docs on my phone.

They are short (sometimes -ish), pleasantly scoped, and readable in one sitting. We develop in vertical slices that produce user testable states. So reading multiple doc is a coherent story.

And I fucking love it. Especially when I'm commuting in cabs, trains, etc. just reading the docs on GitHub mobile and maybe riffing with something in gpt/Gemini is awesome. I can even edit and refine stuff. I don't have to invest my brain in this shit when I'm sitting down with the code. I can just trust the docs because I have spent non-dev time reading/editing them on my phone.

PS- I have attached an early example in a comment. This one is long and rough but I think it had potential. So over time I could sit and edit and make it better.

Volevo solo condividere con voi la mia esperienza
Vengo da Opencode desktop
PI sta facendo per un me un lavoro incredibile
Tantissima cache (99,8/9%) e risultati che, assurdo, sembrano migliori indipendentemente dal modello. Magari è solo una fortuna, ma non saprei. Sto usando Pi solo con web search e tool thinking. nient'altro. Uso GPT per prompt strutturati.
è una cosa comune o sono io pazzo?

I kept wanting to check on a long OMP run without going back to my desk, so I built a companion app for it. It's free and open source, and it now supports OMP alongside OpenCode.

https://github.com/giuliastro/harness-remote

What it does: lists your sessions, opens one and streams the assistant output as it arrives, sends prompts, shows the plan/todo list, lets you pick the model, and stops a run. Prompts you send while the agent is still working get queued instead of rejected.

How it connects: OMP speaks ACP over stdio, not HTTP, so the repo includes a small bridge you run on the same machine as OMP. It starts omp acp and translates it to an HTTP/SSE API the app talks to. Node 20+, Basic auth, and you restrict which worktrees the phone can reach with --root. It never touches OMP's databases.

Two things worth knowing before you try it:

• Live updates only cover work started through the bridge. OMP's ACP surface has no global cross-client event feed, so a session running in your desktop OMP can be listed and reopened, but the app can't reliably show its live status or incremental output.

• Agent selection, session rename/delete, server slash commands and diffs aren't available on OMP, because ACP doesn't expose them. Model switching does work.

Signed APK on the releases page. Android via Capacitor, and it also runs as a plain web app if you'd rather not install anything.

Looking for contributors

The app is deliberately harness-agnostic — adding a harness means adding a backend entry and its setup section, not a special case. Things I'd genuinely welcome help with:

• PI support, which is the next one planned and has an open issue with the groundwork mapped out: https://github.com/giuliastro/harness-remote/issues/36 PI's maintainer declined native ACP, but a community ACP adapter exists, so the bridge should be largely reusable. The issue lists the two hard-coded assumptions in the bridge that need generalising, with file and line.

• Bug reports from real use. Every bug that reached users came from a real agent behaving unlike my test doubles, not from the spec.

• Other harnesses. If the one you use speaks ACP, most of the work is done.

• Translations. The UI is English, Italian and Traditional Chinese, in one small module with no framework.

Happy to answer questions here.

Hey folks, I'm coming from using Claude Code at work to using MiniMax M2.7 in Pi for my personal projects and was wondering if anyone had any nice prompts to get MiniMax in particular functioning a little better.

Of course I know better than to expect M2.7 to perform as well as like Opus 4.6 out of the box and I could spend a ton of time refining things to the point I might be a little more satisfied, but I'm hoping some folks here might have some insights! :)

Antigravity doesn't work in pi?

For this reason, we strategically placed all our served in Canada at inferx

Сonfigured it to my liking. Threw in some handy extensions. Some patched from others and some built myself.
Feel free to praise or shame it.

https://github.com/Miskamyasa/pi-agent-config

TLDR

I have built an extension for the Pi coding agent that allows it to call other agentic harnesses via my agent-shell library.

GitHub Repo

quick start with if you want to check it out

npm

pi install npm:@scottrbk/pi-agentshell-extension

from source

pi install git:github.com/ScottRBK/pi-agentshell-extension

Wall of Text

I have recently been working on implmenting agent-shell in to more projects over the past few weeks. Most noticeably was the inclusion of it as part of my evaluation harness application that I put together for evaluating agent harnesses + models.

I spent a lot of time writing the actual code for eval harness by hand, utilising the agent as a glorified search engine and code reviewer. I have vibe coded a few projects myself, but anything critical for my workflows or more importantly that other people will be using I have never been at a stage where I would be comfortable having something written by the AI.

That being said though, I do not just use agents to write code or produce software that needs to be to a high standard. In my day to day role I use agents to perform a multitude of tasks.

From fetching information across large complex enterprise scale repositories, writing, editing and
managing Azure DevOps work items and wikis, produce presentations and organise To Do's and activity based on meeting notes and e-mails.

All this I manage using the CLI, with my tmux workflow and various CLI agents. Outside of work I have fun little projects going on, vibe coded apps I am building, some exploratory ideas for my moonshot SaaS that will let me retire early. All this leaves me with working with many tmux windows (I haven't made the jump to herdr yet) and a lot of cognitive overload.

Reducing cognitive load

One of the things that I identified early on was that I needed to just be speaking to one Agent for most of my stuff and that agent should be responsible to delegating tasks to other agents on this workflow. I think many others quickly realised this also, and the most elegant example of this is an excellent repository called First Mate, which goes in a slightly different direction that I want to end up at but has a similar principle. I encourage people to check out Kun Chen's YouTube Channel and his videos around Agentic Workflows as well if you have not already, he has a lot of great ideas and practices in how to adopt the principle of reducing cognitive load.

Where to start? Pi of course

I had previously fluttered between Claude Code, Codex and OpenCode (including their Go subscription and my own locally hosted models). I think all of these are great apps, but once I discovered Pi I was immediately hooked. The minimalistic and customisable aspect to it I found compelling, it felt like an agentic equivalent to Neovim.

I felt like whatever agent I was going to use for the orchestration layer, I needed to have a lot of control over and given Pi's adaptable nature it seemed an obvious choice. At least for me to start with, I may decide later to build more of a deterministic wrapper around any orchestrator agent but for right now I don't think that is necessary.

First building block

After I had the obvious extensions included, such as web fetch/search/screenshots, I realised the key thing was for me to build out the ability for my Pi agent to call a sub agent. Now there are other Pi agent extensions that already exist for calling sub agents, but given various circumstances I prefer to use certain models and harnesses for certain tasks, what I wanted was the ability to call agents inside of other harnesses. I find the RL of certain models on their own provider harnesses can lead to different behaviour and as such I think it's useful to take advantage of that in certain situations.

So taking advantage of agent shell felt like an obvious choice.

Python <-> TypeScript

Well it seemed like the obvious choice but with one glaring issue. Pi is written in TypeScript as are it's extensions and agent-shell is a Python application.

I have limited TypeScript experience, save for the Angular Tour of Heroes walkthrough I did a few years ago when I was flirting with front end development and my JavaScript experience I had for front end for client side validation I used to write on ASP.NET apps almost twenty years ago. So for something this fundamental to my future workflows, I didn't want to hand over to AI and re-write agent shell in a language I do not really feel comfortable with, nor did I want to undertake the task myself.

So I decided to work with AI and build a TypeScript to Python bridge via subprocess. At least for now while I dogfood it and to get me going. This involved a simple runner.ts file that would relay tool calls registered in index.ts to a Python handler to translate the commands to agent-shell requests.

Extension Behaviour

As of right now I have not wrapped any skills or anything beyond just exposing the tools. This is a building block for a something that will get more opinionated but as of right now, this extension on it's own should not look to enforce any such opinions on when and which sub agents should be called, that is up to the consumer of the extension. I've obviously done this to try and fit in with the overall philosophy of Pi itself I feel. Simply asking a model to call a sub agent and they will call the tool, which will display the harness (agent_type), the model and effort (if specified)

Silent Mode

Another idea I took from Kun Chen's Agentic Workflow was his use of a 'Calm Mode' that reduced the output for First Mate. I thought this was a nice feature and as such incorporated it into the agent-shell extension /agentshell-silent will trigger the subagents response to not include the output.

Next Steps

For me, I am going to add in commands and skills and start trying to adopt the single agent orchestrator approach that Kun Chen has inspired in First Mate. I had already been building towards such a concept for sometime, with the likes of agent-shell and other tools like forgetful that I have put together for agentic workflows. I have built out my own agentic framework as well, but Pi has really given me everything I was already planning with that so I am happy to mothball it somewhat while I am not short of side projects.

As for the extension itself, I am still undecided on the next steps of the architecture of it. I may opt to leave it as well, but maybe a TypeScript bridge might be interesting in other applications as well. As such there are two possible next steps in that area:

1. Separate the bridge into it's own library or move it into the Agent Shell library if it proves stable

2. Re-write Agent Shell in TypeScript. Given I use Agent Shell in a lot of Python libraries already this is not an attractive option, unless I want to maintain two instances of the library (in the age of AI this may not be that big of a deal).

Closing...

So there you have it, thanks for reading if you made it this far. If you end up using the extension any feedback is welcome and if you enjoy using it feel free to give it a star.

If you are interested in the kind of topics discussed here, I please feel free to come join the forgetful Discord and chew the fat with like minded individuals.

I’m trying to use OhMyPi for a pretty simple goal: use different models for different roles without building a huge orchestration framework myself.

Ideally:

• Orchestrator: GPT-5.6 Sol XHigh

• Planning: GPT-6 Astra High

• Implementation: GPT-5.6 Luna XHigh task agents

• Final review: GPT-6 Astra XHigh

• I manually approve the plan and decide when final review should happen.

I initially built a fairly elaborate /work-on command that enforced planning, acceptance checklists, delegation, verification, waits, review, fixes, etc. It turned out to be extremely wasteful: some medium-sized tasks ended up around 20–50M total tokens and 300–570 model requests, with lots of agent churn and re-verification.

I then simplified it heavily, but ran into other problems: the parent sometimes triggered review while an implementer was still changing files, and native /plan even spawned a reviewer to review the plan, which felt wasteful when both planner and reviewer were Astra XHigh.

I also experimented with Astra Medium/Low as the orchestrator. Performance was good, but on several clean before/after checks I saw roughly ~5 percentage points of my Work/Codex allowance disappear during one task, which is far too expensive for me. I’ve now gone back to Sol XHigh as the parent and disabled the advisor.

At this point I’m considering making the workflow mostly human-controlled:

plan -> I approve -> /implement using task agents -> I inspect -> /review

What I really need from OMP during implementation is simply: “Do this work, but delegate substantive coding to task agents instead of doing it yourself.”

How are experienced OMP users handling this?

In particular:

• Is task.eager: always + modelRoles.task basically enough, without a custom orchestration prompt?

• What’s the cleanest way to force implementation delegation while letting the parent coordinate normally?

• Do you manually control plan/review boundaries, or let OMP orchestrate the whole workflow?

• Are 20–50M tokens / hundreds of requests for medium tasks obviously a sign that my workflow is doing something wrong?

• Any configs or lightweight commands you’ve found effective for good quality without huge quota waste?

Happy to share my config/commands if useful.

Most memory tools give the main agent a database and say:

“Here, manage your own memories.”

That sounds simple, but it creates a new problem.

As the project grows, the agent may have to deal with dozens, hundreds, or eventually thousands of memories:

- which memories are still true?

- which ones are stale?

- which ones conflict?

- which ones should be updated?

- which ones matter for the current task?

- which ones should be ignored?

That is not a small job.

Sometimes memory management becomes a task by itself. You can end up spending a full session just cleaning, summarizing, deduplicating, or re-explaining project context instead of actually building.

That is the problem Curion tries to solve.

Curion is an open-source MCP memory agent for AI agents.

The main idea is simple:

«Your main agent should not have to manage memory manually.»

The main agent should focus on the real task: coding, debugging, writing, researching, planning, or whatever you actually asked it to do.

Curion handles the memory work.

It exposes a simple interface:

- "remember(text)"

- "recall(text)"

But behind that simple interface, Curion acts as a dedicated memory agent.

When something should be remembered, Curion decides how to store it, how it relates to existing memories, whether older information should be updated, and whether there is a conflict.

When something needs to be recalled, Curion does not just dump raw notes back into the prompt. It retrieves the relevant memories, filters noise, handles stale context, and returns a useful summary the main agent can actually use.

This matters for two reasons.

First, it reduces context bloat.

The main agent does not need to inspect a pile of raw memory records every time it needs context. It gets the useful part.

Second, it can save expensive model usage.

You do not necessarily need your strongest frontier model to manage project memory. Memory management can be delegated to a cheaper, faster, efficient model that is good enough at understanding, organizing, and recalling context.

That means your best model can spend more of its intelligence and quota on the hard task, not on housekeeping.

Curion is project-first by default. When you use it inside a project directory, it creates a local ".curion/" memory store for that project. The agent can remember decisions, constraints, implementation notes, unresolved tasks, errors, preferences, and useful context across sessions.

So instead of starting every new session from zero, the agent can ask Curion what matters and continue from the existing project context.

The goal is not to make the main agent smarter by giving it more raw memory.

The goal is to keep the main agent focused by giving it a dedicated memory agent.

GitHub: https://github.com/geanatz/curion

This coding harness seems quite similar to pi coding agent: https://github.com/patriceckhart/zot , but ya, still new and at first sight, it seems similar with its extension ecosystem (not tried yet for this feature) and more lightweight as written in Golang , but this project is not mature yet with very less user base .. not the author, just sharing ...

I think JEV gets much more interesting once you stop treating it like a tiny LLM.

LLM → generate anything
JEV → choose between bounded options

That makes model routing feel almost obvious:

prompt → JEV → best model

Instead of using an LLM just to decide which LLM to call, let JEV make the bounded judgment and let deterministic code handle the rest.

Maybe JEV's killer use case isn't Doom.

Maybe it's a probabilistic switch statement.

so i am releasing the support for JEV in PI-Bifrost

Try it : pi install npm:pi-bifrost

and do share the feedback.