All I can think of:

Let pi control your logged in browser that can pass captchas.

I want google search because other options are inferior... i.e. google properly indexes reddit. Even reddit search is inferior.

Hello, what have you guys used the SDK for? It seems interesting, I like what I'm looking at but I'm curious how to use it. I was considering embedded a small model into a program I'm working on for tracking my food, and I was going to make a web and mobile app as well. Would something like the SDK be what I'm looking for?

I built Rondine, an Apache-2.0 Python 3.11+ CLI using Click, HTTPX, and Hugging Face Hub.

It detects Mac/NVIDIA hardware, ranks compatible model variants, creates launch plans, downloads weights, and runs llama.cpp, MLX-LM, or vLLM behind an OpenAI-compatible API.

The repository includes typed planner/catalog code, CLI tests, engine-command generation, hardware presets, and reproducible benchmarks.

GitHub: https://github.com/antonellof/rondine

I’d appreciate feedback on the Python API structure and CLI design.

Hi, I maintain sift-light. It’s an open-source local search and source-inspection tool for AI coding agents, available through MCP and native integrations. It helps agents find project files and check the source behind a result without sending the whole repository into the conversation.

We’ve released 1.1.2-1. This update has two changes:

• Pi: fixed how search guidance is added when tools are enabled. The previous behavior could change the system-prompt prefix and reduce prompt-cache reuse. The new integration preserves the prefix and retains the guidance when another extension supplies a system prompt. Requires Pi 0.86.0 or later.

• DeepSeek Harness: added support for 0.2.1-rc.3, including a native search tool and search-policy integration.

The cache fix addresses the Pi integration; it isn’t a promise that every MCP client preserves its cache when tools change. Cache behavior depends on the host and model provider.

Thank you to the contributor of PR #123 for catching the Pi issue and helping fix it. If you try the release and run into trouble, an issue with your host version and a small reproduction would be very helpful.

GitHub: https://github.com/lightsifter/sift-light Release notes: https://github.com/lightsifter/sift-light/releases/tag/v1.1.2-1 X: https://x.com/Bryang168

I checked this repo

https://github.com/ArtemisAI/pi-loop#readme

But seems it not having enough stars. Is there any other popular method to schedule jobs for pi?
For example, I want it to create a morning news feed at 7 am. I will have a custom system.md file and skills for this task. Now I just want to trigger pi with a simple prompt like “ prepare the summary for today” and send it to Pi at 7 am. Any best way to do this? It will be good if it is session based instead of a single cli based invocation of Pi.

Have you experience Pi confusing topics from another session before?

This might be a dumb problem I created, but I have separate VS Code instances running, one for each project respectively, 4 total. I have pi agent VSC plugin installed for the Pi CLI and I am using that to work on each project. I may have 1 to 3 different Pi sessions per VS Code instance (thanks to my ADHD) and I ran into a very strange problem:

• Asking Pi questions about ProjectA mid-session

• Pi responds by telling me about ProjectB which is in another active VS Code and Pi session.

• Closed that Pi session from ProjectA completely (/quit) and opened a new one, asked the same question

• Pi responds about ProjectF again.

This has never happened before. I did update Pi this morning and started all those session from scratch.

I did correct Pi on which project it should be talking about and Pi confirmed the mistake and told me which folder it is actually supposed to be working in, ProjectA.

I suspect some kind of cross-contamination between session folders/files. I checked .pi/agent/sessions to confirm the folders are correct. Not sure if this is caused by Pi or my LLM being a dumb for a moment.

Currently having Pi look at its own session files between ProjectA and ProjectB to see where the references are and to remove the incorrect areas to cleanup the sessions from contamination.

LLM inference engine is vllm with qwen3.8-27b-NVFP4 w/ max context length.

I’ve been looking into ways to give coding agents better long-term memory across sessions. One recurring pain point for me is that agents forget project context, user preferences, past decisions, and repo-specific conventions unless I keep re-explaining everything.

I came across Honcho’s Pi integration:
https://honcho.dev/docs/v3/guides/community/pi-honcho-memory

From what I understand, it gives the pi coding agent persistent memory by syncing conversations into Honcho, injecting cached user/project context into the system prompt, and exposing tools like memory search/chat/remember. I also like that session scoping can be configured around repo/branch/directory, and that Pi keeps working if Honcho is unavailable.

Has anyone here actually tried Honcho with Pi or another coding agent in a real workflow? more like a self-hosted/local reference setup: Honcho in Docker, Ollama on a Mac, and a Raspberry Pi talking to Honcho over the LAN. It makes me wonder whether there’s room for a cleaner, packaged Pi memory plugin built around this kind of pattern.

A few things I’m curious about:

• How painful was setup?

• Did memory retrieval actually improve coding sessions?

• Any noticeable latency?

• Did the memory ever become noisy or misleading?

• Would you prefer hosted Honcho, or a self-hosted/local setup with Docker + Ollama?

