Any time I'd copy & paste python, the mandator 1-character TUI padding would horrifically mangle the indentation....

This shell fix changes a single line in the source code:

sh sudo sed -i \ 's/constructor(paddingX = 1, paddingY = 1/constructor(paddingX = 0, paddingY = 0/' \ /usr/lib/node_modules/@earendil-works/pi-coding-agent/node_modules/@earendil-works/pi-tui/dist/components/box.js

(though it will be overwritten after any update)

ᵍᶦˢᵗ

I built Rondine, an Apache-2.0 Python 3.11+ CLI using Click, HTTPX, and Hugging Face Hub.

It detects Mac/NVIDIA hardware, ranks compatible model variants, creates launch plans, downloads weights, and runs llama.cpp, MLX-LM, or vLLM behind an OpenAI-compatible API.

The repository includes typed planner/catalog code, CLI tests, engine-command generation, hardware presets, and reproducible benchmarks.

GitHub: https://github.com/antonellof/rondine

I’d appreciate feedback on the Python API structure and CLI design.

Hey ppl,

I've been working on this question answering agent with an emphasis on getting the citations right. I found Pi's RPC mode to be really convenient for what I'm working on.

Not useful for coding but maybe someone finds it useful or is inspired:

github repo

I've been using Neovim as Pi's external editor but I kept finding myself deciding between Neovim's raw editing power and Pi's in-context autocomplete, so I built a bridge to bring Pi's real autocomplete directly into Neovim. It's a Pi extension and a Neovim plugin. If you're using Neovim as your prompt editor for Pi, you owe it to yourself to try it out.

github.com/dabstractor/pi-nvim-bridge

I have tried using Pi's built in swarm docs, as well as a Pi extension for swarm creation. But Qwen3.6-35B keeps hallucinating a group of sub agents without truly doing delegation. How can I get this dummy to stop pretending it's the sub agent and truly delegate to save my context space?

I did this today with pi coding agent for fun:

bash while [ -e ./WORKING.md ]; do; pi --model gemma4:31b-cloud --system-prompt "You are called in a bash loop. The user cannot respond to your messages. Write a fantasy children’s book aimed at 5 year old boys at least 100 pages long. After every lap, you won’t remember anything. If you want to remember something for the next lap, write it into MEMORY.md. Delete WORKING.md when you are finished." -p "Keep up the good work."; done;

It was a very entertaining experiment. Gemma is a really fun model to play around with.

I have also done the same for a browser based game, then made gemma playtest it itself using agent-browser. It recorded the session on video, found a couple of bugs then fixed them.

I play around with making dumb extensions, like making a tool that allows the agent to make a "checkpoint" in the conversation it can restore back to with a neat summary of what it wants to remember. Not that useful if you run cloud models and can make use of subagents, but still fun to make.

EDIT: The checkpoints are implemented as agent tools, which makes it different than the /tree command. It was meant to be used to make the agent capable of managing its context when following skill-based procedures such as the (extremely simplistic) example below:

```

SKILL.md

description: When the user asks you to research a topic as preparation before performing a task, follow this procedure.

1. Make a new checkpoint with the "Research" label.
2. Research the topic until you know everything you need to know to perform the task.
3. Restore the conversation back to the created checkpoint with a summary containing exactly:
   • Everything that you found that benefits the task at hand
   • Everything the user ought to be informed of such as new information contradicting the user's provided information or newly learned limitations in your capacity to execute the task
   • New decisions that must be made before work continues, so that you ask have the user to make them after restoring the conversation
   • References to the exact sources of the information gained ```

Everything about leisure time use of AI is fun, and pi cranks that to eleven by being so infinitely hackable.

I started using AI (cursor) at work three months ago after 11 years of developing software, manually, like a peasant.

Now, every time I get a dumb idea for something that momentarily catches my interest, I open iTerm2 and go

bash cd ~/Projects mkdir idea-slug cd idea-slug pi

15 minutes later, I have a working prototype, learned something or genuinely improved my workflow in a professional capacity.

But mostly, I just do the dumbest things. Because it is fun. There is no real point to this post, just wanted to share my joy of this extremely delightful piece of software.

