dsh-baton entrega tarefas longas do Claude Code ao DeepSeek: $3,16 em vez de $14,18

Uma cena familiar: e quinta-feira, o limite semanal do agente de programacao esta quase esgotado e ainda restam duas sessoes de trabalho. O autor de uma publicacao no X descreve a situacao com a ironia de quem passa por isso regularmente. Em seguida, apresenta uma das possiveis saidas: o utilitario dsh-baton.

Que ferramenta e essa

A ideia e simples. Um modelo caro como Claude Code ou Codex nao deveria processar sozinho cada tarefa longa. Ele repassa a tarefa ao DeepSeek, que e mais barato e roda na maquina do usuario, e depois apenas verifica o resultado. E como um engenheiro senior que delega a implementacao rotineira a um profissional junior e depois revisa o trabalho.

Esse esquema combina bem com a forma como os limites sao consumidos. A maior parte dos tokens nao e gasta em decisoes complexas, mas em ciclos longos: escrever codigo, executar testes, corrigir e rodar tudo novamente. Verificar o resultado custa consideravelmente menos do que executar todo esse ciclo.

O que os numeros prometem

O README do projeto apresenta um exemplo: um pequeno aplicativo kanban. Desenvolve-lo inteiramente com o Opus custa $14,18. Com o dsh-baton usando o DeepSeek como executor, a conta ficou em $3,16. Isso representa uma economia de cerca de 78%, ou um custo aproximadamente 4,5 vezes menor. Nos dois casos, todos os testes passaram: 55 de 55.

O autor da publicacao aponta imediatamente a desvantagem: o tempo de execucao aumentou de 39 para 93 minutos. Isso e 2,4 vezes mais. Trata-se da troca classica de dinheiro por tempo, e ela e perfeitamente razoavel para muitas tarefas. Se o agente trabalha durante a noite ou em segundo plano, uma hora extra nao incomoda ninguem. Se voce esta diante da tela esperando o resultado, a vantagem diminui consideravelmente.

Como interpretar esses resultados

Vale lembrar que este e um unico exemplo retirado do README do proprio projeto, e nao um benchmark independente. Um aplicativo kanban com 55 testes e uma tarefa clara e nao particularmente complexa. Nao ha dados sobre como o esquema se comportara em uma grande base de codigo, com dependencias pouco obvias ou testes instaveis. A propria publicacao teve zero visualizacoes, portanto ainda nao houve discussao nem verificacao pela comunidade.

Tambem existem riscos ocultos. Testes verdes dizem apenas o que esta coberto pelos testes. Se o modelo revisor examinar somente o resultado final, erros que os testes nao detectam poderao passar despercebidos. Alem disso, toda delegacao envolve custos adicionais: transferencia de contexto, novas execucoes e possiveis erros do executor.

O que fazer na pratica

O passo mais sensato nao e migrar integralmente para esse esquema, mas testa-lo em suas proprias tarefas. Bons candidatos incluem:

• tarefas grandes, mas claramente descritas e com boa cobertura de testes;
• execucoes em segundo plano nas quais o tempo nao seja critico: migracoes, refatoracao baseada em modelos e geracao de testes;
• projetos nos quais o limite do modelo caro regularmente se esgota antes da hora.

Compare tres numeros na mesma tarefa: custo, tempo e quantidade de alteracoes necessarias apos a revisao. Se a economia continuar sendo de varias vezes e forem necessarias poucas alteracoes, o esquema podera ser adotado de forma mais ampla. Se o tempo aumentar alem do que voce esta disposto a tolerar, deixe as tarefas complexas para o modelo caro e delegue ao barato apenas o trabalho rotineiro e repetitivo.

O panorama geral revela a principal tendencia: o mercado de agentes de programacao esta deixando para tras o uso de um unico modelo para tudo e avancando para combinacoes em que um modelo caro planeja e revisa, enquanto um barato executa. O dsh-baton e um exemplo inicial e, por enquanto, pouco validado dessa abordagem, mas a logica em si e clara e vale um experimento.