Context optimization vs repository packing: two ways to give a model your codebase
The short answer
Repository packing concatenates some or all of a repository's files into a single block of text and lets the model find what's relevant inside it. Context optimization instead selects and retrieves only the specific pieces relevant to a task before they reach the model. Both aim to give a coding agent the full picture, but they trade off completeness, token cost and precision differently.
Packing sends more of this, not less
Each square is a file. Repository packing compresses the whole field and sends it. Context optimization sends the lit ones. The distinction matters most exactly when the repository is too big to pack.
What repository packing is
Repository packing tools walk a codebase and concatenate its files, sometimes with a directory tree or manifest, into one large text blob that gets pasted or streamed into a model's context window. The model then reads through that blob to find whatever is relevant to the current question. It requires no parsing or indexing step: it's a straightforward concatenation.
What context optimization is
Context optimization selects only the functions, classes, files or relationships relevant to a specific task and sends those, instead of the surrounding repository. It requires an upfront step (parsing, indexing, or another retrieval mechanism) so that a targeted query can be answered without sending everything.
Comparison
| Capability | Repository Packing | Context Optimization |
|---|---|---|
| Setup complexity | Low: concatenate files | Higher: requires parsing/indexing |
| Token cost on a large repository | High, scales with repository size | Low, scales with the task |
| Completeness (nothing left out) | High: everything is present | Depends on retrieval quality |
| Precision (only relevant code included) | Low: includes unrelated code | High |
| Works on very large repositories | Breaks down at context-window limits | Scales independently of repository size |
| Freshness | Point-in-time snapshot at pack time | Can update incrementally as code changes |
Neither approach is wrong. Packing is simple and complete for small, well-scoped inputs. Optimization becomes more valuable as a repository grows, because packing's token cost and context-window pressure grow with it while a good retrieval system's cost stays tied to the task instead.
When packing is fine
For a small repository, or a deliberately narrow subset of one, packing everything relevant into context can be perfectly reasonable: there's little to gain from a retrieval layer if the whole scoped input already fits comfortably and cheaply. The tradeoff shifts once a repository is large enough that packing means paying to send, and the model reading through, a large amount of code that has nothing to do with the actual question.
Where CodeMesh fits
CodeMesh does context optimization, not repository packing: it maintains a structural understanding of a repository and retrieves only the entities and relationships relevant to a question, rather than concatenating source files into context.
Sending everything and sending only what's relevant solve the same problem at very different costs.
See what retrieving only what's relevant looks like
CodeMesh's published benchmark measures the token and cost difference directly.