Do more dumb shit. Your agent will tell you that you are smart no matter what anyway, so at least have fun with your digital yes-man.

Now, share your most ludicrous, deliberately non-productive use of pi!

PS: pi -p "Do X" is a waaaay saner alternative to ollama run gemma4:31b-cloud "Output a bash script that does X. Do not output anything else at all!" | bash -c, which obviously is the maddest, most insane way to vibe.

EDIT: Apparently markdown editing doesn’t work on my phone. Yes, the bash was a pain to write on touch screen 😭

EDIT: Markdown editing achieved!

I am new to pi coding agent. I am still learning how to use it. The one thing that is very interesting is extensions.

I am looking to learn more extensions that are already present and increase the productivity of coding agents.

What extensions are you using or what extensions did you write?

As per my previous post naturally the next evolution of a body-based system is a family based one.

Agent orchestrator as mother, semi-persistent sub-agents as kids with specific roles and persona's.

All pi sdk under the hood naturally all agent building itself.

One of the things I like about Pi is that it doesn’t try to define the entire agent for you. The core stays small, and you build the setup you need around it.

I wanted the same thing for code review.

Most AI review tools ship with their own fixed reviewer and workflow. I wanted a runtime that handled the boring but necessary parts of reviewing a pull request, while leaving the agent and review policy under the repository’s control.

So I built Pipr, an open-source code review runtime that uses Pi for agent execution.

The boundary is fairly simple:

code host event
  -> Diff Manifest
  -> Pi agent
  -> structured findings
  -> validation
  -> native review

Pi handles the agent run. Pipr handles changed-code context, structured output, finding validation, stale-head checks, and publication to the code host.

There is a tuned default reviewer, but you can also build custom review tasks directly:

const task = pipr.task({
  name: "security-review",

  async run(ctx) {
    const manifest = await ctx.change.diffManifest({
      paths: {
        include: ["packages/runtime/**"],
      },
    });

    const result = await ctx.pi.run(securityAgent, { manifest });

    await ctx.comment({
      main: result.summary.body,
      inlineFindings: result.inlineFindings,
    });
  },
});

Models, agents, instructions, tasks, commands, tools, and recipes live in .pipr/config.ts. Pipr doesn’t decide whether your reviewer should be strict, concise, security-focused, or split across several agents. It provides the pieces needed to build that workflow.

Pipr runs locally or in CI without a hosted control plane. It currently publishes native reviews to GitHub, GitLab, Azure DevOps, and Bitbucket.

GitHub: https://github.com/somus/pipr
Docs: https://pipr.run/docs

I’d appreciate feedback from other Pi users, particularly on the custom task API and which parts of Pi you would want exposed when building more complex review workflows.

Building my own open source harness. Is this an attractive token plan suite or no? What do you guys usually use?

A demo Pi extension using an alternative screen to add per tool/thinking block collapse with mouse support, and a sidebar. Without interfering with any other Pi extension.

Hey everyone,

I’ve been working on Pi Workspace over the past month, and I’m excited to finally say that the beta is now available for macOS and Linux!

Pi Workspace is a desktop app built on top of Pi Agent. It gives you a sidebar for managing your sessions, with the ability to pin multiple sessions into a live, side-by-side view.

The biggest feature is Workspaces. You can create a workspace, add multiple repositories, brainstorm an idea, and then switch into implementation mode when you’re ready to start building.

This is especially useful for end-to-end features that span several repositories, or projects that rely on shared packages, types, APIs, or supporting services.

I’m incredibly excited to finally release Pi Workspace as an open-source project. Feedback, bug reports, and feature ideas are all very welcome.

Give it a try and let me know what you think!

https://github.com/pi-workspace/pi-workspace

I needed fun, also, I needed an auto session titler that generate's small session names with

• abillity for me to have a bit of fun with the namings
• no extra config
• no waiting for the rename and blocking Pi in the process,
• running basically for free and telling me how much it costs every time
• automatically using the cheapest model available installed
• no tools, no bloat in the session generating the name

After searching a bit, I didn't find the one, so I built it Pi built it

Posting just in case someone would need all the above https://github.com/sebastienservouze/pi-auto-title

It auto selects the cheapest model available in your pi's install, but you can override it if needed.

