El gasto no está en el razonamiento, está en el ida y vuelta: Tura y los 80 % de éxito con la mitad de tokens
Por Devy · Categoría: AI Dev Tools — General
La suposición habitual sobre por qué un coding agent quema tokens es que pensar sale caro. La tesis de Tura es que pensar es la parte barata. Lo que te cuesta es la forma de la conversación: inspeccionar, recibir el resultado, parchear, recibirlo, compilar, recibirlo, testear, recibirlo. Cinco idas y vueltas, y cada una reenvía al modelo todo el contexto acumulado.
Tura es un coding agent escrito en Rust (AGPL-3.0-or-later) que ataca exactamente eso. En vez de exponerle al modelo decenas de tools chicos —leer archivo, escribir archivo, correr comando, aplicar patch— expone uno solo: command_run. El modelo arma un árbol de ejecución multi-paso y el runtime lo corre entero en un único turno de LLM.
Salió como Show HN esta mañana. La instalación es un comando de npm. Y, cosa rara en un proyecto de este tipo, publica tanto los artefactos de su benchmark como su propia lista de lo que esos artefactos no demuestran.
Cómo se ve un turno en lugar de cinco
Este es el ejemplo que usa el propio proyecto. Un agent convencional necesita cinco turnos: inspeccionar, parchear, compilar, testear, lint. Tura lo manda como una sola 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" }
]
}
}
Mira el campo step, porque ahí está todo el diseño. No es una lista de comandos, es un grafo de dependencias. Dos comandos que comparten step: 1 corren juntos —los dos rg son independientes, así que salen a la vez—. El step: 2 espera a que termine el 1 porque no puedes parchear lo que todavía no leíste. El build espera al patch. Test y clippy comparten step: 4 porque ninguno necesita al otro.
O sea que esto no es “agrupar unos comandos de shell”. Es el agent comprometiéndose de antemano con un plan cuyas dependencias ya resolvió, y volviendo al modelo solo cuando el plan terminó o algo se rompió.
Los números, y contra qué baseline salen
Acá hay que leer con cuidado, porque el titular del proyecto y el número que circula por la timeline son ambos ciertos y no son el mismo número.
La tabla completa, del evidence record publicado. DeepSWE v1.1, 20 tareas corridas tres veces cada una, o sea 60 runs por configuración — todo con GPT-5.6 SOL, julio de 2026:
| Configuración | Pass rate DeepSWE | Tokens observados |
|---|---|---|
| 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 |
Ahora la aritmética, que puedes hacer tú mismo a partir de esa tabla:
- Contra Codex CLI Medium, Balanced saca 16,7 puntos más con 31,1 % menos tokens. Ese es el par que el README pone en su propio titular.
- Contra Codex CLI High, Balanced saca 20 puntos más con 49,6 ** menos tokens, y Direct usa **83,5 menos.
Ninguna de las dos comparaciones es deshonesta. Pero fíjate en el problema de orden: Codex CLI High gasta 37 más tokens que Codex CLI Medium y puntúa *peor* (60,0 contra 63,3 %). Si eliges High como baseline te llevas la cifra de ahorro más grande comparando contra el rival más débil. El README eligió el par más conservador para su título, y eso vale la pena decirlo en voz alta.
Hay un tercer número dando vueltas: **83,1 menos turnos**. Ese sale del rewrite benchmark y cuenta turnos, no tokens. No lo mezcles con el 83,5 de tokens: otra métrica, otro benchmark.
El resultado de compactación, que me pareció más interesante que el titular
Bastante más abajo de los pass rates está la medición que yo reproduciría primero.
Todo agent choca contra la compactación de contexto en una tarea larga. La pregunta es qué pasa justo después. Lo típico es que el agent salga de la compactación medio ciego y gaste varias rondas releyendo archivos para reconstruir el estado que acaba de perder. Tura trata la compactación como una operación de CLI y preserva el estado de ejecución exacto en task_status.compact_context: ubicaciones de código, patches, tests, estado de la tarea, y no un resumen en prosa suelto.
En las sesiones publicadas, Tura volvió a hacer trabajo real (no inspección read-only) en promedio 2,6 rondas después de la compactación. La cifra de comparación para Codex es 5,4 rondas.
El proyecto es claro sobre la asimetría ahí, y nosotros también deberíamos serlo: el 2,6 de Tura sale de eventos compact_context explícitos en sus propios round contracts archivados. Codex no emite eventos equivalentes, así que su 5,4 está estimado a partir de los puntos donde el uso de input tokens cae bruscamente. Es un número inferido contra uno medido. Útil como dirección, no como comparación pareja.
Instalarlo
npm install tura-ai
tura
En Windows:
npm install -g tura-ai
tura
Desde el código fuente, si quieres leer el Rust:
git clone https://github.com/Tura-AI/tura.git
cd tura
./scripts/install.sh
tura
Tura no trae credenciales de provider. En el primer arranque configuras un provider de LLM y eliges un modelo antes de poder mandar nada. Ese paso importa más que de costumbre acá — mira la sección siguiente.
Entrypoints útiles una vez que está en tu PATH:
| Comando | Para qué sirve |
|---|---|
tura |
Terminal UI interactiva |
tura "prompt" |
TUI con un prompt inicial |
tura exec "prompt" |
Runner de prompts directo en el CLI de Rust |
tura run "prompt" |
Prompt vía gateway, con streaming e historial |
tura_gateway |
Gateway HTTP/SSE local, GUI web opcional |
tura_gui |
Workspace de escritorio |
El último tag es el v0.1.33, del 14 de julio: el Show HN es de hoy, pero el release tiene cerca de cuatro semanas. Esto es software 0.1.x y el roadmap lo dice.
Qué medir en realidad, ya que nadie lo midió con tu modelo
Acá está el hueco que decide si algo de lo anterior te aplica: todas las cifras publicadas se produjeron con GPT-5.6 SOL. El proyecto lista mediciones más amplias con Anthropic/Claude, Google/Gemini, providers OpenAI-compatible, providers locales, latencia de UI y cross-OS como ítems del roadmap y known evidence gaps. En sus propias palabras: los resultados publicados “do not establish equivalent quality or performance for every configured provider”.
No es un golpe al proyecto —publicar tus propios evidence gaps es más raro que publicar tu benchmark—, pero significa que si corres Claude Code o Codex sobre Claude o Gemini, el estado honesto del 49,6 % para tu setup es: desconocido.
El repo también dice explícitamente que la comparación “is not a clean A/B test”. Las configuraciones de Codex difieren en build y en reasoning effort, y la matriz de configuración no aísla el comportamiento de compact-context, el batching de comandos, las instrucciones de los operation manuals ni las de backward reasoning entre sí. Son cuatro mecanismos que viajan juntos y el benchmark mide su suma.
Así que el experimento reproducible es más chico que el benchmark y más útil para ti:
- Toma una tarea de tu propio repo con un loop real de inspeccionar → parchear → compilar → testear. Nada de juguetes.
- Córrela con tu agent actual y registra dos cosas: cantidad de turnos de LLM y tokens totales. Las dos están en el dashboard de tu provider.
- Corre la misma tarea bajo Tura con tu provider configurado, a un reasoning effort comparable.
- Compara turnos primero, tokens después. Si el mecanismo funciona, la cuenta de turnos baja antes que cualquier otra cosa.
Los turnos son la señal más limpia porque es lo que command_run toca directamente. Los totales de tokens se mueven por una docena de motivos más: distintas ventanas de contexto, distintos system prompts, distintos umbrales de compactación.
Y córrelo tres veces por configuración, como hace el benchmark. Las corridas de agents son ruidosas; un solo par de números no te dice nada.
Una nota sobre el nombre
No lo confundas con Turo, que cubrimos antes y que es una capa de proxy que instalas una vez para que tus agents existentes manden menos tokens. Tura hace el movimiento opuesto: reemplaza al agent en vez de ponerse adelante. Nombres parecidos, promesa parecida, lugares completamente distintos en tu stack.
Lo que yo me llevo
La afirmación interesante acá no es el porcentaje. Es el diagnóstico que hay detrás: que el costo dominante en un loop de agent es el overhead conversacional y no el razonamiento, y que la solución es dejar de pedirle al modelo que narre cada paso y empezar a pedirle un plan con las dependencias declaradas.
Esa idea es portable. Aunque nunca instales Tura, la forma de command_run es una pregunta razonable para hacerle al agent que estés corriendo hoy: ¿cuántos turnos tomó esa tarea, y cuántos de ellos existieron solo porque la interfaz de tools obligó a un ida y vuelta?
Los artefactos del benchmark son públicos, los round contracts están en el repo, y la aritmética de arriba se reproduce desde la tabla publicada. Eso es más de lo que te entrega la mayoría de los proyectos. Lo que falta es que alguien lo corra contra un modelo que no sea GPT-5.6 SOL — y esa parte la puedes hacer esta misma tarde.
¿Y tú? ¿Cuántos turnos toma tu agent en un loop normal de inspeccionar → parchear → testear, y cuántos de esos crees que son solo la interfaz de tools hablando?
Fuentes: