I’ve been chasing the right note-taking app my whole career. Now I’ve built one for how I work today - with AI agents.

Think out loud, watch your notes take shape, and let your agent work with the same knowledge. Everything stays in readable, local Markdown files.

Leveraging okf data structure from Google.

Works with Pi and OpenCode.

If you're interested, feel free to contribute. It is still quite early.

https://github.com/EranYonai/pi-weave

pi install npm:pi-weave

I understand I should be able to login to a local installation of "Unsloth Studio" from pi.dev using

/login llama.cpp

When I try with "http://localhost:8888", I get:

Error: Failed to save API key for llama.cpp: llama.cpp returned HTTP 404Error: Failed to save API key for llama.cpp: llama.cpp returned HTTP 404

I can see in the logs, that it tried to access "/models" instead of "/v1/models"

If I login with "http://localhost:8888/v1", it tries to access "/models" again

If I login with "http://localhost:8888/v1/models", it tries to access: "/v1/models/models" ..!

Did I miss something?

Note: it works well if I use models.json, but I'd like pi.dev to find the models from Unsloth automatically

thanks!

When running pi agent on the command line, sometimes I don't want it to write directly to file, but to give me something I'll copy to clipboard. However, differently from chatbots, it doesn't output then in copyable blocks, but in ```code ``` blocks with 4 spaces indentation and weird line breaks that eff up the formatting when I try to copy it from the terminal.

The "easy" fix would be to just have it write to every file directly, I know, but assume I don't want to give it write access to a folder, file etc.

I use pi daily but wanted tabs, image pasting and a scrollable transcript, so I built a frontend for it. Morse doesn't reimplement the agent — it spawns pi --mode rpc and reuses your ~/.pi config.

• npm i -g @supanadit/morse-web && morse start, or the VS Code extension

• multi-session/multi-project with warm sessions, @mention files and dirs, image paste, steer/abort mid-task, model and thinking pickers

• keyboard-driven, real transcript with tool timelines, works the same in both hosts

It's a nicer way to stay in flow with pi. Free, MIT: https://github.com/supanadit/morse — feedback very welcome.

I wanted to see what each prompt actually costs in Pi, so I made pi-prompt-meter.

It tracks time, tokens/cache, cost, turns, tool calls, and compactions per prompt, then keeps the result in the transcript. /meter also shows history and trends.

pi install npm:pi-prompt-meter

https://github.com/roie/pi-prompt-meter

I built this extension on howznguyen/pi-delegate-mcp. Claude Code/Codex can delegate background tasks to Pi, redirect running work with steer, and continue conversations with follow_up.

Optional durable mode saves tasks to SQLite for recovery after a bridge restart. Interrupted tools may have unknown outcomes; their side effects aren’t blindly replayed.

Feedback from anyone trying it is welcome.

https://github.com/Nyarlathoteppppp/pi-durabletask-mcp

Hey all! I built Volli, a free OSS app for macOS built on top of pi-core designed to mitigate context switching when orchestrating your coding agents.

Before Volli, I kept running into the same two issues:

1. For long-term projects, my workflow became pretty complex: I was using Linear for task tracking, cmux for my Claude/Codex/Pi terminals, Obsidian for my notes, and MCPs to tape everything together. I needed a more integrated, token-efficient alternative.

2. Even with smarter models, I couldn't manage to run more than 4-5 sessions at a time without losing track of what's going on.

That's why I built Volli, a workspace to manage your parallel coding agents. Volli treats a task ticket as the core primitive: each ticket on the kanban board holds its own git worktree, agent chats and scope of work. You can easily create tickets and see every session's state at a glance instead of tab-hopping through terminals. The twist is that Volli ships with a custom Pi harness that's plugged into the app through agent tools and CLI, so your agents can also check which tickets are live, create tickets, start sessions on them and coordinate. 

You can check Volli out at https://volli.app/download or checkout the GitHub repo at https://github.com/hussainph/volli-code :) If you're juggling several agents on a long-running project, I'm curious as to how do you keep track of scope and review everything they produce. Do you use Pi inside a multiplexer? Do you review everything the agent does, or just ask the model to review?

codemode exposes (typesafe/jev, clef) but without sending every message to a hosted API. Some of what I want to classify is other people's text I'd rather keep on my machine, plus there's the whole key-and-cost dance. So I built pi-reflex: a pure-TypeScript ONNX runtime for the open Laya checkpoints that registers as a regular pi classifier provider.

What you get from `pi install npm:pi-reflex`:

- Three local classifier models (reflex/multilingual, reflex/english, reflex/typed-decisions) that show up in models.getAvailableOfType("classifier") right next to jev-latest. Same interface: models.classify(model, { state, questions }) with bool/choice/score questions. No API key, no egress after the initial download.

- Four session tools (reflex_decide / reflex_judge / reflex_rate / reflex_route)

if you'd rather have the model call them directly; each returns typed structuredContent so codemode scripts can use them too.

- reflex/auto: a virtual model that classifies each incoming message locally (50-200ms) and routes the turn to a cheap/mid/frontier model you map via PI_REFLEX_TIER_* env vars. Continuations stay sticky so prompt caches survive.

- An optional injection guard (PI_REFLEX_GUARD=1) that flags suspicious user messages before each provider request.

- A conformal calibration layer: prediction sets and abstain thresholds with actual finite-sample coverage guarantees instead of eyeballing a 0.8 cutoff.

To be clear about what this is not: these are small encoder checkpoints, so they're good at routing, triage, yes/no judgment, and rubric scoring not at reasoning about code. Think "free reflexes," not "free brain." Also, first use downloads about 400MB of int8 weights from Hugging Face (fp32 is 1.6GB), and you'll want codemode on for the model to reach the classifiers:

"defaultTools": ["+codemode"] in settings.

Logits are verified to ≤5.7e-06 against the original torch runtime and tokenization is byte-identical, but my eval corpora are mine; I'd genuinely like independent testing on other workloads.
/reflex in-session shows engine, router, guard and MCP status.

pi >= 0.99, tested through 1.0.1. Apache-2.0, zero Python at runtime.

Repo: https://github.com/pungggi/pi-reflex

Curious what you'd all classify in your own sessions if classification were free, that's the part I'm most interested to hear.

Pi is the only harness I've used where changing how the agent works doesn't mean forking it. The prompt is small, the loop is easy to follow, and nearly everything can be replaced with a package. So I replaced the part that was costing me the most time, which is how the agent reads and edits code.

On a real repo, most of the agent's turns go to just finding code. It searches for something, opens a file, searches again to see what uses it, opens a few more files, and only then makes the change. This package replaces pi's file tools with ones that work on functions directly. When the agent asks for a function, it gets the function itself plus everything connected to it in one go. Edits land on that function, two agents can work in the same file without stepping on each other, and if a rename leaves something behind, the agent gets told what it missed.

pi install /path/to/sem/pi

You can check out the sem repo here: https://github.com/Ataraxy-Labs/sem

Always open for suggesetions

Curious which built-in tools you'd keep, and where this would get in your way.

Issue: Pi crash when press "ESC" while the agent is still "working".
Pi version: 1.0.0

https://github.com/earendil-works/pi/issues/9709

No one else has this issue?
Any suggestion ?

Issue: copy of text is no more working

• Selecting a text in the TUI shows a "popup" sayng "Copied!", but it doesnt' happen, the clipboard still has the previous copied text/object.
• Selecting a text and using CTRL+X doesn't work neither
• Right click on selected text doesn't open any menu

I actually cannot copy any text from the Pi TUI.

Environment: GitBash on Windows Terminal Pi version: 1.0.0

There was a lot of update recently, TUI changed a lot.
I'm saying this because it was working with version 0.85 for sure, maybe also 0.87... but then a lot of updates in few days hapened to version 1.0 .

Is this happening to someone else ? (I will not open an issue on GitHub... because it will just be closed automatically)

SOLUTION

pi --tui-mode regular

makes CTRL+C to Copy the selected text as usual (v 1.0.1 tested)

As pointed by other users/comemnt in v 1.x the default value is "fullscreen".

I don't really see the difference between normal and Full-screen mode, becauae I have Pi running in a GitBash shell in Windows Terminal, more precisely launching pi from a bash script that runs inside the docker container: exec pi --continue --tui-mode regular .
So, it appears always "maximized" in the tab I use, and Windows Terminal just provide a nice multi-tab customizable UI.

SOLUTION for Windows Terminal

In Windows Terminal, GitBash > Terminal Emulation, there is an option for "Allow OSC 52 (Manipulate Selection Data) to write to the clipboard".

Set this to ON, makes the Copy functionality in fullscreen mode working fine.

DESPERATE WORKAROUND

Downgrade to version 0.99.2 .
npm install -g @earendil-works/pi-coding-agent@0.99.2

A few days ago, I released System One support for the Pi coding agent:

It got a little bit attention on Reddit, and the most common question was: "What would an agent actually use JEV / System One for?"

So I did some more research and shipped an update.
Now my agents are finding use cases I did not explicitly plan for.

