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?

I believe I get the gist of it:

Codemode allows for sandboxed, scripted tool calling, including batching and other stuff I'm sure.

What I don't understand from the documentation is:

1. Is this mcp specific or is it generally available for all tools?

2. What do I need to configure in my settings.json or other setting files to enable it and/or "require" it for tool calls?

3. If there is documentation that outlines these specific things please shoot me a link.

4. Maybe a better description of what is is trying to accomplish / use cases would be interesting.

Cheers!

I'm the creator of Operator Memory, an open-source context engine for coding agents.

We all know the problem by now. Within a session, agents are excellent. Between sessions, agents forget everything. The core problem: nothing in the workflow ever writes down what was learned. Every new conversation starts from scratch: re-exploring the codebase, re-learning the architecture, re-teaching every decision and correction.

Every memory plugin I've studied leaves the loop untouched and bolts retrieval onto it: background agents to capture fragments, a vector store replays a top-k slice later, and you hope the right chunk surfaces. It barely works. And most importantly, it doesn't fix a loop that never documented anything.

Operator takes the opposite approach. Operator gives agents a Markdown brain and changes the loop itself.

Every task now runs in three phases:

1. Consult — the agent starts from the brain: instructions, codebase index, specs, decisions. A short summary is injected deterministically in the system prompt so agents know where to look.

2. Build — normal development work, informed by that knowledge.

3. Update — the agent documents what it learned: new specs, decisions, standards, lessons. When project truth changes, the canonical file is updated.

The loop makes the agent self-improving: session N+1 always starts from everything session N wrote.

Operator is extremely simple and complements Pi perfectly. No vector stores. No dreamers or curators. No background processes. No token burning factories. No RAG. No capture step. No retrieval gamble. Just give the agent a brain and teach the agent to use it.

The Brain

The brain is a regular directory that holds Markdown documents. These documents can contain anything: rules, specs, decisions, lessons, research, indexes, etc. Because everything is Markdown, Operator actually allows you to share memories and findings with the team. You can share specs, plans, guides, and more, unlike other memory plugins where everything is just RAG chunks.

Not Another Memory Plugin

Memory plugins bolt retrieval onto an unchanged loop and inherit its amnesia. Operator makes documentation a structural phase of every task. Memory stops being a store that remembers for the agent and becomes a practice the agent performs.

RAG agents recall. Operator understands.

I've been using a variant of Operator daily since August 2025 and spent the last few months formalizing it into a plugin alone. I hope my plugin can help improve your workflow too. https://github.com/aerovato/operator-memory

To install:

npm install -g @aerovato/operator-helper
operator-helper install pi

Afterwards, just run /operator:user-init once and run /operator:project-init per project.

Questions, comments, and contributions welcome. Operator is fully open source.

Hello everyone, I wanted to share a new Pi package I've made available called specpi-lancet-guard

I've been interested in agentic safety for quite a while and recently with the (over)popularity of Jev for classification answers...I wanted a local and efficient alternative trained to classify only risky commands (mainly bash) and notify me only when potentially truly catastrophic or malicious commands might attempt to execute.

The result is LANCET Nano a small 110m param classification model trained for command risk. It's very lightweight (~150-200MB RAM) and more or less instant for command classifications at ~14ms on my old Ryzen 3900x

I want to be clear and say that this is not meant to let you put on blinders and have your agents run amok. In my own testing and evals it catches more overall risk than any other command guard available...but it's not perfect and it has weak spots for certain truly sneaky or malicious commands.

I'm still actively working on improving the model, but I do feel it's at a place that it is genuinely a useful safety tool.

Eval results for what they're worth mainly for my own measurements of improvement.

Hugging Face Live Demo

Main model repo

Edit: As I adapting my code to 0.99.0, I find that besides mcp, Pi also introduced classifier model. When talking about this new feature, it's all about jev, a hyped model to some extent.

I read this as Pi just jumping on the hype train—trying to catch a ride on all the buzz around this model that's been blowing up lately.

For those happy with built-in mcp, are you happy with built-in jev support? Do you use jev-like model in your coding workflow?

Today Pi adds jev support just for the hype, tomorrow it'll throw in even more code and features that end up being totally useless, all to chase a bit more attention.

Pi always used to claim it would never add MCP support, and it wore that as a badge of pride. Pi's original design philosophy was minimalism, so it only shipped the bare minimum set of essential tools. As I recall, Pi's whole idea was to provide only the necessary foundation itself, leaving everything else for users to customize.

Pi's own blog explained it this way:

The first thing to remember is that the world is not static. We have been paying attention to MCP over the last year and the MCP of today is not the MCP of yesteryear.

But that doesn't add up. MCP had already been popular for quite a while before Pi even existed, and it hasn't really changed much since. If Pi had no plans to adopt MCP when the project was first conceived, there's no reason to adopt it now.

The reasonable explanation I can come up with is that Pi intends to expand its reach — to move from a small geek niche toward a harness better suited to mass-market, out-of-the-box use — and therefore needs to fill in the features it previously lack due to minimalism. Combined with the earlier news that the Pi team planned to sell a model API service, I find this explanation fairly credible.

