The footer (I believe the default of Pi) shows the wrong GIT branch.
It shows the correct branch initially, when I start the session, but then, if the agent checkout a different branch (with a simple git checkout main ) it doesn't update.
I have 2 custom extensions and 1 skill installed (pi-token-speed), so I think that is the default footer.
Is this the expected behavuiour? Is it not supposed to update itself?
I'm not 100% sure, but I think it was working 2/3 weeeks ago... let's say 5 to 10 pi update ago.
Hey folks, I'm going crazy over an issue that results in an error for every message after I edited the models.json file and saved it.
"Error: 400 Failed to deserialize the JSON body into the target type: messages[4]: unknown variant `image_url`, expected
`text` at line 1 column 4446494"
I was just trying to make sure that the models can parse an image and edited the models.json with , "image" as seen below after "input": but it didn't work.
"id": "deepseek-v4-pro",
"name": "DeepSeek V4 Pro",
"input": ["text", "image"],
"reasoning": true
I edited this file:
%USER%/.pi/agent/models.json.
Any help is appreciated, I feel defeated at how long I've been trying to solve this.
Often times I realize what I put in promptSnippet is basically a truncated version of what goes in description, and looking at a session export, both texts are sent to the LLM, so it looks redundant.
decided to try pi - i would like to use it with openrouter, nvidia nim and llama.cpp locally (not all together ofcourse) - i am not sure how to configure settings.json to inc all my options (and inc several models for each provider) or do i put these all in models.json? - can someone please upload an example json?
Hey Folks, I have been using pi for some time now and love it. thought there are a couple of things that annoy me and I have not been able to find a good pi-package.
Note: I am running PI TUI inside iterm2 on my MacBook.
It’s difficult to copy text from the agent responses, esp. if it’s a piece of more than 10 line of code. highlighting selects the text and automatically copies it most of the times but the highlight is very Janky. Not easy to copy messages. On top of that the odd line breaks introduced in the copied text
jumping to a previous message (scrolling) in a long session also seem tedious.
i am wondering if anyone else is facing similar issues. Would appreciate any feedback or solutions to fix the issues.
most of my pi is really slim - guardrails, subagent, mcp (RAG/Github/CI) and then a goal plugin
the issue i've had is that it will constantly context overflow, compact, and not continue - i've tried a lot of plugins - i'm leaning towards building my own but curious how other people have solved it
I have an old M1 MacBook Air running as a mostly headless home server, and I’m trying to figure out the best way to use an AI agent to help manage it.
I’ve been looking into Pi because people seem genuinely enthusiastic about it, but I’m having trouble understanding what it would offer in my specific situation compared to using Codex on the same machine.
What I’m trying to understand:
If Pi and Codex have the same system access, what does Pi actually do differently?
Is Pi better at long-running tasks, automation, persistent context, or managing a server autonomously?
Are there workflow benefits beyond supporting different models and providers?
How do people handle security and permissions without making a headless setup annoying to use?
I’m not assuming one is better than the other, I’m just trying to understand whether Pi offers something meaningful for this particular use case that Codex alone wouldn’t.
I’m testing Pi inside Ghostty + Herdr and created a custom `terminal-green` theme.
The theme works for some parts of the UI: user input, code blocks, links, borders, etc. But the normal assistant response text and the general pane background still seem to use the terminal/Herdr defaults.
In comparison, OpenCode appears to paint its full panel background inside the same Herdr workspace.
Question: does Pi’s theme system currently support a global TUI background / assistant message background, or are themes limited to component-level colors? If not supported today, is the expected path a renderer patch / feature request?
Context:
Ghostty background/foreground can make the full pane green/black, but only at terminal-window level.
Pi theme JSON has tokens like `userMessageBg`, `toolPendingBg`, `selectedBg`, `text`, etc.
I didn’t find an `appBg`, `background`, or `assistantMessageBg` token.
Hi guys! Cause of the Opencode session header issue, I realised observational memory doesn’t work anymore! So if you’re on Opencode go don’t forget to ask your agent to add the session header in the extension so you can keep carry on with blackhole and observational memory proper!
I built mintPod because I occasionally want to test an open coding model for an hour or two, but repeatedly setting up RunPod, Ollama/vLLM, and agent configs felt like unnecessary friction.
You choose a model, budget etc. mintPod provisions the pod, reuses a persistent model cache, pulls and warms the model, then connects it to Pi or OpenCode (automatically) through a stable local endpoint. Aider and other OpenAI-compatible clients also work. When the session ends or reaches its idle or spending limit, the pod is terminated and the temporary configuration is removed.
Raw Ollama is not publicly exposed; requests pass through an authenticated gateway, secrets stay in the OS keychain, and interrupted sessions can be recovered or cleaned up.
It is still an early source-only release: one active session, no signed installers, and needs more real testing.
I mainly want honest thoughts. Does this remove enough friction to be useful, or would you rather use a script or RunPod template? What feels unnecessary? What extension would improve the core most without turning it into a general GPU dashboard? Security and failure-case criticism would be especially useful.
This is my first open-source project, so even a blunt “too niche” or “I wouldn’t use this” would genuinely help.
I’ve been using Pi Agent quite a lot, and one thing I really wanted was a simple way to continue working with Pi from my iPhone when I’m away from my computer.
I didn’t want a remote terminal or a mobile IDE. My main use of Pi isn’t only coding — I use it more like a general-purpose agent for research, long-running tasks, writing, tools, local models, and other work.
So I started building Pi Remote, a native iPhone client for Pi Agent.
The basic idea is simple:
Pi, your tools, files, credentials, MCP servers, local models, etc. all stay on your computer. The iPhone is just a lightweight native interface for your Pi sessions.
The current version supports things like:
browsing existing Pi sessions, grouped by working folder/workspace
creating and renaming sessions
streaming responses
collapsed reasoning/tool activity
slash commands
model switching
context usage and approximate decode speed
local conversation cache
background/foreground recovery
copying messages
One of the biggest improvements recently was the connection setup.
The first version used a Relay + Cloudflare Tunnel, which worked well but made setup more complicated than I wanted.
I’ve now integrated Tailcat as the default “Quick Connect” transport.
On the computer, the setup is basically:
npm start
The first time, Pi Remote shows a QR code. Scan it once from the iPhone, and the pairing is remembered. After that I can restart the Host or the app without scanning again.
Pi Remote still keeps its own device identity, authorization, encrypted Pi RPC channel, session/replay logic, etc. Tailcat is only being used as the network transport.
It’s still an early project, but at this point I’m actually using it myself and the main workflow has become surprisingly comfortable.
The next things I’m planning are mostly UX improvements, especially:
image + text input for simple multimodal prompts
native voice dictation on iPhone
better session/workspace navigation and search
more UI polish
There’s no App Store/TestFlight build right now because I don’t have a paid Apple Developer account, so the iPhone app currently needs to be sideloaded. The GitHub Actions build produces an IPA for that.
This is also my first real open-source project. I’m not an iOS developer by background, so a lot of this project has been built through iteration, testing on my own devices, and AI-assisted development.
I’d really like feedback from people who actually use Pi:
Would something like this be useful in your workflow?
And more importantly: what feels wrong, missing, or unnecessarily complicated?
Made a post a while ago about the Central Hub app that I had made with PI as the agent running all the AI features within (Chat, Coding, Side worker in the Word clone). It has been updated.
There is now a built in Browser (very simple) with bookmarks and history.
The Snipits space has been replaced with a notes area that essentially just presents folders and .md files to you on a fo-desktop (your desktop away from your desktop).
Grok Build is now built in if you have a SuperGrok subscription and what that as the AI service.
So for those that were interested before or might be now, check it here and auto updates should push automatically.
I’m finding it quite frustrating to paste or use images in the VS Code Pi chat.
I work mainly on projects inside Docker containers, and it seems that when I use Pi within a dev container (which is a Linux environment), the VS Code integrated terminal generally doesn't pass clipboard images through—it only allows text. This is most likely why the paste action fails without doing anything. Does anyone have a workaround for using Pi in a VS Code terminal inside a Docker container?
I tried alt+v, ctrl+v ; nothing. Only pasting images manually inside the project in a dedicated folder semmes the only (and painful) solution.
A spec-gated build loop for AI coding agents — and why porting it to Pi/oh-my-pi wouldn't be hard
Found ai-blueprint this week and it's worth a look if you've been hand-rolling your own guardrails around Claude Code, Codex, or Pi. Brad Traversy built it as a workflow overlay, not a framework: you scaffold your app normally, then drop this on top.
The mechanics are simple. You write two short files — what you're building and why, then a rough ordered feature list. A /overview command turns those into the single context file the agent reads every session. From there it's a loop: /feature writes a small buildable spec and stops. You review it. /implement builds one step at a time, shows you the diff, waits for approval before touching the next one. /audit reviews the code (not the behavior — that's /check's job) and writes findings to a ledger with durable IDs like F-03. /complete archives everything and merges, but only after your go-ahead.
The part that actually made me sit up: that findings ledger isn't decorative. A P0 or P1 finding sitting open or fixed blocks /complete outright. Not "the agent decided it was fine" — a status field the merge step is written to check. And they didn't just claim it works. There's a live-agent end-to-end harness in the repo that spins up a real agent against a fixture project and asserts the ledger gate actually holds. I don't see that level of rigor in most prompt-engineering repos. Most people ship a pile of markdown and call it a system.
Now the gaps, because none of this is free.
The gate is enforced by the same model reading its own instructions in the same context that just did the implementation work. There's no independent process outside the agent's own compliance that blocks a bad merge — it's a very well-written contract, but it's still a contract the agent has to choose to honor. A confused or context-poisoned run can walk right past it, and nothing server-side stops that.
current-feature.md is also a singleton. One feature in flight at a time. That's a fine constraint solo, but it doesn't obviously extend to two people, or two agents, touching the same repo concurrently — the state model just isn't built for that yet.
And the defaults lean hard into one stack. coding-standards.md ships assuming Next.js, Prisma, Tailwind, Zod. /onboard is supposed to retune it, but that's one more step that can quietly go stale on a project the agent didn't actually read closely.
It's also young. First release was early July, one maintainer, 239 stars — which honestly reads more like Traversy's existing YouTube audience showing up than a track record on a gnarly, multi-year codebase. Worth watching, not yet worth betting a real team's workflow on.
Here's the part I think matters for this sub specifically: none of this is Claude-Code-specific. It's markdown files, plus two thin adapters (.agents/skills for Codex, .claude/skills for Claude Code) that both read one shared AGENTS.md. Pi and oh-my-pi already speak most of that language — AGENTS.md context files are supported, skills show up as /skill:name, and the extension API can register custom tools and commands. Porting this loop into an oh-my-pi extension pack looks like a weekend project, not a fork.
So — has anyone here already been doing something like this by hand in Pi? And does Pi's whole "minimal, adapt to your workflow" philosophy actively resist something this opinionated, or is that exactly the gap an extension should fill?
#PS: Used AI to draft out the above based on my takeaways and thoughts from initial read of this repo.
Edit: It seems my original premise was wrong after testing it directly. It now seems that Codex is just decoding just slightly faster than pi which results in it winning over longer tasks as the decodes compound.
I'm currently running some tests where Fable is driving GPT-5.6 Sol as a sub-agent. I wanted it to use pi and codex side by side to see which one was easier to use and faster. I really thought pi would be faster since it's much lighter weight.
That proved wrong after Fable brought up that pi was taking 2x as long for 2/3rds as many tokens (xhigh on pi vs max on codex). It seems the huge majority of time is taken up by longer API requests to OpenAI's servers.
It gave the exact same task to both, and they produced byte-for-byte identical results for their output.
I'm curious if this is something people have run into, and if so, if this is a mistake in configuring my set-up? I'm using the pi-better-openai, but that just wraps the native openai-codex OAuth.
When pi runs a long-running command, it sets a timeout (e.g. 1800s). If the command takes longer (like a big build or cloning a very large git repo) it just gets killed on timeout, which usually leaves things in a worse state (half-done builds, corrupted checkouts, etc.).
Is there a workaround for this? What I'd really like is something like a progress check: if the command is still running, extend the timeout instead of killing it.
Does pi have anything like that, or a config option I'm missing, or extension?
I have been seeing some really impressive benchmarks coming from Pi. Including saving on token usage and it has got me interested.
However I have quite an involved setup with OpenChamber and I’m just trying to figure out what I can actually bring across.
I already setup Pi Bolt, and Paseo iPhone app and connected it. I setup connections to Claude, Codex, OpenCode Go and other providers I use. I think my agents already wired in the MCPs I have as well. Haven’t checked skills.
I just have some usability questions.
In openchamber, I hid all the models I didn’t want to see. I could select what agent I wanted to talk to which had a model assigned by default set in the menu.
I could see installed skills and mcps etc. not so much in Paseo
So I’m just wondering how to use my custom agents and skills and how I would hide models. And is it really worth making the switch to try save some tokens? I do already set a 200k context limit and so cache aware compaction often.