I maintain Tura and open-sourced this implementation. This is a project benchmark, not an independent product review.
A typical repository task can spend separate model turns on environment inspection, several edits, building, tests/lint, and reading Playwright media. The macro approach defines that deterministic workflow once, runs it below the model boundary, and returns the combined evidence when another reasoning decision is actually required.
I tested Codex CLI 0.144.1 with GPT-5.6-sol on 60 DeepSWE debugging and full-repository rewrite sessions:
| 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 and reached 80.0%.
This is not blind batching: the macro stops whenever new evidence requires a decision. I also would not generalize the aggregate table to every repository; task mix, failure handling, and macro boundaries matter.
Implementation, scripts, and data:
Benchmark record:
Where would you draw the boundary between a safe deterministic batch and a step that should always return control to the model?