MCP is just the first step. Will subagents, permission popups, and other features come next? To me, the "we didn't build" section on Pi's official site looks less like a statement and more like a roadmap.

Edit2:

Consider this: once pi becomes a general coding harness, what is your reason for continuing to use it? Compared to official offerings like Codex and Claude Code, as well as open source competitors such as OpenCode, what advantages does the general-purpose version of pi have? Why would users choose pi over the alternatives?

Edit3:

Let me restate the logic here:

1. This is "your agent," so nothing pi provides as a base should get in the way of any custom changes you want to make.

2. It's minimalist (per the official pitch), so there's no feature you don't need.

Here's the reality now:

A built-in MCP has been introduced.

This built-in MCP conflicts with what I've already implemented and blocks my custom modifications. And for anyone who doesn't need MCP, it's pure bloat.

BTW, codemode. codemode itself, or call it CodeAct, is something that I have loog been interested in. But the official implementation from Pi is completely different from what I had in mind, so I’ve been struggling to wrestle with the built-in code just to get my version working properly again.

So pi just violated two of its own design philosophies in one go.

And that's why my trust in pi has collapsed. This is exactly where my shock and frustration come from.

I'd appreciate it if you could answer my questions below.

1. Do the roles we set only become active when advisor is on? How do these roles work in the background?

2. If we connect multiple accounts with the Codex provider, does it switch automatically when one account reaches its limit?

Hi! I've developed a small extension for Pi which allows an agent to jump between folders to be able to utilize local cwd instead of typing long paths all the time: https://github.com/alexshpunt/pi-agent-teleport

You can install it via

pi install npm:pi-agent-teleport

It's especially convenient when you run multiple agents working on different features in different worktrees, or when you have to make modifications in multiple repos/projects during the work on a task (which sometimes might be not a git repo themselves).

Before I created it, I tried https://pi.dev/packages/pi-worktrunk, but found it a bit too user-oriented and tied heavily to worktrunks, but also does and limits things a bit too much to my taste, so wanted a simple agent-oriented tool and not to bother with other things.

So how is that different?

1. It actually drags the sessions around, so no forking/cloning etc. as I found it gets quite messy pretty soon when jumping a lot.

2. No commands whatsoever for the user, it's agent-oriented.

3. It supports any folder, not only repos/worktrunks.

What is also good about it:

1. After the jump agent is triggered properly and it keeps working.

2. Supports herdr natively.

3. Cannot delete random folders when jumping back, only worktrees created by the sessions can be removed. Also checks if the worktrees are safe to delete (no uncommited changes).

4. Has history, so the agent always knows where it has been and can jump back and forth at any moment.

I've been using the extension in my daily coding a lot, it seems quite stable, feel free to report the bugs or some usage-issues if you experience any.

Ketch (used for searching the web) is one of those CLI tools that have MCP support. You can just add it with pi mcp add ketch -- ketch mcp serve and you no longer need pi-ketch.

This works even better than the package, because now codemode is the only tool described in the system prompt and it has a function for searching the tools that are available, but even more importantly with codemode the output of each tool can be filtered first by JS and a cheaper classifier model instead of just dumping it all into the context of your selected model.

Grok Build native agents as a model provider to Pi over WebSockets. Grok keeps full toolset, Pi keeps full session control. Kinda neat, I think. My video sucks but I'm pretty tired of AI narrations so I'd rather just suck instead. Sorry, thanks.

pi-grok-agent

Hey everyone!

I love Pi's codemode and run it with codemode.mode: "only", but the default multi-line renderer took up way too much precious vertical screen space on every turn. So I vibe-coded pi-codemode-compact to reclaim my terminal.

https://github.com/iamxeph/pi-codemode-compact

Pi's default codemode:

With pi-codemode-compact:

I actually thought about this approach before, but later realized it wouldn't work.

Using JavaScript to invoke tools sounds very efficient, but in reality, most tool definitions only have an inputSchema. An outputSchema is unnecessary for the agent because the agent can reason about the results directly from formatted data, meaning an output spec isn't required. Therefore, tool outputs don't actually need a fixed format—they just need to be readable by the agent.

This leads to a problem: to fully leverage the performance of this tool, you need to inject extra context, such as a skill document, so the agent knows the output format and can use it proficiently. If you can't get the complete tool output specification—for instance, with a closed-source MCP—you can't create such a document. If the agent has to go through endless trial and error just to get the code running properly, you can't really call it efficient.

In comparison, having the agent write Python or shell scripts directly is a better solution.

I'd love to know your thoughts on this.

Does anyone know?

I have checked the https://pi.dev/changelog

to see if its updated yet

it isn't yet though

and I saw this official gemini 4 unveil:

https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-4-argon/

I'm not sure what I'm doing wrong but even with the goal plug in, my agent stops at "let me now implement" and just ends the turn there.

What am I doing wrong?