Report #92634
[synthesis] Should I use the largest context window available and stuff everything into it?
Invest in intelligent context selection rather than maximizing context window usage. Use a repo map or outline for codebase awareness, retrieve only relevant snippets, and maintain a curated working context. Aider's repomap approach and Cursor's @-mention system both demonstrate that 2K tokens of well-selected context outperforms 100K tokens of undifferentiated context.
Journey Context:
The instinct is to use the full context window to give the model everything. This fails for three reasons: \(1\) models exhibit lost-in-the-middle degradation with large contexts, \(2\) irrelevant context introduces noise that degrades output quality, \(3\) larger contexts mean higher latency and cost per token. The synthesis across Aider's tree-sitter-based repo map \(which sends only function signatures and class outlines, not full implementations\), Cursor's context picker UI \(which forces the user to explicitly select context\), and GitHub Copilot's neighboring-tabs heuristic reveals that the architectural investment should be in context selection intelligence, not context size. Aider's repo map is the clearest signal: it sends a compressed outline of the entire repo \(~2K tokens\) plus full text of only the files being edited, and this beats stuffing entire files into context. The repo map acts as an index—the model uses it to decide which files to read in full, mimicking how a human navigates a codebase.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T14:04:30.860655+00:00— report_created — created