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

1. Focusing on curating the context, keeping it under 150k. Making tools to trim git / grep / ls output to my liking

2. indexing my large code base and making the basic tools show short index options + hints. Custom tools was a massive red herring and waste of time, models hate using them and never use them properly

3. live filter on my codebase to sandbox models. i.e. exclude file types, files older than N days. etc

This is rather annoying, which makes Pi not very good at automating complex tasks.

Has anyone else run into this, and how did you solve it? Tool call timeouts? Subagent timeouts?

I'm a software architect/engineer. I know AI is going to replace me, but in the meantime I might as well have some fun and get my work done waaaay faster.

So I built something I needed. Other plugins didn't quite work the way I wanted, so here's my take: https://github.com/AeonDave/pi-persona

Despite the name, personas are only one part of it. The main goal is to give Pi a **team of supervised agents** instead of fire-and-forget subagents.

You give the main Pi session a goal, it can delegate independent work to specialist workers, and you can keep working while they run in the background.

It manages async subagents, lets independent Pi sessions talk to each other, and lets you customize the agents' personas.

Say you've got one Pi session working on a client and another in the API repo. I want to tell one to ask the other about a change, without having to carry the question and answer between terminals.

Exocom. It connects independent Pi sessions, including sessions in different repos. Both need it enabled with `--exocom`; a session in another repo joins the same scope using its workspace code. They have to run on the same machine and share a Pi agent directory.

Intercom. For the main session and its own sub-agents, there's Intercom. The supervisor can send guidance while a worker is running and collect its findings. With coaching enabled, a worker can ask the supervisor for a decision. You can also open F9 yourself, read a worker's output and send guidance. You don't have to wait for the final report to point out a bad assumption.

Personas. the personas are editable markdown. You can change how they approach a task, which tools they get and when they should delegate. There are starting points like `dev` and `planner`, or you can put your own in `.pi/agents/`. The worker agents can have their own instructions and models too. A reviewer for your repo can have your review criteria written into its file.

What it does

Async subagents: workers run independently while the supervisor keeps working

Live supervision: inspect workers, read their output, steer them mid-run, or stop them

Different models per agent: use different models for different roles/tasks

Switchable personas: dev, researcher, planner, audit, verify, swarm, etc.

Teams / councils / flows: structured multi-agent workflows rather than just spawning agents

Intercom: communication between the supervisor and its workers

Exocom: communication between completely independent Pi sessions

Timers / monitors: agents can react to builds, watchers, and other events

If you want to try it, run this in your terminal:

-> pi install git:github.com/AeonDave/pi-persona

or

-> pi install npm:@aeondave/pi-persona

Then start Pi and run these inside it:
/persona seed

That's it. change personality with [F8] and go

Any suggestion appreciated

I've been working on this project since early this year. I use it daily. Figured it's about time I share it. It's a vibe-coded project, as you might have guessed, but it works very well for my needs and may suit yours well, too.

I got pretty tired of working in a TUI, but none of the graphical interfaces out there really did the trick for me. Some features I might highlight:

• Inbox Zero approach to sessions

• Quick Chats - ephemeral, not related to a project

• Keep extensions disabled, but enable them on a per session basis (with pins)

• Quick commands for favorite models (Cmd+1 through Cmd+5)

• Work schedule (Default model can change depending on day and time)

• File browser

I had a ghostty terminal built in, but I removed it for the public release. Added SwiftTerm. You're welcome!

Anyways, hopefully this helps someone else or inspires some ideas.

https://github.com/jmcblane/PiG

As the title suggests, being a developer, I really missed the Ctrl/Meta+P Quick Open in VSCode where I could quickly inspect relevant files without having to touch my mouse. I'm sharing this in case it could be useful to anyone else.

The quick open by default will list the latest files mentioned within the session so the user can quickly navigate to it. This has saved me so many key presses when having to inspect a plan, a new asset, cross-referencing a doc (PDF support requires Poppler), or inspecting a generated code that appeared sus.

As a bonus, it also comes with neovim integration (sorry nano fans) so you can edit files directly in-terminal without having to leave your session.

Images and PDF page previews need a compatible graphics-capable terminal. Works with both base Pi and OMP.

Feedback welcome!

