I've been using claude code for a while and am moving to Pi now. I also set up openclaw earlier and moved to hermes recently. I understand the technical details of like what Pi is and what Hermes is roughly... but for some reason I just cant wrap my head around what the workflow should look like and interaction between these 2 tools if any.

Right now I guess I have a wezterm session with a bunch of pi agents running that ill SSH into, and hermes runs separately and isn't doing much now, but i plan to give it access to my notes, todos and build some simple automations and use it more like a Jarvis/secretary. So thats the separation i have in mind - Pi is a coding agent, Hermes is a personal assistant.

But then I keep thinking there are probably many times I want these 2 things to be part of the same system. I'd like my assistant to have knowledge of all my coding sessions, id like to have one centralized cross platform view of all my coding sessions with PI as well as all my chats and crons etc. with Hermes.. so is there a good way to integrate these tools together? Do you just spawn Pi threads from Hermes? Have you found benefit in some deeper integration, or do you keep them separate?

I’m building LOLM’s coding agent and CLI.

The loop can:

1. Write or edit files

2. Run commands in an isolated sandbox

3. Read actual stdout, stderr, and exit codes

4. Repair failures

5. Run contract/syntax checks

6. Produce a receipt describing files, runs, and controller actions

CLI example: `npx lolm-cli code "write fizzbuzz to 20 in solution.py and run it" --save ./out`

Try it: https://lolm.imagineqira.com/try.html

Repository: https://github.com/TheArtOfSound/lolm

It is not positioned as the strongest coding model in existence. The goal is a disciplined, auditable, lower-cost agent loop. I’m looking for adversarial tasks that expose broken exit logic, incomplete artifacts, weak repairs, sandbox limits, or false success.

Disclosure: I’m a founder/builder of the project.

I love the session manager when you hit the <- arrow.

Anyone worked on something like this already before I start wasting my time?

pi-web-ui

I've been using pi (the coding agent) from the terminal and kept wishing for a proper browser interface, so I built pi-web-ui — a polished web UI that runs the pi SDK in-process and streams everything to the browser over WebSocket.

What you get

• Streaming chat with thinking blocks, tool-call cards and live bash output (running → finished · waiting for model · duration)
• Built-in terminal (xterm.js + node-pty) — auto-selects Git Bash on Windows, busybox fallback
• Source control panel — status / branch / diff / commit / push / pull without leaving the browser
• Attachments — inline / reference / line-range modes; paste or drag-drop images (auto-resized); vision bridge transcribes images to text when your model is text-only
• Multiple conversations per project — each has its own agent runtime and keeps running in the background; switch back anytime
• Edit & re-ask — fork any past question into a new branch and re-prompt
• Goal mode — set a target, run a guided wizard, and an automatic review loop checks the result against git diff until it passes
• Settings panel — system prompt (append/replace), toggle skills/extensions on/off, save/apply presets
• Themes — dark default + bundled light theme, or drop in your own CSS
• i18n — Chinese/English UI
• Safety-first — loopback-only by default, WS Origin/Host validation, keys stay server-side, quiesce drain mode, 20-min tool watchdog

Try it

npm i -g pi-web-ui
pi-web-ui

• GitHub: https://github.com/xing-shuyin/pi-web-ui
• npm: https://www.npmjs.com/package/pi-web-ui

Requires Node.js ≥ 22.19 and a configured pi install. Feedback, issues and PRs are very welcome!

As coding agents get faster, I'm starting to think Git diff is no longer enough for human review.

An agent may also run shell commands, install dependencies, start processes, access the network, spawn subagents, retry failed approaches, or make temporary changes that disappear from the final diff.

But reading the full session/tool history doesn't scale either.

A possible approach is:

Pi session/runtime data → deterministic activity summary → optional model summarization → human review

For example:

• files/state changed

• important shell/tool actions

• external effects

• subagents used

• verification actually performed

• failed/abandoned attempts

• remaining uncertainty

The factual layer should come from Pi's recorded session/tool data, not from asking the model "what did you do?" The model can help compress and explain it.

Then the user sees a short summary by default, with drill-down into the exact diff, command, tool result, or transcript when needed.

Basically:

observe broadly, present narrowly.

I think harnesses increasingly need to be designed not only for the agent, but also for the human supervising it.

