A new preprint on arXiv reports that an AI agent framework called E3 matched the strongest baseline's 100% success rate on a 121-edit benchmark while cutting cost by 85%, token usage by 91%, and files inspected by 92% [S1]. The reason those cuts are possible is that current agents treat every task, even a one-line fix, as a full codebase audit. What happens when you teach an agent to estimate effort before it starts, and why did the real-world test tell a more complicated story?

The problem with maximum effort

The authors, Junjie Yin and Xinyu Feng, start with an observation anyone who has watched an AI coding agent work will recognise [P2]. LLM-based agents now take on multi-step software engineering tasks, but they seldom pause to gauge how much work a given job truly demands [S1]. They default to what the authors call a "maximum-context-first" strategy: revisiting files and dependencies they have already examined, so that changing a single line becomes a full audit of the surrounding code [S1].

The cost is not abstract. Every token an agent reads is a token you pay for. Every file it opens adds latency. A two-person startup running an agent on a modest API budget can watch a month's allocation vanish on tasks that needed five seconds of attention.

How E3 works

The authors formalise two concepts. "Minimum-sufficient execution" is the idea that an agent should do the least work needed to complete a task correctly. The "Agent Cognitive Redundancy Ratio" (ACRR) measures how much extra work an agent does beyond that minimum [S1].

E3, the framework they propose, has three steps [S1]:

  1. Estimate: The agent guesses an initial operating point, how much context and effort the task likely needs.
  2. Execute: It runs a minimum viable path, doing only what the estimate says is necessary.
  3. Expand: If verification fails, the agent expands its scope and tries again.

The key is that expansion is conditional. The agent starts small and only grows its effort when the result does not pass verification. Most current agents do the opposite: start with everything, then trim if they can.

The benchmark numbers

The authors constructed MSE-Bench, which consists of 121 editing tasks inside a simulator that controls agent capabilities [S1]. On it, E3 matched the strongest baseline's 100% success rate while cutting cost by 85%, tokens by 91%, and inspected files by 92% [S1]. It also beat a strong adaptive retrieval baseline by 16% [S1].

The authors report that these gains held up across different instruction phrasings and across nearly every cost weighting they evaluated [S1]. The gains did not depend on a specific prompt or an advantageous pricing model.

What it means

The core finding is simple. AI agents over-read. They treat a hangnail like a heart attack, scanning files and dependencies that have nothing to do with the task at hand. E3 flips the default. Instead of loading everything and then deciding what matters, it loads the minimum and expands only when the work fails verification.

For anyone paying API bills, this matters directly. The 91% token reduction on the benchmark means an agent that previously cost $1.00 per task might cost $0.09. The 92% reduction in files inspected means faster runs and less context-window pressure on large repositories.

The authors frame this as a step toward what they call "engineering-grounded AI" (EGAI), agents that calibrate their effort to the actual engineering demands of the task [S1]. A good agent should know the difference between a typo fix and a refactor, and act accordingly.

What it means for business

A suburban web agency running AI agents for client work could see the most immediate impact. If an agent currently spends 10 minutes and 50,000 tokens auditing a codebase to change a single configuration value, an E3-style approach could cut that to under 5,000 tokens and a fraction of the time. On a monthly API bill of $500, that is the difference between sustainable and prohibitive.

For a two-person firm, the workflow change is concrete. Instead of letting an agent run unsupervised with full repository access, the agent estimates scope first, runs a narrow path, and only widens if the fix does not pass tests. Fewer tokens, faster feedback, lower cost per task.

The authors have released the framework and benchmark on GitHub [S1] [P4], so teams can test the approach against their own codebases. The code repository is public, though it had no stars at the time of writing [P4].

The real-world test

The benchmark numbers are one thing. The authors also built LLM-Case, a companion harness that tested a live gpt-4o agent editing a real open-source library, with every candidate patch graded by running the project's actual pytest suite against a measured oracle [S1].

The real-world results were more muted. The tendency to over-read was less pronounced but still present, and E3 stayed the most token-efficient and quickest approach at similar levels of task completion [S1]. On LLM-Case, E3's only failure stemmed from an API rate limit imposed by the provider, not from generating an incorrect patch [S1]. That is a meaningful distinction: the framework did not produce incorrect code, it simply hit an external constraint.

What we don't know yet

The preprint is not peer-reviewed [S1]. All experimental claims are self-reported by the authors on their own custom benchmark. The benchmark uses a deterministic, capability-controlled simulator, and real-world stochastic conditions may produce different results [S1].

The live-model validation used gpt-4o specifically. Results may not generalise to other models or agent architectures. The authors themselves frame the work as "a controlled probe of execution redundancy, not a measurement of any deployed agent" [S1].

The 100% success rate and the 85% and 91% reductions are specific to MSE-Bench. LLM-Case showed milder over-reading and encountered a rate-limit failure. Whether E3 holds up across larger codebases, different models, and production conditions remains an open question.

The next concrete signal will come from independent teams running the released benchmark and framework against their own repositories [P4]. Until then, the numbers are promising but provisional.

If this kind of reporting helps you understand what AI tools actually do behind the scenes, subscribe for more.

Sources

More from Not A Tech Guy

Generated from an audited evidence pack with primary-source research. Social-media items are discussion signals, not verified facts. Nothing here is financial, legal or medical advice.