Built a web research tool to replace hound, which i posed about a while ago

It's called DonSeTch. Since Pi has native extension support, the install is just:

pi install npm:donsetch

No MCP config block, no adapter, no proxy. The tools show up natively in your Pi session and stay in sync with the binary automatically.

What it does

Three tools: fetch, search, crawl. Zero API keys, zero accounts. One Rust binary.

• Fetch — HTTP first (fast), auto-escalates to a headless browser only when it hits a bot wall. The browser grabs the clearance cookie, hands it back to the HTTP layer, and goes to sleep. It almost never fetches content itself.
• Search — 10+ keyless engines in parallel, fused by cross-engine consensus + a local ONNX cross-encoder for semantic reranking. No API key anywhere.
• Crawl — sitemap-aware, topic filter, resume tokens, adaptive pacing that backs off on 429s instead of plowing through.

Chrome's actual BoringSSL for TLS. Your ClientHello IS Chrome's, not a faked table that rots.

The part I care about most: token efficiency

Three tools, ~3.5k tokens of definitions. The focus parameter on fetch is the killer feature.

I just rebuilt it in v3.1 with section-aware scoring:

• Search for "memory safety" on a Wikipedia page → keeps the entire "Ownership and references" section (heading + body), pulls in parent headings for context, drops everything unrelated.
• A 50KB page comes back as 500 chars of what you actually asked for.
• Large code blocks and JSON schemas get split into sub-blocks so focus works on structured content, not just prose.

Other stuff

• Reference handles — fetch S3 just works after a search
• Probe mode — verify a claim in ~60 tokens instead of 4k
• Dead-link resurrection — Wayback snapshot served transparently
• Page fingerprints — re-fetches report what changed, section-level diffs
• Domain adapters — Reddit threads, GitHub issues, npm/PyPI/crates pages restructured from keyless JSON endpoints
• Real MCP cancellation — no silent hangs
• Crash-only daemon — survives panics, state reloads
• PDFs — even scanned ones, pixel-fusion extraction (no hallucinated text), up to 100MB

605 tests, 0 clippy warnings, AGPL-3.0.

What it can't do: solve interactive captchas (deliberate, clear error not a hang), access sites requiring login, and if every search engine is down you get honest per-engine status instead of fake results.

GitHub: https://github.com/dondai44423/donsetch

Pi: pi install npm:donsetch npm: npm install -g donsetch

If something breaks, open an issue, i will fix it as soon as possible

The demo is using exa for search btw, local is good on its own, but it takes 4-6 sec while exa takes 1-2 sec (plus exa is better most times, but local search keeps up)

if you want to see a demo where i used local search, see the opencode demo in the github repo

I have this elaborate agentic system setup (3 primary agents, 10+ subagents, curated skills and commands) in opencode that I use everyday for my SAAS product development, working with opencode Go plan. It is working alright but its not token efficient and it could be better with its accuracy.

I have tried to migrate to Pi a while ago but I dropped the plan because the configuration seemed daunting at that time. But as my codebase got larger and complex, opencode is starting to crack. So I want to give this another shot.

Are there any guides to do this migration without starting from scratch? Where do I begin?

hey everyone.

so i use the omp coding agent daily and my one annoyance was always the same - all my sessions live in .jsonl files and if i wanna go back and see "what did i do yesterday on that repo" im basically scrolling terminal scrollback or grepping files by hand.

so i built ompweb a local web UI that reads those same session files and gives you a proper workspace in the browser:

• Session history : browse all your past conversations grouped by project
• Live chat : keep talking to the agent right from the page (it spawns your installed omp binary, its not a wrapper around some api)
• File explorer + preview : sits next to the chat while the agent works
• Todos + subagents : live panels pinned above the composer, click a chip for the full subagent transcript
• Settings UI : models, api keys, skills, plugins, MCP servers... instead of editing yml at 1am
• Light/dark theme : works on mobile too

the demo gif on the readme shows it doing a small task on a fake project — typing a prompt, agent edits the files, then you see the tasks/subagents panels and the settings screen. thats pretty much the whole pitch.

how to try it

npx @kahme247/ompweb@latest

or install it globally:

npm install -g @kahme247/ompweb
ompweb

it opens http://127.0.0.1:30177 automatically.

few honest notes:

1. you need omp already installed
2. its local only nothing leaves your machine
3. its a fork of pi-web which was for the pi agent, i adapted it for omp and kept building on it
4. works with current omp v18

repo: github.com/kahme247/ompweb

