The token bill for a RAG system is not set by your vector database. It is set one step later, by how you assemble the context you hand the LLM. Retrieval finds candidates; assembly decides how many of them, how much of each, and across how many LLM calls. That is where the money is spent.
So "vector DB vs. framework vs. SWIRL" is the wrong axis. The real comparison is between context-assembly strategies. We ran that comparison, checked it against the actual source of the popular frameworks, and wrote it up. Here is the short version.
The honest headline first
SWIRL does not win by using smaller chunks. Anyone can lower top_k. On a single lean query, a minimal config like LlamaIndex's default (top_k=2) sends fewer raw tokens than SWIRL. If someone tells you SWIRL "always uses the fewest tokens," a technical evaluator will disprove it in five minutes, and you will have lost them.
SWIRL's advantage is structural, and it shows up exactly where enterprise content lives: in corpora full of document versions.
First, it never spends tokens on duplicate or superseded versions. Stock top-k returns whatever is nearest in embedding space, which in a versioned corpus means several near-identical copies. SWIRL collapses them to one canonical document before the LLM ever sees them. Second, it always answers in one bounded call. The multi-document synthesis modes people reach for when they want quality (LangChain refine and map_reduce, LlamaIndex refine and tree_summarize) multiply LLM calls, and refine multiplies tokens super-linearly because it re-sends the growing answer at every step. SWIRL never pays that tax.
Putting numbers on it
Scenario: a query over a corpus where the relevant policy exists in five versions, plus three other relevant documents. A realistic enterprise shape. Here is the total LLM input tokens per query, summed across every call.
Reading it honestly: against a deliberately minimal stuff config (LlamaIndex compact, top_k=2), SWIRL is comparable per call, but that config buys its low count with poor recall and still ships duplicate versions. Against a typical stuff setup (k=5, roughly 1,000-token chunks), SWIRL is around 40 to 45 percent fewer input tokens, and it removes the redundant-version half entirely. Against the quality-oriented multi-call modes, SWIRL is a 2 to 3 times reduction in input tokens, and a larger reduction in output tokens, because those modes generate once per call.
What SWIRL 5 actually does
SWIRL treats the LLM prompt as a hard budget and fills it deliberately: a prompt capped at roughly 3,000 tokens, no more than 10 sources and only those scoring at least 0.8 for relevance, a topic matcher that scores the spans inside each source so only the passages that answer the query are sent, per-source truncation to fit the budget, and version de-duplication that drops the superseded copies before assembly. The result is about 3,000 input tokens, one call, and zero redundant-version tokens; a ceiling that does not grow with document or corpus size.
Where the advantage is real, and where it isn't
Real and hard to get off the shelf: cross-version de-duplication. None of these frameworks do it by default, and in a versioned corpus it is the difference-maker; the more versions, the more SWIRL saves. Also real: one bounded call versus N-call synthesis, and a predictable cost ceiling. And the honest caveat, which we put right in the study: a hand-tuned vanilla RAG (low k, a good reranker, small chunks, plus your own de-dup layer) can match SWIRL's per-call token count. SWIRL's value is delivering that discipline by default, and adding version de-dup the others lack. It is not magic per-token compression; it is better engineering, out of the box.
Read it, measure your own
The full write-up, with the verified framework defaults and source links, is on our RAG token efficiency page, and there is a one-page version you can download as a PDF. No form, no email. Then measure your own stack the same way: total input and output tokens per query, summed across every LLM call. That number, not top_k, is your bill.
To see SWIRL run this against your own corpus, request preview access.