A plain-language tour

Your code is a map,
not a pile of text.

travsr reads your whole codebase, turns it into a graph (who calls whom, what depends on what), keeps that map up-to-date on every git commit, and lets an AI assistant walk the map instead of guessing from scattered snippets.

The one analogy to remember

travsr is Google Maps for a codebase. Functions are places. A function calling another is a road between them. When you ask Google Maps “how do I get from A to B?”, it doesn’t re-read every street sign, it already has the road network and just traverses it. travsr does the same for code: it builds the road network once, then answers questions by following roads.

The problem it solves

Today most AI coding tools use “vector search”: they chop your code into chunks, convert each chunk into a list of numbers, and when you ask a question they fetch the chunks that look similar. That’s like finding directions by grabbing a handful of random street-view photos that resemble your destination. It wastes words (tokens) and the AI often invents connections that don’t exist (“hallucinations”).

The old way: text chunks

Search by fuzzy similarity over text. No idea what actually calls what. The AI guesses structure. More tokens, more mistakes.

vector RAG

The travsr way: a real graph

Search by following real edges the compiler-grade parsers found. The AI sees true call paths, so it works from fewer, more relevant tokens and does not have to invent structure that is not there.

graph traversal

See it once

Here is a tiny real-world example used throughout this whole site: an online payment flow. Each circle is a function; each arrow is a call. Hover or tap the buttons, this exact graph is what every algorithm below operates on.

The example: an online payment’s call graph
function / method calls (RefCall) depends-on

This is the graph travsr stores in .travsr/graph.db. Click a button to highlight a real query.