The Whole-Repo Prompt That Fits the Window

Counting Tokens Before You Paste the Whole Repository

The most expensive mistake in whole-repo prompting happens before the model ever answers, and it is assuming that the advertised context window is the same thing as your input budget. It is not. The window has to hold the system prompt, your message, every file you pasted, every tool result your editor agent returns, and the answer you expect back. When a model with a very large window reads forty thousand tokens of source and then writes a fifteen hundred line refactor, the output side is eating space you thought you had for files.

A workable habit is to reserve output first and paste second. Decide how long the answer can be, subtract that from the window, then subtract a generous allowance for tool calls and intermediate reasoning, and only then treat the remainder as the paste budget. On a repository-scale request I usually keep roughly a quarter of the window free, because an agent that plans three edits and runs two searches will burn through it faster than a chat turn ever does.

The second counting mistake is estimating instead of measuring. Roughly four characters per token is a decent gut check for prose, but code is denser: long identifiers, nested generic types, and import blocks all compress less than you expect. Ask your tooling for usage numbers, run your candidate files through a tokenizer once, and keep a small table of token costs for the directories you touch often. You will stop guessing within a day.

• Treating the advertised context window as your full input budget ignores output reservation and tool results.
• Pasting files before deciding the answer length wastes room you will need for the actual fix.
• Estimating token counts from character counts alone underestimates generated and typed source files.

Letting Lockfiles, Bundles, and Build Output Eat the Window

Whole-repo does not mean whole-directory-tree. The single biggest waste I see is a glob that drags in a lockfile, three minified bundles, and the entire output of a code generator. A package lock can be tens of thousands of tokens of dependency resolution noise that tells the model almost nothing about your architecture. Minified assets are worse, because they are unreadable to a human and only marginally more useful to a model, yet they are charged at the same rate as your hand-written code.

The fix is a filtering step that runs before the prompt. Exclude anything generated, vendored, minified, snapshotted, or derived: build output directories, dependency trees, translation catalogs produced from a source of truth, and test fixtures that are just serialized data. If a file is generated from another file, send the generator and skip the artifact. If a fixture exists only to exercise a parser, describe its shape in one sentence instead of shipping it.

The second fix is to send a map before you send the territory. A file tree with line counts, one sentence per module, and a note on which directories are hot gives the model enough structure to ask for the right files next. Two rounds of targeted retrieval usually costs fewer tokens than one round of dumping everything, and the answer is better because the model is reading source that actually matters.

• Lockfiles and package manifests consume thousands of tokens while adding almost no architectural signal.
• Generated files and their generators together double the cost of explaining a single feature.
• Sending a full tree without line counts hides which files deserve their place in the prompt.
• Test fixtures full of serialized data are better summarized than pasted into the request body.

Cache Writes and Cache Reads Across Long Editor Sessions

Prompt caching is where repository work either gets cheap or gets expensive, and the mistake is assuming cache reads are free. In practice you pay for the write when a prefix is first cached and for the read on every later turn that reuses it, so the economics reward stability. If you reorder the pasted files on each turn, or regenerate a repo map with slightly different wording, every turn pays the write price again instead of the read price.

Build the prompt like a layered cache. Put the stable material first: the repo map, the coding conventions, the API surface you are not touching today. Put the volatile material last: the current diff, the failing test output, the file you are actively editing. That ordering lets the prefix stay warm while only the tail changes. It also means a long session stays predictable when your relay bills per real token, cache reads and cache writes included, with no monthly fee sitting behind it.

The related mistake is rewriting huge blocks every turn. If a file did not change, do not resend it; reference it and let the cached prefix carry it. If a file did change, send the diff rather than the whole module. Whole-repo prompts get cheaper and more accurate when you treat the conversation as an incremental ledger instead of a series of self-contained essays.

• Reordering pasted files on every turn breaks cache reuse and forces repeated full-price writes.
• Assuming cached reads cost nothing leads to bloated prompts that never shrink.
• Regenerating a repo map with different wording each turn silently invalidates an otherwise warm cache.
• Sending unchanged files again in full charges you for tokens the cache could have carried.

Picking a Shelf Model for Repository-Scale Context

Reaching for the most capable model on every prompt is the easy mistake, because repository work is not one task. Indexing, summarizing, and answering narrow questions are cheap chores; architectural decisions and cross-file refactors are not. Splitting the work by cost keeps a whole-repo session affordable and usually faster, since a smaller pass that only reads and reports finishes sooner than a large one that also tries to edit.

On Fluxo the shelf includes Claude Haiku 4.5, which I use for the first sweep over a repository: build the file map, flag likely culprits, and produce the compact summary I paste into later turns. For the actual design work and multi-file refactors I switch to Claude Opus 5.5, where the reasoning quality shows up in fewer follow-up corrections. Because everything runs behind one key and one base URL at https://api.fluxorelay.com, switching is a model parameter change rather than a new integration, and billing stays honest since you pay per real token, cache reads and cache writes included.

The other mistake is choosing by window size alone and ignoring latency and cost per turn. A long session compounds both. Keep a short list of jobs and the model you assign to each, and revisit it when a model proves cheaper at the same quality on your actual repository rather than on a benchmark.

• Using a top-tier model for indexing and summarizing burns budget on work a smaller model handles.
• Choosing models by context window size alone ignores per-turn latency and accumulated cost.
• Rebuilding the same integration for each provider wastes time a parameter switch would save.

Compaction Surprises in Claude Code, Codex, and Gemini CLI

Terminal agents compress their own history when a session runs long, and compaction is where whole-repo context quietly disappears. The mistake is assuming that a fact stated once early in the session survives until the end. It often does not. When the agent summarizes and discards older turns, your architectural constraint, your naming convention, or the reason a file is off-limits can be flattened into a line that no longer carries the detail you need.

Push durable context out of the conversation and into files the agent can re-read: a short conventions document, a current-state map, and a decisions log with the constraints that must survive compaction. Then ask the agent to consult those files after any compaction event. This is cheaper than re-pasting the repository and much more reliable than hoping the summary kept your nuance.

The second mistake is one giant message asking for everything at once. Break the work into a planning pass that writes the map, an execution pass that edits against it, and a verification pass that re-reads the changed files. Each pass has a smaller, clearer window to fit into, and you can see where tokens went. Fluxo works with Claude Code, Codex, Gemini CLI, and any OpenAI SDK, so the same workflow travels across your editors and your shell without rework, and the referral share you earn when people you invite pay is a nice offset to a heavy month of agent sessions.

If any of this feels unclear once you are running it, sign in and leave a note on the contact page and I will point you in the right direction. When you are ready to try repository-scale prompts with predictable billing, create a Fluxo account and run one real session against your own codebase.

• Compaction summaries often flatten constraints that mattered at the start of a long session.
• Assuming early instructions survive compaction leads to edits that violate your stated conventions.
• Keeping durable context in re-readable files beats re-pasting the repository after every summary.
• One giant message asking for planning, editing, and verification wastes window space on ambiguity.