There are a lot of AI coding agents right now, and the marketing is mostly noise — every one of them “understands your whole codebase.” So I read the source of three, and they split cleanly into three camps by one design choice: how they get your code into the model’s context. Aider ranks a static graph of your code. Continue embeds it into a vector index and retrieves. Cline builds no index at all and lets the model read files on demand through tools. That one choice — pre-select vs. let-the-model-pull — decides almost everything downstream: whether the behavior is deterministic, what it costs in tokens, whether your code leaves the machine, and how it copes with a big repo. Here’s the terrain, read at Aider v0.86.3.dev, Continue v2.1.0, and Cline v4.0.5, and where you fit on it.
The one question
Everything reduces to: when the model needs to see code, who decided what it sees — the agent, ahead of time, or the model itself, in the moment?
- Index-first agents build a structure over your repo and pre-select a relevant slice to inject. The model gets a curated view. (Aider, Continue.)
- Agentic agents build nothing and hand the model tools; it pulls code as it goes. The model gets whatever it thinks to fetch. (Cline.)
The two index-first agents then differ on what kind of index — a static-analysis graph, or semantic embeddings. That gives us three camps.
The core split is who chooses code context: a static graph, a semantic retrieval index, or the model pulling files through tools.
Camp 1 — Static graph (Aider)
Aider builds a repo map: it parses your code with tree-sitter, builds a graph of which file references which symbol, and runs PageRank over it to rank what’s structurally central — then packs the top-ranked signatures into a token budget with a binary search (repomap.py:525, :666). There are no embeddings and no network in that path. The ranking is deterministic and biased toward files you’ve named. It’s cheap, offline, and predictable — but it finds code by name and centrality, not meaning, so you steer it by mentioning things. (Full mechanism in the Aider repo-map teardown.)
Camp 2 — Embedding & retrieval (Continue)
Continue does what most people picture when they hear “understands your codebase”: it chunks your files, embeds the chunks, and retrieves by similarity. By default those embeddings are computed locally with a bundled all-MiniLM-L6-v2 and stored in a local LanceDB, alongside a SQLite full-text index (load.ts:424, LanceDbIndex.ts:203). A query is answered by blending vector hits, full-text hits, and a reranker down to ~25 chunks (retrieval.ts:9). This is the only camp that can find “the function that parses dates” when you don’t know its name — at the cost of an index to maintain and one real privacy lever: point it at a remote embeddings provider and your code chunks get POSTed out (OpenAI.ts:717). (Full mechanism in the Continue indexing teardown.)
Camp 3 — Agentic, no index (Cline)
Cline keeps no index of your codebase at all — no embeddings, no vector store, no ranked outline. I grepped for every vector/embedding library and found nothing that indexes your code. Instead the model pulls code on demand through tools: read_file reads a path fresh from disk (ReadFileToolHandler.ts:362), search_files shells out to ripgrep (ripgrep/index.ts:64), and list_code_definition_names parses a directory with tree-sitter on each call — the source literally carries a TODO: implement caching (tree-sitter/index.ts:9, ListCodeDefinitionNamesToolHandler.ts:79). What Cline injects automatically is only state, not code: an <environment_details> block of open tabs, terminals, and a recursive file list capped at 200 entries, shown once at the start of a task (task/index.ts:4189, :4341, :1719). As the conversation grows, it doesn’t re-rank an index — it deletes old turns with a sliding window (and can summarize) (ContextManager.ts:299). Note Cline uses tree-sitter, like Aider — but reactively, when the model asks, never as a pre-built ranked outline.
The comparison
| Aider — static graph | Continue — embedding | Cline — agentic | |
|---|---|---|---|
| How code is chosen | PageRank over a reference graph | vector similarity + full-text + rerank | the model calls tools, turn by turn |
| Pre-built index | ephemeral outline (mtime-cached) | yes — LanceDB + FTS, refreshed | none |
| Relevance signal | graph centrality + your mentions | semantic similarity | the model’s judgment |
| Deterministic? | yes | depends on the embed model | depends on the model’s choices |
| Finds code by meaning? | no — by name/centrality | yes | yes — the model greps and reads |
| Standing infrastructure | none (just parsing) | an index to build & keep fresh | none |
| Token cost shape | bounded by the context budget | bounded (top-N) | grows as it reads; needs compaction |
| Privacy surface | nothing leaves | local by default; remote provider ships code | code leaves as the model reads it |
| Freshness | recomputed on file change | hash-diff refresh | always live — reads the current file |
Why the split decides everything
Pick any row and the camps fall exactly where the mechanism puts them. Determinism: Aider’s PageRank gives the same outline for the same code; Cline’s context depends on what the model chose to open. Token cost: an index-first agent pays once to build the index and then injects a bounded slice; an agentic one pays per turn, and a long task accumulates file reads until compaction culls them. Privacy: Aider sends nothing, Continue is local until you choose a remote embedder, and Cline’s exposure is simply “whatever the model reads.” Big repos: the graph and the vector index both scale by pre-computing; the agent scales by navigating, which is why Cline caps its file list at 200 and expects the model to drill down with list_files.
None of these is strictly better. They fail differently, and that’s the point of the comparison.
Where do you fit?
- You want cheap, deterministic, offline context and you’re willing to name what matters → the static-graph camp (Aider). No index server, nothing leaves, but you steer by mentioning files and symbols.
- You want to find code by meaning across a large repo and you’ll maintain an index → the embedding camp (Continue). Semantic recall is real; just make the remote-vs-local embeddings choice deliberately, because that’s your data-egress decision.
- You want a hands-off agent that reads and edits live, with zero index to manage, on the newest models → the agentic camp (Cline). It’s always working against the current file, but watch the token bill on long tasks, and know its “understanding” is only as good as what it thought to open.
Scope & honesty
These camps are about each agent’s default, defining mechanism, not a cage. Modern agents blend: Continue also has an agent mode with tools, and Cline has subagents and a focus chain. There’s also a fourth shape I’m flagging but did not read for this piece — the managed retrieval server (Sourcegraph Cody, Tabby), which is camp 2’s embeddings pushed to a shared backend; I’d want to read one before placing it in the comparison. And this is all version-pinned: Aider at v0.86.3.dev, Continue at v2.1.0, Cline at v4.0.5. The Aider and Continue mechanisms were each verified against their source in the linked teardowns; Cline’s “no index, tools on demand” claim was run through an adversarial verifier at commit 9da3c59 (it even checked the lockfiles — the only SQLite in the extension is a file-lock table, not an index).
