I built an optimization layer underneath coding agents instead of building another agent
There are already enough coding agents.
I was more interested in what happens underneath them.
Agents repeatedly interact with deterministic tools:
tests, typecheckers, linters, file reads, builds, git commands, etc.
Those can produce a lot of low-signal output and repeated work.
So I built TidyRun, an opensource local optimization layer around that part of the loop.
It doesn’t choose what code to write and it doesn’t call another model.
Instead it handles things like:
- deterministic tool-output compression
- recoverable raw artifacts
- safe verified command reuse
- duplicate-read avoidance
- large-file guards
- loop detection
- incremental test impact
Install:
npx tidyrun@latest init
The result that surprised me:
In a 10-task Codex comparison, TidyRun reduced agent-visible tool output 14.2% with the same 10/10 task success...
...but total tokens and wall time got worse, not better.
So I don’t think “less context = cheaper agent” is as simple as I originally assumed.
I’d like to test the architecture with other agents/workloads rather than optimize to one benchmark.
Where do you think deterministic optimization belongs in an agent stack?
Agent layer? Tool wrapper? MCP? Shell hooks? Somewhere else?
Repo is Apache-2.0; forks/PRs/benchmark results are welcome.