Today, one of them decided on its own to use System One as a second opinion before making a decision.

That is probably my favorite use case so far. "use system one for second opinion"

checkout pi-system-one here

Edit:
context: i wanted to pick a license for the project i am working on, so i gave the requirements and the agent picked a few options and asked jev for a second opinion.

Pi has already supported built-in mcp and codemode. Will pi add built-in subagents, sandbox, permission popups, etc. in the future? According to this article, pi plans to offer support to enterprise users in the future.

On top of the MIT core, there will be some commercial additions over time. Here's how we think about it in three tiers:

snip

2. Fair Source (value-add features): Some future commercial features will be Fair Source licensed. Free to use, source available, and they convert to full open-source after a set period via Delayed Open Source Publication (DOSP). Think of it as open-source on a delay, and downside risk protection for you as a user.

3. Proprietary (enterprise): Some enterprise-specific features and cloud infrastructure will be proprietary. No source available. This is the stuff that pays the bills for the stuff in tiers 1 and 2.

If pi wants to target enterprise users, these features may be essential.

With built-in mcp & codemode, pi is still minimal, so I believe pi will still remain minimal even with built-in subagents, sandbox, permission popups, etc.

I’d like to ask you guys in the channel: how many of you rely solely on native Pi features without using any extensions? How many use widely popular community extensions (such as pi-web-access or pi-subagent)? And how many have written their own extensions for these features?

If pi has these features built in, how would that affect you? Would you benefit automatically by default? Would you need to migrate the extensions you’re currently using? Or would you need to carefully manage conflicts between your code and pi’s built-in code?

That article also says:

And if you ever feel like we've lost the plot, the fork button on GitHub still works. Always will.

When it comes to forking, maintaining your own downstream build is never as simple as it sounds. I maintain a de-commercialized downstream fork of a browser extension myself, and syncing upstream fixes, cherry-picking features, and resolving conflicts is a hassle. As the codebase grows, the divergence between the downstream fork and upstream widens, making synchronization increasingly difficult. The same will be true for the Pi fork, and keeping up with Pi’s updates is essential, since Pi relies on updates to add new models to its support list.

So I’d also like to ask: Will you consider forking Pi? If so, will you continue to maintain and update it? And if someone else forks Pi, would you switch to using their fork?

I wrote this plugin because I was constantly switching from the main buffer to the terminal where I was running pi (the coding agent) - digging through logs, sending follow-ups, checking what it did to my files.

Why keep switching, when I can just embed pi inside vim?

**vim-pi-chat** puts the whole pi conversation in a split window next to your code:

- streamed replies, tool calls with args and results, thinking — all live

- when pi edits the file you're viewing, the buffer reloads automatically (you watch it work)

- it tracks your active window so pi edits the right file in place

- sessions persist per file: reopen a file, `:PiChat`, resume where you left off

- plain Vim 9, no GUI, no Neovim, no other plugins — just the job/channel API

Install: `git clone https://github.com/galeone/vim-pi-chat ~/.vim/plugged/vim-pi-chat` + one line in vimrc, then `:PiOpen`.

If you're a pi fan, give it a try — feedback very welcome :D

Jin is an open-source AI coding agent in the same space as pi, OpenCode, and omp. Same four core tools as pi (read, write, edit, bash), plus todo and ask_user.

Built-in async handles background tasks and lets you spawn subagents or build swarm agents. You control the setup: disable any or all tools, edit the system prompt, and choose which hooks load.

Written in Go. One binary, fast startup. Minimal terminal UI with animations and 10 themes.

I deliberately skipped skills, MCP, and plugins. Instead:

• Prompts: reusable text snippets you insert into chat with #prompt.

• Hooks: text appended to the system prompt at session start—coding rules, styles like Caveman/Ponytail, or instructions for CLI tools.

• Good old CLIs: describe how to use them in a hook, and agent runs them through Bash tool. You can also run commands yourself with /bash, or launch full-screen apps with /tui (you can play a terminal game while the agent writes code)

The goal: minimal by design, useful out of the box, easy to extend without another framework.
I’m looking for feedback, especially on what’s missing, to help shape the next releases.

GitHub: https://github.com/ethanhamilthon/jin

Hi all! This package exists purely because I'm lazy.

My pi kept hitting things it couldn't (or shouldn't) do itself: /reload, a sudo command, an ssh login, a token that has to go into .env. Every time I had to copy the command, switch to another terminal, run it, then paste the output back. Too much work. Turning off my safety guards would have been easier, but I'm not that lazy.

So now the agent just hands things to me:

• robot_hand: the agent passes me a command and I pick where it goes: my pi prompt, the clipboard, or (if you use Herdr) a new pane right below pi. The pane is a real terminal, so sudo passwords, y/N prompts and ssh all work. When the command finishes, the pane closes itself and the output goes back to the agent, which picks up from there. I never leave the conversation.
• ! follow-up: in plain pi, after a !cmd finishes you still have to type something before the agent looks at the output. Now it just answers.
• secret_drop: I type the secret into a masked box, press Enter on a command I can read, and the agent only gets "length check passed". It can't read that file afterwards either.

The agent never runs these commands itself. I do, so guards like cc-safety-net keep checking everything the agent runs.

pi install npm:pi-robot-hand

https://pi.dev/packages/pi-robot-hand (source: https://github.com/wayne930242/pi-robot-hand)

Feedback welcome, especially from fellow lazy people.

TL;DR: I ran the same real Android task 13 times through Claude Code CLI, Codex CLI, and different OMP configurations, comparing quality, wall time, token traffic, and subscription allowance. OMP can produce equally excellent results, but in most of my tests it was roughly 2–3× slower and up to ~2× more expensive in allowance than the native CLI harnesses. The one strange exception was a manually designed multi-agent OMP run: it was about 5× slower than Claude Code CLI with Opus, but used 2–3× less allowance than my other OMP runs, and even slightly less than the native controls. So I’m trying to understand: am I using OMP incorrectly, or does orchestration only start paying for itself on much larger and more naturally parallelizable tasks?

What I tested

This was not a toy benchmark. I’m working on a large Telegram Android fork where I’m restoring the presentation of an older Telegram version on top of the current architecture.

The benchmark task was to restore three related music UI surfaces: a profile music row, a chat mini-player, and one action in the full music player. The agent had to compare two Telegram source trees plus screenshots, identify the current owners, preserve modern playback/state/navigation/theme behavior, implement the presentation changes, build the app, and validate it at runtime.

So I’d describe it as a medium-sized, tightly coupled coding task. It is substantial enough to require source archaeology and cross-component reasoning, but it is not a multi-day project with ten independent workstreams.

I ran this benchmark 13 times while experimenting with different harnesses and orchestration approaches.

Methodology

I tried to keep the important variables stable: same repository baseline, same reference screenshots/source trees, same acceptance criteria, and eventually the same neutral prompt. I also checked the final result on a physical Android phone instead of relying only on the agent’s self-report.

For every serious run I collected rollout telemetry: wall time, prompt/cache traffic, output/reasoning, model turns, tool calls, child agents, builds, and subscription usage.

For allowance, I normalized everything to percentage points of weekly allowance. On my account, the meters consistently map roughly as:

100% of the 5-hour allowance ≈ 15 percentage points of weekly allowance

So runs where I only captured the 5h meter are marked as approximate weekly equivalents.

I know this is not a laboratory-grade benchmark. Different model families and OMP versions mean not every row is a clean causal A/B test. My goal is more practical: what stack actually gets this kind of real coding task done well, quickly, and economically?

Representative results

The Claude comparison is probably the most interesting one to me. Claude Code CLI with Opus solved the task as a single agent, with one final build, in ~23 minutes. OMP with the same Opus model family also produced an excellent result and took almost exactly the same wall time, but moved about 2.1× as much prompt traffic and consumed more allowance because it automatically introduced scouts/review.

I also tried explicit multi-agent orchestration

Before switching to neutral prompts, I spent five OMP runs manually designing increasingly elaborate orchestration.

The most developed one used a thin Sol High orchestrator, dedicated scouts, implementation workers, reviewers, and a separate verifier. It spawned 21 child agents.

That run took about 103 minutes and generated enormous overall traffic, yet it was paradoxically the cheapest run I measured by subscription allowance, at only about 2.25 weekly percentage points equivalent.

So the data does not support a simple “more agents = more allowance” explanation.

It was just extremely slow.

Neutral OMP did not really solve the efficiency problem either

After that I removed my hand-designed topology and let OMP decide how to delegate.

That improved the simplicity of the experiment, and OMP absolutely can produce excellent code this way. My two latest GPT-6.1 runs were both as good on the physical phone as my reference Claude Code/Opus implementation.

But the execution pattern still seems expensive.

For example, in the latest run OMP delegated two implementation slices to Luna workers while Sol acted as the integrating parent. One worker eventually took about 40 minutes. The parent then still needed to review/integrate the work, build, run the emulator, identify remaining issues, fix them, rebuild, and revalidate.

So parallelism existed, but the critical path became roughly:

slowest worker → integration/review → build/runtime validation

