The complaint that actually points somewhere
A developer on V2EX put it plainly: writing plans, review checklists, test cases, even the code and boundary analysis, all of that stays reasonable on token spend. What gets expensive is document cross-review. Once the pile of accumulated docs grows, checking one thing against everything else means the association analysis fans out, and the token count climbs with it. Someone replied in the same thread that writing a novel burns through 4B tokens a month. Over in a multi-agent workbench post, a builder mentioned roughly 34 billion tokens spent since July while iterating. Different projects, same shape: cost scales with how much context you keep shoving back into the prompt.
The instinct is to reach for a bigger context window. That treats the symptom. The real issue is that a review pass rarely needs the whole corpus. It needs the handful of passages that touch the thing you're actually reviewing. If you keep re-feeding everything, you pay for everything, every time.
What changes when you retrieve instead of re-feed
The move is to stop treating your document set as one giant blob you paste in, and start treating it as an index you query. Chunk the accumulated docs once, index them, and at review time pull only the slices that are semantically close to what you're checking. The prompt that reaches the model carries the current section plus its relevant neighbors, not the entire history.
The cost model flips from "grows with the pile" to "grows with the query." A review of one requirement against related sections touches a bounded set of chunks whether your corpus is fifty docs or five hundred. I won't put a number on the savings, that depends entirely on your corpus and chunk sizes and stays unverified until you measure it on your own material. But the direction is the point: you decouple review cost from total document volume.
A build you can stand up on the platform
This maps cleanly onto confirmed VicroCode pieces, and it's the kind of thing you can wire up without leaving the platform.
Start with ingestion. You can run Python online to handle the pipeline: read the source files through file management, split each document into chunks with sensible overlap, and attach metadata like source name, section, and a version or content hash so you can tell later which slice came from where. Keep the chunking honest, section boundaries and headings usually make better cut points than a blind fixed-length split.
For the retrieval layer, index those chunks into a LanceDB knowledge base. At review time your query embeds the passage under review, pulls the top relevant chunks, and hands only those to a model from the Model Center. If you want structured tracking alongside the vectors, an SQLite database is a reasonable place to store review runs, which chunks were pulled, and what verdict came back, so you have an audit trail rather than a black box.
Wrap the whole flow behind an API endpoint hosted in-platform. That gives you one call that takes a passage and returns "here are the relevant slices and here's the review against them," which you can trigger from a small HTML front end you publish on the same platform. The people doing the reviewing never see the plumbing.
The boundary, said out loud
Retrieval is good at "find the passages related to this." It is not good at "is the whole document set internally consistent," and it can't read intent. This is the same trap flagged in a widely-shared post about AI agents: locally each edit looks fine, globally the thing quietly rots. A retrieval-scoped review has exactly that blind spot. If a contradiction lives between two sections that don't share vocabulary, similarity search may never place them side by side, so the conflict slips past.
So don't sell scoped review as global review. Use retrieval for the high-frequency, per-section passes where re-feeding everything is wasteful. Keep a separate, deliberate full-corpus pass, or a human read, for the questions retrieval can't answer: overall coherence, whether the intent still holds after a dozen edits, whether two clauses secretly disagree. Those need the whole shape in view, not a slice of it.
There's also a plainer limit worth naming: retrieval quality is only as good as your chunking and your embeddings. Bad cut points scatter a single idea across chunks that never get retrieved together, and you're back to missing things, just more cheaply. Expect to tune this against your actual documents rather than trusting a default.
Where this leaves a small team
If you're an independent developer or a small operation drowning in accumulated specs, plans, and review notes, the practical payoff is that review stops getting more expensive just because you wrote more docs. You pay per question, not per archive. The pipeline is modest: ingest, index, query, review, log. And because the same platform handles the Python execution, the knowledge base, the API endpoint, and the front end, you can ship a working internal tool and iterate on the chunking without stitching together separate services.
If you want to go deeper on the assistant-driven parts of building this, the learning material on AI coding is a decent starting point. But the core idea needs no ceremony: retrieve the slices that matter, review those, and keep the global judgment calls explicitly out of scope until you run a pass built for them.