I maintain Tura and open-sourced this implementation. I wanted to test a simple question: does a coding agent really need a fresh model round between every deterministic tool step?
A normal repository task may spend separate rounds on inspecting the environment, editing package files, fixing the implementation, updating tests, building, running tests/lint, and then reading Playwright media. The macro approach describes that executable workflow once, runs the steps below the model boundary, and returns the combined evidence for the next genuine reasoning decision.
I tested Codex CLI 0.144.1 with GPT-5.6-sol on 60 sessions covering DeepSWE debugging tasks and full-repository rewrites:
| Configuration | Passes | Pass rate | Observed tokens | Rounds | Estimated cost |
|---|
| Macro + backward reasoning | 48/60 | 80.0% | 229,695,477 | 2,017 | $221.138 |
| Macro Direct | 39/60 | 65.0% | 75,108,167 | 969 | $99.620 |
| Codex CLI Medium | 38/60 | 63.3% | 333,538,349 | 3,140 | $257.173 |
| Codex CLI High | 36/60 | 60.0% | 455,742,296 | 6,074 | $327.483 |
Against Codex CLI High, Macro Direct used 83.5% fewer observed tokens and 84.0% fewer rounds, with a 5-point higher pass rate. The backward-reasoning configuration spent part of the saved budget on stronger investigation and verification, reaching 80.0%.
This is not blind batching: a macro must stop whenever new evidence requires another decision. I also would not treat the aggregate table as proof that every repository improves by the same amount. Task mix, failure handling, and macro boundaries matter.
Implementation, scripts, and data:
https://github.com/Tura-AI/tura
Benchmark record:
https://turaai.net/docs#benchmark-current-test-set-record
The question I'd like feedback on: where would you draw the boundary between a safe deterministic batch and a step that should always return control to the model?