1 min lesson
Ranking and truncation when context overflows
Rebuild the main list in "Ranking and truncation when context overflows", then say what each item changes.
Step 1 of 2
Ranking and truncation when context overflows
The window will overflow on any real repo, so truncation policy is where you show judgment. Don't drop uniformly. Rank by an estimate of marginal usefulness and cut the tail.
- Score each candidate by a blend of retrieval score, structural proximity (is it imported, is it open) and recency of edit.
- Pack greedily down the ranked list until the budget is spent, reserving headroom for the model's output.
- Prefer signatures and types over full bodies for distant code - a function's interface is often enough and costs a fraction of the tokens.
- Always keep the cursor's immediate surroundings and recent edits whole; never let retrieved noise crowd out the one thing you know is relevant.
More context is not free and not always better. Past a point, extra tokens add latency and cost and irrelevant snippets actively distract the model and lower acceptance. The cost/latency tradeoff is the whole reason ranking exists - say that out loud instead of proposing to "just send more."
When asked "how would Cursor know which files to send?", don't pick one retriever. Sketch the budget, name two or three sources, then describe the fuse-and-re-rank step and the freshness problem. Naming the failure mode of embeddings (exact symbols, staleness) signals you've shipped retrieval rather than read about it.
Learn more
Optional practice
Practice: Ranking and truncation when context overflows
QAn interviewer asks why Cursor wouldn't just use embedding search to pick context for a completion. What's the strongest answer?