Five tabs in sequence

Before writing the textproxy post I had five sources open: a 400-comment Reddit megathread on Claude usage limits, two blog posts, a forum thread, and a README. I needed them all read together, with the same frame: token limits, what's visible, what isn't. Reading them in sequence and hoping I'd remember the connections wasn't going to work.

I ran textread across the folder with a one-line goal. It came back with a themed digest, sections already shaped around the frame I'd given it, quotes pulled verbatim and placed where they'd be useful. The textproxy post took about an hour to write. Most of that time was in the writing, not the research.

That's the use case textread is built for.

What RAG gets wrong here

RAG is designed for large corpora and low-precision retrieval. The question it answers is "find me something about X across thousands of documents." It indexes, embeds, stores, retrieves. That machinery makes sense when you don't know what you have and need to discover it.

This is a different problem. I know exactly what I have: five files, chosen deliberately, all relevant. I don't need retrieval. I need reading with a frame. The goal isn't to find the needle; it's to read the haystack with a specific question in mind and get a structured answer back.

Search has the same mismatch. Search finds documents. I already have the documents. What I need is someone to read them for me, with context, and tell me what they say in relation to each other.

What textread does

You give it a folder (or a list of files) and a lens: a short description of what you're trying to understand. It reads every file with that frame and produces a digest. The digest has sections, each covering a theme that emerged across the sources. Each section includes direct quotes, not paraphrases. Nothing is indexed, nothing is stored, nothing persists between runs.

textread --lens "token limits and API visibility" \
  ~/research/textproxy/

# output: digest.md
# sections: Limit mechanics · Visibility gap · Community workarounds · Prior art

The lens steers the reading. The same folder with a different lens produces a different digest. "How do users respond emotionally to hitting limits" gives you something different from "what technical approaches exist for tracking consumption." Both are valid readings of the same sources; the lens decides which one you get.

Cross-source themes

The part that saves the most time is the cross-source section. After the per-theme summaries, the digest surfaces where sources agree, where they contradict, and where one source says something the others don't address. You don't have to hold five documents in working memory and notice the pattern yourself.

For the textproxy research, the contradiction that came up was between the Reddit thread (users experiencing limits as sudden and opaque) and the README (which describes the limits as documented and predictable). Both were right from their respective positions. That tension became a structural beat in the post: the limits exist, the opacity is the problem, not the limits themselves.

The quotes in the digest are verbatim, with source attribution. When I'm writing and I want to use something specific, I don't go back to the original file to find it. It's already there, already in context.

What it's for

textread is for focused, time-bounded research over a small known set. You've already decided what to read. You have it in front of you. You need to read it fast, with a consistent frame, and come out with something usable rather than a pile of tabs and a vague sense of what they said.

It's not a replacement for RAG when RAG is the right tool. If you're building a retrieval system over a knowledge base, textread isn't that. It's a replacement for reading five tabs in sequence and hoping you remember the connections by the time you reach the last one.

Paperworlds is a pet project where I'm working through a set of small problems that kept arriving in the same shape while building a text RPG. textread is one of them: the specific friction was spending more time on research logistics than on writing. Whether the approach generalizes I don't know yet, but it worked here.