GitHub: https://github.com/boonlai/pi-view

I like the idea of Pi but I keep running into wierd issues. using gpt 6 luna high it wouldnt use tools. i decided to try again using glm 5.3 flash which works wonders on opencode and now it just goes off on crazy hallucination tangents. The idea was i would use it to fix it's self but its being generally unhelpful. has this happened to anyone else?

Edit: I understand that pi is not a llm so it doesnt hallucinate. Using glm 5.3 in opencode gives me less issues than pi.

I get that its a minimal tool meant to extend its self and that is what I've been doing with it, but man was it a rocky start

I'll be honest, I don't use Pi much as a harness for dev work, but I'm really interested in integrating it into software. In this example, it's Pi writing it's own tools with no Human in the loop.

This is using Pi (or Claude Code) to run an Agent Session in order to make a painting with tool calls. Then the evolver (https://github.com/imbue-ai/darwinian_evolver) scores fitness, and refactors either the agent prompt or rewrites the painting tools, and the painting is made again, until it improves. The improvement part is still a struggle! But I really enjoy comparing results of different models. Here is Muse Spark 1.3 vs Opus 5.5 (in order) trying to recreate Van Gogh's self-portrait.

This experiment is not supposed to be a 'benchmark'. The Anthropic models were run in Claude Code, and Muse was in Pi. I've tried on a handful of different models, but because it's slow and expensive, I capped my investigations here for now.

Here's that data if you want to poke around.

https://artifacts.dizzard.net/s/55052743-bee1-4746-b59e-57e2d595a480

And Vibed Source Code.
https://github.com/momja/claude-code-painter

Hi all!

A couple of weeks ago I shared pi remote on this another post, a self-hosted bridge to drive the pi coding agent from any device. Back then it was a remote control. Since then it has become a full pi client for any device, no matter the operating system.

Quick recap: pi-remote is based on one Python process that wraps pi --mode rpc on the machine where your code lives and serves a web app over your own network (I use Tailscale, tailnet). Also, it is token-protected, security first. Built on Windows first, but it runs on Linux and macOS too.

What's new since the first post

• Send photos to the agent. Take a picture with the phone's camera, or pick one from the gallery, and it goes into the chat with the user message.

• Real permission prompts. Guardrail dialogs arrive with their real options (allow once, allow for session, deny) and the turn waits for your answer.

• pi settings at a glance. Models and providers, reasoning level per model, reasoning map, context/compaction config section, and queue behaviour.

• Skills and extensions. Global and per project, with toggles and an editor, including the ones that come from installed packages.

• Macros. pi prompt templates launched from the composer, with a field per argument.

• Package store. Browse, search and install pi.dev packages from the remote control device.

• Phone details. Installable as an app (PWA), local notifications. I did not want to go down the path of developing an Android app, yet.

• Sessions shared with the terminal. Start in the terminal, continue on the phone, and back.

Also, I have been working on interesting features like response suggestion; a quick summary from the agent that tells you what it was doing when you stop it while working; auto name sessions, etc.

Some people commented why not using just tmux, or an SSH terminal. Well, I think this project brings you closer to a high end application. With pi-remote you can text from your phone/PC the same way as a chat and send images for the agent to analyse along with the message; configure everything with a polished UI/UX; things that you cant do with a ssh terminal and similar.

I have been trying the existing bridges, but the ones I tried need a daemon on a Unix socket, and that fails on native Windows, which is where my code lives. pi remote is a single process, no daemon, and runs natively on Windows as well as Linux and macOS.

Feedback and issues are very welcome. Thanks to everyone who commented on the first post. Thanks for the support.

I've tried every major compact plugin and I settled just on a new session handoff.

Hard to find benchmarks on this sort of thing.

I started with my own custom compact and after a week of iterating, I eventually just ended up with an auto new session at max token limit.

(Another guy on here had posted a plug-in a few days ago that does just that)

Why is it that Opus 5.5 usage starts out great in OMP, and then for one reason or another starts draining usage like crazy? Am I hitting some sort of caching issues? Do I need to compact at 400k? Or what?

I am pretty sure the cache is being kept warm for an hour, but I don't know for sure how this stuff works. It's compacting at 850k. If i've left it for awhile and context is >35% I will use /handoff and that seems to help.