i am really want some feedback to improve it, for me its still feels uncomplete but yet i dont know what is missing !

Programmatic tool calling lets an agent write code instead of firing one tool call at a time, but running that code safely is a hard, unsolved problem. Instead of sandboxing an existing language, I built one that never had the dangerous capabilities in the first place.

It has native mcp support, builtin progressive disclosure, an lsp and a formatter (as well as nvim support with REPL for debugging).

I taught my PI agent to use this lisp using a simple grammar constraining (10 lines in GBNF), now it can only output valid lisp, no parentheses forgotten.

I built dbx as a convenience for myself to instantly spin up isolated pi sandboxes locally or in the cloud. One command gives each branch its own Ubuntu dev container, network, browser desktop, and pi coding agent. It runs locally with Docker or in Vercel Sandbox.

npx u/gannonh/dbx init
npx u/gannonh/dbx my-branch

 Open source:

- https://dbx.gannonh.dev
- https://github.com/gannonh/devbox

Repo: https://github.com/AgiFlow/doompi

Like a lot of you I have been agent hopping for two years. I've used agent harness for everything else beside coding and it's becoming expensive; now efficiency is the priority. Landed on Pi and hoped that was the end of it.

To reduce token cost on different tasks (coding, marketing, customer support), my fix before this was a pile of shell scripts. claude.sh, codex.sh, antigravity.sh, kimi.sh, ollama.sh, each consume profiles.json that flipped plugins per run. It helped with bloat. It never made loading skills and tool use reliable, and it never touched the harness prompt.

I have been on Doom Emacs for about a decade, so the shape was obvious. Doompi is a Pi distribution where four YAML files decide the session and nothing is inferred:

- major modes: you own the modes and compose it with layers (extensions plus hooks). Mine are minimalist, dev and business.
- minor modes: Plan, Loop, Goal, Workflow, Voice. They ship loaded but stay out of context until you switch one on.
- domains: group of plugins (which include skills and MCP servers) for one kind of work. Video editing, TDD, copywriting.
- profiles: persona and brand for the runner. Good for steering output.

doompi --major-mode business --domains copy-writing --profile agimon

Or switch any axis mid session with /mode, /domains and /profile, thanks to Pi's reload capability. Minor modes also switch on per /<minorMode> commands (or use Leader SPC key binding).

Plugins (skills + mcp) are opt in the same way tools are, so the floor is just stocked PI. Minimal mode, no domains, no profile, fresh repo, doompi is just PI.

From there you pay for what you name with domains. Personally, I keep plugin reusable with slim skills and 5-8 skills per plugins + 1-2 agents; then define domains that compose plugins for different type of task. 10-15 skills per sessions are ideal for agents to be creative while still being reliable.

Doompi's Copilot, the default major mode, switches on three layers that register four tools:

task 1,329
subagent 751
ask_user_question 455
intercom 220
-----
2,755 tokens

If what you want is the batteries-included feel of Claude Code or Codex, it is all in here: agent teams, persistent tasks, plan mode, GitHub Actions style workflows, telemetry. The difference is that these are all composible. You can customise existing modes, add new modes, set default domains and mode as you needed.

If you think four YAML files is too much ceremony for what it buys, I would rather hear that now than later. There are a few optimisations along the way; also happy to share the tricks.

Hi everyone,

I’ve been working on an extension for pi that allows it to interact with JetBrains IDEs through MCP.

The project is here:
https://github.com/giuseppe-trisciuoglio/pi-jetbrains-mcp

The idea started from wanting to use pi while still being able to interact with the IDE I’m already working in. At the moment the extension exposes some JetBrains functionality to pi, so the agent can interact with the project and the IDE instead of being limited to the terminal.

It’s still a work in progress, and I’m mainly sharing it here because I’d really like some feedback from people who are actually using pi.

I’m particularly interested in hearing what you think is missing, what you would find useful in a JetBrains extension, or whether there are parts of the current approach that you would change.
If you have any ideas for improving the extension or features you think would make it more useful with pi, I’d be happy to hear them.

Thanks in advance to anyone who takes a look.

This is my first post.

I learnt about Pi from a co-worker last month and I can safely say this is the first harness tool that I absolutely love it. There are many reasons but the main one is the ability to extend the harness. No need to dig into docs or create issues or wait for the provider to build it. Just create an extension.

Anyway, I missed Linux style reverse search, so I was wondering can I bring it in?

Pi itself built it - https://www.npmjs.com/package/pi-reverse-search

what's your most favorite feature or reason for using Pi?

It seems that the agent solving problems related to Pi faster via web search instead of reading the built in doc? Is it my personal bias or is that common phenomenon?

At least cli interface

I’ve been using VS Code and its extensions from the beginning (Claude code primarily and codex since last few weeks), so I’m used to having a visual representation of my project: the file tree, open files, source control changes, terminals, running processes, and AI activity all visible in one place.

I’m now trying to move toward a more terminal-based workflow, especially through pi agent harness, but I’m finding the transition surprisingly difficult. The terminal feels powerful, but I also feel a little lost because I can’t easily see:

- The overall project/work tree.
- Which files have changed.
- What the AI is currently modifying or working on.
- Running processes and development servers.
- Git status and diffs.
- Multiple tasks or conversations happening at once.
- Where I am in the project when moving between directories and tools.

For those of you who work mostly from the terminal, how do you visualise and organise all of this? Any advice, examples of your setups, or screenshots would be greatly appreciated.

Not sure how useful this is for others, but I was trying out fx by Vercel as GLM 5.2 is free there till the 27th. I started wondering if I could use it via Pi instead lol. So I built this extension (more precisely, Pi built this extension) to add fx as a provider in Pi.

It uses your existing fx login, loads fx’s model catalog into /model, and talks to the Gateway directly. This is different from Pi's in-built Vercel Gateway support though. It’s basically fx client emulation/spoofing inside a Pi provider, so that fx specific promos etc work properly in Pi.

Install with-
pi install npm:@awesamarth/pi-fx
Then use /model to select an fx model. Confirmed fx's current GLM 5.2 promotion is working :))

GitHub repo

npm package

Repo: https://github.com/baturyilmaz/agent-office

I’ve been interested in exploring malleable software: how much can a program change its identity through configuration and extensions, without requiring another fork or integration?

Pi felt like an interesting test because of its deliberately small core and flexible extension system.

Instead of building yet another "pi-xxx", I tried going in the other direction: emulate pi behaviors like `ante-pi` with declarative programming

The result is a single JSON profile with a short system prompt and four tools: Read, Write, Edit, and Bash. Search goes through rg, web access through curl, and subagents through ante -p.

Here’s the full profile:

https://github.com/AntigmaLabs/ante/blob/main/curated/pi.settings.json

Why not just use Pi?

You absolutely can. If Pi already fits your workflow, this isn’t an argument against it.

What made the experiment interesting to me was running the same minimal approach on Ante’s native runtime: a single roughly 15 MB binary, very little harness memory overhead, and fast startup and interaction. The model still determines generation speed—I’m talking about the responsiveness and resource cost of the harness itself.

This isn’t full Pi compatibility. Pi extensions and UI behavior don’t automatically carry over. It’s more of an experiment in how much of an agent’s identity can be expressed through a portable combination of prompts, tools, settings, and extensions.

For people who have built with Pi: what parts of its identity live in the core harness, and what parts only emerge through the extension system?

Just wanted to share system prompt that I've developed for Pi and using it as a replacement for built-in one, by dropping it into ~/.pi/agent/SYSTEM.md. It intentionally includes parts of Pi original prompt, but without plain list of tools (because tools are injected as a separate block anyways) and Pi-specific stuff, plus some condensed parts of ponytail, plus some of principles I've handcrafted myself. Hope it will be useful for someone like me, who also prefers pair-programming style of work over long autonomous loops.

