Symbols Workflow comparison

get_symbols

Fetch multiple symbols by ID in a single call. More efficient than sequential get_symbol calls.

−91%
Token reduction
N× grep + Read
Native baseline

What it does

If get_symbol is the precise single-symbol fetch, get_symbols is the batch version that saves an agent from repeating the same retrieval pattern over and over.

Native agents usually do this the hard way: identify a set of candidate functions, open one, open another, open another, keep reconstructing context from repeated file reads.

get_symbols turns that into one structured batch retrieval step.

What the benchmark compares

The baseline is not one isolated file read. It is the closest native multi-symbol workflow: find candidate definitions, then read each candidate region separately.

Against that baseline, get_symbols typically wins by compressing both calls and output. The savings are often substantial because the native path duplicates file headers, surrounding code, and search noise across repeated reads.

Why this matters

Agents rarely stop at one candidate. They compare several handlers, several create* functions, several hooks, or several types with similar names.

When that happens, batch retrieval changes the economics of the workflow. Instead of five partial reconstructions, the agent gets one structured response with exactly the symbols it asked for.

When to use

  • After search_symbols returns multiple candidates you want to compare
  • Reading related functions from the same or different files
  • Any time you’d call get_symbol more than once

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.