The call graph from your compiler or type checker, for humans and coding agents
Who calls a function, what it calls, who uses a type or a field, and edits by symbol. x.get() links
to the get of x's type, because the language's own compiler resolves it, where a text search finds every get.
It also has the tools an agent needs instead of Grep, Glob, Read, Edit and Write, so the graph stays up
to date as the agent works.
On macOS and Linux:
| Language | Status | Answers come from |
|---|---|---|
| Rust | Supported | rust-analyzer |
| TypeScript | Supported | tsrs |
| JavaScript | Supported | tsrs |
| Python | Supported | pyrefly |
| Go | Supported | scip-go andgopls |
| C | Supported | clangd-indexer andclangd |
| C++ | Supported | clangd-indexer andclangd |
| Java | Next |
Lantern Lattice's own code: Live
A chosen symbol: what calls it, what it calls, what it uses, and its source.
With Homebrew, on macOS and Linux:
brew install julymetodiev/tap/lantern-lattice
Or download an archive for your platform from the
latest release and put latt on your PATH.
The binaries are not signed, so on macOS one downloaded in a browser may need
xattr -d com.apple.quarantine latt.
Or build it, with Rust 1.95 or newer:
cargo install --git https://github.com/julymetodiev/lantern-lattice lantern-lattice
For exact answers, Lantern Lattice needs rust-analyzer for Rust, tsrs for TypeScript and JavaScript, pyrefly for Python, go with scip-go and gopls for Go, and clangd with clangd-indexer for C and C++. In a Python project, install its packages in a .venv at the top: without them less is answered. A C or C++ project needs a compile_commands.json, at the top or in build/, and Lantern Lattice never runs what makes one, as that runs the project's code.
rustup component add rust-analyzer rust-src
npm install -g tsrs
pipx install pyrefly
go install github.com/scip-code/scip-go/cmd/scip-go@latest
go install golang.org/x/tools/gopls@latest
clangd comes with xcode-select --install on a Mac and with the system's package on Linux. clangd-indexer is in clangd_indexing_tools of a release of clangd.
In a git repository, nothing else is needed. The first command starts a daemon, which stops after 30 idle minutes or when the project is gone.
latt trace -s process_data # who calls it, what it calls
latt trace -s process_data --callers # only who calls it
latt impact # what the uncommitted changes touch, and what depends on them
latt impact --base main # the same for a whole branch
latt search --pattern "^process" # symbols by regular expression
latt grep "TODO" --path "*.rs" # text in any file, with the symbol it is in
latt read -s process_data # the source of a symbol
latt files "crates/**/*.rs" # files by glob, skipping what git ignores
latt cat src/lib.rs --first 10 --last 40 # a file, numbered
latt write src/new.rs --content "fn new() {}" # a new file; --overwrite to replace one
latt edit --symbol process_data --mode symbol --content "fn process_data() {}"
latt edit --file src/lib.rs --mode text --old "a = 1" --content "a = 2" # exact text, found once
latt sync # up to date, wait until nothing is provisional
Through MCP, the same operations are tools the model can use: trace, impact, search, read,
edit_symbols, insert_after, grep, files, read_file, edit_lines, replace_text,
write_file, sync, status. The server is latt mcp, and it serves the git repository of the
directory it runs in. So for most agents, add it to the project's own settings. latt must be on the
PATH the agent sees.
The plugin brings the server and a skill that tells the model when to use it instead of Grep, Glob, Read, Edit and Write:
/plugin marketplace add julymetodiev/lantern-lattice
/plugin install latt@latt
Or only the server, without the skill:
claude mcp add --scope user latt -- latt mcp
There is no plugin for these yet: add the server to the file shown. Claude Code is the one agent Lantern Lattice has been used with so far, so these come from each agent's configuration format and are untested. If one does not work, please open an issue.
| Agent | File in the project |
|---|---|
| Cursor | .cursor/mcp.json |
| Gemini CLI | .gemini/settings.json |
| Roo Code | .roo/mcp.json |
{ "mcpServers": { "latt": { "command": "latt", "args": ["mcp"] } } }
Codex, in .codex/config.toml:
[mcp_servers.latt]
command = "latt"
args = ["mcp"]
VS Code, in .vscode/mcp.json:
{ "servers": { "latt": { "type": "stdio", "command": "latt", "args": ["mcp"] } } }
Zed, in .zed/settings.json:
{ "context_servers": { "latt": { "command": "latt", "args": ["mcp"] } } }
OpenCode, in opencode.json:
{ "mcp": { "latt": { "type": "local", "command": ["latt", "mcp"], "enabled": true } } }
Any other MCP client: run latt mcp over stdio in the project's directory. To teach an agent when to
use the tools, put the skill's text in its
instructions, such as AGENTS.md.
Look at Lantern Lattice's own code this way, in a browser with WebGPU. On your project:
latt view
A browser opens on the whole graph, which changes as the code and the agents do. Symbols are placed by
crate and file. Zoom in, search, or choose a symbol to see what it calls, who calls it and its source.
What a query or an edit touches lights up as it happens, blue for a read and red for an edit, so you can
watch an agent work. It only reads, loads nothing from the network, and listens on 127.0.0.1 with a
private token in the address. It needs a browser with WebGPU; it has been tried in Chrome.
latt view --export DIR writes the same page as files for any static host, with the graph as it is and
the source of every symbol, so use it only on code that may be public.
- A call in
traceis exact. A call Lantern Lattice cannot be sure of is left out, never guessed. [via trait, possible]and[implementation, possible]: which implementation runs is decided at runtime.[as value, possible]: a function named without being called, as in.map(helper), or a constant holding one. It may run later, or never.[reads it]: on a constant or static, a symbol that reads it.[uses it]: on a type or field, a symbol that names it. Neither of these is a call, and they come only for what you traced, not further along a chain.Partial:analysis is still running, so calls may be missing. Ask again shortly.
Without rust-analyzer, tsrs, pyrefly or scip-go, or with LATT_NO_SCIP=1, only syntax rules apply, and latt sync says how many files that covers. In Rust they find about half the calls. In the others they link only
functions of the same file or of an import in the project, and no methods.
On a copy of a project with 1311 Rust files and 20 260 symbols, on a laptop:
| A query with nothing changed | 0.01 to 0.02 s |
| A first answer after an edit | about 1 s (0.8 to 1.1 s), marked partial until complete |
| A complete answer after the first edit | 8 to 12 s, then under 1 s |
| From no daemon to a first answer | 3.2 to 3.8 s, with the index already written |
| A first index | 1 to 2 minutes, at a peak of about 6 GB |
| Memory | daemon about 370 MB idle; rust-analyzer about 2.2 GB while in use, stopped after 10 idle minutes |
On TypeScript, JavaScript and Python projects, on the same laptop, with the server stopped after 10 idle minutes too:
| hono | nest | three.js | flask | requests | django | |
|---|---|---|---|---|---|---|
| Symbols | 12 497 | 27 854 | 27 387 | 2 046 | 1 114 | 67 865 |
A first latt sync |
11 s | 48 s | 45 s | 2.1 s | 1.5 s | 65 s |
| A new daemon with nothing changed | 1.0 s | 2.9 s | 4.2 s | 0.1 s | 0.1 s | 12 s |
| Daemon after asking | 121 MB | 187 MB | 373 MB | 31 MB | 27 MB | 539 MB |
| The server while in use | 963 MB | 1.6 GB | 603 MB | 233 MB | 178 MB | 614 MB |
An edit of a file most of a project imports asks about those files again: about 30 s on nest and django, with answers marked partial until then.
On Go projects, which work as Rust does, with an index and gopls for the files edited since:
| hugo | kubernetes | |
|---|---|---|
| Symbols | 19 065 | 221 808 |
A first latt sync , compiling what the project needs |
331 s | 513 s, and 14 GB in Go's build cache |
| A new daemon with nothing changed | 1.3 to 1.9 s | 32 s |
| A first answer after an edit | under 0.9 s | not measured |
| Daemon after asking | 96 MB | 1.7 GB, and a peak of 4.7 GB while it reads the indexes |
On Lantern Lattice's own code, 1326 of 1326 calls between its functions match what rust-analyzer reports. The
measurement says 1325, and the one difference is the measurement's: SCIP gives two functions in
different test binaries one symbol. Every entry of a hand-written list of traps in
crates/latt-resolve-ra/tests/fixture/expected.rs holds too: same
names across types and crates, calls inside macros, trait methods. Scripts behind these numbers are in
scripts/bench.
Who uses what, against rust-analyzer's find-references on the project above:
| Compared | Both agree | Only Lantern Lattice | Only the server | |
|---|---|---|---|---|
| Constants and statics | all 944 | 1814 | 46 | 13 |
| Types and traits | a sample of 40 | 420 | 0 | 0 |
| Variants | a sample of 40 | 295 | 0 | 0 |
| Fields | a sample of 40 | 157 | 0 | 0 |
"Only Lantern Lattice" is mostly code a server on this machine does not compile, as behind #[cfg(...)] or a
feature. A graph kept up to date through edits had 0 differences from a new index, on edits of comment
lines in 3 files. These are measurements of one project, not a guarantee for yours.
In TypeScript and JavaScript, against scip-typescript, the targets inside a project agree at 70 998 of 72 557 places on hono, 57 401 of 58 894 on nest and 91 559 of 108 715 on three.js. Nearly all the rest are places only tsrs answers, or the start of a file against its first line; scripts/bench/scip_compare.py names each kind. After edits of comments in 2 to 3 files the graph had 0 differences from a clean start, on hono and nest. Agreement is not proof: these two tools can be wrong together.
In Python, against scip-python, the targets of places that name a function agree at 739 of 778 on flask and 414 of 434 on requests; on django that comparison did not finish. Most other differences read are local variables assigned twice, which give no edge. pyrefly gave the same targets at all 299 205 calls and attributes on django with files asked in reverse order, and after edits of 3 files on django the graph had 0 differences from a clean start. Agreement is not proof.
Known limits in Python: pyrefly runs a project's .venv/bin/python (see SECURITY.md). What has no type has no target, about a fifth of the calls in django's own code, and Lantern Lattice leaves those out and does not guess. A call through a variable, as alias() after alias = plain, or cls(), gives no edge. A call the source does not spell gives none either, as a + b running __add__. A class that fits a Protocol without naming it is not shown as implementing it. A package installed without a change to a lock file leaves saved answers stale. Environments other than a .venv at the top of a project are not measured.
Known limits in TypeScript and JavaScript: what has no type has no target, so plain JavaScript gets about two thirds of its calls (62% on express, 66% on three.js, against 91% and 94% on TypeScript projects). Lantern Lattice leaves the rest out and does not guess. list[0].area() on a union of types shows one member. pnpm and yarn workspaces are not measured, and .vue and .svelte files are left out. tsrs is a young beta.
In Go, against gopls, all 103 967 places on hugo that name something agree or fall in a known class: 50 369 at the same place, 36 908 outside the project in the same package, and the rest definitions, built-in names and files outside the build.
Known limits in Go: a first index compiles the project, as a build does, and a go.mod may make Go fetch the toolchain it names (see SECURITY.md). A file behind a build tag or for another system has syntax rules only, and latt sync says how many there are. A file over 500 KB is left out, in any language. C.f() is not linked. A call the source does not spell, as through reflect, has no edge, and neither has f() on a variable holding a function.
Known limits in Rust: a proc macro that fails silently while the index is written loses its calls;
one that says so is handled. A read and a write of a field are not told apart. A constant inside a format string has a read only in macros known to take one, and only if it is an item of the same module or imported by a project path: an attribute such as #[error("{NAME}")], a glob import or a renamed import leaves it out. A function named in an attribute, as in #[serde(skip_serializing_if = "name")], has no call. Replacing a file by renaming breaks a hard link to it.
Left out on purpose for now: telling a read of a field from a write; keeping hard links when a file is written.
Read docs/ARCHITECTURE.md, the specification, and
CONTRIBUTING.md. scripts/check.sh runs every check.
Security: SECURITY.md. Changes: CHANGELOG.md. Releases: RELEASING.md.