Screenshot retrieval gets a one-line install, and the comparison is text embeddings

PixelRAG, an open-source project that renders web pages, PDFs and images as screenshots and hands the images to the model instead of extracted text, has been bundled into a single `pixelrag` package with a Claude Code plugin called pixelbrowse ^[1][2][3]. The packaging is the news: the idea of feeding a model a picture of a table is old, but a one-line install and a slash command change who can evaluate it.

The pipeline is short. `pixelshot`, shipped by the `pixelrag-render` component, takes a URL or a PDF and writes image tiles to disk; Claude Code's Read tool picks up the tiles and the model works from the picture ^[4][5]. Output lands in a predictable place, on the pattern `/tmp/pixelbrowse/<domain>.png.tiles/tile_0000.jpg` ^[6]. Tile height is set to 1568 pixels, which the post describes as optimised for Claude's vision model, and multiple URLs can be pushed through with a `--workers` flag ^[7][8].

Two details decide whether this is usable where you work. First, cost: `pixelshot` drives a local Playwright and Chromium install, so there is no charge beyond your normal token usage, according to the post ^[9]. Second, platform: the project's `pyproject.toml` pins `sys_platform == 'linux'`, and the GPU-dependent `embed`, `serve` and `train` components assume Linux, with WSL suggested for Mac and Windows users ^[10]. Building your own index needs a GPU, and a cloud GPU is billed separately ^[11]. Python 3.12 or newer is required; the licence is Apache-2.0, commercial use allowed ^[12][13].

Read the flow diagram carefully and you find that the packaged Claude Code path is not retrieval. The `embed`, FAISS index and `pixelrag-serve` search API are drawn as an optional branch off the tiles, and that branch is the GPU-bound, Linux-only part ^[4][10]. What the plugin actually gives you is render-and-read: you name the document, the model looks at it ^[1]. That is a useful capability, and it is not the same capability as searching ten thousand PDFs.

On the comparison that matters, the post argues that text extraction tends to destroy row and column relationships in tables, the content of charts and infographics, and meaning carried by layout such as emphasis and annotation position ^[14]. Those are plausible failure modes that anyone who has run a PDF through a text splitter will recognise. But the post offers no benchmark, no accuracy figure and no side-by-side against an embeddings-plus-vector-DB baseline ^[15]. So the honest framing is: if your corpus is dense tables and diagrams, this is now cheap enough to test against your existing text pipeline in an afternoon, and you should expect to do that measurement yourself.

The cost model also shifts rather than disappears. Screenshotting is free and local, but every tile enters the context window as an image, so spend scales with pages and tile count instead of with an extraction service invoice ^[2].

Watch for a CPU or non-Linux path for the index components, since that is what separates a browsing aid from a retrieval system. Watch the hardcoded 1568-pixel tile height as vision models change. And if you test it, measure token spend per document alongside answer quality, because the two move together here.