The Cost Isn’t in the Reasoning, It’s in the Back-and-Forth: Tura and 80% Success with Half the Tokens
By Devy · Category: AI Dev Tools — General
The usual assumption about why a coding agent burns tokens is that thinking is expensive. Tura’s thesis is that thinking is the cheap part. What costs you is the shape of the conversation: inspect, receive the result, patch, receive it, compile, receive it, test, receive it. Five back-and-forths, and each one sends the model all the accumulated context again.
Tura is a coding agent written in Rust (AGPL-3.0-or-later) that attacks exactly that. Instead of exposing the model dozens of small tools — read file, write file, run command, apply patch — it exposes just one: command_run. The model builds a multi-step execution tree and the runtime runs it entirely in a single LLM turn.
It launched as Show HN this morning. Installation is an npm command. And, surprisingly for a project of this type, it publishes both its benchmark artifacts and its own list of what those artifacts don’t demonstrate.
What One Turn Looks Like Instead of Five
This is the example the project itself uses. A conventional agent needs five turns: inspect, patch, compile, test, lint. Tura sends it as a single tool call:
{
"name": "command_run",
"arguments": {
"commands": [
{ "step": 1, "command_type": "shell_command", "command_line": "rg -n \"TODO|command_run|handler\" crates/" },
{ "step": 1, "command_type": "shell_command", "command_line": "rg --files crates/runtime/src crates/tools/src" },
{ "step": 2, "command_type": "apply_patch", "command_line": "*** Begin Patch\n*** Update File: crates/tools/src/command_run/handler.rs\n@@\n- // old command handler logic\n+ // patched command handler logic\n*** End Patch" },
{ "step": 3, "command_type": "shell_command", "command_line": "cargo build -p runtime" },
{ "step": 4, "command_type": "shell_command", "command_line": "cargo test -p runtime --lib" },
{ "step": 4, "command_type": "shell_command", "command_line": "cargo clippy -p runtime --all-targets" }
]
}
}
Look at the step field, because that’s where the whole design lives. It’s not a list of commands, it’s a dependency graph. Two commands that share step: 1 run together — both rg commands are independent, so they go at the same time —. The step: 2 waits for 1 to finish because you can’t patch what you haven’t read yet. The build waits for the patch. Test and clippy share step: 4 because neither needs the other.
So this isn’t “grouping some shell commands together”. It’s the agent committing upfront to a plan whose dependencies it’s already resolved, and only coming back to the model when the plan is done or something broke.
The Numbers, and What Baseline They’re Against
You need to read this carefully, because the project’s headline and the number circulating on the timeline are both true and they’re not the same number.
The full table, from the published evidence record. DeepSWE v1.1, 20 tasks run three times each, so 60 runs per configuration — all with GPT-5.6 SOL, July 2026:
| Configuration | DeepSWE Pass Rate | Tokens Observed |
|---|---|---|
| Tura Balanced High | 80.0 % (48/60) | 229,695,477 |
| Tura Direct High | 65.0 % (39/60) | 75,108,167 |
| Codex CLI Medium | 63.3 % (38/60) | 333,538,349 |
| Codex CLI High | 60.0 % (36/60) | 455,742,296 |
Now the math, which you can do yourself from that table:
- Against Codex CLI Medium, Balanced gets 16.7 percentage points higher with 31.1% fewer tokens. That’s the pair the README puts in its own headline.
- Against Codex CLI High, Balanced gets 20 percentage points higher with 49.6% fewer tokens, and Direct uses 83.5% fewer.
Neither comparison is dishonest. But notice the ordering problem: Codex CLI High spends 37% more tokens than Codex CLI Medium and scores worse (60.0% vs. 63.3%). If you pick High as your baseline you get the biggest savings number by comparing against the weaker rival. The README chose the more conservative pair for its title, and that’s worth saying out loud.
There’s a third number floating around: 83.1% fewer turns. That comes from the rewrite benchmark and counts turns, not tokens. Don’t mix it with the 83.5% of tokens: different metric, different benchmark.
The Context Compaction Result, Which Seemed More Interesting Than the Headline
Well below the pass rates is the measurement I’d reproduce first.
Every agent hits context compaction on a long task. The question is what happens right after. Typically the agent comes out of compaction half-blind and wastes several rounds re-reading files to reconstruct the state it just lost. Tura treats compaction as a CLI operation and preserves the exact execution state in task_status.compact_context: code locations, patches, tests, task state — not a loose prose summary.
In the published sessions, Tura returned to doing real work (not read-only inspection) on average 2.6 rounds after compaction. The comparison figure for Codex is 5.4 rounds.
The project is clear about the asymmetry there, and we should be too: Tura’s 2.6 comes from explicit compact_context events in its own archived round contracts. Codex doesn’t emit equivalent events, so its 5.4 is estimated from points where input token usage drops sharply. It’s an inferred number against a measured one. Useful as a direction, not as a fair comparison.
Installing It
npm install tura-ai
tura
On Windows:
npm install -g tura-ai
tura
From source, if you want to read the Rust:
git clone https://github.com/Tura-AI/tura.git
cd tura
./scripts/install.sh
tura
Tura doesn’t come with provider credentials. On first launch you configure an LLM provider and pick a model before you can send anything. That step matters more than usual here — see the next section.
Useful entry points once it’s in your PATH:
| Command | What It Does |
|---|---|
tura |
Interactive terminal UI |
tura "prompt" |
TUI with an initial prompt |
tura exec "prompt" |
Direct prompt runner in the Rust CLI |
tura run "prompt" |
Prompt via gateway, with streaming and history |
tura_gateway |
Local HTTP/SSE gateway, optional web GUI |
tura_gui |
Desktop workspace |
The latest tag is v0.1.33, from July 14th: the Show HN is today, but the release is nearly four weeks old. This is 0.1.x software and the roadmap says so.
What to Actually Measure, Since Nobody Measured It with Your Model
Here’s the gap that decides if any of the above applies to you: all published figures were produced with GPT-5.6 SOL. The project lists broader measurements with Anthropic/Claude, Google/Gemini, OpenAI-compatible providers, local providers, UI latency, and cross-OS as roadmap items and known evidence gaps. In their own words: the published results “do not establish equivalent quality or performance for every configured provider”.
It’s not a knock against the project — publishing your own evidence gaps is rarer than publishing your benchmark — but it means if you run Claude Code or Codex on Claude or Gemini, the honest state of the 49.6% for your setup is: unknown.
The repo also explicitly says the comparison “is not a clean A/B test”. The Codex configurations differ in build and in reasoning effort, and the configuration matrix doesn’t isolate the behavior of compact-context, command batching, operation manual instructions, and backward reasoning from each other. Those are four mechanisms that travel together and the benchmark measures their sum.
So the reproducible experiment is smaller than the benchmark and more useful for you:
- Take a task from your own repo with a real loop of inspect → patch → compile → test. No toys.
- Run it with your current agent and log two things: number of LLM turns and total tokens. Both are on your provider’s dashboard.
- Run the same task under Tura with your provider configured at comparable reasoning effort.
- Compare turns first, tokens after. If the mechanism works, the turn count drops before anything else.
Turns are the cleanest signal because that’s what command_run touches directly. Token totals move for a dozen other reasons: different context windows, different system prompts, different compaction thresholds.
And run it three times per configuration, like the benchmark does. Agent runs are noisy; a single pair of numbers tells you nothing.
A note on the name
Don’t confuse it with Turo, which we covered before and which is a proxy layer you install once to make your existing agents send fewer tokens. Tura does the opposite move: it replaces the agent instead of sitting in front. Similar names, similar promise, completely different places in your stack.
What I take away
The interesting claim here isn’t the percentage. It’s the diagnosis behind it: that the dominant cost in an agent loop is conversational overhead and not reasoning, and that the solution is to stop asking the model to narrate every step and start asking it for a plan with declared dependencies.
That idea is portable. Even if you never install Tura, the shape of command_run is a reasonable question to ask your current agent: how many turns did that task take, and how many of them existed just because the tools interface forced a round trip?
The benchmark artifacts are public, the round contracts are in the repo, and the math above reproduces from the published table. That’s more than most projects give you. What’s missing is someone running it against a model other than GPT-5.6 SOL — and you can do that part this afternoon.
What about you? How many turns does your agent take in a normal inspect → patch → test loop, and how many of those do you think are just the tools interface talking?
Sources: