O gasto não está no raciocínio, está na ida e volta: Tura e os 80% de sucesso com metade dos tokens
Por Devy · Categoria: AI Dev Tools — General
A suposição habitual sobre por que um coding agent queima tokens é que pensar é caro. A tese de Tura é que pensar é a parte barata. O que custa é a forma da conversa: inspecionar, receber o resultado, fazer patch, receber, compilar, receber, testar, receber. Cinco idas e voltas, e cada uma reenvia ao modelo todo o contexto acumulado.
Tura é um coding agent escrito em Rust (AGPL-3.0-or-later) que ataca exatamente isso. Em vez de expor ao modelo dezenas de ferramentas pequenas —ler arquivo, escrever arquivo, rodar comando, aplicar patch— expõe uma só: command_run. O modelo monta uma árvore de execução multi-passo e o runtime a executa inteira em um único turno de LLM.
Saiu como Show HN esta manhã. A instalação é um comando npm. E, coisa rara em um projeto desse tipo, publica tanto os artefatos do seu benchmark quanto sua própria lista do que esses artefatos não demonstram.
Como se vê um turno em lugar de cinco
Este é o exemplo que o próprio projeto usa. Um agent convencional precisa de cinco turnos: inspecionar, fazer patch, compilar, testar, lint. Tura o envia como uma só 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" }
]
}
}
Olha para o campo step, porque ali está todo o design. Não é uma lista de comandos, é um grafo de dependências. Dois comandos que compartilham step: 1 rodam juntos —os dois rg são independentes, então saem ao mesmo tempo—. O step: 2 espera terminar o 1 porque não dá para fazer patch no que você ainda não leu. A compilação espera pelo patch. Test e clippy compartilham step: 4 porque nenhum um precisa do outro.
Ou seja, isso não é “agrupar uns comandos de shell”. É o agent se comprometendo de antemão com um plano cujas dependências ele já resolveu, e voltando ao modelo só quando o plano termina ou algo quebra.
Os números, e contra qual baseline saem
Aqui tem que ler com cuidado, porque o título do projeto e o número que circula pela timeline são ambos corretos e não são o mesmo número.
A tabela completa, do evidence record publicado. DeepSWE v1.1, 20 tarefas rodadas três vezes cada uma, ou seja 60 execuções por configuração — tudo com GPT-5.6 SOL, julho de 2026:
| Configuração | Taxa de sucesso 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 |
Agora a aritmética, que você pode fazer você mesmo a partir dessa tabela:
- Contra Codex CLI Medium, Balanced tira 16,7 pontos a mais com 31,1 % menos tokens. Esse é o par que o README coloca no próprio título.
- Contra Codex CLI High, Balanced tira 20 pontos a mais com 49,6 ** menos tokens, e Direct usa **83,5 menos.
Nenhuma das duas comparações é desonesta. Mas veja o problema de ordem: Codex CLI High gasta 37 mais tokens que Codex CLI Medium e pontua *pior* (60,0 contra 63,3 %). Se você escolhe High como baseline você leva o número de economia mais grande comparando contra o rival mais fraco. O README escolheu o par mais conservador para seu título, e isso vale a pena dizer em voz alta.
Há um terceiro número circulando: **83,1 menos turnos**. Esse sai do benchmark de rewrite e conta turnos, não tokens. Não misture com o 83,5 de tokens: outra métrica, outro benchmark.
O resultado de compactação, que me pareceu mais interessante que o título
Bastante mais abaixo das taxas de sucesso está a medição que eu reproduziria primeiro.
Todo agent se choca contra a compactação de contexto em uma tarefa longa. A pergunta é o que acontece bem depois. O típico é que o agent saia da compactação meio cego e gaste várias rodadas relendo arquivos para reconstruir o estado que acabou de perder. Tura trata a compactação como uma operação de CLI e preserva o estado de execução exato em task_status.compact_context: localizações de código, patches, testes, estado da tarefa, e não um resumo em prosa solto.
Nas sessões publicadas, Tura voltou a fazer trabalho real (não inspeção somente leitura) em média 2,6 rodadas depois da compactação. A cifra de comparação para Codex é 5,4 rodadas.
O projeto é claro sobre a assimetria aí, e nós também deveríamos ser: o 2,6 de Tura sai de eventos compact_context explícitos em seus próprios round contracts arquivados. Codex não emite eventos equivalentes, então seu 5,4 está estimado a partir dos pontos onde o uso de input tokens cai abruptamente. É um número inferido contra um medido. Útil como direção, não como comparação justa.
Instalá-lo
npm install tura-ai
tura
No Windows:
npm install -g tura-ai
tura
A partir do código-fonte, se quiser ler o Rust:
git clone https://github.com/Tura-AI/tura.git
cd tura
./scripts/install.sh
tura
Tura não traz credenciais de provider. No primeiro arranque você configura um provider de LLM e escolhe um modelo antes de poder mandar qualquer coisa. Esse passo importa mais que de costume aqui — veja a seção seguinte.
Entrypoints úteis uma vez que está no seu PATH:
| Comando | Para que serve |
|---|---|
tura |
Terminal UI interativa |
tura "prompt" |
TUI com um prompt inicial |
tura exec "prompt" |
Runner de prompts direto no CLI de Rust |
tura run "prompt" |
Prompt via gateway, com streaming e histórico |
tura_gateway |
Gateway HTTP/SSE local, GUI web opcional |
tura_gui |
Workspace de desktop |
A última tag é v0.1.33, de 14 de julho: o Show HN é de hoje, mas o release tem perto de quatro semanas. Isso é software 0.1.x e o roadmap diz isso.
O que medir na verdade, já que ninguém mediu com seu modelo
Aqui está o buraco que decide se algo do anterior se aplica a você: todas as cifras publicadas foram produzidas com GPT-5.6 SOL. O projeto lista medições mais amplas com Anthropic/Claude, Google/Gemini, providers compatíveis com OpenAI, providers locais, latência de UI e cross-OS como itens do roadmap e known evidence gaps. Em suas próprias palavras: os resultados publicados „do not establish equivalent quality or performance for every configured provider1. Pegue uma tarefa do seu próprio repo com um loop real de inspecionar → corrigir → compilar → testar. Nada de brinquedos.
2. Execute-a com seu agent atual e registre duas coisas: quantidade de turnos de LLM e tokens totais. As duas estão no dashboard do seu provedor.
3. Execute a mesma tarefa sob Tura com seu provedor configurado, em um nível de reasoning effort comparável.
4. Compare turnos primeiro, tokens depois. Se o mecanismo funciona, a contagem de turnos cai antes de qualquer outra coisa.
Os turnos são o sinal mais limpo porque é o que command_run toca diretamente. Os totais de tokens se movem por uma dúzia de motivos a mais: diferentes janelas de contexto, diferentes system prompts, diferentes limiares de compactação.
E execute-o três vezes por configuração, como o benchmark faz. Execuções de agents são barulhentas; um único par de números não te diz nada.
Uma nota sobre o nome
Não o confunda com Turo, que cobrimos antes e que é uma camada de proxy que você instala uma vez para que seus agents existentes enviem menos tokens. Tura faz o movimento oposto: substitui o agent em vez de se colocar na frente. Nomes parecidos, promessa parecida, lugares completamente distintos na sua stack.
O que eu absorvo
A afirmação interessante aqui não é o percentual. É o diagnóstico por trás: que o custo dominante em um loop de agent é o overhead conversacional e não o raciocínio, e que a solução é parar de pedir ao modelo que narre cada passo e começar a pedir um plano com as dependências declaradas.
Essa ideia é portável. Mesmo que nunca instale Tura, a forma de command_run é uma pergunta razoável para fazer ao agent que você está executando hoje: quantos turnos aquela tarefa levou, e quantos deles existiram apenas porque a interface de tools obrigou um vai e vem?
Os artefatos do benchmark são públicos, os round contracts estão no repo, e a aritmética acima se reproduz a partir da tabela publicada. Isso é mais do que a maioria dos projetos te entrega. O que falta é alguém executar contra um modelo que não seja GPT-5.6 SOL — e essa parte você pode fazer ainda hoje à tarde.
E você? Quantos turnos seu agent leva em um loop normal de inspecionar → corrigir → testar, e quantos desses você acha que são apenas a interface de tools conversando?
Fontes: