Tura: an agent harness that cuts tokens

What Tura is, and what the 77.5% claim covers

Tura is an open source coding agent harness that runs on your own server and calls your own provider account. It ships on npm as tura-ai, it is licensed AGPL-3.0-or-later, and 0.1.37 is the current version as of 17 August 2026. The headline on the project README is 77.5% fewer tokens than Codex CLI, measured by a benchmark that the Tura authors wrote, ran and published themselves.

Vendor benchmarks are normal, and this one publishes its raw runs and its own list of limitations. Still, a number you cannot reproduce is a number you should not budget against. What follows is where the saving comes from, and how to check it on one VPS using your provider's usage reporting rather than either harness's self report.

The numbers Tura publishes

Both blocks below hold the vendor's figures, copied from the Tura benchmark repository in August 2026. They are published figures, not our measurements.

[
  {
    "config": "Tura Balanced",
    "round_count": 2017,
    "total_tokens_millions": 229.7,
    "run_cost_usd": 221.14
  },
  {
    "config": "Tura Direct",
    "round_count": 969,
    "total_tokens_millions": 75.1,
    "run_cost_usd": 99.62
  },
  {
    "config": "Codex CLI Medium",
    "round_count": 3140,
    "total_tokens_millions": 333.5,
    "run_cost_usd": 257.17
  },
  {
    "config": "Codex CLI High",
    "round_count": 6074,
    "total_tokens_millions": 455.7,
    "run_cost_usd": 327.48
  }
]

[
  {
    "config": "Tura Balanced",
    "success_pct": 80,
    "tasks_passed": 48
  },
  {
    "config": "Tura Direct",
    "success_pct": 65,
    "tasks_passed": 39
  },
  {
    "config": "Codex CLI Medium",
    "success_pct": 63.3,
    "tasks_passed": 38
  },
  {
    "config": "Codex CLI High",
    "success_pct": 60,
    "tasks_passed": 36
  }
]

The headline is the second row against the third. Tura Direct spent 75.1 million tokens where Codex CLI Medium spent 333.5 million, over 20 DeepSWE v1.1 tasks run three times each. The round counts moved the same way: 969 model round trips against 3140. The published cost for the whole sweep followed, at $99.62 against $257.17.

Two details in that data deserve attention before you quote it anywhere. First, the baseline is the medium reasoning configuration of Codex CLI. The high configuration, the last row, spent 455.7 million tokens and passed the fewest tasks of the 4 configurations, so "fewer tokens than Codex CLI" depends on which Codex CLI you mean. Second, the pass rates sat close together: Tura Direct at 65% against Codex CLI Medium at 63.3%, which is a difference of one run in sixty. The configuration that pulled ahead on outcomes was Tura Balanced at 80%, 48 of 60 runs, and it saved far fewer tokens to get there.

The benchmark's own methodology page lists its limits: 20 DeepSWE tasks plus 5 rewrite tasks give restricted statistical power, the sampling was stratified rather than random, public repositories may sit in the model's training data, and the configurations vary jointly with no component ablation. That last one matters most here. Because nothing was isolated, the published number cannot tell you how much of the saving came from any one mechanism.

Where the token saving comes from

One macro command instead of a tool call per turn

Most coding agents run a ReAct loop: the model emits one tool call, the harness runs it, the result goes back, the model is called again. Every one of those calls resends the system prompt, the task and the whole transcript so far. Four turns over a 40,000 token context replay roughly 160,000 input tokens, and Tura's documentation uses exactly that arithmetic to justify the design.

Tura replaces the one-call-per-turn protocol with a single tool named command_run. The model sends a batch of commands, each carrying a step number, and the runtime executes them locally without returning to the model in between. Commands sharing a step must be independent of each other, so the runtime can run them together. A higher step waits for the step below it.

{
  "commands": [
    {"command_type": "shell_command", "step": 1, "command_line": "rg --files"},
    {"command_type": "shell_command", "step": 1, "command_line": "rg -n TODO crates"},
    {"command_type": "apply_patch", "step": 2, "command_line": "*** Begin Patch ..."},
    {"command_type": "shell_command", "step": 3, "command_line": "cargo test -q"}
  ]
}

Reads at step 1, the edit at step 2, the test at step 3: one model turn where a ReAct agent needs four. If a step fails, the runtime stops the batch and marks the rest cancelled, returning a top level cancelled: true and a cancel_reason such as apply_patch failed; command_run stopped before later commands. The model gets one result describing what ran and what never got the chance.

This one is a genuine harness property. You cannot prompt your way to it, because the saving lives in the tool protocol: the model must be able to describe a dependency ordered batch, and the runtime must be able to execute that batch and report on it as a unit. It is also where the risk sits. A batch built on a wrong guess burns local time and returns one large result, and the model only learns that at the end.

