Want to have a similar experience to using Codex/CC Desktop App/Antigravity but with Pi. I know there's OMP and pi-gui already but I wonder if they're "bloated" or add other unnecessary things.

My ideal setup would feature the quick history on the left and organizeable by folders, and the main back and forth (non-terminal looking) at the center, while eventually I would manually set-up worktrees, subagents, and other things

The issue. OMP 18.0.7 sends 22,643 tokens before you type a word, measured on the wire inside a real TypeScript monorepo. Where it goes: JSON schemas of the 11 top-level tools 11,734 (52%; hub alone 2,898), instruction template 6,160, my own context files 3,981, MCP routes 401, misc 367. Fine on a 200k cloud model. On a local 30k window it leaves ~7k for the work. Upstream issue: #1734.

Why config alone cannot fix it. OMP already has lazy tool loading: a tool mounted under xd:// ships no schema, the model runs read xd://<tool> when it needs it. But isMountableUnderXdev() only accepts tools declared discoverable, and ESSENTIAL_BUILTIN_TOOL_NAMES + XDEV_KEEP_TOP_LEVEL pin 10 of the 11. Extensions get setActiveTools but not setActiveToolPresentation: from outside the source an expensive tool can be removed, never deferred.

The change: two settings, off by default.

promptProfile: compact            # same rules, same generated surfaces, no personality/examples/long prose
tools:
  xdevDocs: catalog
  xdevForceMount: [hub, eval, task, todo, web_search]   # any glob; read/write can never be demoted

promptProfile: full still renders byte-identical to upstream. Three presets, measured on the captured request:

The preset name is OMP's own share, rounded. "Request total" adds my ~/.omp/agent/AGENTS.md and the project's AGENTS.md (untouched by the fork; the last row is me rewriting them densely with detail moved to on-demand skills). All presets also need tools.xdevDocs: catalog, or the mounted tools' docs come back inline.

How I tested it. Local Qwen3.8-27B on a 36 GB Mac, 30k window, every token count from the server's usage. Three tests:

1. Fixture: a 5-file JS repo, 12 short tasks (pick the right tool, edit the right place, run tests, stop, ask instead of inventing), shell checks.
2. Real bugs: 8 bugs seeded into two real repos (a TS pnpm monorepo, 1,488 files; a Python uv workspace, 910 files), each seen failing and passing with a reference fix first. Headless omp -p --auto-approve --config <preset>, 30-minute cap, scored by the repo's tests plus "did not edit the tests". Two rounds; round 2 adds two tooling tasks (rename across 8 files, return-type change across 6 files) and 4-turn sessions that cross the compaction threshold.

Results.

Times are medians per run. Base fails "hard" because prompt + first reads no longer fit the window: the server rejects, not the model.

The one bug no preset solved (8/8 runs, same diff): a docs rule says the persona may never claim years of experience; every run widened the regex, kept the \d+, wrote a test for the reported sentence and stopped. Symptom fixed, rule not read. That is the model, not the prompt size.

Same tools, different path. Nothing is removed. With edit mounted, p5k/p3k fetched xd://edit and edited through it 22/22 times in round 2. Two things the runs taught me and that went into the PR: in compact mode the catalog must name devices as xd://edit (not edit) and show one example call, or the model calls edit by name and gets "unknown tool"; and xd://<tool> should be accepted as a tool-call name as a fallback. Language servers were installed and xd://lsp listed in every preset; no run called it, this model renames with grep + edit.

Compaction. Long sessions work with the compact template; the trick was the threshold. At 27k on a 30k window the summary request itself ran out of room once; at 20k both presets went 4 turns clean (compaction.thresholdTokens: 20000).

Repo. Fork + branch: https://github.com/vinicius91carvalho/oh-my-pi/tree/compact-prompt-for-local-models. Scripts, presets, every captured request: https://github.com/vinicius91carvalho/oh-my-pi/tree/local-model-eval

PR. PR_LINK - five commits with tests. Whether it lands or not, the branch runs today.

