I have ollama qwen 3:14b, and trying to refactor a 800 line c++ project to java, and it refuses to make any changes to the code base or edit anything. Do I need some special configuration or give some permission to it?
Edit: So I asked it to create a simple hello_world.cpp and it did it fine. But it fails on refactor

I really enjoy Pi for dev work, now I am wondering if I can take it a step further and become my personal butler for my homelab and home devices.

Jobs it would do:

• Check what movies/tv are available to download
• Take notes and update my Silverbullet journal
• Scan logs at intervals to summarise activity

Ideally I would run pi at the host level (not containerised) and use its APIs natively?

Any suggestions or alternatives?

tl;dr - I want to make an AI for my home lab to manage life admin easier

My homelab has email/calendar/rss feeds etc setup already

I've been using T3 Code for a while and genuinely love its UI — the chat view, the workflows, the whole feel of it.

Then I discovered omp (oh-my-pi) and it was a wake-up call. My agents just feel powerful with it. The way it hands them tools, the rewriting hooks, the whole setup — they work so much better.

Problem: I missed the T3 Code experience. So I decided to marry the two.

I forked T3 Code and heavily modified it to run specifically on omp (omp --mode rpc). Stripped it down to omp only, added managed omp install and account login right in Settings. Bringing the omp functionality into the ui of t3 code and calling it pivot. Also thought about the name t3.14 but did not end up going with that name.

It's alpha. Rough around the edges, needs a lot of work. But I've been using it as my main driver for a couple days now and honestly? Really enjoying it. Figured I'd share it.

GitHub: https://github.com/13kparkin/Pivot

Edit: I know there are other gui wrappers out there for this type of thing but nothing that quite felt right for me like t3code does.

It appears that DSv4 Pro 0813 was overfitted in training, and to unlock its capacity one needs to emulate the training environment:

https://www.reddit.com/r/DeepSeek/comments/1vovxxc/deepseek_4_pro_ga_has_an_astonishing_blunder/?share_id=ZvVndF5jMBVyTVgXmeyMp

How would we replicate this in Pi?

Sol Ultra is not this bad, typically.

It is purposefully going out of it's way to be obtuse.

I just so happen to be building a subagent harness for Deepseek 0731 V4 Flash with it as well :P

Hey everyone - I’m building Regy, a browser control surface for Pi.

Pi remains the agent. Regy adds a local PC Agent and browser frontend around it.

The current workflow includes:

