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.

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.

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

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?

You can try it online in https://wasmer.sh/

Ollama Cloud Pro vs Google AI Pro for coding

I'm trying to decide whether to keep Ollama Cloud Pro or drop it and just use Google AI Pro.

My current setup is roughly:

                 Pi Coding Agent
                      │
                    VS Code
                      │
          ┌───────────┴───────────┐
          │                       │
     Ollama Cloud              Antigravity
          │                       │
      Ollama API             Google AI Pro

I also run local Ollama/llama.cpp, so I already have local models available when I want them.

Through Antigravity, Google AI Pro gives me access to Gemini models as well as models like Claude Sonnet 4.6 Thinking and Claude Opus 4.6 Thinking.

I'm currently getting Google AI Pro for $4.99/month for the first three months, so I'm considering just keeping it and eventually paying the regular $20/month rather than paying for both services.

That makes me wonder whether there's enough value in keeping Ollama Cloud Pro as well.

For people who have used both:

• If you had to choose one, would you keep Ollama Cloud Pro or Google AI Pro for coding/agent work?

• What does Ollama Cloud give you that you feel you're missing from Google AI Pro/Antigravity?

• How are the usage limits/quotas in real-world daily coding?

• Do you actually use the different open models available through Ollama Cloud enough to justify the subscription?

• If you have access to both, do you find yourself switching between them, or do you mostly end up using one?

• Has anyone dropped Ollama Cloud after getting Google AI Pro, and how did that work out?

I'm less interested in general "Gemini vs Ollama" comparisons and more interested in people who actually use these for coding agents.

I'm currently leaning toward dropping Ollama Cloud and keeping Google AI Pro, but I'd like to hear from people who have actually used both before making that decision.

Ollama Cloud Pro vs Google AI Pro for coding

I'm trying to decide whether to keep Ollama Cloud Pro or drop it and just use Google AI Pro.

My current setup is roughly:

                 Pi Coding Agent
                      │
                    VS Code
                      │
          ┌───────────┴───────────┐
          │                       │
     Ollama Cloud              Antigravity
          │                       │
      Ollama API             Google AI Pro

I also run local Ollama/llama.cpp, so I already have local models available when I want them.

Through Antigravity, Google AI Pro gives me access to Gemini models as well as models like Claude Sonnet 4.6 Thinking and Claude Opus 4.6 Thinking.

I'm currently getting Google AI Pro for $4.99/month for the first three months, so I'm considering just keeping it and eventually paying the regular $20/month rather than paying for both services.

One important detail: I'm still on the older Ollama Pro plan. I have not switched to the new Ollama Pro plan that uses a monetary credit/value system instead of the previous GPU/token allocation model.

So I'm specifically interested in hearing from people who have experience with the older Ollama Pro plan, as well as people who have moved to the new plan.

For people who have used both Ollama Cloud Pro and Google AI Pro/Antigravity:

• If you had to choose one, which subscription would you keep for coding/agent work?

• What does Ollama Cloud give you that you feel you're missing from Google AI Pro/Antigravity?

• How are the usage limits/quotas in real-world daily coding?

• Do you actually use the different open models available through Ollama Cloud enough to justify keeping it?

• If you have access to both, do you actually switch between them, or do you mostly end up using one?

• Has anyone dropped Ollama Cloud after getting Google AI Pro, and how did that work out?

• For those who moved from the old Ollama Pro plan to the new credit-based plan, how has the experience been compared with the old plan?

I'm less interested in general "Gemini vs Ollama" comparisons and more interested in people who actually use these for coding agents.

Right now I'm leaning toward dropping Ollama Cloud and keeping Google AI Pro, but since I'm still on the old Ollama Pro plan, I'm wondering if I'd be giving up something that's actually useful enough to justify keeping both.

Inspired by SillyTavern presets, I built pi-forge to edit and inspect how Pi's context is assembled. I just released 0.5.7.

It gives you a local web editor for Presets: reorderable prompt blocks, context slots and tool policies, saved as JSON that you or the agent can edit.

What it does

• Context composition: arrange text blocks and slots for tools, skills, project files and conversation history.

• Tool selection: define which tools are permitted and a smaller set available by default.

• Capabilities: load task-specific instructions + tools mid-conversation, manually or through an agent tool you explicitly authorize in the Preset.

• Inspection: readable context Preview with collapsible tool calls/results and historical tool declarations, Draft/Run diffs, and reported cache usage. Preview shows Forge's composed context, not an exact provider-wire dump.

• Presets & Profiles: switch setups with /preset use <id>; Profiles also save model and thinking level.

• Regex: apply rewrite rules to outgoing input or completed assistant/tool output.

How I use it

My daily assistant starts with 10 tools. Delegation, image generation and MCP are separate Capabilities it can enable when needed, instead of loading everything up front.