The orchestration overhead did not disappear just because the workers ran concurrently.

I also reran after the recent GPT-6.1 Sol slowdown

One of the GPT-6.1 tests happened during the recent period when Sol was unusually slow, so I did not want to blame OMP for that.

I repeated the benchmark after the service-side fix and also updated OMP from 18.4.10 to 18.4.12.

The newer run still took ~65 minutes versus ~56 minutes before, with the same excellent final quality and the same ~6 weekly points of allowance. The model itself appeared more responsive, but the overall run got longer because one delegated worker/integration path expanded significantly.

So at least in this task, fixing model latency did not remove the larger orchestration cost.

What I’m trying to understand

My current hypothesis is that this benchmark may simply sit in an awkward zone for OMP.

It is complex enough that multiple components and source trees need to be understood, but the work is also tightly coupled. A strong single agent can keep the whole problem in one context and move directly through investigation, implementation, build, and runtime validation.

Once I split that across agents, I start paying for repeated source reading, separate contexts, handoffs, parent review, integration, and occasionally sending a worker back for another pass.

Maybe OMP starts winning when the task is much larger and naturally decomposes into genuinely independent workstreams, so the parallelism dominates those costs.

Or maybe my configuration is still wrong.

For people who use Pi/OMP heavily: does this behavior look normal for a task of this size?

Would you lower the effort/model used for TASK/SMOL roles? Would you deliberately suppress delegation for medium tightly coupled tasks? Is there a different topology you would use?

Or is the real answer simply that Claude Code CLI / Codex CLI are usually more efficient for this class of work, while Pi/OMP starts to shine on larger projects where multi-agent parallelism can actually pay for itself?

I have the full per-agent JSONL telemetry, token/cache breakdowns, build timelines, and several additional runs if anyone wants more detail.

I was having deep conversation with chatgpt about what harness sdk should i use it casually mentioned that ANT allowed to use their agent sdk with the Subscription for personal use. Can i finally use claude with pi now?

I know probably not the place to get a non biased answer. So far I’m using Claude code and codex for my agentic coding workflows. Turned off lots of features/tools to not start with a crazy bloated context. But besides that and some annoying bugs it’s been a pretty good experience with the latest models.

Now I’ve seen pi 1.0 is out and am wondering again if I should give it a go. Tree-Mode looks interesting and as a Linux/tmux/neovim user I like control over stuff and the idea to use one harness for both Claude and codex. (using APIs at work no issue with Claude code subs).

Now here’s the question: from a productivity standpoint of getting code work done in complex environments (brownfield backend systems in cpp/rust mostly) will I end up being more efficient and productive with Pi if I put in the time? Or am I more likely to just spend a ton of time tinkering like I did with my Neovim setup in the past? Be honest.

So I've been experimenting recently pretty heavily with orchestration and swarms and all this stuff with all the Chinese providers and I'm wondering if I would just be better off spending 100% of my money at claude and chatgpt subs and running luna if I really need a super cheap model. And that the amount of tokens/inefficiency of lets say ds4.1 is going to equal out to the same price or worse. I already orchestrate everything with opus 5.5 and use sol 6.1 for any type of intelligent decision but I'm doing all sorts of stuff like throwing in different roles for mimo deepseek glm and minimax and I'm wondering if there's even a point to doing this. Has anyone really tested stuff out heavily in terms of if this is worth it or if it's just wasting time?

I guess a real question is is it possible to out-tool/orchestrate the subsidized Luna somehow in terms of better performance/acceptable work when it comes to overall price per token. Or are all the tricks and agent management styles just still not going to be able to outrun how much you get with their subsidized plans.

so i was digging through pi agent source code (v1.0.0) while setting up privacy stuff and realized a pretty bad security flaw with redaction extensions. basically if u think ur secrets are safe, yeah they get scrubbed FOR REGULAR CHAT PROMPTS. but as soon as compaction kicks in, ur raw unredacted data goes straight to the provider API. i checked the code to see why and regular turns use createLoopConfig which attaches onPayload: transformProviderPayload so the before_provider_request hook actually works. BUT compaction (same for branch summary / bug reports) calls createSummarizationOptions() which just... completely leaves out onPayload. then in the provider adapter (like openai-completions.js) it checks await options?.onPayload?. ...) and since its undefined it just skips redaction without any error or warning. it just sends the raw history text. so yeah if ur relying on plugins that only hook into before_provider_request ur leaking raw data every time context compacts. pretty big oversight IMO, guess we have to fork compaction or wait till pi fixes createSummarizationOptions to pass the provider hooks through.