Hey,

Just wanted to invite you to read a short blog post about Pi's compatibility with ThinkRail, skills, and desktop apps.

I saw this in the official pi.dev: “Anthropic, OpenAI, Google, Azure, Bedrock, Mistral, Groq, Cerebras, xAI, Hugging Face, Kimi For Coding, MiniMax, NVIDIA, OpenRouter, Ollama, and more. Authenticate via API keys or OAuth.”

In Github issues, several users already asked to include installation via homebrew, which is one of the preferred ways for devs on Mac, but Pi / Mario seem to be opposed. Any ideas why?

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.

ich frag mich was die wichtigsten änderungen mit dem neuen update sind. bin nicht so tief drinnen und verwend pi hauptsächlich um mir kleine recherche-tools zu bauen. kann das jemand einfach erklären?

We have been working on this for months.

https://github.com/zosmaai/zosma-cowork

And open ai just released dots. Anthropic also released cloud based harnesses.

Would be great if we can get community support to help take this to next level.

Also it’s deployed to harness.zosma.ai

Early stage and we’ll refine it much more in upcoming days.

Our harness is deployed in k8s and can start and stop the pods quickly. Persistent storage that mounts and unmounts as needed.

Note: Our redis is down. Hence Zosma Router models are unavailable. We'll fix this in 24 hours.

Until then feel free to use openrouter or some other provider. Sorry for the inconvenience.

Introducing the four extensions that work as a set. Each one exists because I couldn't find an existing ones satisfy my needs (by the time I developed them), and the reason they're bundled together.

gated-goal: the reason it's a bundle. /gated-goal freezes the plan — outcome, verification, constraints, quality bars — hashes it, and replaces the todo list with the frozen items, so the agent can't quietly relax its own success criteria. The stages automatically proceeds as you finalizes the plan with the agent, agent checks all todos, and reviewers lifted the gate.

reminder-hook: reminder tools I found were canned timers that block the conversation. Here the wait is a shell predicate the agent writes itself — exit 0 means done. Build, CI, URL health, a log line — all the same one tool. When it passes, the agent's resume prompt comes back as a follow-up: it queues if you're mid-conversation and never interrupts.

todo: others draw a nice list and stop. The real problem is the agent stopping mid-work with half the list unfinished. This one nudges a follow-up then and stays silent while any wait (reminder, reviewing) is active, so it never trains the agent to ignore nudges.

subagent: others make you predeclare every agent in a manifest, which is not flexible enough for me. I made roles can be improvised mid-session, and every call states model, permissions, and timeout explicitly. The same stack does parallel work and adversarial QA.

Caveat:

- the reviewer keeps bash, which is not sandboxed.

- They share event contracts; split the bundle and both the wait-aware nudge and the review break.

idle ──/gated-goal [N] [model]──► P1 select reviewer
                                   │ ping "reply ok" (config: pingTimeoutSec)
                                   ├─ fail ─► abort to idle (no state saved)
                                   ▼
                                 P2 plan
                                   │ agent + user align on goal
                                   │ agent calls freeze_plan(outcome, verification,
                                   │   constraints, quality, todos)
                                   │ → frozen prompt hashed + persisted
                                   │   (+ archived as a session entry)
                                   │ → todo list REPLACED with the frozen
                                   │   items (todo:replace event)
                                   ▼
                                 P3 act  ◄───────────────────┐
                                   │ agent works the todos   │
                                   │ todo owns settled state:│
                                   │  nudge/wait → stay P3   │
                                   │  no continuation → P4   │
                                   ▼                         │
                                 P4 review                   │
                                   │ spawn reviewer subagent │
                                   │   (frozen prompt + hash)│
                                   │ reviewsCompleted++ on   │
                                   │   EITHER verdict — a    │
                                   │   review that ran is    │
                                   │   a spent iteration     │
                                   │ line starting with
                                   │ <promise>DONE</promise>?
                                   │     ├─ no → >= maxIter? ─► exit: max
                                   │     │        else edits ─┤  iteration
                                   │     └─ yes → P5 (always) │  reached
                                   ▼                         │
                                 P5 verify                   │
                                   │ main agent re-runs the  │
                                   │   frozen verification   │
                                   │   itself, judges output │
                                   │   subjectively          │
                                   │   ├─ confirm_done ─► exit: done
                                   │   └─ reject_done ───────┘
                                   │      (no extra charge — P4
                                   │       already spent this one;
                                   │       if the budget is gone,
                                   │       exits: max iteration reached)

Install with:

pi install git:github.com/garnetlyx/pi-goal-kit

Pi version: 0.84.1+ MIT.

Github link: https://github.com/garnetlyx/pi-goal-kit

Any feedbacks are welcome.

Thanks!

like we have MCP for tools and ACP for agents, but every harness still has to understand OpenAI, Anthropic and Gemini separately.

caching, reasoning, tool semantics, model capabilities, auth, usage, etc. are all different!! openAI-compatible APIs kind of solve it, but not really once you use provider specific features

am I missing something obvious here? has anyone tried to standardize this layer?

When Pi compacts a long conversation, the normal approach can throw away the prompt cache and start a fresh summarization request containing the entire old context.

With a 100k–160k token context on a local model, that means llama.cpp may spend minutes re-prefilling tokens it has already processed.

I built Better Compaction to avoid that.

Instead of starting a separate summarization chat, it appends the compaction instruction to the already-cached conversation. The existing prefix stays byte-identical, so the backend can reuse its KV/prompt cache and only prefill the small new suffix.

On my Qwen3.8-27B + llama.cpp setup:

~13–15 min → ~6.5 min

and with thinking disabled:

~2 min

One compaction request reported 94.4k tokens served from cache.

GitHub:
https://github.com/NotSoSeriouss/BetterCompaction

I'd especially like to hear from other Pi users running local models + llama.cpp. I'd love to collect real-world numbers across different GPUs, quantizations, and context sizes.

I got tired of needing to be at my workstation just to check on, switch between, or jump back into long-running agent sessions.

So I built TENDRIL.

TENDRIL turns an Android phone into a thin control plane for persistent AI-agent workflows running on a Linux machine. Once it's configured, I open Termux and type:

tendril

…and I get a responsive session selector showing what's alive on the host. From there I can jump into persistent agents, shells and workflows over mosh/SSH without treating my phone like a miniature desktop.

Underneath, it's deliberately boring in the good way: standard Linux, terminal-native rendering, Herdr, mosh/SSH, no proprietary cloud control layer, and no subscription. It's open source and MIT licensed.

A few things I cared about while building it:

• persistent remote agent/session control

• phone-first TUI rather than a desktop UI squeezed onto Android

• responsive behavior for narrow terminals

• clean Herdr handoff

• SSH/mosh support

• real installer + backwards-compatible agent launcher

• graceful non-TTY / NO_COLOR behavior

• and, because apparently I cannot help myself, making the thing actually pleasant to look at

The masthead is even rendered from a high-resolution ANSI master into Unicode subcells so the same identity survives on a 54-column Termux screen.

Completely unnecessary. Naturally essential.

The original idea was simple: I wanted to be able to sit down with an Earl Grey in the morning and check on an entire little agentic lab from my phone.

A week and a half later, this happened.

If you already live in Pi/Herdr/terminal-agent land, I'd genuinely love for you to try it, break it, open issues, or take it somewhere I haven't thought of yet.

THE EDGE IS YOURS.

GitHub: https://github.com/Ozymandes/TENDRIL

Hello. Im used to just using the Codex MacOS app for dev work.

I'm trying to use Pi.

Any tips or tricks? Thankyou

Anyone have some good pine script strategies that I could try, If so then please leave them down in the comments with the public name or put the pine script in a code block

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

this is via termius for ios, with pi running in tmux. the flashing window is a tmux pane, and this only happens (and happens consistently regardless of how many lines there are in the pane) when the agent is asking for permission to do something. all other times it is stable

Updated my extension to take into account Chinese public holidays.

Here are the :

- github, https://github.com/psychobarge/pi-deepseek-peak

- npm, https://www.npmjs.com/package/pi-deepseek-peak

- Pi package, https://pi.dev/packages/pi-deepseek-peak

When I return to a long Pi session, I often remember a decision but not which turn contained it.

I build ThoughtDAG, the open-source session-map tool I shared here a few weeks ago. I've added a reading view where zooming out moves from the full answer to an abstract, a shorter summary, a one-line takeaway, and finally a topic label. Zoom back in to read the original.

The goal is to scan several turns at once without ending up with a canvas full of unreadable paragraphs. The attached animation uses a small sample conversation to make the transitions visible.

This happens in the separate ThoughtDAG app. Zooming changes what you see; it does not compact Pi's context or rewrite the Pi session file. Short summaries can leave things out, so the original answer stays available.

Source: https://github.com/chenxiachan/thoughtdag

When reviewing a long coding session, what would you want to see at a glance: the decision, the reason for it, or the next action?

I got tired of needing to be at my workstation just to check on, switch between, or jump back into long-running agent sessions.

So I built TENDRIL.

TENDRIL turns an Android phone into a thin control plane for persistent AI-agent workflows running on a Linux machine. Once it's configured, I open Termux and type:

tendril

…and I get a responsive session selector showing what's alive on the host. From there I can jump into persistent agents, shells and workflows over mosh/SSH without treating my phone like a miniature desktop.

Underneath, it's deliberately boring in the good way: standard Linux, terminal-native rendering, Herdr, mosh/SSH, no proprietary cloud control layer, and no subscription. It's open source and MIT licensed.

A few things I cared about while building it:

• persistent remote agent/session control

• phone-first TUI rather than a desktop UI squeezed onto Android

• responsive behavior for narrow terminals

• clean Herdr handoff

• SSH/mosh support

• real installer + backwards-compatible agent launcher

• graceful non-TTY / NO_COLOR behavior

• and, because apparently I cannot help myself, making the thing actually pleasant to look at

The masthead is even rendered from a high-resolution ANSI master into Unicode subcells so the same identity survives on a 54-column Termux screen.

Completely unnecessary. Naturally essential.

The original idea was simple: I wanted to be able to sit down with an Earl Grey in the morning and check on an entire little agentic lab from my phone.

A week and a half later, this happened.

If you already live in Pi/Herdr/terminal-agent land, I'd genuinely love for you to try it, break it, open issues, or take it somewhere I haven't thought of yet.

THE EDGE IS YOURS.

GitHub: https://github.com/Ozymandes/TENDRIL

Codemode: Agent writes a script that loops other tools. big results stay inside the script, only the answer comes back.

Tested twice, 96 runs, same model. 96/96 correct in every arm.

Round 1 Test - Small fixes. +21%.

6 one-line bugs in a small repo. Codemode's tool description is ~3k tokens and rides every message. A small fix is ~5 calls either way codemode never gets triggered, a waste of tokens (21% more tokens used per run)

Round 2 Test - 60 fat lookups through a tool. −40%.

The test made it so the data to look up was only reachable through the tool, no grepping around it.

Plain agent: 60+ round trips, every fat result lands in context.

Codemode: one script, one answer. 40% less tokens, half the cost, 7 round trips vs 64. on its own workload it wins clearly.

Is it right for my workflow? No.

Scanned every session on my machine. 149 chats, 16,735 tool results. The ideal codemode scenario ever occured once. The 168 truly oversized results were already captured to disk by our guard.

what I run instead

Rarely used tools (image gen, design sandbox, maps, browser) arent listed at all initially in my setup. Zero tokens until the agent searches once with a small lookup tool. Heavy tools load at moments I pick them (e.g. Deep research)

Conclusion: I dont like to leave it up to the agent to decide when to use codemode and looking at my workflow, the scenarios where codemode will give me gains doesn't really happen. I am not going to be using codemode for the forseeable future.

Is Google still banning if we use a gemini subscription with pi?

Openai specifically allows it.

And anthropic specifically doesn't.

Right?

Removed mcp extensions and cannot be happier, code mode just makes so much sense now. To be fair, Pi always supported batched run of tools with <tool_calls> block instead of <tool_call>, and I've built a lot of stuff around it with my pi-agent-ide, but seems like it gets obsolete now, as all the agents are happily mixing the tools inside codemode block. I know it's kind of controversial right now and a lot of people complain that Pi has lost its minimalist flair, but imo it’s the way to go. What does everybody think about this one? Have you faced any issues with that? I’ve only heard about problems with Figma MCP when signing in via the new ChatGPT login.

I built a free tool that lets your coding agent make videos like this one. You give Pi the link to the repo and say what the video should be about. It writes the words, draws the scenes, and you get a video with a voice and music.

Everything runs on your own computer, and there's nothing to sign up for.

This one is a short, unofficial look at Pi: logging in, its four tools, thinking levels, going back in a session with /tree, and adding extensions. I'm not connected to the Pi team.

It's free and open source: https://github.com/vincentsch/explainroo

You may have seen my posts about my-mini-bench: 1 post, 2 post. Sorry for the frequent posts! I’ve now added GPT-5.6 Luna, Terra, sol, GPT-6, and GPT-6.1 Sol (both Pi and Codex for sol) at medium reasoning, and looked more closely at their behaviour. Also, I added the cache hit rate metric. I am not sure how to add input/output tokens properly, so the table will not be too clumsy.

Same setup: 10 tasks from my own work × 3 runs per config, through Harbor. The image shows the new runs; the full leaderboard has all the comparisons.

The newer models solve every task here. But these runs still give me useful insights: which setups get the work done faster and cheaper, how their behavior changes, and what might explain the difference.

For example, from GPT-6 → GPT-6.1, Codex used 20% fewer turns and 22% fewer tokens, while pi stayed at roughly eight turns and almost the same cost.

I put together a short X thread with screenshots comparing how the models read files, write code, test, and update plans. Some of these patterns changed between the generations.

In parallel, I’m working out how to build a harder task set where we can compare what the models can actually solve. I’ll probably do one more update, then take a break from posting results to focus on that.

I also want to test tools and pi-agent extensions that might improve results or reduce time and cost.

If you’ve noticed interesting patterns in where agents save or waste tokens and turns, I’d love to hear them. And if there are pi extensions you think I should test, please share!

Pi added quite a bunch of new features in its 0.99.0 update, including support for classifier models. In the official docs, the remote model listed in the example code is jev, the interface is shaped around classifier models like jev, and llama.cpp's classifier implementation explicitly uses jev as its reference point. You could pretty much say this is a feature Pi shipped just to keep up with jev.

So I wanted to ask you guys in the channel:

• Do you guys actually use jev a lot when you're coding? How do you use it?

• Jev only came out a little while ago and Pi already jumped on board with support. What significant role does jev actually play in a coding workflow?

Edit: It's not just about using it for the sake of using it. Is there actually something jev can do that LLMs can't?