01 · read funnel

The cheapest tool that answers.

A model that reads code needs three different answers to "what is this doing" — one free, one instant, one that actually knows what a symbol is. Engine picks between them; it never guesses with just one.

Three tiers, cheapest first.

01 · grep

~0ms · this file only

search and read_file. Free, but it doesn't know a symbol from a string — burns context reading whole files to find one function.

list_filesread_filesearch

02 · tree-sitter

~0ms · this file only

Parses one file, no server, no warm-up. find_symbol returns the definition and its exact coordinate — the handoff into the LSP tools. Doesn't know what the file imports.

list_symbolsfind_symbolget_node_atquery_treeparse_file

03 · language server

seconds · whole workspace

Warm start indexes up to 500 files before the first question. Answers where a symbol actually comes from and who calls it — real types, not guesses.

goto_definitionfind_referenceshoverget_diagnosticsdocument_symbolsrename_symbol

Climbing in order.

ask and coder both follow the same cost hierarchy on every question:

1search / list_fileslocate the file

2list_symbolssee what's in it

3find_symbolone definition's source, plus its 1-based coordinate

4goto_definition / find_references / hoverthe cross-file, cross-type question

5get_diagnosticswhat the type checker already knows

6read_filewindows for whatever context is still missing

find_symbol's coordinate is the handoff — it feeds the LSP tools directly, so the model is never asked to count characters itself.

Why three, not one.

Grep alone can't tell a symbol from a string, and burns context reading whole files to find one function. Tree-sitter alone can't tell you that the parse_config it just read is a different parse_config than the one three directories away. Only the language server knows that — and it costs seconds to ask.

The full argument: why a coding agent needs three different ways to read code.