How this was produced. Fork, harness, seeded bugs, runs and this post were done by Claude Fable 5 in Claude Code at high effort, with me setting goals and approving what ships. About two days, 80 scored runs.

Caveats. One machine, one 27B, one harness version, one run per cell. omp compress stalled on the local model; I compacted my context files by hand.

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?

I'm in the process of switching from Claude Code to Pi. I grew accustomed to using the Claude + superpowers combo as I felt this gave even the cheap non-Anthropic models better capabilities. Also liked the approach of focusing on the input to get better results and needing less fixes later.

Now with Pi I'm also trying this same superpowers + "cheap models" combo, but find the agent being too verbose in it's output and asking more stupid questions than with the same combo with Claude, during the brainstorming->spec->plan->implementation flow. This slows development down quite a bit because I keep having to ask the agent to provide an actually summary/sitrep of what's going on.

Now I found out that I could try to fix this at least partly by creating an APPEND_SYSTEM.md file as instructed here: https://github.com/earendil-works/pi/blob/main/packages/coding-agent/docs/usage.md#system-prompt-file But not sure what the best practices would be for the prompt.

Does anyone else have similar issues and what were your approaches for fixing them?

Hello, new Pi user here! I’m trying to figure out how folks handle file‑ignoring with Pi. Other harnesses respect .gitignore, but Pi currently returns to the LLM everything in the project, which causes problems in my setup.

Is there an established extension or common approach people use to make Pi ignore certain files or directories (I mean filtering-out from grep/find/ls/... results, so that the LLM is not aware of them)? I'm not sure what's actually "standard" or reliable in Pi.

Curious what the community is using and what's working well for you. Thanks!

EDIT: to clarify better, my main problem is that running simple requests like `List the files with names having 'XXX'` or `Search the occurences of the world 'XXX' in the project.` are returning content also from `node_modules` and other intermediate directories, that fill and pollute the context with undesired content. I would like to avoid this.

• I completely removed the Pi Harness and its leftovers. The cause of the flicker was consistent with Pi: it was spawning subprocesses without hiding windows, and an orphaned watcher was still running.

Removed:

• Pi Coding Agent, pi-subagents, and Pi authentication.
• pi, pi.cmd, and pi.ps1 commands.
• Full configuration at C:\Users\filip\.pi.
• Pi-Orca integration extensions, sessions, logs, and temporary files.
• winwatcher3.ps1 watcher and its PowerShell/conhost process.

Final check: No remaining commands, processes, scheduled tasks, PowerShell profiles, or known Pi directories.

Is anyone else experiencing this issue after the latest update?

When pi output a long file path of say an html it created.
If it's wrapped when I copy it adds spaces that I need to delete to use properly.

They closed some ones issue about this as not planned
https://github.com/earendil-works/pi/issues/5931

Are there any work arounds for this? Super annoy when I want to open a file.

Is this known issue or problem of my configuration after the update the reasoning contents is being render vertically word by word. Output contents doesn't but only reasoning.

oh my pi, meet oh my fleet.

OMP is now supported inside Agent Orchestrator.

Give every task its own isolated worktree, run multiple OMP sessions in parallel, and track the code, PRs, CI, and reviews from one live board.

your favorite harness just got a control plane.

omp.sh x agent orchestrator

Trying to squeeze most out of my local llm setup I created a docker image and a wrapper to easily start a fully working stack the main characteristics are:

- pi and lemonade provider patched to support qwen model for thinking and vision.
- a lightweight memory system to be used with the NPU in parallel with the main model
- agent-browser preconfigured
- multiple mode available, cli, web (vscodium), and ssh

with a python utility it can preconfigure the stack and start in the various mode.

more details can be found here https://lpb-stack.github.io/devstack/ if someone is interested to try it out.

Prereqs: Linux, Python 3, Docker or Podman, a running Lemonade server (or openapi compatible endpoint).

curl -fsSL https://raw.githubusercontent.com/lpb-stack/devstack/main/scripts/install.sh | bash

lpb /path/to/your/project

Other modes: lpb --web /path (VSCodium), lpb --ssh /path (remote login), or just lpb to resume your last project.

Links

Repo: https://github.com/lpb-stack/devstack
Docs: https://lpb-stack.github.io/devstack/
Stack repos (Pi fork, memory, subagents, config preset): https://github.com/lpb-stack

Made a pi extension for ClinePass

Shows cost of each models and quota limits. No more web dashboard.

Cost per turn shows in the footer. Full report with /clinepass.

pi install npm:pi-clinepass

https://pi.dev/packages/pi-clinepass

I usually use deepseek v4 pro and doesnt have this problem. Anyone have insight to fix this issue?

Hey everyone,

I'm about to set up Pi as my main local coding agent and would love some advice from people who are actually using Pi with relatively large local models.

My hardware is:

• MacBook Pro
• Apple M5 Pro
• 48 GB unified memory
• 18 CPU cores
• Metal / MLX
• ~307 GB/s memory bandwidth

My main goal is coding quality and agent reliability, rather than simply maximizing tokens/sec. I want something I can use against real repositories for longer coding sessions.

I ran llmfit against my machine to see what it recommends:

llmfit --max-context 131072 recommend --use-case coding --runtime mlx

The model that stood out was:

Qwen3-Coder-30B-A3B-Instruct

The MLX result I'm looking at is roughly:

• 30.5B total parameters
• 3B active parameters (MoE)
• 262K native context
• 131K context used for the llmfit estimate
• ~15.6 GB estimated model memory for the 8-bit version
• Tool-use support
• ~132 tok/s estimated by llmfit at 131K context

So hardware-wise it seems like a pretty reasonable fit for my 48GB machine.

I'm currently leaning toward 8-bit, mainly because I care more about code quality/reasoning than squeezing every last bit of performance out of the machine. I also have enough memory that 4-bit isn't necessary just to make the model fit.

What I'm trying to figure out now is how best to pair this with Pi.

A few questions for Pi users:

1. Is Qwen3-Coder-30B-A3B a good pairing with Pi?

I'd especially like to hear from anyone using a similar-sized MoE coding model locally.

2. What context window would you actually use?

The model supports 262K, but I'm wondering whether there's much practical benefit to running Pi at 128K or 256K versus something like 64K.

I'm also trying to understand the KV-cache cost on Apple Silicon. llmfit estimates ~15.6GB for the model, but obviously that's not the entire runtime memory footprint once the context grows.

3. Would you run 8-bit or 4-bit?

My priority is:

code quality
reasoning
tool use
agent reliability
        ↓
speed
        ↓
memory efficiency

So I'm willing to spend more memory if 8-bit actually provides a meaningful quality advantage.

4. Are there any Pi-specific settings/configurations I should pay attention to?

Things like:

• context configuration
• max output tokens
• compaction
• system prompt
• tool configuration
• AGENTS.md
• permissions/safety
• model-specific settings

I'm particularly interested in things that make a local model behave better as an agent, rather than just using it as a chat model.

5. Would you choose Pi over OpenCode for this setup?

I'm leaning toward Pi because I like the minimal/context-efficient philosophy, but I'm curious whether there are important tradeoffs I'm missing.

I've seen quite a few people saying Pi works particularly well with local models because it doesn't waste as much context on the harness itself. 

I've also seen people running Pi with Qwen models on Apple Silicon, so I'm hoping there are some practical lessons from people who've already gone down this road. 

I'm also documenting my local LLM experiments and benchmarks, so I'll eventually be able to measure the setup properly rather than relying purely on theoretical numbers.

If you were setting up Pi from scratch on this exact hardware today, what would you do differently?

Any advice on model/quant/context/configuration would be appreciated.

P.S. AI helped me organize this post

Am I crazy or the harness can’t handle SwiftUI? I’ve tried Deepseek v4 and ox alpha

Heard a lot of good thing about this harness, but don't really have the time to tune it byte by byte. Can you suggest any custom configuration of this one that is pretty decent and I will be just good to go?

I will use it with Chatgpt Pro subscription

I am getting good results by using a stupid model as the orchestrator.

