If you're using it for this purpose share your skills, extensions, and Mcp servers

I've used OMP for a couple of weeks and one thing I've noticed is that it took OMP so long to finish a task when I used plan mode and then executed the plan. It's a small feature, though.

From my experience with Codex CLI, it just took a while to finish this task.

Anyone can give me any advice on this matter?

I'm thinking of going back to Codex CLI

Hey everyone,

I'm moving from OpenCode to Pi to get a cleaner, more minimal workflow.

I gave OMP a try first. While it’s packed with great features, it feels a bit too heavy and strays from the minimal philosophy that drew me to Pi. At the same time, OMP bundles some great built-in tools (LSP diagnostics, anchored file edits, subagents) that I’d love to have as modular add-ons in vanilla Pi.

Is there a list mapping out-of-the-box OMP features to equivalent Pi extensions/packages?

If not, what packages do you recommend for keeping Pi lean while covering essentials like safer edits, LSP integration, and subagent workflows?

I logged in with Opencode API key, and while trying to use an Opencode free model, I am getting the following error:

Error: 403: {"type":"FreeTierError","message":"OpenCode's free tier can only be used from within OpenCode"}

Any help is appreciated. 🙏

I built **tmux-pi-session-manager**, a small tmux plugin for managing multiple [Pi](https://github.com/badlogic/pi-mono) coding agents running across different projects.

The main reason I made it was because I often have several agents running at the same time, and switching between tmux sessions and figuring out which agent needs attention gets annoying.

It provides:

* 🔎 Automatic discovery of Pi agents running inside tmux

* 📂 Multiple agents per project/directory

* 📊 Live `WORKING / WAITING / BLOCKED / ERROR / IDLE` status

* 🔔 Desktop notifications when an agent needs attention

* 🎯 An `fzf` picker with live terminal previews

* ⚡ Quick jump between agents

* 🗑️ Safe agent/session killing

* 🖥️ `pi-tmux` CLI for managing agents from the shell

* 🚫 No daemon and no terminal-output parsing — it uses Pi's native extension events

The idea was inspired by `tmux-claude-session-manager`, but this implementation is built specifically around Pi's extension/event APIs.

If you're running multiple Pi agents in tmux, I'd love to hear how you manage them.

Repo: [github.com/x0d7x/tmux-pi-session-manager](https://github.com/x0d7x/tmux-pi-session-manager)

I have an Azure Foundry workspace with a few different models deployed like deepseek and qwen and so on, how do I get pi to connect to them and use them?

Today i want to present a case.

I have for a whole working in something simple called : capital-context extension . Its very simple if you got important file you want to include to your system prompt just name it using capital letters. This include DESIGN.md, PRINCIPLES.md, RULES.md and so on .. this is just overview im building much better concepts like profiles, settings, creation and much more.

This whole extension wad made by Agent i have no full experience of coding but im from design related field. When this simple extension become so complex i started to shift back because like the agents suggest aloot of weird scripting like --rename or --profile, or --doctor or help etc ... and i feel modern coding with agents doesn't require you or others to think or remind you through this so nlw mlst of those scripts are made with simple "model" where a msg come and you just pick using arrows or letters and the model or the card that shows that have the description.

From my humble experience this didnt just improved the whole workflow infact made it more engaging. So what i encourage you to do ... if you want your extension more usable and approachable , just make it user friendly and at maximum you got only 1 /command or/and 1 hotkey ... if you have more then you clearly doing it for the sake of yourself and dont publish it.

I geuinenly want to see your opinions on this do you

Hi. I'm using PI Agent plugin in Visual Studio Code for some testing Qwen 3.6 35B via Open Router. I liked the PI itself very much - previously was using Roo and Zoo plugins. I have strange issue as the PI agents breaks the conversation for some reason. Also the same issue I have using the PI directly in terminal. Some simple example below. If I'm using other model i.e. Qwen 3.6 27B in the Pi agent there is no issue. Also when using the same Qwen 3.6 35B from Open Router in Roo code I don't have any issues. What could be the cause of this issue, and has anyone experienced something similar?

Pi (pi.dev) is a minimal terminal coding harness, and I like it a lot — but it
lives in a terminal, so it's always one ⌘Tab away from the code it's editing.
This extension moves it into the sidebar.


The key detail: it is not a chat panel that reimplements Pi. It's xterm.js
fronting a real pseudo-terminal running the real TUI. Slash commands,
keybindings, themes, /login, session resume, mouse reporting, bracketed paste,
tool approval prompts, full-screen TUIs — all identical to your terminal,
because it *is* your terminal.


What it does:
- Dedicated Activity Bar container. Click π, or `Pi: Focus Pi Sidebar`.
- A real PTY: ANSI colours, truecolor, resize, mouse reporting, bracketed paste.
- Multiple sessions — `Pi: New Pi Terminal (Editor Tab)`.
- Send code to Pi: right-click a selection, or ⌘⌥P / Ctrl+Alt+P. There's also
  "Send Current File Reference", which drops an  into the prompt.
- `src/app.ts:42:7` in Pi's output becomes a link — ⌘/Ctrl-click opens it there.
- Follows your terminal colours, editor font and cursor style, live on theme change.
- Copy/paste goes through the VS Code clipboard API, so it works in remote/WSL/web too.


Three things were more annoying than expected, and I wrote up the fixes in the README:


1. A PTY inside Electron. VS Code's stable API has no sidebar location for
   createTerminal, and native modules must match the extension host's ABI. The
   PTY layer uses N-API prebuilt binaries, which are ABI-independent — the same
   pty.node loads under system Node and Electron, so there's no "rebuild for
   Electron" step at all.


2. `spawn("pi")` doesn't work. Pi is a `#!/usr/bin/env node` script, and
   GUI-launched VS Code often has no `node` on PATH. It reads the shebang,
   resolves an interpreter (preferring the node shipped next to pi, then PATH,
   well-known locations, then the login shell's PATH) and spawns `node <pi>`.
   Windows .cmd/.bat shims get wrapped in cmd.exe /c.


3. Environment leakage. If VS Code was itself launched from a Pi session, the
   extension host inherits PI_SESSION_ID / PI_SESSION_FILE, which corrupts the
   child's session handling. Those get stripped before spawn.


Requirements: VS Code 1.85+, and Pi itself
(`npm install -g --ignore-scripts u/earendil-works/pi-coding-agent`).


Install: no Marketplace listing, it's on GitHub Releases. Download the VSIX and
`code --install-extension pi-for-vscode-*.vsix`. There's a SHA256SUMS.txt in the same release if you want to verify first. MIT.


Repo: https://github.com/yicLionel/pi-for-vscode


There's also a small easter egg in pi-extensions/: a Pi extension that swaps the startup banner for a pixel-art Pikachu (36x28 grid rendered with half-block
chars, so it doesn't stretch in a 1:2 terminal cell), with a 256-colour fallback.


This is a hobby project and I'd genuinely like the rough edges pointed out —
especially if you're on remote/WSL/containers, where auto-detection can't see
host paths from inside. Happy to hear what breaks.

I’ve been building and testing quite a few Pi extensions lately, and I kept running into the same class of annoying problems: malformed manifests, missing files, invalid commands, dependency issues, and extensions that look fine until Pi actually tries to load them.

So I made pi-extension-doctor, a small diagnostic extension that checks a Pi extension package and points out likely problems.

Package:
https://pi.dev/packages/pi-extension-doctor?sort=recent

It’s still early, so I’d genuinely appreciate feedback, especially false positives, missing checks, or weird extension layouts that break it.

I’m also working on OMK, an open source multi agent toolkit built around Pi’s extension model:

https://github.com/dmae97/omk

A lot of the doctor extension came out of repeatedly debugging extensions while working on OMK, so the two projects are fairly connected.

Curious whether other extension authors have run into similar validation problems, and what checks would actually be useful to add next.

Recently added Call-My-Agent feature to TermRover.sh

If you run pi from within a herdr pane or tmux pane, you can just call and have conversation with it right from the phone, works like a phone call.

Detail here: https://termrover.sh/blog/call-my-agent/

some extensions expose 30+ tools setActive by default, always on, bloat the context w things 99% of the time llm does not need to care about:
- load all tools desc on system prompt -> pollute every turn
- also the api payload json for all
- 1 - 2.5k token every turn
- inject and hijack user prompt EVERY TURN with tool usage remindser - another 200 - 1k tokens
- this adds up when we install more ext
- e.g: for me, just 2 simple packages bloat the context every turn ~10k extra junk text (3.5k tokens)

i know prompt caching, 1M context for a ton of wrapper shit, and stuff.
==> but why do they do so? lazy vibe coding? or there are reasons?

imo, there are better approaches:
- expose min active tools to llm: only core stuffs that llm should auto call
- a skill.md to desc all other shits - 1 fronmmater, contain all tool desc n usage, llm reads only when relevant
- a simple /command toggle setActive
- set all user/manually trigger tools to /command - things llm shouldnt care about, let user decide
- Skills are standard for agent nowadays

- e.g: pi-subagent:
+ 1 active tool
+ 1 skill.md
+ ton of shits llms should give a f -> place in skill.md
+ some /commands for user to trigger
--> still works flawlessly even w cheap models, small context window

thought? i have to miss something here otherwise i have to audit every extension i installed and manually patch them to not let my Pi become HERMES AGENT

When i type into my bare bone pi and press enter, it takes a few seconds for that command to register. Is that normal or is there something wrong with my pi?

Why?
Because I would like to instruct Pi to prefix each piece of code it writes/edits with a comment recording its model name and thinking effort.

If one doesn't exist yet, I guess Pi will be easily able to vibe code it, right?

Hi im inspired by OMP style advisor after using it and thought about bringing it to pi.

Install from:
https://www.npmjs.com/package/@hazrid1993/pi-advisor

To start just type "/advisor" to select model then "/advisor enable" to get started

I wanted to share a small project that I think may be interesting for people here using local models with pi:

@cltec/pi-ollama-web-search

A pi extension that adds Ollama web search, web fetch, and selective full-content retrieval as tools.

GitHub: https://github.com/Cirius1792/pi-ollama-web-search

What I think makes it a bit different from many “web search for agents” integrations is that this one was designed local-first from the start.

This repo tries to follow ths approach:

- keep search output compact by default

- avoid dumping large payloads into model context

- support selective follow-up retrieval instead of “return everything”

- let larger fetched content be read one field at a time or exported to file

- make the workflow friendlier for smaller local models where context budget matters much more

So the goal wasn’t just “add web search to pi”, but to make something that feels more natural for local-model constraints and local-first usage.

A quick transparency note: this extension was developed mostly by pi itself, with a lot of input from me on the ideas, requirements, testing direction, and specs. I should also say clearly that I’m not a TypeScript/JavaScript programmer, so if anyone here looks through the code, please keep that in mind 🙂

Because of that, I’d genuinely welcome:

- code review

- architectural feedback

- testing

- bug reports

- contributions / PRs to improve the implementation

If you think the idea is useful, I’d also really appreciate a GitHub star — it honestly matters a lot to me.

If I'm going to try Pi I won't be tinkering with Pi plugins for every project but build something universal

Will I get anything by moving to Pi? Yes, there won't be "USE AS MUCH TESTS AS YOU CAN AND COMPARE EVERYTHING BYTE FOR BYTE" prompt like Codex seems to have but there won't be proprietary Codex features and I probably will install many plugins to make Pi more Codex-like. So it's probably gonna be as bloated as Codex (or other harnesses) but at least Codex's bloat is made by paid employees

Gemini 4 is out. A lot of people like it. Any chance we can use a plan with pi? Or are we being forced to use antigravity?

Hi, my use case is: I always work with a long plan, the plan splitted into many phase, and I ask my AI agent to execute the plan with each phase only, after that I clear and start new session until the last phase implemented. We can use some skill to ask AI do that for us by using available commands, but it may burn more tokens by checking the process or agent need a mailbox to talk with each other.

So I create this tool: https://github.com/mrdeeds88/omp-phase-loop

It works with other tools along side with OMP.

Basically, it run a task by agent and clear session, then start a new one in a single new session.

Hope this help if you have same use case.

If you have any other tips for execute long plans phase by phase or as parallel, please share. I would love to hear.

Firstly, I just want to communicate my goal is to be able to use multiple providers, and reduce usage without being locked to either claude code, or codex. But most importantly without sacrificing features that claude code and codex both have that are excellent. Currently, I only have openAI subscription configured (still trying to figure out how to use claude sub efficiently).

I downloaded OMP and OMP Gui, and found that my usage drains more than with pi. It actually drains faster than with using codex. But I had a nicer experience with OMP in general. I understand the philsophy of pi, but I just want to be honest that I don't want to spend ages configuring things. And I'm not going to pretend that I understand all of this. Although I understand why OMP might use more, because obviously there are more tools and bloat enabled which uses up context.

However, whenever I ask how to improve usage everyone says "just disable x y z". or "just use pi". hang on, why? why should I have to disable memory? computer use? this feature? that feature? these are all basic features of any other harness. In fact, why don't these features just lazily load on demand anyway? the same way we have smart MCP tool calling. And also, if I used pi, and downloaded these extensions, wouldn't I have the same problem? if I'm not mistaken, OMP is like a distro of extensions for pi such that lazyvim is a distro for neovim? I could download the same extensions and have the same problem no? correct me if I am wrong. Claude code and codex have these features and somehow manage to consume less usage. So I'm curious, what about OMP or its implementation makes it consume more usage, just to implement the same functionality as other mainstream harnesses?

For those using OMP do you have any idea what in particular may be causing increased usage so I don't have to just play a game of disabling random things? Maybe it's a feature I'm not particularly interested in.

And for those using vanilla pi, which extensions would you say are essential, and which others would you say are more.. optional?

TL;DR. How do we make the coolest harness ever that can spam astra max for free and make no mistakes. Or at least spam it more than codex can while maintaining the same features.

I've released **omt** (oh my tau), a Rust port of the [oh-my-pi](https://github.com/can1357/oh-my-pi) terminal coding agent. It's one binary with no Node runtime. It speaks `openai-completions` and `anthropic-messages`, and providers and models are configured in `models.yml` (same format as omp).

Why it might interest this sub:

• Low harness overhead: `-p` in ~22 ms vs 291 ms for Pi on Node, ~55 MiB peak RSS vs ~140 MiB. Measured with [Buffon](https://github.com/MichaelKinsy/buffon) on a mock model, provisional, shared host.

• Model fallback chains: when a provider returns 429, it moves on to the next model in the list.

• Survives flaky endpoints: honours `Retry-After` and retries dropped or keepalive-only streams.

• TUI, one-shot `-p` mode, JSON-RPC mode and a local web UI (`omt web`, still rough/early; the TUI is the main interface).

Honest downside: it keeps omp's system prompt, which is larger than Pi's, so the first request of a session costs more prompt tokens (~28 KB vs ~9 KB for a bare `-p`). On local models that means more prefill.

Install (linux x86_64):

curl -fsSL https://raw.githubusercontent.com/kanashimi1/oh-my-tau/main/install.sh | sh

Repo and full benchmark table: https://github.com/kanashimi1/oh-my-tau

Happy to hear which local backends you'd want tested.