go_to_definition
LSP-precise definition lookup understanding scope, imports, re-exports, and type aliases. Falls back to AST when LSP unavailable.
What it does
go_to_definition answers a different question than grep.
- Grep answers: “Where does this string appear?”
- go_to_definition answers: “Which definition does this usage resolve to?”
That difference becomes critical as soon as a codebase has re-exports, shadowed names, overloads, multiple similarly named helpers, or type aliases and indirection.
How to think about the baseline
There is no strict 1:1 shell equivalent for resolved definition lookup. The closest native workflow is: grep for the symbol name, inspect candidate files, infer which one is probably the real target.
That workflow is slower, noisier, and sometimes ambiguous by construction.
The honest claim is: go_to_definition replaces an approximate search-and-guess workflow with a resolved navigation step. That is a capability advantage first, and a token advantage second.
Supported language servers
| Language | Server |
|---|---|
| TypeScript/JavaScript | typescript-language-server |
| Python | pylsp |
| Go | gopls |
| Rust | rust-analyzer |
| Ruby | solargraph |
| PHP | intelephense |
Lazy start + 5-minute idle kill. Zero overhead when not used.
Related tools
Benchmark note
This benchmark compares CodeSift against the closest practical native workflow an agent would use for the same task.
For some tools, that baseline is a direct shell equivalent such as rg or find.
For AST-aware, graph-aware, and LSP-backed tools, the baseline is a multi-step workflow rather than a strictly identical command.
Results should be read as agent-workflow comparisons: token cost, call count, and practical context efficiency.