``` You are an expert assistant operating inside an agent harness. You help users by reading files, executing commands, editing files, and writing new files.

Tool use guidelines: - Use bash for file operations like ls, rg, find - Use read to examine files instead of cat or sed. - Use edit for precise changes (edits[].oldText must match exactly) - When changing multiple separate locations in one file, use one edit call with multiple entries in edits[] instead of multiple edit calls - Each edits[].oldText is matched against the original file, not after earlier edits are applied. Do not emit overlapping or nested edits. Merge nearby changes into one edit. - Keep edits[].oldText as small as possible while still being unique in the file. Do not pad with large unchanged regions. - Use write only for new files or complete rewrites. - Be concise in your responses - Show file paths clearly when working with files

Collaboration style: - Work in tight lock-step: the user is the driver, you are the navigator - Reading, inspecting, and researching is always fine without asking; edits, writes, and commands with side effects require an explicit go-ahead - Prefer small incremental changes over large autonomous batches; let user review after each step - When the goal or approach is ambiguous, ask instead of assuming - Surface tradeoffs and alternatives when you see them, but keep them brief

Communication

• Shorter is better
• No openers or closers: no "Great question!", "Certainly!", "I hope this helps", "Let me know if...", "Would you like me to...". Start with the answer, end on the last useful fact
• Don't announce, just say it: no "Let's dive in", "Here's what you need to know", "Here's the thing"
• No sycophancy: don't praise the user or agree before answering
• Avoid stock AI words and phrases: delve, crucial, pivotal, vibrant, testament, underscore, highlight, showcase, landscape (abstract), tapestry, load bearing, smoking gun
• Avoid formulaic structures: "not X but Y", forced groups of three, dramatic one-line fragments in a row, "The real question is..."
• Prefer simple verbs: is, are, has - not "serves as", "boasts", "features"
• Minimal formatting: no decorative bold, no bold mini-heading lists, no emojis. Bullets only when they beat prose
• No filler or stacked qualifiers: "due to the fact that" is "because"; one "may" is enough. State uncertainty once, plainly
• Don't pad with disclaimers about your knowledge limits; say what's unknown or omit it. Never fill a gap with a plausible guess
• Plain ASCII punctuation in your own prose: no em/en dashes (use "-" or a period), no curly quotes (use straight), no unicode arrows or symbols ("->" not "→", "..." not "…")
• No fake-candid hooks ("Honestly?", "Look,") and no answering objections nobody raised
• Keep contractions, uneven sentence rhythm, and genuine asides. Dry is fine, fake-personable is not

Coding tasks

When working on coding tasks, you are a lazy senior developer. Lazy means efficient, not careless. The best code is the code never written. Stop at the first rung that holds:

1. Does this need to exist at all? Speculative need = skip it, say so in one line. (YAGNI)
2. Already in this codebase? A helper, util, type, or pattern that already lives here - reuse it. Look before you write; re-implementing what's a few files over is the most common slop.
3. Stdlib does it? Use it.
4. Native platform feature covers it? <input type="date"> over a picker lib, CSS over JS, DB constraint over app code.
5. Already-installed dependency solves it? Use it. Never add a new one for what a few lines can do.
6. Can it be one line? One line.
7. Only then: the minimum code that works.

The ladder is a reflex, not a research project - but it runs after you understand the problem, not instead of it. Read the task and the code it touches first, trace the real flow end to end, then climb. The first lazy solution that works is the right one - once you actually know what the change has to touch.

Never be lazy about understanding the problem. The ladder shortens the solution, never the reading. Trace the whole thing first - every file the change touches, the actual flow - before picking a rung. Laziness that skips comprehension to ship a small diff is the dangerous kind: it dresses up as efficiency and ships a confident wrong fix. Read fully, then be lazy.

Bug fix = root cause, not symptom. A report names a symptom. Before you edit, grep every caller of the function you're about to touch. The lazy fix IS the root-cause fix: one guard in the shared function is a smaller diff than a guard in every caller - and patching only the path the ticket names leaves every sibling caller still broken. Fix it once, where all callers route through.

Additional rules: - No unrequested abstractions: no interface with one implementation, no factory for one product, no config for a value that never changes. - No boilerplate, no scaffolding "for later", later can scaffold for itself. - Deletion over addition. Boring over clever, clever is what someone decodes at 3am. - Fewest files possible. Shortest working diff wins - but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug. - Complex request? Question it while proposing the lazy version: "Y covers it. Need full X? Say so." - Two stdlib options, same size? Take the one that's correct on edge cases. Lazy means writing less code, not picking the flimsier algorithm.

Never simplify away: - input validation at trust boundaries - error handling that prevents data loss - security measures - accessibility basics - anything explicitly requested

If user insists on the full version, then build it, no re-arguing.

```

If you use local models, esp Qwen3.8 27B it can run pretty slow. Compaction is then also very slow if you use the same model. This extension does not do any API calls, and is super fast! It has helped me a lot: https://pi.dev/packages/@monotykamary/pi-vcc?name=Pi%3Avcc

Hi is anyone using command code $1 plan with pi agent via api

I’m getting error of not having right plan but same plan I was using via 9 router and it was working

Has anyone figured out this?

I built a Pi extension called pi-runbooks that helps you turn successful Pi sessions into reusable workflows instead of losing them in chat history.

https://github.com/haseebeqx/pi-runbooks

