A new open-source Python project called Context Compiler makes a sensible case for treating a coding agent’s prompt as build output: keep the file being edited in full, reduce reachable dependencies to signatures and docstrings, and omit the rest. But the project’s headline claim — 69% to 74% context reduction in under 75 milliseconds — measures savings against a deliberately maximal baseline, not against the context-selection systems used by current coding agents.
The repository, published by Emmimal and accompanied by a Towards Data Science write-up, is real and small enough to audit. Its value is not that it has discovered a universal replacement for larger context windows. Its value is that it turns an often-informal agent step into an inspectable local tool, with a clear warning that the resulting dependency graph is incomplete.
That is a useful contribution for Python shops using agent workflows on Windows, particularly where prompts are assembled locally before being sent to a cloud model. But the evidence supports a narrower conclusion: Context Compiler is a lightweight prompt-pruning prototype, not yet a demonstrated improvement in coding-agent accuracy, cost, or task completion.
Context Compiler uses only the Python standard library and targets Python source files. Its first pass indexes
The resolver adds files in two ways. It looks at imported module names and tries to match them against the local module index. It also records every called function or attribute name, then searches a repository-wide table for definitions with the same bare name.
That second method is the project’s central trade-off. A call such as
The second pass runs an AST transformation on files selected as dependencies. It retains declarations, signatures, annotations, decorators, and docstrings, but replaces function and method bodies with an ellipsis. The target file itself remains whole. The third pass emits a prompt-like text bundle with a Tier 1 target file, Tier 2 skeletons, and an excluded Tier 3.
For a human reviewing an agent’s input, that output is easier to reason about than a black-box repository map. It can show the precise files that survived filtering. It can also expose when a simple static resolver has reached its limit.
Those diagnostics are safer than silently presenting an approximate call graph as a fact. In a Django-style codebase, for example, an explicit warning that
However, the source code shows that “unknown” conditions are not consistently surfaced to the user. The resolver maintains an
There are further omissions that matter in ordinary Python repositories. Relative imports are not resolved correctly: the AST visitor stores
In other words, the tool is honest about several highly visible blind spots, but it does not yet meet the stronger claim that every uncertain dependency outcome is explicitly marked. For coding agents, a silent omission is more dangerous than an extra skeleton. A model can ignore surplus material; it cannot reason about a helper, handler, configuration file, template, generated client, or relative import that never reached its prompt.
Those figures are plausible for seven- and 12-file repositories. They are also reproducible in a limited sense: the repository includes a command-line entry point, the source is available, and the self-benchmark can be rerun. The claimed external
More importantly, the percentage is derived from a comparison to a full dump of every Python source file under the repository root. The code counts the characters in that dump, divides by four, and calls the result a token estimate. It performs the same calculation on its compiled output.
That baseline is explicitly described in the project as a “naive full-repo dump.” It is useful as an upper bound. It is not a credible stand-in for how established coding agents typically construct context. Tools such as Aider, Cursor, Claude Code, Codex, and GitHub Copilot do not generally attach a complete repository’s raw Python files to every edit request. They use combinations of file selection, repository maps, search, tool calls, conversation state, and model-directed retrieval.
The project acknowledges this, but the acknowledgment changes how the headline numbers should be read. The tool has shown that it can make a full source dump materially smaller. It has not shown a 69%–74% reduction versus an existing agent’s real prompt payload, and it has not measured whether skeletonization causes an agent to make better edits, fewer edits, more tool calls, or more mistakes.
The token calculation adds another limitation. Python code is not uniformly tokenized at four characters per token; indentation, punctuation, identifiers, comments, strings, and non-ASCII text all vary by tokenizer and model. Because the same heuristic is applied to both sides, the direction of the savings is likely useful. But exact token budgets, billing, and context-window safety margins need a tokenizer that matches the deployed model.
OpenAI’s public Codex repository shows that pull request 33972 was merged on July 18, 2026, backporting refreshed bundled model metadata to the Codex 0.144 release line. The linked source commit states that it set bundled GPT-5.6 model variants’ context windows to 272,000 tokens. The checked-in model metadata lists both
What the pull request does not establish is the stated 372,000-token previous value, nor does it establish that every Codex surface or API customer had a “default context window” reduced on that date. The pull request describes a catalog refresh for stable 0.144 clients and says the change would arrive in a subsequent non-alpha hotfix. It is evidence of a bundled-client metadata change, not a comprehensive public announcement of a product-wide capacity cut.
The broader lesson still stands: developers should avoid designing workflows that require every potentially relevant source file to fit into a vendor-controlled window. Yet changing client metadata from one published number to another is not proof that larger windows are the wrong answer. Context capacity and context quality solve different problems. More capacity helps when a task legitimately needs a large working set; filtering helps when irrelevant material would otherwise compete with the relevant evidence.
The strongest candidates are repositories that use explicit imports, predictable package structure, and ordinary function calls. A service-oriented internal application with a clear
The project should not be deployed as an unattended gatekeeper that decides what an agent is allowed to see. At its current stage, its exclusions should be treated as a suggestion, and its diagnostics should feed an escalation path: include a broader directory, inspect unresolved calls, add known registries, or let the agent search the repository when the static pass is uncertain.
The next meaningful milestone is not a larger percentage reduction. It is a benchmark that compares this approach with actual agent context assembly on named repositories and issue-resolution tasks, reports recall for required files, and measures whether the smaller prompt improves outcomes. Until then, the code demonstrates a useful engineering pattern: make prompt construction observable, conservative, and debuggable before making it aggressively small.
That is a useful contribution for Python shops using agent workflows on Windows, particularly where prompts are assembled locally before being sent to a cloud model. But the evidence supports a narrower conclusion: Context Compiler is a lightweight prompt-pruning prototype, not yet a demonstrated improvement in coding-agent accuracy, cost, or task completion.
What the three passes actually do
Context Compiler uses only the Python standard library and targets Python source files. Its first pass indexes .py files beneath a selected repository root, excluding folders such as .git, venv, __pycache__, and node_modules. It then parses the target file and nearby reachable files with Python’s ast module.The resolver adds files in two ways. It looks at imported module names and tries to match them against the local module index. It also records every called function or attribute name, then searches a repository-wide table for definitions with the same bare name.
That second method is the project’s central trade-off. A call such as
invoice.save() becomes a lookup for every method or function named save in the repository. The resolver has no type inference, no variable binding, no import-alias tracking, and no awareness of which object sits to the left of the dot. It may therefore include too much code, and it can still miss the code that actually executes.The second pass runs an AST transformation on files selected as dependencies. It retains declarations, signatures, annotations, decorators, and docstrings, but replaces function and method bodies with an ellipsis. The target file itself remains whole. The third pass emits a prompt-like text bundle with a Tier 1 target file, Tier 2 skeletons, and an excluded Tier 3.
For a human reviewing an agent’s input, that output is easier to reason about than a black-box repository map. It can show the precise files that survived filtering. It can also expose when a simple static resolver has reached its limit.
The warnings are real, but they are not exhaustive
The project deserves credit for documenting three failure modes:getattr()-style dynamic dispatch, decorator-based registration, and collisions produced by name-only lookup. The included resolver does flag a file containing a getattr() call; it flags functions using decorator names including receiver, signal, event, hook, register, and route; and it records when a call name maps to more than one source file.Those diagnostics are safer than silently presenting an approximate call graph as a fact. In a Django-style codebase, for example, an explicit warning that
@receiver handlers might be absent is better than quietly sending an agent a partial picture of signal flow.However, the source code shows that “unknown” conditions are not consistently surfaced to the user. The resolver maintains an
unresolved_calls collection when it sees a call with no matching definition in its global symbol table. Yet the CompiledContext.summary() routine prints warnings for dynamic dispatch, event decorators, and collisions only; it does not display unresolved calls. A caller can inspect the raw diagnostics programmatically, but a developer running the advertised command-line benchmark will not see that list in the normal summary.There are further omissions that matter in ordinary Python repositories. Relative imports are not resolved correctly: the AST visitor stores
node.module from from .services import save, but does not use the import’s relative level or the current package location. Imports where the module is absent — including forms such as from . import services — are also not represented as a local dependency. Syntax errors and decoding errors are skipped without a diagnostic.In other words, the tool is honest about several highly visible blind spots, but it does not yet meet the stronger claim that every uncertain dependency outcome is explicitly marked. For coding agents, a silent omission is more dangerous than an extra skeleton. A model can ignore surplus material; it cannot reason about a helper, handler, configuration file, template, generated client, or relative import that never reached its prompt.
The 69%–74% reduction is not an agent benchmark
The repository reports a 69.4% reduction for its own seven-file codebase and a 74.3% reduction for a 12-file external project calledloop-engine. It reports build times of roughly 43–61 milliseconds and 66–73 milliseconds, respectively, using Python 3.12 with max_hops=2.Those figures are plausible for seven- and 12-file repositories. They are also reproducible in a limited sense: the repository includes a command-line entry point, the source is available, and the self-benchmark can be rerun. The claimed external
loop-engine result is less independently checkable because the project’s documentation does not identify the specific repository revision, target file, operating environment beyond the broad description, or the command output used for that run. No independent outlet appears to have reported or reproduced the external benchmark.More importantly, the percentage is derived from a comparison to a full dump of every Python source file under the repository root. The code counts the characters in that dump, divides by four, and calls the result a token estimate. It performs the same calculation on its compiled output.
That baseline is explicitly described in the project as a “naive full-repo dump.” It is useful as an upper bound. It is not a credible stand-in for how established coding agents typically construct context. Tools such as Aider, Cursor, Claude Code, Codex, and GitHub Copilot do not generally attach a complete repository’s raw Python files to every edit request. They use combinations of file selection, repository maps, search, tool calls, conversation state, and model-directed retrieval.
The project acknowledges this, but the acknowledgment changes how the headline numbers should be read. The tool has shown that it can make a full source dump materially smaller. It has not shown a 69%–74% reduction versus an existing agent’s real prompt payload, and it has not measured whether skeletonization causes an agent to make better edits, fewer edits, more tool calls, or more mistakes.
The token calculation adds another limitation. Python code is not uniformly tokenized at four characters per token; indentation, punctuation, identifiers, comments, strings, and non-ASCII text all vary by tokenizer and model. Because the same heuristic is applied to both sides, the direction of the savings is likely useful. But exact token budgets, billing, and context-window safety margins need a tokenizer that matches the deployed model.
OpenAI’s July metadata change supports a narrower point
The accompanying article says OpenAI “quietly dropped” the default Codex context window from 372,000 to 272,000 tokens on July 18. The primary record supports only part of that statement.OpenAI’s public Codex repository shows that pull request 33972 was merged on July 18, 2026, backporting refreshed bundled model metadata to the Codex 0.144 release line. The linked source commit states that it set bundled GPT-5.6 model variants’ context windows to 272,000 tokens. The checked-in model metadata lists both
context_window and max_context_window as 272,000 for GPT-5.6-Sol.What the pull request does not establish is the stated 372,000-token previous value, nor does it establish that every Codex surface or API customer had a “default context window” reduced on that date. The pull request describes a catalog refresh for stable 0.144 clients and says the change would arrive in a subsequent non-alpha hotfix. It is evidence of a bundled-client metadata change, not a comprehensive public announcement of a product-wide capacity cut.
The broader lesson still stands: developers should avoid designing workflows that require every potentially relevant source file to fit into a vendor-controlled window. Yet changing client metadata from one published number to another is not proof that larger windows are the wrong answer. Context capacity and context quality solve different problems. More capacity helps when a task legitimately needs a large working set; filtering helps when irrelevant material would otherwise compete with the relevant evidence.
Where this fits in a Windows development workflow
For a small or medium-sized, convention-heavy Python application, Context Compiler can be a practical preprocessor. A Windows developer could run it against an active file, review the resulting target-plus-interface bundle, and place that bundle in a local prompt template or agent wrapper. Its lack of dependencies makes it convenient in constrained environments and easy to inspect before adoption.The strongest candidates are repositories that use explicit imports, predictable package structure, and ordinary function calls. A service-oriented internal application with a clear
app.services, app.models, and app.views layout will gain more from static pruning than a plugin host driven by configuration, runtime imports, signals, framework discovery, generated modules, and string-dispatched handlers.The project should not be deployed as an unattended gatekeeper that decides what an agent is allowed to see. At its current stage, its exclusions should be treated as a suggestion, and its diagnostics should feed an escalation path: include a broader directory, inspect unresolved calls, add known registries, or let the agent search the repository when the static pass is uncertain.
The next meaningful milestone is not a larger percentage reduction. It is a benchmark that compares this approach with actual agent context assembly on named repositories and issue-resolution tasks, reports recall for required files, and measures whether the smaller prompt improves outcomes. Until then, the code demonstrates a useful engineering pattern: make prompt construction observable, conservative, and debuggable before making it aggressively small.
References
- Primary source: Towards Data Science
Published: 2026-08-01T15:00:00+00:00
Coding Agents Don’t Need Bigger Context Windows — They Need a Context Compiler | Towards Data Science
Most coding agents treat prompt construction like retrieval: gather more files, add more context, hope the model figures it out. But that approach breaks down fast. As context grows, irrelevant code competes for attention, and when the window fills, agents start compressing their own...towardsdatascience.com - Related coverage: bursasiu.ro
Context-Engineering
Context engineering is the discipline of systematically managing the full information ecosystem available to an AI agent — selecting, compressing, ordering, and delivering the right content to the context window at the right time.bursasiu.ro - Related coverage: ht-x.com
+1 for "context engineering" over "prompt engineering" · HUMAN TECHNOLOGY eXCELLENCE
+1 for "context engineering" over "prompt engineering". People associate prompts with short task descriptions you'd give an LLM in your day-to-day use.ht-x.com - Related coverage: ht-x.com
+1 por "ingeniería de contexto" sobre "ingeniería de indicaciones". · HUMAN TECHNOLOGY eXCELLENCE
+1 por "ingeniería de contexto" sobre "ingeniería de indicaciones". La gente asocia las indicaciones con descripciones cortas de tareas que le darías a un LL...ht-x.com - Related coverage: linkedin.com
Context Is the Real Work
What separates people who create consistent impact from those who struggle despite obvious talent? After more than a decade of leading engineering teams, I keep coming back to the same answer. It isn't intelligence.www.linkedin.com
- Related coverage: marktechpost.com
- Related coverage: discuss.huggingface.co
Making local LLMs more reliable with a deterministic “context compiler” - Show and Tell - Hugging Face Forums
I’ve been experimenting with running LLMs locally, and kept running into a common issue: constraints and corrections drift out of the prompt over time Example: User: “don’t use peanuts” …long conversation… M…
discuss.huggingface.co
- Related coverage: digitalocean.com
Context Engineering: Moving Beyond Prompting in AI | DigitalOcean
Discover how context engineering manages knowledge, instructions, and memory in LLMs. Learn strategies to optimize context windows and build AI applications.www.digitalocean.com
- Related coverage: augmentedadvisors.com
Context Engineering: From Vibe Coder to Software Engineer
A practical guide to context engineering for AI-assisted developersaugmentedadvisors.com
- Related coverage: intuitionlabs.ai