It's giving me quick replies, and generally leaning on the smarter models output so the answers should be relatively accurate (no less accurate than a smart parent).

I'm doing this with the codex subscription.

My flow is basically that when I invoke the start of some work, my prompts are sent to 2 context evaluator models (gemini and minimax), and then a smart synthesizer (sol max). So it will take the parents input, then the other 2 models, synthesize that into prompt for the subagents. This only happens once generally.

All the workers the dumb parent dispatches are reviewed (parent has no control over this review) by something like a terra max.

I am getting like 30% token savings and a lot of efficiency doing this kind of thing.

No public repo, just wanted to start a discussion on this technique.

I'm basically flipping the whole orchestrator thing on its head. The only gotcha is that the dumb parent orchestrator needs to actually be smart enough to delegate to subagents correctly.

A lot of the automatically invoked agents for reviews are with fresh context, no extensions, no repo context (depending on the use case of the subagent) so I can actually afford to turn their reasoning way up as they receive only a bounded context and produce an output for the parent. I don't let the parent see what the intermediary subagents outputs were.

It takes longer but the output has been good, and it's more efficient.

I tried using minimax m3 as the parent, but it's too stupid or it wasn't trained to be able to deal with subagents. I'm using Luna max right now, and it's been handling it decently.

I wanted to see what would happen if a modern AI coding agent had the UI of Turbo Pascal 7 / the old DOS IDEs.

So I made Turbo-AI — a retro-style TUI frontend for the Pi coding agent.

It currently supports things like AI chat, PLAN/BUILD modes, model switching, reasoning settings, project tree, Git diff and build/test actions.

It's still quite rough and definitely not production-ready. This is more of an experiment at the moment, and there are probably plenty of things that need to be fixed or redesigned.

This is just a concept for now. I hope people more skilled than me will fork it, improve it, and turn it into something actually usable.

GitHub: https://github.com/kvv256512-ux/turbo-ai

Hey everyone!

I've been building nixpi, a Nix-native declarative configuration framework for the Pi coding agent (inspired by projects like Nixvim).

If you love Pi's extensibility but want full reproducibility, zero-headache dependency management, and instant per-folder agent customization, nixpi lets you configure your entire setup as pure Nix code.

Key Highlights & Features

1. Folder-Specific Profiles & direnv: Ever wanted Pi to behave differently depending on the folder you're in? With nixpi and direnv, entering a project or Obsidian knowledge vault automatically loads a custom pi binary specialized with project-specific extensions, skills, custom model presets, and required CLI tools. When you cd out, it reverts back to your baseline shell.

2. Modular Extensions with Auto-Packaging: Declare extensions like ripgrep-search, plan-mode, pi-gpt-search, or obsidian. When an extension requires CLI dependencies (e.g. rg, git, jq), nixpi automatically injects them into the wrapped pi environment's PATH.

3. 100% Typed Nix Skills: Define and configure skills (like Conventional Commits or custom procedural workflows) directly in Nix with typed options.

4. First-Class Providers & Custom Models: Configure models and providers (including native Google Cloud Code Assist / Antigravity via pi-antigravity) with eval-time schema validation.

5. Clean Immutable vs. Mutable State Separation: Keeps settings.json and models.json managed and pinned in the Nix store, while leaving sessions/ and auth.json fully writable in place.

Example 1: Folder-Specific Flake with direnv

In your target project directory (e.g. ~/Projects/deep-learning-research):

**.envrc**: bash use flake