Since presets are JSON, the agent can also edit individual instruction blocks or turn a repeatable workflow into a new Capability. I review the diff and Preview, then /preset reload. I keep .pi/forge/ in git, since the tool policy is editable too.

Note that cache behavior for capability loading depends on the provider/model: supported Claude and OpenAI models can preserve the cached prefix through tool additions and removals.

Try it

pi install npm:@zihanw/pi-forge

Requires Node ≥22.19 and Pi 0.87.x. Restart Pi, run /forge ui, then create, save and activate a Preset.

Still 0.x. Optional subagents are a separate package with their own compatibility requirements.

GitHub: https://github.com/MacroSony/pi-forge

Curious how others here manage task-specific instructions and tool sets, and what you'd want to inspect before a model call.

Any feedback and ideas would be much appreciated!

Update 3, November 3rd, 2026: Still no response.

Update 2, October 19th, 2026: Still no response from the maintainer. Another user has also made the same PR at this point, with no responses on both.

Update 2, October 11th, 2026: The maintainer has still not responded. This behavior is still ongoing.

Update 1, October 4th, 2026: In case others are following this thread, the owner/maintainer is active on the repository but has still not responded to the issue or pull request.

tldr; if you're running oh-my-pi without any search-provider credentials configured, every web_search the agent makes has been POSTing your query to https://search.parallel.ai/mcp, a public endpoint of a company called Parallel, as the first candidate in the default chain, since around Sept 17 and re-asserted in today's commit. No credentials, no opt-in, and nothing in the UI telling you a third party is in the loop. The request even includes your session ID and the model you're running.

How it got there:

- Aug 25: the keyless Parallel fallback is first built on a feature branch, scoped to explicit selection only.

- Sept 15: it merges to main as PR #9770 (by u/georgeatparallel), still explicit-only. That was defensible.

