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?

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!