Date: 2026-09-08
pi-pew-pew gives Pi a small read-only web tool. It can fetch ordinary pages, render JavaScript-heavy ones, and take screenshots when the visual result matters.
That clean description came after a considerably less clean planning process.
I was thinking about web search, research models with restricted tools, browser automation, frontend work, and eventually the increasingly unpleasant relationship between AI systems and website operators. Somewhere in those conversations, pi-pew-pew emerged as the part that just looks at things.
It does not click, type, log in, or crawl around a site. That boundary ended up being useful, even if I did not begin with it neatly drawn on a whiteboard.
Pi does not have a native web-fetch tool.
That is not necessarily a serious limitation for a model with full host access.
Give it a shell and it already knows about curl and similar tools. I also
considered search-oriented command-line utilities and services such as Tavily.
The awkward case was models I wanted to use in a more restricted research role. A model might have access to scientific or documentation-oriented sources such as OpenAlex or Context7, and perhaps permission to read or edit files, without having unrestricted shell access.
I wanted those models to be able to follow a useful reference out onto the ordinary web without giving them Bash merely so they could fetch a page.
That was one thread that became pi-pew-pew.
My first mental model was less an architecture than an escalation ladder.
Try the cheap thing first. Fetch the page.
If the useful content is already in the HTML, pi-pew-pew passes that HTML through Pandoc when it is available and returns GitHub-flavoured Markdown. Pandoc is one of those pieces of software that keeps quietly solving problems for me. Here it turns a great deal of ordinary web HTML into something much nicer to put in a model’s context.
But some websites barely put the page in the initial HTML at all. They send a shell, run JavaScript, fetch more things, and only then produce the content. Fine. Render the page with Chromium, take the resulting DOM, and give that to Pandoc instead.
And sometimes even that is not a very good representation of what is actually on the screen. Layout can carry information. A chart can carry information. A badly structured page may simply make more sense when seen than when flattened into text.
At one point I considered adding OCR as another step. While discussing the tool, that started to seem slightly backwards. If the model is already vision-capable, why build an ad hoc OCR layer whose output I then feed back to the model? Just give it the screenshot.
So the progression became roughly:
This also made screenshots useful for a completely different reason. A model working on HTML or CSS can render the thing it just built and look at it itself. I no longer have to be the person taking screenshots merely so a vision-capable model can discover that its logo is enormous.
I would not claim I designed these three modes in one sitting. They grew during planning and brainstorming. The instinct was simpler: if the page is not letting me see the useful information yet, escalate until I can see it.
That escalation raised another question: just because I can make the page visible to a model, what am I entitled to ask somebody else’s website to do for me?
Website administrators have been dealing with enormous amounts of automated AI traffic. I did not want my tiny personal tool contributing much to a world in which every site is continuously hammered by crawlers because somebody, somewhere, might want its contents later.
I also started wondering about terms of service, robots.txt, access controls,
and what respectful automated access should mean for a tool that is not really a
traditional crawler.
I am neither a lawyer nor an ethicist, and I would not claim that pi-pew-pew has found the legally or morally correct answer.
The politeness machinery grew partly out of trying to make the escalation above
something I could at least understand and defend. The current tool identifies
itself honestly, checks and reports robots.txt, does not recursively crawl,
bounds its requests and output, and stops rather than trying to defeat actual
resource-level refusals or anti-bot measures. It can surface llms.txt and
terms-of-service hints when a site provides them, but it does not pretend that
any one of these signals settles every question about whether an isolated read
is appropriate.
“Polite” is therefore an aspiration rather than a certification.
While all this was happening I was also thinking about a more general assistant. Some of the boring things I would quite like an assistant to do involve web forms and authenticated applications. That requires much more than fetching a page.
The brainstorming was messy and fairly AI-mediated. I discussed versions of the idea with models, changed my mind, mixed together search, research, browser use, and automation, and gradually separated concerns that were not very separate in my head at the beginning.
The result now looks simple:
I like that separation now. I would be rewriting history if I claimed I designed both projects from the start around an elegant “eyes versus hands” architecture.
That is simply where the exploration ended up.
The current boundary also means pi-pew-pew can be useful to models that should not have browser automation or unrestricted shell access.
For research, documentation, coding, and frontend work, looking is often enough. When it is not, I can use a different tool and know that I have crossed into a different kind of capability.
This project also came during a period when I had started enjoying writing small Pi extensions and trying to keep their source code understandable. That probably helped the boundary survive once I found it.
I do not know whether this is the best architecture for web access. It is the one I currently understand.
For an experiment, that counts for quite a lot.
Thank you so much for reading!
If you would like to give some feedback please open an issue on this blog’s GitLab.