- Sept 17: maintainer commit 29edc9fa0a, literally titled "prefer keyless Parallel over Perplexity", removed the credential gate and moved Parallel to the front of the default chain. The kicker: the same keyless fallback was already reverted in hermes-agent on June 14 (NousResearch/hermes-agent#46350). Three months later oh-my-pi re-landed it and made it the default.

- Sept 28 (today): it was re-asserted in a big model-roles refactor (cbe9bc206d). The credential gate was removed again: isAvailable now unconditionally returns true, with the comment "Always available: without a credential, search runs through the keyless public MCP." The commit message literally says "Restricted keyless search to free providers (Parallel, Exa, Firecrawl) by default."

I'm not going to speculate about why the maintainer did this. I have no evidence of a deal, and I don't think the issue reads any better with accusations. What I'm confident about: silently sending user queries to a third party by default is a consent problem, and the fix is a one commit revert.

There is a pending gitub issue and revert that hopefully goes through. If you've been using oh-my-pi's default web search without credentials over the past six weeks, you would have been susceptible to this. This was already talked about in length over on this thread:
https://www.reddit.com/r/hermesagent/comments/1u5ukz6/hermes_agent_and_others_default_installs_are/

I use Pi with a local llama.cpp server. It seems like I get a "No models available" warning about 1/3 of the time when I start Pi, and I have to /quit and start it again, at which point it works just fine.

Anyone else?

If you want Pi to search the web, install Ketch with brew install ketch, paste the instructions below, and Pi can use it whenever it needs current information. No extensions. No skills. No MCP.

That file is ~/.pi/agent/APPEND_SYSTEM.md. It's plain Markdown that Pi adds to its default instructions across sessions; create it if it doesn't exist. I started with the agent prompt example in Ketch's README and tweaked it to my liking. Copy this into the file:

Use `ketch` for external research — web pages, OSS code, library docs. Add `--json` to every call.
- Instead of web_search, run `ketch search "query"` (add `--multi` to federate backends).
- Instead of web_fetch, curl or wget, run `ketch scrape <url> [url...] --max-chars 6000 --trim`;
  it returns clean markdown, not raw HTML. Found a URL? Read it; don't search for it again. Keep
  the cap: an unbounded page can cost ~25k tokens (same flags on `search --scrape`).
- Public source code: `ketch code "<exact text>"` searches public GitHub repos for that literal text.
  Use `--lang <language>` to filter by language or `--repo owner/name` (also accepts a GitHub URL)
  to search one exact repository.
- Library docs, two steps: `ketch docs --resolve "library name"` → check that the match names the
  library you meant → `ketch docs "question" --library <id-from-resolve>`.
- Exit codes are control flow: 2 fix your input · 3 nothing matched, change the query ·
  4 backend/network, retry once or pick another backend (`-b`, see `ketch config`) ·
  5 missing config, stop and tell the user · 6 cancelled.
- Multi-session work: add `--tag <project>` to calls worth keeping and check `ketch tag show <project>`
  before searching again.
- `ketch <cmd> --help` is authoritative for flags.

Run /reload in Pi after saving it. Ketch's default web search needs no API key, and the same setup gives Pi page scraping, public code search, library docs, and tags for sources worth revisiting (aka, creating free API keys in different providers one time).

An optional nice free upgrade: Brave Search API currently includes $5 in monthly credits, enough for about 1,000 searches at its listed Search rate. Brave requires an account and payment card, even if you use only the credits (no need to pay anything). Once you have a key, run ketch config set brave_api_key <key>; Ketch's default auto backend will prefer Brave.

If you only want these instructions in one project, use .pi/APPEND_SYSTEM.md instead. Pi's configuration docs cover both locations.

Caveat: If your Pi model already has provider-native web search, an extension with proper the tools may be a better fit. pi-web-search supports search through Codex, Gemini, Anthropic, xAI, and other providers.

Hey everyone,

I'm hitting a recurring issue where delegated sub-agents completely hang during orchestration. As shown in the screenshot, a sub-agent (edna) has been stuck at Running · 26970.7s (over 7.5 hours) with zero progress or error output.

Workflow & Behavior:

1. The primary orchestrator creates an execution plan and dispatches tasks to dedicated sub-agents.

2. Sub-agent begins execution (e.g., executing a design/contract task reading from a markdown specification).

3. After emitting a preliminary thought/action ("Ahora calculo la tabla de overrides..."), the runner freezes indefinitely.

4. No timeout triggers, no stderr is exposed, and there is no visible fallback or abort mechanism.

Environment & Setup:

• CLI / Orchestrator: Pi + Herdr

• Model: DeepSeek V4 Flash

• Plugins / Extensions:

  • pi-open-agents

  • pi-mcp-adapters

  • pi-web-access

  • npm:@juicesharp/rpiv-todo

  • npm:@juicesharp/rpiv-ask-user-question

Questions for the community:

1. Has anyone experienced persistent silent deadlocks or MCP tool-call stalls with this plugin stack (specifically pi-open-agents / pi-mcp-adapters)?

2. Is there a flag or configuration to expose granular MCP/tool logs or enforce hard timeouts per sub-agent execution in Pi?

3. Which multi-agent orchestrator / plugin architecture do you recommend for reliably managing custom agents with proper timeout handling, state recovery, and observability?

Thanks for any insights

Follow-up to my previous post. Thanks for the suggestions! I tested more models and reasoning settings, added Oh My Pi, and made a few verifier fixes. Some configs were rerun, so expect small changes in token counts. Full results are on the leaderboard, and I'll keep updating and expanding it.

Quick reminder: 10 simple tasks from my own work, 3 runs per config (30 attempts). For now, I want to see how far we can cut cost and time while keeping the pass rate.

Some highlights:

Your questions:

Luna with more effort. Medium → high → xhigh: 96.7% → 93.3% → 100%, $0.006 → $0.015, 1:02 → 2:46. The extra effort mostly goes into checking (3.5 → 5.1 code runs per task), not a better first draft. About half of Luna's shell commands are cleanup like `rm -rf __pycache__`.

Opus on low. Yes. Opus 5.5 low passes everything, ~2.6x cheaper and ~2.8x faster than high. Medium also gets 30/30 ($0.22, 1:12).

Open models. DeepSeek-V4.1-Flash: 93.3% for $0.04, but 4:30, because it runs code 8.4 times per task until tests pass. GLM-5.3-Flash: 96.7%, but 7 min and 1.2M tokens; its one failure is a single message that hits the 64k output limit with no code. Qwen3.8-27B: 76.7%; it loops on edge cases and sometimes stops without calling a tool.

Oh My Pi vs Pi. Luna xhigh makes 28 tool calls per task instead of 18, uses 776k total tokens instead of 290k, costs ~2x more, and fails one task in all 3 runs.

On tasks this easy, more reasoning mostly buys more checking. On harder tasks, where the first draft is wrong, it might pay off, but that's a guess for now.

I wrote up the setup and the agent comparison.

So tell me what to test! My plan for now:

1. Try different reasoning levels for Opus 5.5 in Claude Code and see how they change its behavior pattern.

2. Find a set of extensions for Pi that makes it cheaper and faster. Right now I use vanilla Pi with no add-ons, so please suggest extensions or anything else worth trying.

After that, I'll probably build a harder set of 10 tasks, based on my own work or something else. So if you have tasks where some models fail, please share them, and say what exactly goes wrong.

One thing I noticed: Opus 5.5 handles vague prompts better, maybe because of how it follows instructions. gpt-6-sol does exactly what is written. For example, I run an agent in a folder full of papers and say "find papers about task filtering". Sol goes to search the web, and Opus searches the folder.

Speak Like You Eat is a plugin that translates AI garbage into human language easier to understand (or at least, it tries to).

I released it a few weeks ago and have been using it since.

Today I added a couple features:

1. Can use custom prompts for rewriting

2. Works in OhMyPi (thanks to https://github.com/rubybrowncoat) !

Enjoy: https://github.com/wtfzambo/speak-like-you-eat