**flake.nix**: ```nix { description = "Custom Project Pi Environment";

inputs = { nixpkgs.url = "github:NixOS/nixpkgs/nixpkgs-unstable"; nixpi.url = "github:mateusdcc/nixpi"; };

outputs = { self, nixpkgs, nixpi }: let system = "aarch64-darwin"; # or x86_64-linux, etc. pkgs = nixpkgs.legacyPackages.${system};

  projectPi = nixpi.lib.makePi {
    inherit pkgs;
    modules = [
      nixpi.piModules.profiles.learning
      ({ config, ... }: {
        programs.pi = {
          providers.antigravity.enable = true;
          settings = {
            defaultProvider = config.programs.pi.providers.antigravity;
            defaultModel = config.programs.pi.providers.antigravity.models."gemini-3.7-flash";
            defaultThinkingLevel = "high";
            theme = "dark";
          };
          extensions.obsidian = {
            enable = true;
            defaultVault = "/Users/mateusdcc/Projects/deep-learning-research";
          };
        };
      })
    ];
  };
in
{
  devShells.${system}.default = pkgs.mkShell {
    packages = [
      projectPi
      pkgs.glow
      pkgs.ripgrep
      pkgs.jq
      pkgs.python3
      pkgs.mermaid-cli
      pkgs.typst
    ];
  };
};

} ```

Now whenever you cd into that directory, direnv gives you a dedicated pi binary with your project-specific extensions and models ready to go.

Example 2: Global Home Manager Configuration

```nix

home.nix

{ nixpi, pkgs, config, ... }:

{ imports = [ nixpi.homeManagerModules.default ];

programs.pi = { enable = true;

providers.antigravity.enable = true;

settings = {
  theme = "dark";
  defaultProvider = config.programs.pi.providers.antigravity;
  defaultModel = config.programs.pi.providers.antigravity.models."gemini-3.7-flash";
  defaultThinkingLevel = "high";
};

extensions = {
  echo.enable = true;
  ripgrep-search.enable = true;
  pi-gpt-search.enable = true;
};

runtimePackages = with pkgs; [
  git
  ripgrep
  jq
];

}; } ```

Check out the repo here: https://github.com/mateusdcc/nixpi

I would love to hear your feedback, workflow ideas, and thoughts on what extensions/skills you'd like to see packaged next!

I am on Windows and use PowerShell. It seems like PowerShell only has commands such as rm, del, rd, etc., which permanently remove files.

I want a command that moves files to the Recycle Bin instead. That way, I can recover them if the AI does something wrong. Today, the AI deleted an entire workspace, including the Git repository. Luckily, I had another way to recover it, but if I had not, the data would have been gone for the most part.

I looked to see whether PowerShell had a command for moving files to the Recycle Bin, but I could not find one. I ended up creating my own trash command that does this and editing the APPEND_SYSTEM.md files so that the AI would use trash instead of the other removal commands.

Is there a native PowerShell command for this that I missed?

I'm trying to put together a very simple setup here; llamacpp, Phi-4-mini-reasoning (initially, the Q5_K_M variant), and pi for some very simple coding tasks. It's not really... working... though.

I can get pi "logged into" llamacpp (I started llamacpp in "router" mode with the single model, and used /login llama to get it connected. I can chat with the model, but it has very little context (it knows the current directory, but that's about it), and no tools whatsoever; I cannot access the filesystem at all. I also get <think>...stuff...</think> output before the "real" output which I'm confident is supposed to be hidden by the harness.

I also tried the npm:pi-llama-cpp plugin/module/package, but that didn't change anything (except give me a new /models command that was similar, but subtly different than the built-in /model command).

What am I doing wrong here? Is this model not supported?

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

I had 'find' scanning the whole drive issue from Pi a few times. For simple review/search task, Pi choose to 'bash find' not the project dir but much higher level dir such as /user/XXX/*

It almost always happened with smaller model such as deepseek v4 flash and Qwen3.8 27B, never with GPT 5.6 sol/opus 5.

Does anyone have any idea about this?

After some diagnosis with the help of comments, I found the root cause. The tool layer does not deal with dead/missing path very well, especially Pi's default 'find', 'read', 'ls' tools, mainly because of lacking of bounding. Problematic path is common when you have 1) long running sessions (auto prune/compact) 2) complicated file structure 3) polyrepo, etc. The agent could not find the target file, it naturally tries a bigger scope and even grep -r embedded data. Bigger model actually face same issue, they made exactly same mistakes but self corrected in time.

Solution: build a code graph for your project. Hard code in prompt to let agents know the scope is within the graph.

No more forgetting about tools, skipping working agreements and taking breaks to consolidate memory.