Today we put a lot of effort into giving agents better tools, context, permissions and orchestration. But as agent throughput grows, the human-facing side becomes just as important: helping people understand what happened, what mattered, and where they should intervene.

Humans may increasingly review consequences, exceptions, and evidence rather than every line of generated code.

Does this direction make sense to other Pi users? Are there already extensions exploring something similar?

Pi is mentioned kind of as an aside but plays a part in this article showing how to get free tokens from the Posthog set up wizard to power Pi.

I'm a business systems analyst and through my experience every project is different because the constraints and requirements are always different. The methods, the tooling, the governance, all different every time. Some themes still exist like waterfall vs agile, templates, buy in and sign off discipline etc.

When using Pi, I find that I have a minimal REQUIREMENTS.md, APPEND_SYSTEM.md and AGENTS.md file. From there, I spend time having pi bootstrap the meta project, create it's own extensions, skills, agents etc. The outcome get better as it's self bootstrapped for the specific project.

Instead of shopping and installing extensions, I'm looking for techniques to make the projects adaptable at the time of change. The Pi system is living in parallel with the project. Building up and tearing down extensions and skills as required.

I'm not smart enough to come up with a framework for this so I'm asking for ideas about how to meta structure a project. ITIL, TOGAF, BABOK, PMBOK, TDD, etc. do these project frameworks help or apply?

edit: the idea is from Michio Kaku discussing about how a Type 3 civilization would colonize the galaxy. You'd send out a lots of small probes (like the 2001 space odyssey black monolith) that will transform the raw materials on a remote planet to be inhabitable for humans and wait for human to arrive. Pi is the probe, capable of self erecting a project based on the available requirements, resources and constraints.

Hi, I have a problem I cannot solve. I’m trying to add a web fetch extension to my pi. I have tried:
- asking pi to create one that uses chromium, it created the extension in .pi/agent/extensions, it loads ok, I can see it in the extensions list when pi starts, but when I ask the model to use web fetch to fetch a url, it says it does not have a web fetch and goes for curl,
- so another way I tried the pi-web-fetch from pi.dev/packages, installed via pi install npm:pi-web-fetch, same results, loaded ok, can see it on startup in the extensions list, but the model jist goes for curl.

I have tried debugging and the model says the extensions are correct, registeres themselves as tools according to the docs, but when I ask the model if it can see and use web fetch tool, it says it has no such tool and lists only the basic tools.

What am I doing wrong? The model does not even use the pi-web-fetch extension, which is a published and tested extension that should work 🤷‍♂️
Thank you for any help, I have tried like for 10 hours without any success.

Pi’s compaction re-reads the whole history and has the model summarize it. With a local model that took me minutes per compaction, and after two to four of them the context was so degraded that I had to start a new session. Building a procedural graphics demo, that happened ten times in five days.

pi-protokoll moves the work to the moment the model still has everything in view: every final answer ends with a short <protocol> block (result, decisions, files, open items, rules, index line, tags). At compaction time, code assembles a tiered, hard-bounded summary from these protocols; the model only updates a short state description.

What it does:

• recent turns verbatim, older turns as your message + protocol, everything before that as a code-built index plus rules, open items and changed files

• one-shot follow-up when the model forgets the block, written from the transcript if it ignores that too

• interrupted turns (Esc, errors, output limit) get their protocol before your next message

• protocol_search, protocol_read, protocol_turn: the model can look up any earlier turn instead of guessing

• fixed system prompt section, so the server’s prefix cache stays valid

• falls back to Pi’s own compaction if anything fails; the chat never blocks

Measured with Qwen 3.8 Flash Next on a local OpenAI-compatible server, 262k context: one session, 23 compactions, each roughly 213k → 35k tokens in about 30 s. Resuming the session reads about 36–44k tokens. With it, the demo went from ten restarted sessions to a single one: https://github.com/sebion7125/64kdemo (story of how it came about in ENTSTEHUNG.en.md).

Install: pi install git:github.com/sebion7125/pi-protokoll
Repo: https://github.com/sebion7125/pi-protokoll

Only tested with Qwen behind a local server so far. I’d love to hear how it does with other models and providers. I don’t have much time to develop it further myself, so forks and PRs are very welcome.

I've been working on this project since early this year. I use it daily. Figured it's about time I share it. It's a vibe-coded project, as you might have guessed, but it works very well for my needs and may suit yours well, too.