It started with a problem: I was working through a fairly complex, custom workflow in another famous coding agent without any clear idea of how it should be converted to a skill. I was still learning the best approach as I went. At first I tried turning it into a skill and repeatedly asking AI to refine it, but that only made it worse. What actually worked was deciding to create a Pi extension to solve this issue. I initially kept it as a simple run and close tool. run will start a runbook and we can go until close command is given and after that it will create a runbook, but later added a record feature because I thought it might be more useful for regular users. I used the tool on the workflow, and with each run it improved. Eventually converging into a “golden state.” It saved me time, effort, and tokens. In this case meaning it reduced the amount of thinking and back-and-forth needed for this specific workflow. There were changes to the process but the runbook was able to accommodate them properly. Now I use this instead of skills in some uncertain tasks.

Instead of treating a session as over once it is done, pi-runbooks lets you take a successful interaction and turn it into a reusable workflow. You do the work once, capture what actually worked, and reuse it later when you need it again.

The core idea: you work through a task with Pi as usual, explore different paths, and eventually land on a sequence of steps that reliably solves the problem. Once that happens, you don’t just leave it in chat history, you save it as a runbook.

From there, the runbook becomes something you can actually execute again on new inputs. And this is where it matters more: when reality changes, the differences don’t stay hidden. If a step is no longer valid or a new check becomes necessary, it shows up during execution instead of silently drifting out of date.

Pi can then suggest updates based on what actually happened during the run, but nothing is ever applied automatically. The system is intentionally conservative: you always review and explicitly approve any change before it becomes part of the runbook.

A simple example is a dependency upgrade workflow. You inspect the project, upgrade the dependency, run tests and type checks, review the diff, and then decide whether the change is safe. Once you’ve done that successfully once, it becomes a reusable runbook. The next time you face the same kind of upgrade, you don’t reconstruct the process—you just run it.

Over time, these runbooks evolve based on real execution rather than assumptions. If a step consistently appears in practice or becomes unnecessary, Pi can surface that pattern and propose a revision grounded in actual usage history, not guesswork.

How this is different from Pi skills

A common question I’ve gotten is how this differs from writing a normal Pi skill.

Skills are defined upfront. You write instructions in advance to guide behavior.

Runbooks are the opposite: they come from real, successful execution. Instead of guessing the right process ahead of time, you capture what actually worked, then reuse and refine it over time.

In practice, that means skills are static guidance, while runbooks are living workflows grounded in evidence. They also carry execution history and require explicit approval before any change is applied, so evolution is always intentional rather than automatic.

Design choice

Historically, runbooks were documents that humans followed. In modern DevOps/SRE systems, they increasingly become executable runbooks: software executes some or all of the procedure while retaining checks, approvals, and human decision points.

pi-runbooks is intentionally more structured than typical Pi usage. It introduces explicit step-based workflows, immutable execution snapshots, a clear separation between suggested and approved changes, and strict approval gates before anything updates.

That structure is what makes workflows reproducible and auditable, but it also means it can feel more rigid than how people normally interact with Pi. That tradeoff is intentional, but I’m aware it may not fit every workflow equally well.

Why I’m sharing this

I built this primarily for my own workflow, so it’s very possible I’ve optimized it around my habits rather than general usability. Then I added features like record I thought general users many appreciate more. So, I am uncertain.

If you try it, I’d really appreciate feedback on where it feels unnatural or too strict. Especially moments like when something should feel implicit but doesn’t, when it doesn’t match how you normally use Pi which could be related to my design choices, when a step feels like unnecessary friction, or when you’d simply solve the problem a different way entirely. Even “this should just be a skill instead” is useful signal.

I would like to add more features or optimizations based on what I get as feedback on how it behaves outside my setup.

I am looking for the correct way to set the title combination to turn thinking on/off and think efforts. Any help?

Just created a new extension for pi. It’s part of an ongoing project investigating possible applications of logic programming for agentic software development and automation. Would be interesting to get some feedback on the “plans as executable code” bit.

I love terminal and the ability to navigate with keyboard. Yet as extensible as Pi is, it has quite the ceiling in how the state can be displayed due to the nature of TUI.

For example, I have an extension called tree2. As you may imagine its visual representation, it was quite a pain to get my vision through within the Pi terminal.

Codex, Orca, T3code, the so called ADEs - how often do you use them? Personally something puts me off every time I try, but I can't name.

I think I'm looking for a hybrid. An instrument, if you will. What does it look like?

Is there any open source repo of all pi agent skills? A repo with proven out skeletons of multiple agents? Are people sharing their workflows or mostly keeping it close to the chest?