Goal first planning and a verification gate

Tura loads a runtime prompt, which is an operation manual selected by task_type from a bundled set that includes debug, devops, refactoring, new_build and frontend. The manual is injected only while the current task needs it. A second command, task_status, holds the live state of the work: the task group, a status of doing, question or done, the task types in force, and a compact handoff summary. The documentation is explicit that the runtime prompt forbids marking a task done when required verification failed or was skipped.

Stating the finished condition first and refusing to declare success without a passing check is good practice, and it is the part of Tura you can take with you. This is prompting, not architecture. Any agent you already run can be told to write down what "done" looks like before it starts, plan the steps that reach it, and treat a failing test as a blocked task rather than a finished one. If you want the discipline without a migration, put it in your existing system prompt today and measure that change on its own.

Pruning stale context instead of replaying it

Tura does not grow one transcript forever. It stores raw session events and rebuilds the messages it sends to the provider from compact records. At a checkpoint it writes a context_compaction record holding the goal, the evidence, a workspace snapshot and the next steps, then rebuilds from that. It keeps the current run's messages, the tool evidence and validation results behind them, the command results immediately before the checkpoint, and at most two recent compact summaries. It drops prompt scaffolding and old tool output far from a checkpoint, along with reporting metadata such as command ids and timestamps. The active token budget defaults to 260,000, and the active manuals are appended again after a compaction so the operating mode survives the trim.

Half of this is portable. Any agent can be told to summarise and restart, and many already do. The half you cannot copy with a prompt is the session log underneath: the raw events stay on disk in the workspace, so a compact record can be rebuilt or replaced without losing what actually happened. Summarising a transcript in place is lossy and one way. Rebuilding from an event log is neither.

Install Tura on a VPS

The npm package ships prebuilt native binaries, so the install needs Node 20 or newer and nothing else. No Rust toolchain, no Bun. The platform packages published for 0.1.37 cover Linux x64, macOS on Intel, macOS on Apple silicon, and Windows x64. There is no Linux arm64 package, so an arm64 VPS has to build from the repository instead, and that path does want Rust, Bun, uv and Python 3.12.

node --version
npm install -g tura-ai@0.1.37
tura --help

node --version must print v20 or higher before you continue, because an older Node fails the package's engines check during install. tura --help should print the command list without contacting any provider, which is why it is a safe first check. If the shell answers tura: command not found, the npm global bin directory is not on your PATH, and npm prefix -g tells you which directory to add.

Pin the version. The project is moving quickly, so tura-ai@0.1.37 keeps your comparison reproducible. Upgrade deliberately once you have a baseline to compare against.

Point Tura at your own provider

Tura bundles no credentials. Nothing works until you attach a provider and select a model.

export OPENAI_API_KEY="sk-..."
tura provider list
tura provider set-auth openai --key "$OPENAI_API_KEY" --type api
tura config model-tiers
tura config set model=openai/MODEL_ID

tura provider list prints each provider with its authentication status, so run it a second time after set-auth and confirm the one you configured now reports as authenticated. Documented credential variables include OPENAI_API_KEY, ANTHROPIC_API_KEY, GOOGLE_API_KEY or GEMINI_API_KEY, DEEPSEEK_API_KEY and OPENROUTER_API_KEY. Tura also reads a .env file, and TURA_ENV_PATH points it somewhere else. Passing the key through an exported variable, as above, keeps the literal secret out of your shell history.

Then a smoke test that costs one short call:

tura exec -m openai/MODEL_ID "print the current git branch and stop"

A short answer means the credential path works end to end. An authentication error here is a provider problem rather than a Tura problem, and running the same key against the provider's own API tells you which of the two you are looking at.

What AGPL-3.0 means if you embed Tura

Tura is licensed AGPL-3.0-or-later. Running it yourself as a developer tool creates no obligation: use it and modify it, and keep your changes private. The clause that catches people is section 13. If you modify Tura and let other people use that modified version over a network, you must offer those users the corresponding source of your modified version. Wrapping Tura in an internal tool for your own staff is the same conversation as any other internal AGPL use. Putting it inside something you sell is the case where the source offer clearly applies, so raise the licence with whoever owns that decision at your company before you build on it.

Run the comparison yourself

The exercise is simple. Take one task you have already completed, so you can judge the output instead of guessing at it. Use the same repository, the same starting commit and the same model for every run.

START_COMMIT="1a2b3c4"
git clone https://github.com/your-org/your-repo /tmp/run-a
git -C /tmp/run-a checkout "$START_COMMIT"

Set START_COMMIT to the commit your task started from, and reuse that same value for every run. Clone again into /tmp/run-b for the second harness. Two separate clones stop one run's edits from becoming the other run's starting state, which is the most common way this comparison gets quietly ruined.

