Skip to content

devlog/model-bench/whole-repo-prompts-32k-128k-or-1m-tokens-299.md

Whole-Repo Prompts: 32K, 128K, or 1M Tokens?

Whole-Repo Prompts: 32K, 128K, or 1M Tokens?

When a coding agent misses a dependency three directories away, uploading the entire repository feels like the obvious fix. Sometimes it is. Sometimes you have just paid to bury the relevant function under generated clients, old migrations, and yesterday’s terminal output.

The useful comparison is not simply which context window is largest. It is which window can hold the evidence for your change, leave room for tools and output, and still produce a patch you can review.

The same repository inside three context budgets

Take a medium-sized service whose selected source files tokenize to roughly 90,000 tokens. Reserve another 12,000 for instructions, conversation history, tool definitions, and command output, plus 8,000 for the answer. That gives us a planning budget of approximately 110,000 tokens.

The following sizes are illustrative budget tiers, not specifications for particular models. Providers differ in how they account for input, output, and other token categories. Check the selected endpoint’s current limits before scripting around them.

  • A 32K window cannot hold this workload, so you must select files or retrieve relevant sections.
  • A 128K window fits this workload on paper, with approximately 18,000 tokens of remaining headroom.
  • A one-million-token window provides substantial capacity for additional files, but does not guarantee better answers.

Those numbers assume decimal token counts for readable arithmetic. Measure your actual request with the appropriate tokenizer or token-counting facility; file size and line count are poor substitutes.

32K: targeted files beat a repository dump

At 32K, I start with the failing test, the implementation it exercises, and the interfaces crossing that boundary. A directory tree and a short architecture note help the agent request missing files instead of guessing.

For a payment retry bug, that might mean the retry worker, queue adapter, idempotency helper, and two tests. Search with ripgrep first. Exclude lockfiles, compiled bundles, vendored dependencies, and generated code unless they are directly relevant.

The trade-off is extra retrieval turns. The benefit is a smaller, auditable evidence set. This tier is often enough for localized fixes, provided the agent can inspect more files when needed.

128K: a working set, not necessarily the whole repository

Our example fits here, making this tier attractive for changes spanning a service boundary. Include the API handler, business logic, persistence layer, schema, and representative tests together. The agent can inspect relationships without repeatedly fetching neighboring files.

However, that spare 18,000 tokens can disappear quickly after several test runs. Trim repetitive logs, summarize completed investigation steps, and avoid resending unchanged material unnecessarily. A request that fits initially may overflow later in an agent loop.

One million tokens: broader coverage still needs navigation

A much larger window becomes useful for repository-wide migrations, unfamiliar monorepos, or tracing conventions across multiple packages. It reduces how aggressively you must prune source material.

It does not remove the need for structure. Put the task and acceptance criteria first, label file boundaries consistently, and provide a repository map. Require the answer to identify affected paths and propose tests. Capacity is a ceiling; reliable retrieval and reasoning remain things to measure.

Comparing endpoints without confusing capacity and cost

For a concrete bake-off, try Claude Sonnet 5.5 and Gemini 3.1 Pro with the same task, selected files, and acceptance tests. Verify each endpoint’s advertised context and output limits first. Compare passing tests, missed dependencies, latency, and billed usage—not just whether the request was accepted.

Fluxo provides one key and one base URL, https://api.fluxorelay.com, for Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok, and more. It works with Claude Code, Codex, Gemini CLI, and any OpenAI SDK. Billing is per real token, including cache reads and writes, with no monthly fee; a large cached repository should not be treated as free input.

If you want to run this comparison from your existing tools, you can create a Fluxo account. Users also earn a referral share when people they invite pay.

The verdict: choose the smallest window that preserves evidence

Use 32K for focused fixes with retrieval, 128K for coherent cross-file working sets, and million-token capacity when broad repository coverage genuinely matters. Whole-repo prompting is justified when excluding files risks missing the change’s dependencies—not merely because the upload fits. The winning window is the smallest one that repeatedly produces a correct, testable patch with safe headroom.

Next in the buffer

Sign up in a minute and get credit to try every model mentioned here. Sign up →