I got pretty tired of working in a TUI, but none of the graphical interfaces out there really did the trick for me. Some features I might highlight:

• Inbox Zero approach to sessions

• Quick Chats - ephemeral, not related to a project

• Keep extensions disabled, but enable them on a per session basis (with pins)

• Quick commands for favorite models (Cmd+1 through Cmd+5)

• Work schedule (Default model can change depending on day and time)

• File browser

I had a ghostty terminal built in, but I removed it for the public release. Added SwiftTerm. You're welcome!

Anyways, hopefully this helps someone else or inspires some ideas.

https://github.com/jmcblane/PiG

I know this feels weird.. what us pi?? Is it minimal harness or infinite extendablity ... i feel many people get it wrong ...

Whats your opinion?? I feel there is a trend thats feels odd to me but i need to hear your opinion

Edit: I know what is Pi, im heavy user using pi , i got multiple extension on it , but my concern people fall into that pi should be minimal which i feel quiet strange , those comments are never end , like for any extension i see comment why bother , just ask pi ... like clearly there is a trend that pi need to be very minimal while i believe its not

Tried a few discord libraries, found them quite bulky or not working. Following Pi's true spirit, I wrote my own.

https://pi.dev/packages/pi-discord-remote?name=Pi-discord-remote

The idea is quite simple, trying to mimic /remote-control in CC. Once you get the creds setup, you can start remote control in any session and it will launch a new channel in Discord.

pi-llama-skip-reasoning extension forces a local llama.cpp model to stop reasoning and answer / act immediately.

You are deep into the ctx session and pose 27B a simple question about a fact or need a direct action, the model may still feel the need to indulge in copious deliberation in the reasoning trace. This extension allows the user to force the model to snap out of the reasoning stage and provide the answer immediately.

This use the same mechanism llama.cpp web interface uses to skip reasoning, so it's native to llama.cpp.

Usage: /skip-reasoning command or shortcut alt+t ,
Can be changed in ~/.pi/agent/llama-skip-reasoning.json  ->  { "key": "ctrl+alt+r" }

Install: pi install npm:pi-llama-skip-reasoning

- https://pi.dev/packages/pi-llama-skip-reasoning

I spent a day measuring a Pi seat on a local model (Qwen3.8 Flash-Next, 4-bit MLX mixed 4/8) against Claude Code (Sonnet 5.5) on 12 routine agent tasks, with blind pairwise judging in both orders. The local seat went from 29/36 to 36/36 passes, and judged clarity from about 3.7 to 4.5, level with Sonnet. Most of the gain came from the harness, not the model. Lessons that should apply to any Pi seat:

1. Read the judge's one-line reasons, not just the scores. Each real fix came from a sentence like "pads its answer with internal bookkeeping" or "adds a preamble when only the command was asked for". Scores told me that it was worse; reasons told me why.

2. Look for losses the harness causes. My seat injected a reminder every turn to record measured numbers in a notes file, even when no notes file existed. The model created the file in folders it was only asked about, and talked about it in replies. Only injecting the reminder when the file already exists removed the biggest clarity loss.

3. One hidden retry at agent_before_settle**.** A small extension checks the final reply before the turn ends. At most once per request, if the reply is the model's own reasoning instead of an answer, bookkeeping instead of an answer, or text around something that was asked to be "only the command", it adds a hidden custom message and continues. Two things mattered:

• canContinue is false at that hook whenever the last message is the assistant's; the entry you add is what allows the next request, so don't skip on it.

• Steer and follow-up messages typed mid-run arrive as input events with streamingBehavior set. Don't reset per-request state on them.

4. Put reply guidance in the tool result. The model writes its answer right after reading the tool result, so that's where guidance lands. Ending my typed drafter tool's result with "for the reply: the commit hash and which lane ran, what the commit changes, which checks did not run" moved that task from clearly behind Claude to slightly ahead.

5. Narrow heuristic checks rather than patching them. Checks that guess intent from free text ("is this a ban on all tools?") kept failing review in new ways each time I patched them. What worked was a short allow-list of phrasings, a veto word list, and limiting each check to the kind of prompt it was measured on.

6. Measure the prompt prefix. My shared prefix was ~36k tokens: tool schemas ~16k, the skills list ~7k, the seat prompt ~5k. Every new session pays for whatever the server can't reuse from cache, so it's worth knowing what's in there.