Run your current agent in the first clone exactly as you normally would. Then run Tura in the second:

tura exec -C /tmp/run-b -a direct -m openai/MODEL_ID --sandbox --goal "<the same task text>"
tura exec -C /tmp/run-b -a balanced -m openai/MODEL_ID --sandbox --goal "<the same task text>"

-a picks the agent, and the built-in ids are direct, balanced and direct-text-only. The direct agent prefers the fast model tier and turns the operation manuals off. The balanced agent uses the thinking tier and keeps the verification discipline on. --goal keeps the run going until the task is marked complete rather than stopping after one reply, --sandbox restricts writes to the workspace, and --json gives you the events as JSONL if a script is reading them. Tura's own history lands in <workspace>/.tura/session_log.sqlite3.

Count the tokens at the provider. Each harness reports what it believes it sent. The provider reports what it billed, and those two numbers separate as soon as cached input reads and hidden reasoning tokens are in play. Most provider consoles break usage down by API key or by project, so create one key per harness before you start and read each total off the console when the runs finish. If your provider does not split usage that way, run the two harnesses on different days and read the daily totals.

Then score the outcome next to the cost. A run that spends a quarter of the tokens and leaves the test suite red saved you nothing. Mark each run pass or fail on the task itself first, and compare spend only among the runs that passed. Do the pair at least three times, because one agent run on a real task varies enough to flip the ranking by itself. The vendor ran three replicates per task for that same reason.

Reading the result honestly

Token counts are not costs. Input tokens, cached input reads and output tokens bill at different rates on every major provider, and reasoning tokens bill as output even though you never see them. A harness that replays a long stable prefix on every turn may be reading most of that prefix from cache at a fraction of the input rate, which shrinks the real money gap well below the token gap. Our guide to the prompt caching break even point works through where that flips, and the breakdown of where a coding agent's tokens actually go shows which part of a session is worth attacking first.

The other limit is your task mix. DeepSWE tasks are self contained repository bugs with a test that decides the answer, which is close to ideal for batching reads, one patch and one test run into a single turn. If your agent mostly writes new features across services, reads long logs, or drives a browser, the round trip pattern is different and so is the saving. That is the whole reason to measure on your own repository.

Where Tura fits next to your other cost levers

A harness swap is the most disruptive lever available, because it replaces the tool your team already knows how to drive. Prompt caching costs you a prompt reorder and pays back on every turn after that. Model routing sends the cheap turns to a cheap model and saves the expensive one for work that needs it, which routing coding agents across several models covers in detail. A gateway in front of everything gives you per project budgets and one place to read spend, which is what a self hosted token gateway is for. Controlling AI agent costs on a VPS puts those levers in order of effort, and running a coding agent on a VPS is the setup all of this assumes you already have.

Test Tura when your bill is dominated by long agent sessions on well defined repository tasks, and adopt it when the comparison above shows the difference on your own work. Leave it alone when your spend is already mostly cache reads, or when the cost of retraining everyone on a new harness outweighs a saving you have not measured yet.

FAQ

Is Tura's 77.5% token reduction independently verified?

No. As of August 2026 the figure comes from a benchmark that Tura-AI wrote, ran, published and hosts, and the methodology page states that conflict of interest itself. The raw runs are public, which is more than most vendor claims offer, and the sample is 20 DeepSWE v1.1 tasks run three times across four configurations. The same page states there was no component ablation, so the number cannot be attributed to any single mechanism. Treat it as a reason to run your own test, not as a result you can budget against.

Will Tura run on my VPS?

On Linux x64 with Node 20 or newer, yes. npm install -g tura-ai@0.1.37 pulls a prebuilt native binary and needs no compiler, no Rust and no Bun. There is no Linux arm64 platform package at 0.1.37, so an arm64 VPS has to build from the repository checkout, which does need Rust, Bun, uv and Python 3.12. The desktop GUI is excluded from the npm route; the CLI and the terminal UI are included.

Does AGPL-3.0 stop me using Tura at work?

Not for ordinary use. Running Tura as a developer tool, including a copy you have modified, creates no publishing obligation. Section 13 applies when you modify Tura and let other people interact with your modified version over a network: those users must be offered the corresponding source of that version. Raise the licence before you embed Tura inside a product you ship to customers, and treat plain internal use as the low risk case it is.

Should I use the direct agent or the balanced agent?

The direct agent prefers the fast model tier and disables the operation manuals, and it is where the largest published token saving comes from, at a pass rate within one run of the Codex CLI baseline in that same sweep. The balanced agent uses the thinking tier and keeps the verification discipline, and it recorded the highest pass rate in the published run while still spending fewer tokens than the baseline. Start with balanced on work that has to be correct, and compare direct on tasks where a failed attempt is cheap to throw away.