Treeweft indexes codebases into a structured representation that combines semantic embeddings with a graph of the code's actual relationships — calls, imports, inheritance, references. Ask "how does authentication work in this repo?" and get the right code, not a pile of grep matches and partial file reads.
Dumping the whole repo into context burns tokens and dilutes attention. Grep finds strings, not concepts. Standard RAG treats code like prose, which it isn't.
Code has structure worth preserving: an AST parsed by tree-sitter, a graph of how files and symbols relate, and semantic embeddings that capture meaning. Combine all three and retrieval becomes specific, structural, and faithful to how code actually works.
Tree-sitter produces real syntax trees for every supported language, so chunks respect function and class boundaries — never mid-statement cuts.
Calls, imports, inheritance, and references become edges in Neo4j. Traverse from a symbol to its definition, callers, and dependencies — the way you'd actually navigate code.
Code chunks embed for semantic search via a horizontally scalable fleet — Hugging Face TEI (CPU or CUDA), or your preferred hosted service via config.
A separate reranking stage refines initial retrieval, because the top embedding match isn't always the right answer.
First-class MCP support means Claude and other MCP-capable assistants use Treeweft directly as a tool — no bespoke integration required.
Self-host the full stack with one docker compose, or scale embeddings and storage out across machines. Same codebase, both shapes.
Not a single binary. The indexer owns parsing, chunking and all retrieval; the MCP server is a thin proxy to it. A Postgres-backed job queue survives restarts mid-job. Vectors live in Milvus, LanceDB or Chroma, the code graph in Neo4j or SQLite, and embedding and reranking run on self-hosted CPU or GPU workers or through a hosted API.
Scroll sideways to see the whole diagram →
We gave a real LLM agent 200 questions about featbit — a ~1,900-file C#/TypeScript codebase pinned at v5.4.9 — once with Treeweft and once with a grep/glob/read loop, on DeepSeek, Claude Sonnet 5 and GPT-5.5, scored by an independent judge. Treeweft matched grep's answers for less in every configuration — most of all when you can describe what code does but don't know what it's called.
September 2026, n=100 per configuration. Cost differences are significant per query on every symbol-free configuration; answer-quality differences are not significant in any (best p = 0.061). One repository, one run per configuration. Full results, significance tests and caveats →
100 mid-to-large open-source GitHub repos across several popular languages, roughly 650,000 files in total — of which 95 completed end-to-end. The 5 failures had two known causes, an I/O ReadError under high indexing concurrency and chunks exceeding the vector store's varchar ceiling; concurrency is now capped by a semaphore, and oversized chunks route to a CPU embedding backend instead of crashing the GPU one. Initial naive indexing took an estimated week-plus. After tuning Milvus topology, embedding batch sizes, fleet size, and request distribution, the same workload finishes overnight. The scaling axis is embedding-worker parallelism; everything else stays boring.
You want better code search than grep and ripgrep on codebases too big to hold in your head — without leaving your terminal or IDE.
You need to give LLMs faithful, token-efficient access to large internal codebases so the answers stop hallucinating file paths.
You want to understand how a project works without reading every file — and you'd rather start from the graph of how it's wired than a flat directory tree.
Source code, documentation, and installation instructions live on GitHub. The project draws on prior work including repomix and conversations in the broader code-retrieval and repository-level-RAG community.