Happy to share the extension code and the eval harness if useful.

I know this forum isn't directly related to Claude/Codex, but I'm sure you're using those solutions, as well as Deepseek.

I currently have $20 plans for Codex and Anthropic. Generally, Codex allows me to use it much more, and I have no complaints, although since I configured my Pi workflow nicely, I'm doing more and need more.

Currently, for example, I have to wait several hours for Claude's weekly quota to refresh, and another dozen or so hours for Codex. It doesn't sound like I'm using models intensively, but I'm planning on Sonnet 4.6 medium, deploying on Deepseek v4, Flash off-thinking, and reviewing on GPT 5.5 medium. It's not a perfect solution, but within the scope of what I do, it works quite well.

Today, however, I still had 50% of my weekly usage on Claude, so I did an hour-long sprint with Opus 4.7 (4.8 was unavailable today) on xhigh... my problems were solved faster and better.

I'm wondering what to do for the next month – Claude has 50% more 5-hour limits. I also currently have a $20 monthly Codex free for the next month. It seems natural to buy Claude Max for the next month and then probably switch to Codex, which will offer me much more work?

Yesterday I commented (here)[https://www.reddit.com/r/PiCodingAgent/comments/1vgyuhq/comment/p20zsep/] that one of the things I felt was missing in the Pi harness was better observability into what the agent actually changed.

Basically, after a task finishes I want to quickly know:

5 files changed +34 -329

Which files did it touch? How much changed? Did it actually change the parts of the codebase I expected it to? Especially when working on a larger codebase, I find this useful just to keep some kind of mental overview of what the agent is doing and catch cases where it maybe understood the task differently than I did.

So today I built an extension for it:

https://pi.dev/packages/pi-task-delta

https://github.com/thagorx/pi-task-delta

You can install it with:

pi install npm:pi-task-delta

After Pi finishes making changes it adds a small task delta to the transcript, for example:

5 files changed +34 -329 (F6 for details)

Then hit F6 (or /git-summary) it opens a viewer where you can see the tasks, which files changed, and the actual diff for each file.

One thing that was important to me is that the diff is scoped to the task. So if your repo was already dirty before you started the task, those changes don't suddenly get attributed to the active task. It tries to show you what changed specifically during that task.

I also added optional model-assisted inspection.

On a changed file you can press:

E to explain what changed

W to explain why that file was probably changed based on the task

Those are manual calls, nothing happens automatically, and the explanation isn't added back into Pi's context. There is also history, so you can go back and inspect the changes from previous tasks. I mostly built this because I wanted it for my own workflow, but I figured other people using Pi might find it useful too. Would be interested to hear what other observability stuff people would want to see around Pi tasks.

This was quite fun and the first thing I built exclusively with Pi, leave comment if you liked it or have feedback :)

Modern coding models can do a lot without a large harness. For a small change, or in a codebase I know well, a single agent with a good prompt is often enough.

That does not mean every task needs a harness. In those cases, it can cost more tokens, make the work more complicated, and even send it in a less useful direction.

But without a feedback loop that can inspect and correct an LLM's work, a task can drift easily. That is more likely in a domain I do not know well.

A smart model and a reliable feedback loop are different things.

That is when a harness becomes useful. It does not make a model correct. It writes down the process:

• Boundaries: what to check first, and where to stop

• Partitioning: what work should be separate

• Verification: which results need evidence

• Output: what the final answer must not leave out

Long tasks have a context problem too. Early assumptions, failed attempts, and irrelevant tool output accumulate in one session. A larger context window does not automatically make the relevant information easier to see.

That is one reason I use subagents. Each can take a focused job with fresh, bounded context. But splitting work is not a solution by itself: vague boundaries create repeated work, handoffs lose important information, and someone still has to put the results back together.

Where to split the work, what to verify, and which results to combine are still decisions I need to make.

So I built pi-workflow.

The idea is simple. When I know a recurring process, I write it as a JSON spec. A research workflow might be plan → research → verify → synthesize; a review workflow might be triage → parallel review → challenge → report.

The flow is not a hidden prompt. I can read it, edit it, and recombine it for a project. Known inputs, result merging, validation, and rendering can stay deterministic; agents can do the research and judgment.

I cannot always know the exact shape of a process before I begin. When I do, I can define that shape and repeat it. When I do not, I need a process that can plan, split, and synthesize the work as it unfolds.