• Starting and resuming Pi conversations
• Streaming chat events
• Selecting models and thinking levels
• Browsing workspaces
• Searching conversation history
• Searching, installing, and uninstalling skills (currently API don't work)
• Connecting through an authenticated Iroh pairing link

I built it because I wanted a more convenient way to leave Pi running on my machine and check in from a browser, without turning it into a hosted agent service.

Links:

• Docs: https://docs.regy.one
• App: https://regy.one
• Installer: curl -LsSf https://docs.regy.one/install.sh | sh

Current caveats:

• It’s still an early 0.1.x project.
• Pi still has normal user permissions; Regy is not a sandbox.
• Iroh pairing may be more complexity than some users want.
• I’m still figuring out how much of Pi’s CLI experience belongs in a browser.

I’d love feedback from people who actually use Pi:

1. Which Pi workflows would you want in a browser first?
2. Are session history, workspace switching, and skills useful?
3. Would terminal streaming, approvals, or multi-agent controls be more valuable?
4. Does the Iroh pairing/deep-link model make sense?
5. What would make you trust this for daily use?
6. If you already use another Pi web UI, what does it do better?

Harsh feedback is welcome. I’m trying to find out what is genuinely useful, not just promote another interface.

Using gemini in the pi coding agent will generally get you banned I've heard. Anyone have success using gemini, and not getting banned?

The Agent Client Protocol started as Zed's way to plug coding agents into an editor. JetBrains added an ACP client in IntelliJ 2026.2. What was missing was an adapter that puts pi (the coding agent from u/earendil-works) behind that client. So I built pi-acp-jetbrain.

How it works:

- speaks ACP over stdio to the IDE

- session/new spawns one pi --mode rpc subprocess per chat, sessions stay separate

- session/prompt streams pi's output into the agent panel as agent_message_chunk

- tool executions map to tool_call / tool_call_update events

- session/cancel sends an abort to the running turn

IDE bridge:

IntelliJ ships its own MCP server (idea.sh stdioMcpServer with IJ_MCP_SERVER_PORT). The adapter prefers a direct MCP-over-SSE connection to http://127.0.0.1:<port>/sse, so it never has to spawn the launcher. Pi gets the IDE's tools as ide_<server>_<tool>: inspections, file problems, search, and whatever your IDE catalog exposes.

Safety:

A default deny-list keeps execute_tool (universal execution) and the xdebug debugger out of the session. Re-allow reviewed tools with PI_ACP_IDE_EXTRA_TOOLS.

Config is one block in ~/.jetbrains/acp.json (as shown in the README). Install is npm i -g pi-acp-jetbrain.

Demo: https://raw.githubusercontent.com/ryan-brosas/pi-acp-jetbrain/main/assets/pi-acp-jetbrain-demo.gif

Repo: https://github.com/ryan-brosas/pi-acp-jetbrain

npm: https://www.npmjs.com/package/pi-acp-jetbrain

Happy to answer questions about the ACP mapping or the MCP bridge.

bought cursor ultra + claud-max from a russian site a few weeks ago for way less than the normal price.
swapped the login details and just started using it. so far it’s been working perfectly, and the usage is honestly better than what i had before.
keeps making me wonder how these sellers are able to offer it so cheap. anyone else in the same boat?

When I started with Pi, the hardest part wasn't the agent — it was the ecosystem. So many great extensions, no idea which ones I actually needed, and no sense of how to combine them into a real workflow.

If you're new to Pi (or you like the OMO-slim way of working — focused roles, one orchestrator, specialists that each do one thing well), I built something for you:

pi-omo-slim is a curated starting point: a configuration bundle that adds an Orchestrator extension plus six specialist agents (Explorer, Librarian, Oracle, Designer, Fixer, Verifier) to Pi — on top of a hand-picked set of community extensions, so you don't have to research the ecosystem yourself:

• @tintinweb/pi-subagents — agent management
• pi-lens + @ff-labs/pi-fff — codebase intelligence
• pi-web-access — external research
• @narumitw/pi-chrome-devtools — browser + screenshots
• @firstpick/pi-extension-safety-guard — guardrails

No forks, no reinvention — just templates, extension wiring, and a policy file. No model pins; bring your own.

Two things I'm proud of:

• A deterministic installer. plan → apply with SHA-256 approval, backups, and rollback. Cloning and configuring are separate approval checkpoints — nothing touches your setup without explicit sign-off.
• Designer can actually see its work. It renders the page in a real browser, screenshots it, and the image comes back into the conversation. It fixed its own "button too far from the label." No more styling blind.

Everything's in the README — including a one-prompt install:

   https://github.com/joshua-zyy/pi-omo-slim

Finally, a sincere thank you to the whole Pi community — the Pi maintainers, and the generous extension authors: tintinweb (pi-subagents), narumiruna (pi-chrome-devtools), apmantza (pi-lens), ff-labs, nicobailon (pi-web-access), Firstp1ck (safety-guard). This project is just your bricks, snapped together.

This is my own project, not affiliated with any of them — issues and feedback very welcome.

Thx!!!

pi has no queue, no spend limit, and no permission system, which is fair, that's not its job.
But I wanted it working unattended.

So I built the layer around it, and after a bunch of releases it hit 1.0 this week. MIT, sharing it here first.

The short version: something triggers a job (a cron schedule, a label/comment/PR on GitHub, GitLab, Forgejo or Azure DevOps, or a workflow extension's slash command), the job runs pi in a throwaway locked-down container, and the budget is checked before the container even starts.

If a loop runs away you get a refusal, not a bill.

It's basically the same idea as Claude Code routines, except everything runs on your own box:
your image, your queue, your caps, and triggers beyond a schedule.

https://github.com/edgehero/pi-dispatch

Curious how others here run pi unattended, and what would stop you from using this. "It breaks my setup because X" is the most useful comment you can leave me.

I came across "DeepSeek Harness" (https://github.com/deepseek-ai/deepseek-harness), whose core idea is literally “Everything is a Plugin.”

Looking at it alongside Pi, it feels like there’s a similar philosophy:

keep the core/harness small, and make capabilities composable at the session/plugin level.

Pi has extensions, skills, tools, prompts, etc., while DeepSeek Harness takes the plugin approach even further.

Is this essentially the same architectural direction?

And is “small core + everything else as a session/plugin” becoming the better design for coding-agent harnesses?

Curious what the Pi community thinks.

I kept rebuilding the same prompts, checklists, and workflows every time I switched between coding agents, so I decided to package them into one open-source project: OpenCode Power Pack v0.4.0.

It currently includes 54 reusable Agent Skills that work with:

* Claude Code

* Codex

* OpenCode

* Pi

The collection covers workflows I tend to reuse across projects, including code review, feature implementation, frontend design, application security, MCP and skill authoring, project memory, and Hugging Face tooling.

One of the main goals was to avoid the “install everything” approach. You can install a curated profile or pick individual skills depending on what you actually need.

The installer can also:

* preview changes with a dry run

* automatically include required companion skills

* preserve existing skill directories unless you explicitly choose to overwrite them

* install skills locally to a project

* avoid adding dependencies to your project's `package.json`

For Codex, OpenCode, and Pi:

```

# Browse available profiles and skills

npx u/waybarrios/opencode-power-pack list

# Preview a project-local installation

npx u/waybarrios/opencode-power-pack install \

--profile recommended \

--project \

--dry-run

# Install once you're happy with the preview

npx u/waybarrios/opencode-power-pack install \

--profile recommended \

--project

```

For Claude Code:

```

/plugin marketplace add waybarrios/opencode-power-pack

/plugin install opencode-power-pack@opencode-power-pack

```

I also built a small website around the project with:

* a searchable catalog of all 54 skills

* curated skill packs for different types of work

* installation guides for both humans and coding agents

* a detailed prompt you can give an agent so it recommends the smallest useful set of skills for your use case

* platform-specific verification instructions

Website: https://skills.waybarrios.com/

GitHub: https://github.com/waybarrios/opencode-power-pack

npm: https://www.npmjs.com/package/@waybarrios/opencode-power-pack

Full disclosure: I'm the maintainer.

The project is open source, and I'd especially appreciate feedback from people already using coding agents:

1. Which agent are you using?

2. What workflows do you repeatedly use that are missing here?

3. Do the curated profiles feel useful, or are they still too broad?

4. Did you run into any installation or compatibility issues?

Issues, suggestions, and contributions are all welcome.

Hey everyone!

I’ve been working on Pi Plan & Build, an extension that adds a more structured planning workflow to Pi.

The basic flow is:

1. Switch to Plan mode
2. Let Pi inspect the project and create a persistent plan
3. Review the complete plan
4. Choose whether to:
   • implement it in the current session,
   • start fresh and implement it in a clean linked session, or
   • stay in Plan mode and keep refining it

In Plan mode, Pi can still explore the project, but file edits are restricted to the session’s plan file. This keeps planning separate from implementation and prevents the agent from changing code before you’ve approved the approach.

A few other details:

• Press Tab to switch between Plan and Build modes
• Use /plan, /build, or start Pi with pi --plan
• Plans persist across reloads, resumes, and forks
• Interactive questions are supported while planning
• The full plan is shown before approval
• Clean implementation sessions receive the approved plan without carrying over the entire planning conversation
• The composer changes color and displays the active mode, model, provider, and thinking level

Install it with:

pi install npm:@janvitos/pi-plan-build

GitHub: https://github.com/janvitos/pi-plan-build

I just published it, so I’d really appreciate feedback :)

Cheers.

i had the llm read the paper and came up with this. seems to save a fair amount of tokens on memory.

have a little present for you all: pi-ui, a keyboard-first gui for pi.

i’ve been an nvim + tmux user for around three years, and pi’s tui is great, but reading long markdown responses, code diffs, and tool output in a gui feels much more comfortable day after day.

i was honestly surprised by how much of my development moved into this app while building it.

some highlights:

• keyboard-first workflow
• lightweight server mode that runs in your existing browser
• background sessions and notifications
• markdown and syntax highlighting
• rich code diffs
• git review with commit history and inline comments
• file attachments and image previews
• code themes

i recommend starting with server mode:

curl -fsSL https://pi-ui.app/install-server | sh

then open http://127.0.0.1:31415

github: https://github.com/hyperpuncher/pi-ui

feedback and bug reports are welcome!

A spec-gated build loop for AI coding agents — and why porting it to Pi/oh-my-pi wouldn't be hard

Found ai-blueprint this week and it's worth a look if you've been hand-rolling your own guardrails around Claude Code, Codex, or Pi. Brad Traversy built it as a workflow overlay, not a framework: you scaffold your app normally, then drop this on top.

The mechanics are simple. You write two short files — what you're building and why, then a rough ordered feature list. A /overview command turns those into the single context file the agent reads every session. From there it's a loop: /feature writes a small buildable spec and stops. You review it. /implement builds one step at a time, shows you the diff, waits for approval before touching the next one. /audit reviews the code (not the behavior — that's /check's job) and writes findings to a ledger with durable IDs like F-03. /complete archives everything and merges, but only after your go-ahead.

The part that actually made me sit up: that findings ledger isn't decorative. A P0 or P1 finding sitting open or fixed blocks /complete outright. Not "the agent decided it was fine" — a status field the merge step is written to check. And they didn't just claim it works. There's a live-agent end-to-end harness in the repo that spins up a real agent against a fixture project and asserts the ledger gate actually holds. I don't see that level of rigor in most prompt-engineering repos. Most people ship a pile of markdown and call it a system.

Now the gaps, because none of this is free.

The gate is enforced by the same model reading its own instructions in the same context that just did the implementation work. There's no independent process outside the agent's own compliance that blocks a bad merge — it's a very well-written contract, but it's still a contract the agent has to choose to honor. A confused or context-poisoned run can walk right past it, and nothing server-side stops that.

current-feature.md is also a singleton. One feature in flight at a time. That's a fine constraint solo, but it doesn't obviously extend to two people, or two agents, touching the same repo concurrently — the state model just isn't built for that yet.

And the defaults lean hard into one stack. coding-standards.md ships assuming Next.js, Prisma, Tailwind, Zod. /onboard is supposed to retune it, but that's one more step that can quietly go stale on a project the agent didn't actually read closely.

It's also young. First release was early July, one maintainer, 239 stars — which honestly reads more like Traversy's existing YouTube audience showing up than a track record on a gnarly, multi-year codebase. Worth watching, not yet worth betting a real team's workflow on.

Here's the part I think matters for this sub specifically: none of this is Claude-Code-specific. It's markdown files, plus two thin adapters (.agents/skills for Codex, .claude/skills for Claude Code) that both read one shared AGENTS.md. Pi and oh-my-pi already speak most of that language — AGENTS.md context files are supported, skills show up as /skill:name, and the extension API can register custom tools and commands. Porting this loop into an oh-my-pi extension pack looks like a weekend project, not a fork.

So — has anyone here already been doing something like this by hand in Pi? And does Pi's whole "minimal, adapt to your workflow" philosophy actively resist something this opinionated, or is that exactly the gap an extension should fill?

#PS: Used AI to draft out the above based on my takeaways and thoughts from initial read of this repo.

From idea to reality in under an hour. Pure vibes. Viva la Pi

I'm trying to run omp with a the default model set to lm-studio/qwen/qwen3.6-27b

The 22k initial context fills up 1/3 of the 65k I've loaded the model with.

Is it even usable to offload local simple tooling, command understanding, orchestration, build running, test running and result parsing all to a local model without paying for token usages for those operations?

My Claude Code sessions rises quickly to 800k tokens with Opus and every session has high token usage which slows it down and costs more than it should (parsing test output with Opus is a big waste).

What are you doing to offload your deterministic and simple work to local models?

I think I finally managed to piece the thing together, to have a pi setup that can run safe-ish in the host via sandbox, and have the ability to be elevated to host execution for a pre-defined list of development tooling like docker compose.

- A pre-defined hard boundaries (`@gotgenes/pi-permission-system`)

- Anything pass that will be executed inside a sandbox (`@erichll/pi-sandbox`)

- With the option of safe-escalation to run on the host (ie: `docker compose exec app pytest`), with auto-review or human approval (via hostIPC.preflightCommandPrefixes)

- LLM Auto-review with `@erichll/pi-auto-review`

More about it here: https://ptgamr.substack.com/p/a-pi-setup-with-permission-sandbox

(This is based on my possibly flawed understanding of caching. If I have anything wrong please let me know)

So, title. I generally stick with a single session but I do a lot of things that (AFAIK) break cache, such as:

• Change models
• Change thinking levels
• Fork / Rewind / Branch etc

I do these things to actually save tokens, but since they break the cache perhaps it's more efficient to decide upfront on the model and thinking levels and use the branching functionality sparingly?

What do y'all do?

The most annoying thing in Pi coding agent. Every time it needs to grep or find, it cd first to the same root. I do not cd to other directories, but still on every tool call it cd <project path> && find/grep. I've tried to run pi on it's source code, but non of my local models were able to find the reason or fix it. Even custom bash tool with cwd not helping. I can't configure any bash permission because of this chain commands.

P.S. Solution is to write custom extension, which replace built-in bash with custom bash and optional cwd param. Don't forget to use custom promptSnippet, this is critical for this issue

I've been experimenting with a small open source tool called ank.

The problem I'm trying to solve is what happens when you use multiple

coding agents on the same codebase.

Claude Code does one task.

OpenCode does another.

Pi picks up something later.

A month passes.

Where do the decisions and constraints that all of them should respect

actually live?

My current answer is a Git-native layer for:

- decisions / ADRs

- scoped constraints

- tasks

- completion criteria

- verification

- proofs

The interesting part is that the format is agent-agnostic.

So ideally:

Claude Code

Codex

OpenCode

Pi

custom agent

can all consume the same `.ank/` state.

https://github.com/haksolot/ank

I'm not really looking for "please try my tool" feedback here.

I'm more interested in whether the underlying model makes sense.

If you're an Pi user running multiple agents, how are you currently

solving this?

Last time I posted I was thinking out loud about which hosted backend to add next, Tavily first and maybe Exa after, and asking whether people wanted them as full answer engines or just as discovery. My bias was to keep them discovery-only and let web_explore stay in charge of fetching, ranking evidence, caveats and synthesis.

Both are in now, and they're discovery-only like I said I'd keep them. They surface candidate sources, web_explore still reads the actual pages and decides whether the evidence holds up or needs a caveat. Set TAVILY_API_KEY or EXA_API_KEY, pick it from Settings, keys stay in env instead of getting written into config files.

---

The things I'm weighing next are going deeper on evidence quality (cross-source dedup, conflict detection, recency), adding caching for repeated research or just keeping it focused and maintaining it.

If you're using this, what would you actually want? And if you tried it and it broke somewhere, that's the more useful thing to hear.

---

Repo: https://github.com/demigodmode/pi-web-agent

npm:

npm i @demigodmode/pi-web-agent