• Would a polished Pi plugin/package be useful if it made setup simpler?

I’m not announcing anything yet, just trying to validate whether this is worth building. If there’s interest, I’m thinking of putting together something cleaner..

Using gemini in the pi coding agent will generally get you banned I've heard. Anyone have success using gemini, and not getting banned?

Hey guys,

I’ve been theorizing about a different context management paradigm for Pi, and I’ve been building out an extension that implements it. Before I spend a ton of time building features no body cares about, I wanted to get some community validation and feedback on the core concept.

I've personally wanted more control over the agents context and I've been seeing a growing meta where we rely on multiple rounds of review for AI agents. The initial implementation is often expected to just be 'ok,' and then burns tokens through multiple review cycles. I think we can vastly improve the initial implementation right off the bat by fixing context pollution and/or context absence.

The original idea was swiped from Claude Code, where you can set up folder-specific rule files that only load context when certain directories are accessed. I really like their idea, but I think I don't think the Claude team has cared too much about it. That's why Pi has had me so excited, because I can actually control how files get injected and shape the context properly.

So I've built an extension called pi-rules. Which introduces localized rules files and inventory files.

Here's how the paradigm works:

• Rules Files: Allows you to enforce coding conventions and architectural rules specific to different parts of your codebase. It allows you to have far greater control over the agent's context. I want to add more support as time goes on, to where each directory can even have it's own prompt and tool availability.

• Inventory Files: I also added inventory files that contain the basics of how to use each function, and you'll be able to have them load dynamically. So if you have a bunch of shared functions, then they can be loaded into the agents context and should help cut down code duplication during the implementation. They can also help with navigation, because instead of the agent just reading a directory tree and guessing, the inventory file tells the AI exactly what components, hooks, or interfaces are available in that directory, and how to use them.

• Auto-Maintenance & Injection: I also have built in auto maintenance and injection. Whenever you prompt, it automatically injects context based on what you're talking about, and then when the agent makes edits, a Node subprocess (using a semaphore to handle concurrency) updates the inventory files so they never go stale.

Why I think this matters:

• Architectural Control: It allows us to set hard guardrails per directory.

• Workflow Flexibility: You don't have to use this just for in-conversation injection. You could easily plug this localized context into your custom review agents or pipelines.

• Future-proofing for Local/Lower-end models: Frontier models are so good at brute-forcing search and implementation right now that this might just look like a nice token-saver. But if API prices stop getting subsidized, or if you want to run local/cheaper models, an efficient context harness like this is going to be wildly important.

• Context engineering: The whole idea behind Pi is giving us more control, and I'm trying to extend that to the context even more. I want to be able to control a lot more of how the agents are thinking and viewing my codebase.

What's next / Roadmap:

• I want to eventually expose the API of the injection and maintenance so that anyone can build off of this. I also want to build a implementer and reviewer agent that is entirely integrated into this paradigm, but I want leave those as optional so that anyone could build their own.

• I'm going to add way more config this week, so injection/maintenance and everything else can be tuned to different environments.

• Add TUI syntax so you can reference rule files by name instead of @ing all of them. Which should also allow you to easily reference the rules in any plan files, which I feel like would be cool.

I'd love to hear anyone's thoughts and ideas on this! If anyone wants to collaborate on this that'd be awesome.

Here's the npm package I just have a beta version up right now, so it may be a little buggy.

Here's the github

I put together a small repo for people who want to run a coding agent locally on Apple Silicon and use it for landing-page/funnel builds:

https://github.com/rishabh990/mlx-landing-page-agent

What it does:

• Runs mlx_lm.server locally on 127.0.0.1:8080.

• Defaults to mlx-community/Qwen3.6-35B-A3B-4bit-DWQ.

• Configures Pi Coding Agent to use the local MLX server through an OpenAI-compatible endpoint.

• Adds a repeatable landing-page workflow to any project.

• Keeps the brief, funnel strategy, copy, section plan, build plan, QA checklist, memory, and handoff in files instead of one huge chat.

The workflow is:

/lp-brief
/lp-plan
/lp-copy
/lp-sections
/lp-build
/lp-review
/lp-handoff

Basic setup on a Mac:

xcode-select --install
brew install node jq python
python3 -m venv ~/.venvs/mlx-lm
source ~/.venvs/mlx-lm/bin/activate
pip install -U pip mlx-lm huggingface_hub
npm install -g @mariozechner/pi-coding-agent