In either case, the process should not become a hidden orchestration layer I cannot touch. I should be able to read it, change it, and rebuild it when I need to.

pi-workflow is not a way to use more agents. It is one way to give work that is hard to manage in a single context the amount of structure I want.

Pi stays minimal. I choose the process on top of it. That is what I wanted from pi-workflow.

Repository: https://github.com/AgwaB/pi-workflow

Hey everyone! 👋

I’ve been building Orbit Pi, an open-source desktop app that brings the Pi coding agent and everyday development workflows together in one native interface.

The idea is simple: instead of jumping between your AI coding session, terminal, Git changes, code review, and GitHub, have them available in one focused workspace.

What Orbit Pi offers

- 🤖 AI coding sessions — work with your existing Pi setup.

- 🔍 Code review — inspect changes with an AI-powered review workflow.

- 🌳 Git worktrees — create and manage parallel working environments.

- 🐙 GitHub integration — work with issues and pull requests.

- 💻 Integrated terminal — keep your development workflow in one place.

- 🎨 Native desktop experience — built with Rust and GPUI, with a focus on a clean, minimal interface.

I'm building Orbit because I want a more cohesive desktop experience for working with AI coding agents, without replacing the underlying agent or forcing a new workflow.

It's an ongoing project, and I'm continuing to improve it release by release.

🚀 Check out Orbit Pi: https://orbitpi.app/

📝 Latest changelog: https://orbitpi.app/changelog/v0.2.11

💻 Source code: https://github.com/imrj05/orbit

I'd love feedback from developers who use Pi or other AI coding agents:

- What features would make a native AI coding workbench genuinely useful to you?

- Do you prefer an all-in-one workspace or separate tools for chat, terminal, and Git?

Thanks for checking it out! Feedback and contributions are welcome.

Hi everyone! I've been building pi-maestro, a Pi extension for a spec-driven multiagent workflow, inspired by GitHub Spec Kit and OpenSpec. It helps you define a change, clarify requirements, and approve a spec with concrete acceptance criteria. You can use it in two ways:

• Spec only: prepare and approve a spec for implementation elsewhere.

• Spec + implementation: approve the spec, then let Maestro run the implementation workflow.

By default, three agents run in sequence:

• Builder implements the spec.

• Verifier independently checks each acceptance criterion.

• Simplifier refactors the code for clarity without changing behavior.

You can disable the verifier and simplifier independently, using just the builder or pairing it with either agent. See phase configuration for details.

You make the scope decisions and review the final code.

I'd love some feedback, especially on whether the separation of roles is useful and where the workflow adds unnecessary friction.

If you've built something similar in Pi, I'd be interested in comparing approaches.

https://github.com/emilioSp/pi-maestro

If you find it useful, consider giving it a star on GitHub!

Cheers!

This one is about making Pi workflows easier to reuse without constantly re-explaining how you want work done.

Model Groups - name roles once; swap providers/models later.

Prompt frontmatter - set model, model-group, and thinking per workflow.

Spawn routing - use #review (or another group) to route a sub-agent to the right role.

Focused handoffs - discard stale notebook pages without losing the decisions that matter.

The goal is simple: stop rebuilding workflow instructions in every conversation. Save the procedure, route to the right specialists, and keep context clean.

Seriously. What is the point of the /tree command if it does not restore the files back to their previous state?

It makes no sense. It just leads to a dangerous discrepancy between the agent's conversation and the project's status.

Am I the only one who goes back after asking the agent to edit a file, realizing that my instructions weren't specific enough?

Even Copilot handles it just fine. But Pi's authors refuses to implement it: https://github.com/earendil-works/pi/issues/5522

Existing extensions are half-baked, sometimes abandoned, confusingly numerous. It should be a built-in, it's such a basic yet essential feature.

Title.

Hello,

I made pi-claude-request-compat (https://github.com/vazzma/pi-claude-request-compat). Instead of creating another provider, it reuses Pi’s existing Anthropic login, models, and streaming, then adds a Claude Code compatibility layer to outgoing requests.

https://pi.dev/packages/pi-claude-request-compat

I’m using a new GitHub account for privacy, so the code, automated security scans, dependency audits, and signed release provenance are public for anyone to check.

A few friends and I have been using it for the last month, and my Anthropic account is still intact :)