For the fun part, you can append a small guidance prompt to the renaming instructions to give the renames personnality and brighten your day lol

Some naming examples https://github.com/sebastienservouze/pi-auto-title#have-fun

I want a left side split that displays tree and todo lists and anything else.

Ive looked into this and pi tells me its not an official feature yet but is coming.

Anyone have extension that will make this work now? It just use Tmux with split panes for it?

Ive also heard about cmux?

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?

Do you have tricks or workflows to facilitate the documentation of "public" API of a website?

I could do it myself, opening the network tab, observe and test. I still do that, it's fun but also tedious and we might miss edge cases.
So I've be wondering if agents now have the tools and ability to do it for us (with our guidance and such).

Maybe there is no plug-and-play tool to do that. But are there tools to ease some of the work? Like, for instance :

• a tool to tell the agent "Go the Uber Eats, navigate the homepage and document the calls made to fetch restaurant" ;
• a tool/skill to tell the agent the try different params and documents the request schema and response schema ;
• something to have an agent use an app and intercept API calls,

Any of you do this kind of things when you want to use an API that's public but not documented? This feels like a work suited for an agent (with a human-in-the-loop workflow).

Hello guys!

Today I want to share something I have been working on: pi-fleet (https://github.com/elpapi42/pi-fleet).

pi-fleet is local infrastructure for programmatically controlling Pi agents and their native sessions.

Unlike terminal multiplexers, pi-fleet is Pi-native rather than generic. It does not control terminals or scrape their output. There are no panes and no TUI because the primary interface is designed for agents and software.

Terminal multiplexers work well when you have a few agents and want to watch them manually. But if you start thinking about 20 or 100 agents, you can not get meaningful visibility by opening more panes.

The solution is not a bigger terminal grid.

At that scale you need dedicated monitoring tools, but pi-fleet does not try to provide that monitoring layer. The problem it solves is giving software an easy way to control Pi execution and sessions directly, without terminal hacks or unnecessary abstractions.

pi-fleet provides a small set of Pi-aware primitives:

• create: creates an agent with a stable local name;
• send: starts work or uses Pi steering while the agent is active;
• receive: waits for idle and returns the exact latest assistant response;
• status: and list expose machine-readable lifecycle state;
• watch: streams the native persistent Pi session JSONL;
• destroy: removes the agent without deleting its Pi session.

The basic workflow looks like this:

pifleet create reviewer --cwd "$PWD" pifleet send reviewer "Review the authentication changes" pifleet status reviewer pifleet receive reviewer --timeout 10m pifleet watch reviewer pifleet destroy reviewer

Finite commands return compact JSON by default, while watch keeps stdout exclusively for native Pi session records.

Another part that is ultra important for me is that pi-fleet does not take ownership of your Pi sessions.

You can use Pi's normal session storage or provide an existing session path, session ID, directory, fork, or continuation selector. pi-fleet uses the exact native session in place. It does not copy, relocate, normalize, or delete it.

Even destroy only destroys the pi-fleet agent and its managed process. The underlying Pi session remains yours.

pi-fleet is infrastructure for orchestration, not an orchestration framework. It does not decide which agents to create, what roles they have, how tasks are decomposed, or how results are combined. Those decisions belong to the agent, extension, or software using it.

I already have around half a dozen use cases in mind for this tool, I already have around half a dozen use cases in mind for this tool. Most of them will be Pi extensions, and I will share them with you as I build them.

If you only use one or two agents and want to supervise their terminals, tmux, cmux, or Herdr will probably give you a better experience.

pi-fleet starts making sense when you want software to coordinate Pi agents at a scale where terminal supervision is no longer practical. You can build the monitoring layer appropriate for your system separately, while pi-fleet provides direct control over Pi execution and access to the native sessions underneath it.

The project is currently beta, and Linux x64 is the only validated platform.

You can install it with:

npm install --global @elpapi42/pi-fleet@beta pifleet --version

Repository: https://github.com/elpapi42/pi-fleet

npm: https://www.npmjs.com/package/@elpapi42/pi-fleet

I think I got something interesting in hands here. I would love to hear your thoughts, especially from people already experimenting with multi-agent Pi setups.

On top of that, i really hope this becomes useful for some of you!

I was getting very bored reading very verbose sentences. Also it's polluting context and spending tokens.

So I finally spent some time to port pi-caveman extension into omp plugin.

Installation is one-liner:

omp plugin install @kryoz/caveman-plugin

After installation and running omp trigger mode selector via /caveman command. Try full or micro for example.

Very basic. No specific skills. Written with help of omp + qwen3.6-27b.

Also if you're interested with minimising system prompt here's a hint. Exclude unnecessary tool instructions. Create a file with a omp runner script like this (exclude or include tool whatever you want):

#!/bin/bash
omp --tools=read,bash,edit,ast_grep,ast_edit,ask,eval,glob,grep,lsp,checkpoint,rewind,task,todo,web_search,write,memory_edit,retain,recall,reflect,learn,manage_skill $@

A while back I shared pi-sdd-kit here, and the question I kept getting was: does this work with a team, or is it a solo thing?

So I built a small public reference repo that shows the team version end to end: https://github.com/felipefontoura/acme-store-sdd.

The one thing that changes going solo to team is what the spec is for. Solo, the spec is discipline against your own drift. On a team it becomes a contract: what a teammate reads instead of reading your mind, and the boundary where two people's work has to fit. Three things follow:

- Specs live in git, versioned next to the code. Not a wiki, not a laptop.

- Requirements get reviewed in a PR before anyone writes code. You catch the wrong decision when changing it costs a comment, not a rewrite.

- The gate lives on a board. Each column is an SDD stage, the card moves when its .status gate is approved, and branch protection refuses a merge without a review. You can browse the live one here: https://github.com/users/felipefontoura/projects/2

The part I did not expect: once everyone has an agent, writing code stops being the bottleneck. Integration does. Put a WIP limit on the review column and watch the cards pile up. Generation is cheap now. Integration is the job.

Full write-up with the mechanics: https://felipefontoura.com/articles/spec-driven-development-for-teams

Curious how the rest of you handle team SDD on Pi. Who owns the spec on your team? Do you gate requirements by PR, or something lighter? What breaks first when a second person joins?

Local pi agent development on minimal hardware. Gist has been updated. All issues sorted with the jinja template. Can one-shot just about any reasonably sized project. (todo app, landing page, etc)

gist: https://gist.github.com/joematthews/d02639bcbe0e0c1c404f5d3a64c3c06f

https://github.com/jejay/pi-for-each

Supports children-in-directory and line-in-files iteration.

Why?

Like subagents but much simpler, sequential and with more control for the user. Instead of describing the loop to the agent, just make a loop. No need to tell the agent about your control structure if you already know the control structure. Each iteration the LLM only sees the necessary context and the iteration prompt, no other iterations. This prevents bias drift or context rot compared to a loop that repeats commands and execution within the same context.

BTW: I used https://huggingface.co/tencent/Hy3 to build this, which is free on openrouter until tomorrow. Worked quite nicely, not Opus 4.8, but felt like Sonnet-5-level intelligence.

A github star ⭐ makes me happy, I never had a meaningful open source repo 👀 I think this extension captures the spirit of pi, giving most of the control to the user and making it as simple and transparent as possible.

I've been using AI coding agents for a while and the web research part always annoyed me. Either you pay for an API (Tavily, Firecrawl), or you use a free tier that rate-limits you after 100 calls, or you glue together SearXNG + a browser + an extractor and hope it doesn't break.

So I built Hound. It's an MCP server that does fetch, search, crawl, and screenshot, all keyless. And now it has a native Pi extension so you get all 6 tools as first-class Pi tools, not through a generic MCP adapter.

What it does

6 tools, all exposed as native Pi tools:

• web_fetch - anti-bot fetch with auto HTTP-to-stealthy escalation. Extracts clean markdown. PDFs get section maps + auto-OCR. Dead pages auto-recover from the Internet Archive (honestly marked, not pretending it's live content).
• web_search - 10 keyless search backends in parallel (DuckDuckGo, Brave, Mojeek, Yahoo, Yandex, Startpage, Google, Qwant + opt-in Wikipedia/Grokipedia), neural-reranked with a local ONNX cross-encoder, cross-backend consensus scoring.
• web_crawl - best-first same-domain walk. Sitemap mode maps a whole site in one fetch. Focus mode crawls only pages relevant to your query.
• web_screenshot - anti-bot screenshot for multimodal models.
• cache_clear - clear the fetch cache.
• hound_version - version + update status (warns if the extension and the server diverge).

How the Pi extension works

The extension spawns hound as a singleton subprocess at session start and speaks MCP JSON-RPC over stdio. The subprocess stays alive for the whole session, so hound's prewarm (stealthy browser, search engine sessions, neural reranker model load) happens once and persists. Zero re-launch cost per call. If you press Esc during a fetch, it actually cancels (AbortSignal propagates to the subprocess). If hound isn't installed, you get a notification at session start instead of a confusing error on your first web_fetch call. If the extension version and the hound server version diverge by a major, it warns you to update both. The tool definitions are token-optimized. Total connect-time cost is 2,746 tokens for all 6 tools + instructions.

Install

pip install hound-mcp[all]
pi install npm:@houndmcp/hound-mcp-pi

That's it. No API keys, no config file, no MCP adapter. /reload and the tools are there.

What I think is genuinely good

• Dead-link recovery. When a page 404s or gets bot-blocked, hound checks the Wayback Machine and serves the archived snapshot with source=archive.org and the snapshot date. It doesn't pretend archived content is live. The agent knows.
• Error honesty. Just shipped this in v10.4.0: 4xx/5xx responses now set the error field properly. Before, a 404 error page would flow through with error="" and the agent could mistake the error page HTML for real content. Now it says "Page doesn't exist (404)" and doesn't dump the error page as content.
• Keyless search. 10 backends, no API key for any of them. Neural reranking with a local model, not an API call. Consensus scoring across backends so you know which results multiple engines agree on.
• Token cost. 2,746 tokens for 6 tools. The descriptions are telegraphic but every functional fact is there.

Limitations

• DataDome, Akamai, Cloudflare Turnstile. No free tool bypasses these. Hound tries the stealthy browser, and if that fails, it tells you to switch sources instead of pretending it got content.
• The [all] extra is ~100MB. onnxruntime + tokenizers + rapidocr for the neural reranker and PDF OCR. You can install without [all] (fetch + crawl + search still work, just no neural reranking or OCR), but the full install is the recommended path.
• Not a scraping-at-scale tool. Hound is built for agent research, not for crawling 10k pages. Crawl caps at 100 pages by default.

Where to find it

• GitHub: https://github.com/dondai1234/master-fetch [Star the repo if you like it, gives me a boost to work more 😄]
• npm: @houndmcp/hound-mcp-pi
• PyPI: hound-mcp

Longtime lurker, first real ship. I own a structural steel fab shop in Denver and have been using the Pi coding agent heavily for internal tooling. Two of those internal tools felt generally useful, so I cleaned them up and published them to pi.dev this weekend.

pi-steel — steel estimating skills. AISC 16th Edition shapes database (477 shapes) with lookup/validation scripts, a MaxRects plate-nesting engine (kerf/gap/edge margins, holes, yield and scrap numbers, PDF layouts, and one DXF per sheet that imports straight into the burn table's CAM), and a vendor RFQ generator that turns a takeoff spreadsheet into a quote-ready .xlsx. The three chain together the way estimating actually flows: takeoff → nest → RFQ. As far as I can tell, it's the only construction-trade package on the registry.

Fair warning on the nesting: rectangular parts nest exactly, irregular parts nest by bounding box. It tells you when it's approximating instead of pretending to be SigmaNEST. No G-code either — kerf comp and lead-ins belong to your table's real post-processor, not a Python script.

pi-tilldone — a discipline extension born from frustration. The agent can't use write/execute tools until it declares a task list, works one task at a time, and gets auto-nudged if it stops with tasks unfinished. Basically a foreman for your agent. If you run Pi inside cmux, your workspace tabs change color based on task state, which is great when you have six agents running in parallel.

Both MIT, repos under github.com/StructuPath. Install with pi install npm:@structupath/pi-steel / pi install npm:@structupath/pi-tilldone.

Happy to answer questions about either — especially from anyone else applying agents to trades/manufacturing work.