Code changes. Context graphs don't.

A map that stops matching the territory

A context graph is a living map of how a codebase fits together: dependency edges, call chains, module summaries, implicit runtime couplings. But codebases move fast — features land, files get renamed, modules split — so a graph accurate at ROOT~50 silently misrepresents ROOT, and because nothing updates it on its own, the gap widens with every commit. What makes this worse than ordinary documentation rot is who's reading: a developer sees a stale wiki's date and applies skepticism, but an LLM has no such signal. It takes old edges and summaries as ground truth, so a stale graph doesn't just fail — it misleads, with full confidence.

That failure lands in three distinct ways:

You could regenerate the whole graph after every change, but nobody does — building it runs LLM analysis across the entire repo, and that costs real dollars and real minutes. At the pace a team actually commits, rebuilding on every merge would cost far more than the graph is worth. So the update has to work from the diff: re-analyze what changed, and leave everything else exactly as it was.

Update only what changed

lgraph update does not re-index the codebase. It computes a precise diff between the last indexed commit and ROOT, then drives each pipeline phase with only the changed surface. Unchanged files reuse their cached results exactly. The result is a graph that reflects ROOT, produced at a fraction of the cost of a full run.

Phase 1 — Explicit dependencies: content hashing

The explicit dependency analyzer maintains a per-file SHA-256 content hash, computed on whitespace-normalized source (CRLF — carriage return + line feed — collapsed to LF, trailing whitespace stripped, blank lines collapsed). Before re-running LLM extraction on a changed file, the phase checks whether the hash matches the cached result. A file where only whitespace or comments were reformatted gets a cache hit and costs zero tokens.

The phase falls back to full extraction only when it has to:

Incremental eligibility check

# Falls back to full extraction when any of these are true
language not in INCREMENTAL_ELIGIBLE_LANGS   # unsupported language
cache_data is None                           # first run, no prior state
prior_run.budget_stopped == True             # incomplete prior run
prompt_version != cache.prompt_version       # prompt changed, stale cache
model_id != cache.model_id                   # model changed, stale cache

That last pair matters: if we change the extraction prompt or the underlying model, the cache is treated as stale rather than silently mixed with new results.

Phase 2 — Implicit dependencies: threshold-gated diff exploration

Implicit couplings, like shared config keys, runtime event buses, and Redis channels, are harder to diff than explicit imports, because they aren't visible in any single file's text.

This phase computes a change ratio: changed_files / total_source_files. Below 35%, it runs a targeted diff-explorer: it loads the previously discovered entry-point signals and graph nodes, then runs LLM agents only on the modified surface. Above 35%, it falls back to a full scan.

Phase 3 — File enrichment: tombstone, re-enrich, patch

The file enrichment delta runner treats the three change categories differently. Deleted files are tombstoned: their snapshot entries, graph nodes, and module file references are all removed, so a deleted file leaves no ghost edges behind. Added and modified files are re-enriched from scratch. And modified files that other files depend on get their edge summaries surgically patched, without re-enriching every dependent from scratch.

Phase 4 — Wiki: selective module recomputation

Wiki re-runs module aggregation only for modules that contain changed files. Module docs untouched by the change are preserved exactly, byte for byte. The module tree is updated with a targeted upsert, so fields not modified by this run (like PR-mined insights) are never touched.

How the pipeline knows where to diff from

A per-project metadata document stores the git SHA of the last successfully indexed ROOT (per branch, for non-main branches). The terminal phase of every successful run advances this pointer. On the next lgraph update, that SHA becomes the base of the git diff. Simple, and it means an interrupted run never advances the baseline past what was actually indexed.

The thresholds at a glance

All three are tunable per deployment.

What this looks like in practice

We indexed localstack (1,987 files, 539K LOC) once, then made a normal ten-file change and ran lgraph update. Here is what each run actually cost.

Index once for $25. After that, folding in a normal ten-file change cost $0.10 and finished in under two minutes, about 0.4% of the index cost. Keeping the graph at ROOT is cheap enough to run on every commit.

One property matters most: every update calls the LLM only on what actually changed. The wiki and file-index phases compare content hashes against the saved snapshot and skip anything untouched, so the work scales with the size of the diff, not the size of the repo. The graph your agent reads stays the graph of the code you actually have.

npm install -g @latentforce/latentgraph
lgraph init          # index once
lgraph update        # keep it at ROOT