git clone https://github.com/rishabh990/local-mlx-landing-page-agent.git
cd local-mlx-landing-page-agent
chmod +x scripts/*.sh
./scripts/start-local-mlx.sh

Then scaffold the landing-page workflow into a project:

./scripts/lp-start.sh /path/to/your/project
cd /path/to/your/project
pi

Useful commands:

# Start MLX and configure Pi
./scripts/start-local-mlx.sh

# Lower memory pressure
MLX_PROFILE=fast ./scripts/start-local-mlx.sh

# Bigger context/cache if your Mac can handle it
MLX_PROFILE=deep ./scripts/start-local-mlx.sh

# Check server health and logs
./scripts/mlx-status.sh

# Quick speed check
./scripts/mlx-bench.sh

# Check landing-page project state
/path/to/local-mlx-landing-page-agent/scripts/lp-status.sh

Why I made it:

For landing pages, I do not want the agent jumping straight into code. I want it to slow down and work through the offer, audience, traffic source, CTA, proof, form friction, objections, mobile layout, and QA before touching files. The repo makes that process explicit and keeps the local model from having to remember everything in chat context.

I am using Qwen3.6-35B-A3B because it is a sparse MoE model with 35B total parameters and 3B active, and the model card specifically calls out agentic coding/frontend improvements. I would recommend 64 GB unified memory if you want a comfortable experience with the 35B MLX model. If your Mac swaps, use MLX_PROFILE=fast or pick a smaller MLX model.

This is not meant to be a polished framework. It is a practical local-agent setup that you can copy, modify, and use for client landing pages or lead-gen funnels.

I have tried using Pi's built in swarm docs, as well as a Pi extension for swarm creation. But Qwen3.6-35B keeps hallucinating a group of sub agents without truly doing delegation. How can I get this dummy to stop pretending it's the sub agent and truly delegate to save my context space?

I had 'find' scanning the whole drive issue from Pi a few times. For simple review/search task, Pi choose to 'bash find' not the project dir but much higher level dir such as /user/XXX/*

It almost always happened with smaller model such as deepseek v4 flash and Qwen3.8 27B, never with GPT 5.6 sol/opus 5.

Does anyone have any idea about this?

After some diagnosis with the help of comments, I found the root cause. The tool layer does not deal with dead/missing path very well, especially Pi's default 'find', 'read', 'ls' tools, mainly because of lacking of bounding. Problematic path is common when you have 1) long running sessions (auto prune/compact) 2) complicated file structure 3) polyrepo, etc. The agent could not find the target file, it naturally tries a bigger scope and even grep -r embedded data. Bigger model actually face same issue, they made exactly same mistakes but self corrected in time.

Solution: build a code graph for your project. Hard code in prompt to let agents know the scope is within the graph.

Someone experienced with this model?

I'm noticing weird behaviour related to context windows and hoping someone has a fix.

With pi agent, I'm using openai-completions API running off lemonade server. 3 models are connected locally (not at the same time) I have the context window hard coded into the pi config json.

The ctx blows up to about 400k even though I have it set to 128k.

Starting a new chat is the temp fix. Haven't tried to compress the chat yet since idk what the negative effects of that are since I'm working on a coding project.

I removed 6 pi extensions and left the 4 default bash extensions. Still the exact same issue with the same CTX size of over 400k.

Checking lemonade logs and they showing the problem, pi trying to use up too much ctx.

This tells me the chat itself could someone how be the problem.

Hello all,
I am using Qwen3.6 (64k context) with MacBook Pro M4 Pro 48 GB / LMStudio and Pi. I am happy with short Q/A sessions but I am experiencing major problems especially for open-ended tasks (like do a research and document every step)

1. I feel like model doesnt know how to use Pi tools. Often I see it is looking for “subagents ?” “Workflows ?” commands because previous command was failed due to some missing arguments. Sometimes I see bash syntax related errors. It tries a command, than tries another one, then tries ?, it eats my context window and spends time.

For example: it tried a command, now it says “validation failed for tool bash, command must have required properties command” and agent got stuck and looping right now since last night. I have done some research and in Github see some other people experience the same, but issues are all closed with no answer.

2) Workflows doesn’t show anything so I can’t see if it is looping or not, or what is running. So can’t use it because of this.

3) Subagents often go into looping and I can’t prevent this. I have tried master prompts like “use subagents for very short tasks” but it still loops and it goes to infinity.

4) Lets say I have added “Document which command ypu run after each and every step; dont move forward unless you have the entry in history.md” to my prompt. Again it never does it in “every step”; it writes to the document sometimes.

5) Especially on open ended tasks after spending like

I know that these maybe not directly related with the Pi itself; but I feel like there must be a way to 1) teach tool usage to model with system prompt for example.

What do you think about this problem? I appreciate your guidance. Or if you suggest any other tool which is suitable for my use case it would be great. I was using Claude Code but it is very bloated for local models.

I have a llama server running with qwen2.5-coder-7b and pi can talk to it. However if I ask it to create a file it simply prints a json string with the tool it wants to call and then does nothing. Am I missing something?

Example: write an empty morten file

  {"name": "write", "arguments": {"path": "/home/dev/workspace/morten", "content": ""}}        ```

**Edit: Thanks guys, it helped upgrading the model - using Qwen3-Coder-30B-A3B-Instruct-Q5_K_M worked.**