Best Model for Large Repositories: Context Is Not Enough

The intuitive answer is to pick the model with the biggest context window and paste in the repository. That works for a small project and fails for a large one, for reasons that have little to do with the window size.

A million-token window holds roughly 50,000 to 80,000 lines of code depending on language and density. A large repository is several million lines. The window was never going to be the solution.

What large-repository work actually demands

Three capabilities, in descending order of importance.

Navigation over ingestion. The model needs to find the right twenty files, not read forty thousand. That is a tool-calling problem — grep, file read, symbol search — not a context problem. A model that is excellent at code and poor at tool use will flounder; a model that is decent at code and disciplined about searching will do well.

Holding a thread across many steps. Real repository work runs long: find the definition, trace the callers, check the tests, make the change, run the suite, fix what broke. Twenty to fifty tool calls is normal. Per-step error compounds across that, so completion rate falls off much faster than single-turn quality suggests.

Knowing when to stop reading. Weak models keep opening files. Every file read adds tokens, dilutes attention, and pushes the relevant material further from where the model attends best. Discipline here matters more than raw capability.

Why context window is the wrong first filter

Two reasons.

First, usable context is shorter than advertised context on every model. Attention concentrates at the beginning and end of a prompt and thins in the middle, so a fact at 50 percent depth in a 900K-token prompt is materially less likely to be used than the same fact at 5 percent. Filling the window does not mean the model is using it.

Second, filling the window is expensive and slow. At frontier prices, 800K input tokens per turn across a thirty-turn session is a serious bill for information the model largely ignores.

The models that do well on large repositories are the ones that read selectively, and that is a behaviour, not a specification.

What to actually look for

• Long-horizon benchmark performance. Terminal-Bench 2.1 and FrontierSWE measure extended unattended work, which is the right shape. Kimi K3 reports 88.3 and 81.2 respectively. Single-turn benchmarks like SWE-bench Verified tell you less here.
• Tool-calling reliability. Malformed calls, ignored schemas and repeated identical searches are what kill long sessions. Structured outputs and JSON mode covers what to test.
• Instruction adherence over many turns. A model that obeys "always run the tests before claiming done" on turn three and forgets by turn twenty-five is worse than a weaker model that remembers.

The architecture matters more than the model

This is the part teams underinvest in, and it produces bigger gains than switching models.

Give the model good search tools rather than a big prompt. A fast symbol index, a grep that returns file and line, and a way to read a specific range beats dumping directories every time.

Compact the transcript as it grows. Tool output accumulates fast, and most of it is irrelevant three turns later. Summarising completed sub-tasks and dropping raw output keeps the working context small and the attention focused. Agent memory and context management covers the mechanics.

Give it a map. A short architectural overview in the system prompt — where things live, what the conventions are, which directories to ignore — saves many turns of exploration and is cheap to maintain.

A practical recommendation

• Large repository, long agentic tasks, budget available — Kimi K3. Long-horizon completion rate is what you are buying and it leads the open field.
• Same, cost-sensitive — GLM-5.2. Explicitly built for long-horizon coding, MIT licensed, with reasoning effort levels to control spend.
• Bulk reading and triage across the repo — DeepSeek V4 Flash. Reading is nearly free, and shallow questions do not need depth.
• Mixed — Flash for search and triage, escalating to K3 or GLM-5.2 for the actual change. This is the setup that usually wins on cost per completed task.

Measure on your own repository. Take fifteen real tasks from your git history, run them end to end, and record completion rate and turn count rather than per-response quality. How to benchmark LLMs on your own work covers the harness.