Tura
An open-source agent runtime harness that replaces repetitive ReAct loops with runtime-managed command graphs, using roughly 80% fewer tokens while improving task success.
The agent executes arbitrary shell commands and apply_patch write operations via the command_run macro tool — a very broad surface. A permission {allow,deny} structure in GUI fixtures hints at a permission model, but no sandboxing, approval flow, or least-privilege documentation appears in the provided files. No user-confirmation mechanism before writes is documented, and prompt/file data flow to LLM providers is not described. Positives: no bundled provider credentials, env-var tokens, cargo-audit/cargo-deny in CI. Checkpoints retaining execution state are described, but there is no evidence of rollback guarantees or undo. Author attribution (Tura) is consistent with repo/license metadata, but the publisher is unverified, capping attribution at a mid score.
The repo is internally consistent: clean workspace crate split, lockfiles and pinned deps, per-platform optional dependencies, per-crate clippy+test CI, and tri-platform install-script tests. CI scripts show structured failure capture and log upload, suggesting careful failure reporting, but user-facing error message quality cannot be confirmed statically, so no full marks.
README and docs index cover CLI, TUI, and GUI entrypoints across macOS/Linux/Windows, with tri-platform CI proving environment fit. Audience (developers) and scenarios (coding tasks) are explicit; KNOWN_ISSUES and ROADMAP honestly state provider/cross-OS/benchmark capability gaps. Entrypoint semantics are tabulated, but one documented trigger (`tura shel`) looks like a typo, costing a point.
Information architecture is excellent: docs/SUMMARY.md index, per-crate ARCHITECTURE files, CONTRIBUTING, CoC, SECURITY, SUPPORT. Install notes are thorough (npm, source, PATH registration, provider setup, no postinstall disclosure). LICENSE is full AGPL-3.0, consistent with Cargo/package metadata. Known limitations have a dedicated file. Deductions: CHANGELOG.md appears only in the pack list with no content shown, workspace version 0.1.0 vs npm 0.1.37 is inconsistent; no FAQ; the `tura shel` naming looks unstable.
README makes quantified cost/benefit claims (77.5% fewer tokens, 65.0% vs 63.3% verifier success) with footnoted methodology and artifacts, and admits the absence of an ablation test — an honest, well-supported cost/benefit case. Output usability and marginal value are inferable only from static description and screenshot captions without independent reproduction, hence mid scores.
Nearly every performance claim carries footnotes into the benchmark repository's manifests and round contracts, and fact/inference separation is good (Codex's 5.4-round figure is explicitly labeled an estimate; missing ablation is acknowledged). Deduction: all corroboration is self-published in the author's own benchmark repo with no independent replication, so cross-source corroboration is weak; links cannot be checked in this static review, keeping confidence low.
- The command_run macro tool lets the model execute multiple shell commands and patch writes in one turn; use only in controlled/isolated environments and verify whether a pre-write confirmation mechanism exists.
- Performance claims (77.5% fewer tokens, etc.) come entirely from the vendor's own benchmark with no independent replication; do not treat them as procurement-grade evidence.
- The publisher is unverified; validate package integrity and provenance before npm installation.
- Version numbers are inconsistent (0.1.0 vs 0.1.37) and one documented entrypoint (`tura shel`) looks like a typo; rely on actual CLI help output.
- Prompts and code content are sent to the configured LLM provider; assess exfiltration risk before using on sensitive repositories.
What does this agent do, and when should you use it?
Tura (GitHub: Tura-AI/tura) is an open-source agent runtime harness whose core idea is to replace the tool-calling loop where a model must re-enter after every tool result with a single runtime-managed command graph. Instead of exposing dozens of small tools, it exposes one macro tool, command_run, letting the agent build and execute a multi-step operation tree in one LLM turn. Across published benchmarks on 20 DeepSWE v1.1 tasks, Tura Direct used 77.5% fewer aggregate tokens than Codex CLI with a comparable verifier success rate (65.0% vs 63.3%), while Tura Balanced reached an 80.0% success rate — 16.7 points higher than Codex CLI — using 31.1% fewer tokens. Tura also applies backward reasoning (estimating the second-to-last state first, then reasoning backward) and runtime context management: task_status, runtime prompts, and recursive execution manuals keep active context scoped to the current task, and compaction is a CLI operation that preserves exact code locations, patches, tests, and task status, with archived sessions showing an average 2.6-round recovery after compaction. The product ships as a CLI (tura exec / tura run), a TUI, a desktop GUI (tura_gui), and a local HTTP/SSE gateway (tura_gateway), distributed via the npm package tura-ai under AGPL-3.0-or-later. Note that its benchmark advantage comes from specific configurations (GPT-5.6 SOL and similar); the README explicitly states results do not establish equivalent performance for every provider configuration.
After reading a user prompt, Tura has the LLM emit a structured command_run call whose commands array orders shell_command and apply_patch operations by step; the Rust runtime executes the graph deterministically without returning to the model each step. During reasoning it uses backward reasoning: it statistically estimates the pre-goal state s_{n-1} first, then derives the execution path backward, reconstructing the failure state and identifying root cause before writing code. Context is managed as part of the runtime state machine: task_status tracks task state, and task_status.compact_context performs CLI-side compaction that retains code locations, patches, and test results; sessions can be renamed, refreshed, and automatically managed; task-specific manuals and CLI commands load through a recursive task tree. On the output side it supports HTML rich text, with multi-session concurrent work in both GUI and TUI. Entrypoints include tura (interactive TUI), tura "prompt", tura exec (direct Rust CLI runner), tura run (gateway-backed with streaming and history), tura bash/zsh/shel (chosen command-run shell), tura_gateway (local HTTP/SSE gateway with optional web GUI), and tura_gui (desktop workspace client).
- Developers who run multi-step coding workflows like search–patch–build–test–lint in a local terminal and want to compress multiple model round trips into one turn to save tokens
- Engineers running long-lived refactoring or debugging sessions who worry about stale skill files and vague summaries polluting context, and need task-scoped compaction with execution resumption
- Cost-sensitive teams willing to use Direct mode to complete tasks at comparable success rates with 77.5% fewer tokens
- Teams chasing higher verifier pass rates who prefer to reinvest saved token budget into reasoning and verification (Balanced mode, 80.0% success rate)
- Users who prefer parallel multi-session work in a desktop GUI or TUI with HTML rich-text output
- Users who want to stand up a local HTTP/SSE service with streaming output and session history via tura_gateway and a web interface
What are this agent's strengths and limitations?
- Auditable published benchmark evidence: 25 high-difficulty tasks, 6 agent-and-model configurations, 270 sessions, with round contracts, token usage, patches, and verifier results archived in the Tura-AI/benchmark repository
- The command_run macro tool compresses multi-step workflows into a single LLM turn — 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
- Compaction is a CLI operation that preserves exact execution state (code locations, patches, tests, task status); archived sessions show an average 2.6-round recovery after compaction
- Context is tied to task state, preventing unbounded accumulation of skill files and lossy compaction summaries in long-lived sessions
- Multiple entrypoints — CLI, TUI, GUI, and local gateway — with multi-session concurrent work and HTML rich-text support
- The benchmark advantage is tied to specific configurations (DeepSWE tasks, GPT-5.6 SOL); the README explicitly states results do not establish equivalent performance for every provider, and broader Anthropic/Claude, Google/Gemini, OpenAI-compatible, local-provider, and cross-OS coverage remain roadmap and evidence gaps
- The README itself notes there is no ablation test proving command_run alone causes the lower turn and token usage
- Codex's 5.4-round compaction recovery figure is estimated from input-token drops, whereas Tura's 2.6-round figure comes from explicit events, so the comparison is not fully like-for-like
- You must configure an LLM provider yourself before first use; no credentials are bundled
- The AGPL-3.0-or-later license imposes compliance constraints for teams embedding the code in closed-source products
How do you install or deploy this agent?
Global npm install (macOS, Linux, Windows): npm install -g tura-ai, then run tura. Local project install: npm install tura-ai, then npx --no-install tura. The npm package runs no postinstall script; the tura wrapper resolves and launches the installed platform package directly. The same main package is also published to GitHub Packages as @tura-ai/tura (configure the @tura-ai scope for https://npm.pkg.github.com with a token that has read:packages). Source install: clone https://github.com/Tura-AI/tura.git, then run .\scripts\install.ps1 on Windows PowerShell or ./scripts/install.sh on macOS/Linux; the installer performs environment setup, release build, and PATH registration, or add -EnvironmentOnly / --environment-only to skip building.
How do you use this agent?
On first launch you must configure an LLM provider and select a model before sending a prompt (Tura bundles no credentials); CLI, TUI, and GUI each have documented configuration flows (docs/start/providers.md). Then use: tura for the interactive terminal UI; tura "prompt" to open the TUI with an initial prompt; tura exec "prompt" for the direct Rust CLI prompt runner; tura run "prompt" for gateway-backed execution with streaming and history; tura bash / tura zsh / tura shel to pick a command-run shell surface; tura_gateway to start the local HTTP/SSE gateway with optional web GUI serving; tura_gui for the desktop workspace client. The core workflow is having the model generate a command_run macro call that orders shell_command and apply_patch operations by step in a commands array, executed deterministically by the runtime in a single turn.
How does this agent compare with similar options?
The README benchmarks Tura directly against Codex CLI: on 20 DeepSWE v1.1 tasks, Tura Direct used 77.5% fewer aggregate tokens with comparable verifier success (65.0% vs 63.3%); Tura Balanced reached 80.0% success (16.7 points higher) with 31.1% fewer tokens and 35.8% fewer turns. On the same subset, DeepSWE's official mini-swe-agent results show only an 8% gap between GPT-5.6 SOL High and Medium reasoning, while Tura Balanced leads Codex CLI by 16.7%, indicating the advantage cannot be explained by reasoning effort alone.