Your agent truncates the corpus and answers anyway. Two harnesses, and a router that picks between them.

I built a harness that streams an oversized corpus past a small model and aggregates in code. Then I found PrimeIntellect's prime-agent (PrimeIntellect-ai/prime-agent), installed it, pointed it at the same Ollama server on the same 6GB laptop GPU, and got PA_OK back.

They have close to 20,000 stars, a funded team, and a better implementation of the recursive-language-model idea than mine. So this is not a "we beat them" post. It is about the one line where the two architectures genuinely diverge, why that line is a question-class boundary rather than a quality one, and how to route across it.

The one line

I grepped their repo for how it handles a corpus bigger than the window.

splitText        0
chunkSize        7      (terminal-image.ts, snapshot-transcript-cache.ts)
truncate       142
summarize       73
contextWindow   73

Plus packages/coding-agent/docs/compaction.md. Their overflow strategy is compaction: truncate and summarize. Mine is exhaustive sweep: segment the whole corpus, extract from every fragment, aggregate in code.

That is nearly every agent, by the way. Compaction is the default because it is correct for the questions agents are usually asked.

Why the boundary is a question class

question	compaction	exhaustive sweep
"what does this codebase do?"	correct, and cheaper	wasteful
"where is retry logic implemented?"	correct	wasteful
"how many entries have label X?"	cannot work	correct
"which user appears least often?"	cannot work	correct
"is there any file that does Y?"	cannot work	correct

The failure in the bottom three is not that compaction is imprecise. It is that you cannot count what you summarized away, and nothing downstream can tell that it happened. Coverage looks fine. No error is raised. The agent answers confidently from the fraction it kept.

That is the actual danger: not a wrong answer, but a confident wrong answer with no signal attached.

What each side is measurably good and bad at

Everything below is measured on one 6GB RTX 3060 laptop, same Ollama server, same 4B model.

	prime-agent (compaction)	ctxstream (sweep)
overflow strategy	truncate + summarize	segment every byte, reduce in code
model's job	plan, act, summarize	extract from one fragment
aggregation	in-model	in code
agentic loop, tools, sessions	yes	none
ecosystem	~20k stars, extensions, RPC, skills	one binary
targets constrained hardware	num_ctx, VRAM, gguf: 0 hits	the entire premise
published benchmark numbers	none found	see below, including the losses

And my own results, which do not uniformly flatter the sweep:

workload	result
957k-char corpus, literal category= field	correct; Claude Opus on the same corpus: 2/3, self-inconsistent on byte-identical input
OOLONG-synth 131k, public benchmark	0.340 vs 0.428 direct — and 0.500 vs 0.513 once exact-count questions are separated out
262k tokens on 6GB VRAM	4.23–4.54 GB peak across four runs; direct ceiling on that card is 32,768 tokens
5 repeat runs, temperature 0	3 answered (all correct), 2 produced no output

The OOLONG number needs decomposing. Sweeping first scored 0.155, because OOLONG asks "which user has the most instances with the label True" — a two-dimensional group-by over labels the model must infer, while my extraction contract emitted <key><TAB><count>, one dimension. Of 27 rows, 2 were the shape it could represent. Three contract fixes later it reads 0.340.

Split by question class, the remaining gap is entirely one thing:

	direct	sweep
rank-order / comparison (n=18)	0.513	0.500
exact count (n=9)	0.257	0.02

Parity on ranking, near-total failure on counting. The model abandons enumeration partway through a fragment — per-fragment counts of [64, 69, 174, 64, 76, 162, 188, 59, 54, 172, 186, 172, 28] where each held ~154 lines. Rankings survive that because the error is roughly proportional; exact counts do not, because the answer is the number.

So: a sweep with the wrong extraction contract is worse than not sweeping, and my own corpus flattered me because I had designed the corpus and the contract together without noticing.

The 2-of-5 empty outputs are worth naming too. The harness refuses to print a headline answer when any fragment fails, because a partial sweep undercounts every key. I believe those two runs were refusals rather than failures — but I did not capture stderr per run, so I cannot prove it, and an unverified explanation is not a result.

The synthesis: route, don't choose

These do not compete. One is an agent; the other is an aggregation primitive. The agent should call the primitive when the question needs it.

Route on a single test: does the answer depend on data you might have dropped?

superlative        most / least / top / fewest
cardinality        how many / count / total
universal          every / all / any / none
group-by           per user, per label, per file
                                    -> exhaustive sweep
anything else                       -> compaction

That is a cheap classifier over the question, not the corpus, and it fails safe: routing a locate-question to a sweep is merely wasteful, while routing a count-question to compaction is silently wrong.

Concretely, in prime-agent's own extension system, the sweep is a tool:

pi.registerTool({
  name: "aggregate_corpus",
  description:
    "Answer counting, most/least, or every/any questions over a file or " +
    "directory too large for the context window. Sweeps every byte and " +
    "aggregates in code. Do NOT use for 'what does this do' questions — " +
    "normal reading is cheaper and better.",
  // shells out to a binary; returns key/count pairs
});

The agent keeps planning, editing, and tool use — which it is good at. The sweep handles the one class where dropping data is fatal. Neither pretends to be the other.

What I would tell anyone building either

Verify the context arrived. My serving layer auto-sized context up to a ceiling then silently fell back: 30,021 tokens passed intact; 50,000 and 70,000 both clipped to exactly 16,387. No error, confident answer from the remainder. Compare reported prompt tokens against what you sent and make the mismatch fatal.

A partial sweep must refuse. If any fragment fails, every count is low. Exiting non-zero beats printing a plausible number.

Run on a benchmark you did not build. This is the whole post. I had a working system, a real win against a frontier model, and a tidy story. One public benchmark showed the generality was imaginary. It cost an afternoon and was the cheapest thing I did.

Report where you lose. prime-agent publishes no benchmark numbers. I publish 0.340 against a 0.428 baseline, and a 0.02 on the one question class my approach cannot handle. One of those is more useful to you, and it is not the one that looks better.