PromptZone - AI Prompts, Guides and Tools for Builders: Yohji Sakamoto

MCP workflow benchmark: the real token cost is repeated context

Yohji Sakamoto — Sat, 15 Aug 2026 18:47:41 +0000

Most MCP demos are one tool call. Real work is a dependency chain: create a project, read its ID, pass that ID into the next operation, and keep going.

The costly part is often the handoff. In the benchmark's ecommerce workflow, both configurations passed the same five verifier checks and created the same deliverables. Tura Direct used 3 model requests instead of 11, and 56,372 total tokens instead of 262,915 (78.6% lower), despite making 11 MCP calls rather than 9. The saving is repeated model context, not skipped work.

Tura's command_run Macro lets an agent describe the dependency graph once. Values from a successful step can be used by later steps, while independent commands run together. The model does not need a new turn just to read an ID and copy it into the next tool call.

For longer chains, each handoff kept inside the Macro can avoid another model re-entry, so repeated-context savings can accumulate. That is not a universal linear law—caching, retries, and workflow shape still matter—but it is a useful lever for multi-step MCP work.

Full trace, caveats, and variable inheritance: https://turaai.net/blog#what-we-learned-from-the-mcp-workflow-benchmark

Source code: https://github.com/Tura-AI/tura

Disclosure: I am sharing work from Tura-AI.

Cut LLM turns in MCP interactions by 75%+: the 5-to-1 workflow example

Yohji Sakamoto — Tue, 11 Aug 2026 21:53:15 +0000

The problem

A typical MCP coding-agent loop is often: inspect → patch → build → test → lint.

Even when the work is predictable, that means the model wakes up after every tool result to decide the next call. In a simple five-step workflow, that is 5 LLM turns.

What Tura changes

Tura exposes a macro tool called command_run. The agent sends a dependency-aware execution plan once, and the runtime executes the related commands in order. Build, test, and lint still run; the difference is that the model does not need to re-enter between each predictable step.

For the illustrated task, the loop goes from 5 model turns to 1 — an 80% reduction in model re-entries. This is a reduction in conversational/tool-calling overhead, not an attempt to skip verification.

Disclosure: I work on Tura.

Task benchmark: https://turaai.net/benchmark-task?task=workflow-ecommerce-ad-package#runs
GitHub: https://github.com/Tura-AI/tura

Curious whether others are tackling repeated tool-loop overhead in MCP agents this way.

Fewer LLM turns, more commands: a practical way to verify research-heavy agent work

Yohji Sakamoto — Tue, 04 Aug 2026 20:52:36 +0000

What if an agent spent less time going back to the model, but did much more useful work inside each turn?

That is the idea I have been testing: let an LLM turn make a decision, then let one batch of commands search, inspect, compare, and verify the result. The goal is not “fewer turns” by itself. The goal is fewer expensive decision loops and more observable work between them.

I used a deliberately messy task: build a 15-slide guide to 10 East Asian squid recipes, with illustrations, recipe sources, and cooking videos. This kind of job is easy to make look finished while leaving behind broken links, duplicated videos, missing assets, or a layout that only works on one screen.

Across four runs, the two CLI-style runs averaged 13.5 LLM turns and 10.5 tool calls. The two direct-execution runs averaged 10 LLM turns and 82 tool calls. So, in this small matrix, the direct approach used 25.9% fewer LLM turns while issuing about 7.8× more commands.

The interesting part was not the headline number. In one early turn, the agent launched roughly 20 discovery commands for recipes and matching videos. Later checks confirmed 10 sources, 10 unique video destinations, 15 local assets with none missing, navigation behavior, and rendering at 1440, 768, and 390 pixels. One bad recipe destination was corrected, and the remaining video IDs were validated.

This pattern is useful anywhere the work is “collect, produce, then prove it is usable”: research briefs, slide decks, market maps, buyer guides, travel plans, content migrations, link audits, and QA-heavy reports.

The mental model is simple:

Use the LLM turn to decide what needs to happen.
Fan that decision out into many independent commands.
Gather structured results.
Use the next turn only when judgment is actually needed.

This is only a four-run case study, not proof that one setup always wins. Runtime was mixed, and token accounting came from different harness sources. But it does show why “turn count” and “command count” should not be treated as the same thing.

The full interactive task and the raw run artifacts are public:

I maintain Tura and this benchmark. I would be interested to hear: which part of your workflow should be one LLM decision followed by a batch of verifiable commands?

5 coding-agent turns vs 1 command_run workflow: full example

Yohji Sakamoto — Mon, 03 Aug 2026 21:02:26 +0000

Disclosure: I maintain Tura.

Here is the simple idea. A normal coding agent may use five separate LLM turns for one predictable workflow.

Turn 1 — inspect

rg -n "TODO|command_run|handler" crates/
rg --files crates/runtime/src crates/tools/src

Turn 2 — apply the patch

- // old command handler logic
+ // patched command handler logic

Turn 3 — build

cargo build -p runtime

Turn 4 — test

cargo test -p runtime --lib

Turn 5 — lint

cargo clippy -p runtime --all-targets

The overhead is not only the shell commands. The model wakes up five times and receives the growing conversation again.

Tura exposes one macro tool called command_run, so the agent can send the same workflow once:

{
  "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" }
    ]
  }
}

Build, test, and lint still run. The model simply does not need a new turn between predictable steps.

In the full DeepSWE comparison, Balanced used 35.8% fewer turns and 31.1% fewer tokens than Codex CLI. Direct used 69.1% fewer turns and 77.5% fewer tokens.

GitHub: https://github.com/Tura-AI/tura

Benchmark: https://turaai.net/benchmark

I built a repeatable way to check whether token-saving tools actually work

Yohji Sakamoto — Tue, 28 Jul 2026 17:21:22 +0000

Hi, I’m Yu. Earlier this month I released Tura and wrote about why agent harnesses need long-horizon benchmarks, not just one-off demos.

Over the past two weeks, I’ve seen more people publish tests of token-saving tools such as RTK and Ponytail. That’s great, but the results are hard to compare when everyone uses different tasks, logs, and output formats.

So I open-sourced the benchmark framework I use:

https://github.com/Tura-AI/benchmark/tree/main

It can run the benchmark workflow, collect logs and artifacts into one result schema, and let CI index any result added to the repository. The website then turns those results into comparable graphs and detailed run pages.

If you have a tool, harness, or test case you want included, tell me. You can also run the benchmark locally, reproduce the evaluation, and submit the result folder as a pull request. CI handles the indexing automatically.

I’d especially like feedback on what should be tested next and where the framework may introduce bias.

Disclosure: I maintain Tura and this benchmark framework.

Why My Open-Source Project Hasn't Done Better

Yohji Sakamoto — Sat, 25 Jul 2026 14:19:35 +0000

Disclosure: I am the maintainer of Tura. I am posting this to ask for candid advice about open-source communication and evaluation, not as an independent review of my own project.

Since the beginning of 2026, projects such as RTK, Caveman, and Ponytail have claimed that they can reduce token usage by 80–90%. Some gained tens of thousands of GitHub stars in a very short time.

My previous startup was building an e-commerce chatbot. The product was close to what later became the Universal Commerce Protocol (UCP). After UCP was released, I decided not to continue in that direction.

Earlier this year, I began turning the architecture we had built for e-commerce chatbot agents into an SDK. Put simply, its core idea is to use state machines and deterministic execution sequences to reduce the number of round trips to LLM providers by around 80% for the same task, thereby reducing token consumption.

I understand why tools such as RTK are ineffective in genuinely long-running tasks. I published a report on July 18, and JetBrains published a report on July 20 that reached essentially the same conclusion: token-saving plugins such as RTK and Caveman have little or no effect on real-world, long-running tasks.

JetBrains report: https://blog.jetbrains.com/ai/2026/07/rtk-claude-code-token-savings/
My report and reproducible methodology: https://github.com/Tura-AI/tura/blob/main/docs/blog/token-saving-plugins-are-mostly-stupid-idea.md

I also believe I know how to achieve a real reduction of more than 80% in token consumption during long-running tasks. However, I have found it much harder to communicate and promote this open-source project than to build it.

What I think went wrong

Most coding-agent users do not care what actually drives token consumption

There is a large gap in understanding among coding-agent users, whether they have formal software-engineering training or are self-taught "vibe coders."

A long article that systematically explains the mechanism and challenges existing assumptions has little chance of spreading in forums already flooded with AI-written posts and plugins claiming 95% token savings.

Simple ideas are easier to spread. People are not purely rational; we tend to believe explanations that are easy to understand. That is also why pseudoscientific content based on incorrect causal explanations can attract much more attention than careful explanations of the underlying mathematics.

The author's arrogance

This is probably a combination of two problems.

From the perspective of someone who strongly believes in scientific testing, evaluations, and benchmarks, software-engineering claims without an evaluation can feel meaningless.

But perhaps my own arrogance—and my contempt for, or jealousy of, tools such as RTK—has made me less willing to explain and promote my work in ways that would actually be effective.

If you have read this far, I would genuinely appreciate your advice:

How can I communicate this project more effectively without sacrificing rigorous evaluations and benchmarks?
What evidence would make you willing to try an unfamiliar coding-agent SDK?
Is the message too technical, too combative, or aimed at the wrong audience?
What should I change on the repository page or in the benchmark presentation?

I know that building a coding agent with Codex or Claude is relatively easy. But I also believe there will always be people who value benchmarks and evaluation harnesses.

The project was released on July 16 and currently has a little over 400 GitHub stars:

https://github.com/Tura-AI/tura

I welcome critical feedback, including reasons you would not use it.

How GPT-5.6 sol token is used in Codex

Yohji Sakamoto — Tue, 21 Jul 2026 19:30:52 +0000

Disclosure: I maintain Tura, where the full test record is published.

I ran 280+ Codex CLI sessions with GPT-5.6 Sol. In the current build, fewer commands per model turn can mean more turns and more cached-input cost.

Most benchmarks favor 5.6 Sol on cost per result: on DeepSWE, 5.5 High averaged USD 5.1 per task versus USD 3.5 for 5.6 Sol High. But in Codex CLI 0.144.1, my 5.6 Sol High runs were about 21% more expensive than 5.5 High.

The likely mechanism is orchestration: 5.5 explicitly uses multi_tool_use.parallel, while 5.6 mainly uses one top-level exec. I observed 0.97 versus 2.5 commands per model call, roughly 1.84× as many rounds, and 66.5% of 5.6 Sol High cost in cached input. Token-saving plugins did not materially lower that total; reducing unnecessary model rounds did.

Implementation reference: https://github.com/openai/codex/blob/rust-v0.144.1/codex-rs/core/src/tools/code_mode/execute_handler.rs#L20-L72

Full test record: https://turaai.net/docs#benchmark-current-test-set-record

How to batch 5 coding-agent turns into 1 macro workflow

Yohji Sakamoto — Tue, 21 Jul 2026 02:36:12 +0000

Disclosure: I maintain Tura.

Here is the simple idea. A normal coding agent may use five separate LLM turns for one predictable workflow.

Turn 1 — inspect

rg -n "TODO|command_run|handler" crates/
rg --files crates/runtime/src crates/tools/src

Turn 2 — apply the patch

- // old command handler logic
+ // patched command handler logic

Turn 3 — build

cargo build -p runtime

Turn 4 — test

cargo test -p runtime --lib

Turn 5 — lint

cargo clippy -p runtime --all-targets

The overhead is not only the shell commands. The model wakes up five times and receives the growing conversation again.

Tura exposes one macro tool called command_run, so the agent can send the same workflow once:

{
  "name": "command_run",
  "arguments": {
    "commands": [
      { "step": 1, "command_type": "shell_command", "command_line": "inspect files" },
      { "step": 2, "command_type": "apply_patch", "command_line": "apply 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" }
    ]
  }
}

Build, test, and lint still run. The model simply does not need a new turn between predictable steps.

In the full DeepSWE comparison, Balanced used 35.8% fewer turns and 31.1% fewer tokens than Codex CLI. Direct used 69.1% fewer turns and 77.5% fewer tokens.

GitHub: https://github.com/Tura-AI/tura

Benchmark: https://turaai.net/benchmark

Why “90% Fewer Tokens” Can Still Mean a More Expensive Coding Agent

Yohji Sakamoto — Sun, 19 Jul 2026 15:41:25 +0000

Token-efficiency claims are everywhere in the coding-agent ecosystem: a plugin compresses shell output by 90%, a context tool removes thousands of tokens, or a prompt layer reports a large reduction in one step.

Those numbers may be real. The harder question is whether they reduce the cost of a verified, completed task.

I tested that question with a matched repository-rewrite task: rebuild the Rust eza project as a behavior-compatible Python implementation and satisfy 52 harness assertions. Every run used GPT-5.6-sol High through Codex CLI 0.144.1. I compared no plugin, Ponytail, and RTK, with two runs per condition.

What the matched runs showed

Condition	Mean verifier score	Mean tokens	Mean modeled cost	Mean rounds
No plugin	78.85%	6.660M	$5.281946	62.5
Ponytail	80.77%	-7.56% vs baseline	-8.87%	—
RTK	76.92%	+13.20% vs baseline	+7.18%	+44.00%

Ponytail used fewer tokens and cost less in this small sample, but took 13.51% longer. RTK used more tokens, cost more, and took 40.69% longer.

The important caveat is the sample size: n=2 per condition is not enough to estimate a causal plugin effect. In fact, the cost range divided by the mean was 43.25% without a plugin, 51.69% for Ponytail, and 30.78% for RTK. Those within-condition swings are much larger than the headline differences between conditions.

That means a single good run can easily produce a persuasive “saved X%” claim even when ordinary agent-trajectory variance is the simpler explanation.

The denominator is the real problem

The broader dataset contains 140 Codex CLI Medium/High runs, 10,365 agent rounds, 901,608,531 tokens, and $680.34 in modeled API cost. It contains no Tura runs.

The token and cost distributions were very different:

Cached input: 96.46% of tokens, 63.91% of modeled cost
New uncached input: 3.16% of tokens, 20.94% of cost
Model output: 0.38% of tokens, 15.14% of cost

So a tool can compress one prompt fragment or one class of terminal output by a huge percentage while barely moving the full-task bill. It may also change the agent’s path: extra searches, retries, tool calls, or rounds can erase the local saving.

For example, the dataset contains 1,082 uniquely classified RTK-supported shell calls returning 1,458,927 tokens—only 0.1618% of all task tokens. Even a perfect 90% reduction of every eligible return corresponds to about 0.96% in directly attributable modeled cost savings.

A better evaluation checklist

Before accepting a token-saving claim, I now ask four questions:

Was the same task repeated with and without the tool?
Did an external verifier confirm the final result?
Were retries, failures, orchestration, and tool calls included?
Is the metric cost per verified successful task, rather than tokens removed from one step?

Compression can still be useful. The point is that local compression percentage is not a reliable substitute for end-to-end evidence.

The full analysis, assumptions, formulas, and reproducible data links are here:

https://turaai.net/blog#token-saving-plugins-are-mostly-stupid-idea

The open-source project is here:

https://github.com/Tura-AI/tura

Disclosure: I maintain Tura and wrote the linked analysis. This post was prepared with AI assistance and reviewed against the underlying benchmark data before publication.