AI DevelopmentOpen Source

PageIndex: Vectorless RAG Where an LLM Navigates a Document Tree

October 14, 2026
10 min read
A small branching structure of thin wire and beads on a neutral surface, suggesting a tree index
Share:

PageIndex (VectifyAI/PageIndex) takes the vector database out of RAG: it turns a long PDF into a hierarchical tree of sections and lets an LLM reason its way down that tree to the pages that answer the question. No embeddings, no chunking, no vector store.

I read the README, the docs and the package source on 2026-10-14 to separate what the open-source local mode does from what lives only in the vendor’s cloud. I did not run it: every command and number below is attributed to its source.

1. What It Is: Stars, License and Scope

PageIndex is a Python SDK from Vectify AI. Its README calls it a vectorless, reasoning-based RAG engine: each document gets a tree index (think table of contents with summaries) and the chat model searches that tree instead of running a similarity query over chunk embeddings.

⭐

GitHub stars

39,124

GitHub API, 2026-10-14. Repo created 2025-04-01

⚖️

License

MIT

LICENSE file and PyPI metadata

🏷️

Latest release

v0.4.0

Published 2026-10-12. Needs Python 3.10+

🐍

Language

Python

pip install -U pageindex

Vector RAG vs PageIndex (the README’s own comparison)

Vector RAGPageIndex
IndexVector index of chunk embeddingsTree index of the document structure
RetrievalSemantic similarity searchLLM reasoning over the tree
ResultOpaque “vibe retrieval”Traceable to explicit references
ContextOnly the query embeddingCan use conversation history and domain knowledge

Read that table as the vendor’s position

Every row is the authors’ framing. The useful question is not whether trees beat vectors in general, but which of your documents have a structure a tree can exploit. Section 7 covers that.

2. The Architecture in 4 Steps

Putting together the README, the PageIndex Flash post (2026-08-26), the original PageIndex post (2025-09-19) and the package’s agent tools, the flow is four steps.

🌳

1. Build the tree from the layout

Flash, the local default indexer, reads the PDF’s existing layout to extract the outline. Per the README the structure comes from the document layout without an LLM; the index model only writes node summaries and refines the tree, and the authors say a basic model is enough.

🗂️

2. Store the index locally

The tree and its page references are saved in a local directory (Cloud mode keeps them in PageIndex’s storage instead). Each node links back to its raw content by node_id, which is how a node becomes real pages later.

🧭

3. The chat model reads the outline and picks sections

At query time the answering model, not an embedding lookup, receives the outline. In the package’s agent tools this is get_document_structure, and for documents over 20 pages the local instructions tell the agent to read the structure first.

🔁

4. Fetch pages, check, answer with citations

The agent pulls pages with get_page_content using ranges like “1-3,7”, checks whether it has enough and goes back if not (the original post’s loop: read the ToC, select a section, extract, check sufficiency, answer). Add client.citation_prompt() and answers carry page-level tags such as <cite doc=“report.pdf” page=“12”/>.

Where the tool names come from

The docs page for agents does not list tool names. browse_documents, get_document, get_document_structure and get_page_content come from agent_tools.py in the repository on 2026-10-14, plus remove_document when include_management=True. Treat them as internals: v0.2.21 already changed the tree shape in a breaking way.

3. Quickstart (Verified Against the README, 2026-10-14)

The install command and both snippets are copied from the README. I did not execute them: the pip install and the LLM calls are yours to run in a clean virtual environment with your own key.

Install

pip install -U pageindex

Local mode: index and chat on your machine

import os
from pageindex import PageIndexClient

os.environ["OPENAI_API_KEY"] = "your-openai-key"

client = PageIndexClient(
    index="gpt-6-luna",                 # model to build the tree index
    chat="gpt-6-sol",                   # model to search the tree
)
doc_id = client.submit_document("report.pdf")["doc_id"]

answer = client.chat("What was the 2023 operating margin?", doc_id=doc_id)
print(answer)

Cloud mode: same client, index stored by PageIndex

import os
from pageindex import PageIndexClient

os.environ["PAGEINDEX_API_KEY"] = "your-pageindex-key"
os.environ["OPENAI_API_KEY"] = "your-openai-key"

client = PageIndexClient(
    index="cloud",                       # build and store the index in PageIndex Cloud
    chat="gpt-6-sol",                    # use your preferred compatible model for chat
)
doc_id = client.submit_document("report.pdf", wait=True)["doc_id"]
print(client.chat("What was the 2023 operating margin?", doc_id=doc_id))

Model names disagree inside the README

The quickstart and the v0.4.0 defaults use gpt-6-luna (index) and gpt-6-sol (chat). The Benchmarks section, the docs and the benchmark repo use gpt-5.6-luna and gpt-5.6-sol. Use whichever IDs your provider exposes: the config file says names are LiteLLM’s, so bare names are OpenAI models and other providers use provider/model, for example anthropic/claude-sonnet-5-5.

Plugging it into your own agent

docs.pageindex.ai/sdk/agents lists these helpers. Tools are read-only unless you pass include_management=True.

  • • client.agent_tools(): plain Python functions for any framework
  • • client.as_openai_tools(): OpenAI Agents SDK
  • • client.as_anthropic_tools(): Anthropic SDK tool runner
  • • client.as_claude_mcp(): MCP configuration for the Claude Agent SDK

Pin the version

Five releases landed between 2026-09-21 and 2026-10-12. v0.2.19 renamed resolve_citations to get_citations and v0.2.21 changed the tree shape, both flagged as breaking in the release notes. v0.4.0 requires Python 3.10+ and litellm 1.105.0+. Pin pageindex==0.4.0 and read the notes before every upgrade.

4. Local vs Cloud: What the Open-Source Mode Does Not Do

This is the part most summaries skip. The README’s own table, with the Cloud column being the vendor’s hosted service:

FeatureLocal (open source)Cloud
DocumentsText-based PDFsText-based, scanned and image-rich
IndexingOn your machineManaged by PageIndex
StorageLocal directoryCloud storage
CitationsPage-levelBlock-level
OCR & image understanding—✓
Metadata—✓
Folders—✓
MCP server—✓

The practical consequence: a pile of scanned contracts, or slide decks where the meaning sits in figures, is a Cloud job (OCR and image understanding run there). The local package reads only the PDF’s text layer.

MCP is a cloud feature

The hosted MCP server (https://api.pageindex.ai/mcp, Bearer API key) answers questions over documents already indexed in your PageIndex Cloud account. The SDK also has an as_claude_mcp() helper for the Claude Agent SDK; the README table still lists the MCP server as Cloud-only, and I did not verify how that helper behaves in local mode.

Scale-out is vendor territory too

The PageIndex File System post (2026-05-03) describes a tree layer over many documents: virtual topic nodes, LLM-inferred metadata and layer-wise navigation. It ships with PageIndex Enterprise, with the cloud rollout announced as coming. It is not part of the open-source local mode, and the post gives no cost or latency figures.

5. Cost and Latency: What LLM Tree Search Really Costs

A vector query is one embedding call, an index lookup and one generation. A PageIndex query is a multi-step LLM loop: the answering model reads the outline, requests pages, judges whether it has enough and may go around again. You pay for that in tokens and in seconds. These are the vendor’s own numbers, all self-reported.

💵

~$0.001 / page

Local indexing cost

README, index model gpt-5.6-luna: a 1,000-page textbook costs a little over $1, once

⏱️

13 s to 4.5 min

Indexing time

Benchmark documents from 9 to 1,098 pages, same local setup

🎯

85.5% to 100%

Accuracy on 62 questions

gpt-5.6-luna, no reasoning: 85.5% (53/62) at $0.0031 per question; high effort: 96.8% at $0.0036; gpt-5.6-sol medium or high: 100% at about $0.081

📄

2.1x to 16.6x

Native PDF vs tree, cost per query

From 52 up to 420 pages; at 805 pages the PDF no longer fits the context window. Prompt caching excluded

What the numbers do not tell you

The benchmark reports no latency and has no vector-RAG baseline. It covers 62 lookup questions whose answers sit in running text (charts, tables, figures and arithmetic were excluded), and documents PageIndex refused to index were left out instead of scored as failures. The 98.7% FinanceBench figure comes from the Mafin 2.5 post (2025-02-19): it does not name the model or the grader, and says other systems were tested on 66.7% of the dataset. The README chart shows vector RAG at 50%.

My reading (inference, not a measurement)

Compared with one vector lookup, every question carries extra LLM round trips, and the model doing the search is the expensive one the README tells you to buy (“the best model you can afford”). For a few documents and a person waiting, that is fine. For high query volume or a latency budget in milliseconds, measure it on your own questions before committing. I found no independent latency benchmark.

6. Where It Fits

These are the problem shapes the design targets, based on how the vendor describes it. I have not tested them myself.

📊

Long financial and regulatory filings

Annual reports and filings with a real heading structure and cross-references. FinanceBench, the benchmark the vendor cites, is built from SEC filings.

📘

Manuals, specs and textbooks

Documents where the answer lives in a section and “see Appendix G” style references matter, a case the original post argues similarity search misses.

⚖️

Contracts and policies with audit needs

When you must show which page an answer came from: page-level citations come back as structured data through get_citations.

🤖

A document tool inside your own agent

Give an agent a handful of long reference PDFs through the OpenAI Agents SDK, Anthropic SDK or Claude Agent SDK helpers.

7. When NOT to Use It

This is the section I would have wanted before adopting it.

✅ A good fit if...

  • • You have a handful of long, text-based PDFs with real headings
  • • You need traceable page citations, not just an answer
  • • Query volume is low and a person is waiting anyway
  • • You want indexing on your own machine and accept that text still goes to the LLM provider you configure
  • • You can pay for a strong chat model on the search step

⚠️ Skip it (or go hybrid) if...

  • • Your PDFs are scanned or image-heavy and you must stay local: local mode reads only the text layer
  • • You search across thousands of documents: the multi-document tree layer is Enterprise and Cloud, not the open-source package
  • • You need millisecond latency or cheap queries at high volume
  • • Your queries are exact identifiers such as error codes or SKUs: lexical or hybrid search is built for that
  • • Your content has no structure (chat logs, tickets, scraped pages): a tree has little to work with
  • • You need MCP, folders or metadata without the vendor’s cloud
  • • You need a stable API today: it had breaking changes twice in the last month

My take

Treat PageIndex as a navigation layer for the few documents that matter, not as a drop-in replacement for your vector store. If you already run hybrid search, keep it for discovery across the corpus and let a tree-guided read handle the deep document. Whatever you pick, build a labelled question set first: the benchmark above is the vendor’s, and the only numbers that count are the ones on your documents.

Conclusion

PageIndex is a clear, well-scoped idea: let the model read the outline the way a person would, then open only the pages it needs. The open-source package gives you that for text-based PDFs on your own machine, with an LLM bill that is small at indexing time and larger at query time.

What it does not give you for free is OCR, folders, metadata, a hosted MCP server or the multi-document tree layer. Those are the vendor’s cloud and enterprise offering, and it is worth knowing where that line sits before you design around it.

Verification stamp

Commands, API names and numbers were checked against the README, the docs pages, the package source listing, PyPI and the release notes on 2026-10-14 (v0.4.0). I did not install or run the package. Benchmark figures are the vendor’s and self-reported.

Sources

Diego Rodriguez

Diego Rodriguez

Senior Full-Stack & AI Engineer

Diego has 10+ years of experience building production-grade AI-powered applications, from LLM orchestration and RAG pipelines to ML-driven risk detection and algorithmic trading systems.

Learn more about Diego →