Understand the code first
Before Squeezy spends a single model token reasoning about your code, it reads your repository locally and builds a map of what is declared where and how it all connects. That map lets the model ask precise questions and fetch exact answers instead of pouring whole files into the prompt.
Why this is the first place savings come from
Most of what a coding agent needs to know about a codebase is repetitive, mechanical bookkeeping: where a function lives, what its signature is, who calls it, what type it returns, what changed since the last commit. A naive agent answers every one of those questions by reading files, and files are expensive. Asking “what does this function do?” by reading the 1,500-line file it happens to live in can cost thousands of tokens to look at 50 lines of code, and every follow-up re-pays that price.
Squeezy moves that bookkeeping off the model. Parsing, indexing, and cross-linking your code is cheap, repetitive work that a CPU does well and does once. The model's tokens then go only to the hard, non-repetitive part: the reasoning. This is the first and most important saving layer because it changes the unit of retrieval: the model stops asking for files and starts asking for shapes.
Mapping the repository, locally
When Squeezy opens a workspace, it parses every supported source file and builds a code knowledge database: a structured index of the files, modules, classes, functions, methods, and the relationships between them. This happens on your machine; nothing is uploaded to build it.
From that index the model can request a repository map: a compact, depth-limited outline of the architecture, language coverage, and the obvious next places to look. Instead of reading a dozen files to orient itself, it reads one small map. The map is bounded by design, so even a large monorepo produces an outline the model can digest rather than a wall of text.
- Built incrementally: as you edit, only the parts of files that changed get re-read, so the map stays fresh without rescanning the repo on every keystroke.
- Clear about confidence: every relationship carries a label (exact, import-resolved, candidate, external) so the model knows how much to trust each one instead of guessing.
Finding where something is declared
The most common navigation question is “where is this defined?” Squeezy answers it with a declaration lookup against the knowledge database rather than a text scan. You can search by name or by a phrase, and results come back ranked, an exact name match always beats a fuzzy one, so a search lands on the function named that, not on something that merely mentions it in a comment.
Each result is a small packet, not a file: the symbol's signature, location, and kind, plus a suggested next step. The model can read just the signature first, then decide whether it needs the body at all. A declaration search costs a few hundred tokens; the grep-and-read-everything alternative across a repo routinely costs tens of thousands.
- Anchoring by position: a line, column, or byte offset, say from a compiler error or a grep hit, resolves to the smallest symbol that encloses it, so a raw location becomes an anchor the model can navigate from instead of a coordinate it has to re-find by hand.
Finding callers, references, and call chains
“Who calls this?” punishes the file-reading approach worst of all. The naive method is to grep for the name, then open every matching file in full to confirm the hit. On a widely-used function that is tens of thousands of tokens, most of them are wasted on code the model never needed.
Squeezy answers it as a single query. Because calls and references are recorded in the knowledge database, asking for the callers of a symbol returns a tidy list of one-line entries directly, with no file reads. The same surface gives you the reverse direction (what does this call?), broader references like type mentions and identifier uses, and bounded call-chain context for “does A eventually reach B?”. When a call is ambiguous, results are capped and labeled as candidates so a heavily-used method doesn't flood the model with thousands of hits.
- Callers and callees come straight from the knowledge database, so “who calls X” is one query instead of repeated grep-and-read.
- References cover more than calls: type references, identifier uses, and attribute mentions, each tagged with how confidently it binds.
- Call chains are bounded, so tracing a path through the code never runs away into an unbounded payload.
Type and dependency hierarchy
Beyond individual symbols, Squeezy tracks containment and inheritance: which class contains which methods, which type extends, implements, or mixes in which other, which file imports which. That lets the model walk a hierarchy on purpose, in either direction, “show me everything under this module,” “what are all the subtypes of this base class, not just the direct ones,” or “which of those subtypes override this method” become structured traversals rather than a hunt across the tree.
This is where cross-file work pays off most. When the answer is spread across modules, the call site in one file, the definition in another, the type three files away, the knowledge database stitches those together in a few queries. The hierarchy and dependency links are the connective tissue that makes “trace this through the codebase” cheap.
Reading exact lines, not whole files
When the model does need to look at source, it reads a slice, not a file. Squeezy splits every declaration into its signature and its body. The signature, the line that tells you the name, parameters, and return type, is typically 50 to 150 tokens. The body is fetched separately, only when the implementation matters.
So the model can read a function's signature for about 50 tokens and frequently learn everything it needed, versus thousands of tokens to read the whole file it lived in. When it does want the implementation, it asks for just that function's body. Slices can also be requested by plain line range when the model already knows where to look, and a too-tight request is widened slightly so a clipped function doesn't force an immediate second fetch.
- Signature first: read the small shape before deciding whether the whole file is worth it.
- Body on demand: the implementation comes as its own slice, scoped to the function that matters.
- Graceful fallback: if a symbol has no separate body (a constant, an abstract method), asking for the body returns the full declaration rather than nothing.
The current diff as first-class context
“What did I just change, and what does it touch?” is a question you ask constantly while working, normally answered by running a diff and then re-reading files to understand the blast radius. Squeezy treats the current change set as a first-class part of the knowledge database: one query returns your changed files and hunks with the enclosing symbols already identified, so the model can triage what moved without re-fetching the surrounding source.
Because changed symbols are cross-referenced against the rest of the knowledge database, the natural follow-ups, who calls the thing I just edited, what depends on it, come for free off the same starting point, and a single blast-radius query returns the whole picture at once: the affected files, the symbols and tests that depend on the change, and how far it reaches, bounded so even a widely-imported edit stays a tidy list rather than a re-read of half the repo. You can scope the diff against the working tree, the index, or the branch base. Reviewing your own work in progress costs a query, not a re-read.
When a file isn't supported
The code knowledge database covers 22 languages. Within those, navigation is indexed and precise. For anything outside that set, a config file or a template, Squeezy does not pretend. Instead of fabricating confidence, it falls back to bounded search and reads: scoped grep, glob, and file reads that stay inside sensible limits. The model can still work with those files; it uses the labeled fallback path, and results are clearly marked so nothing is presented as more certain than it is.