dsh-baton delega las tareas largas de Claude Code a DeepSeek: $3,16 en lugar de $14,18

Una escena conocida: es jueves, el limite semanal del agente de programacion esta casi agotado y aun quedan dos sesiones de trabajo. El autor de una publicacion en X lo cuenta con la ironia de quien vive esta situacion con regularidad. Y enseguida muestra una posible salida: la utilidad dsh-baton.

Que tipo de herramienta es

La idea es sencilla. Un modelo caro como Claude Code o Codex no deberia procesar por si mismo cada tarea larga. La delega en DeepSeek, que es mas barato y se ejecuta en el equipo del usuario, y despues se limita a revisar el resultado. Es parecido a un ingeniero senior que encarga la implementacion rutinaria a un junior y luego revisa su trabajo.

Este esquema encaja bien con la forma en que se consumen los limites. La mayor parte de los tokens no se dedica a decisiones complejas, sino a ciclos largos: escribir codigo, ejecutar pruebas, corregir y volver a ejecutar. Revisar el resultado cuesta mucho menos que completar todo ese ciclo.

Que prometen las cifras

El README del proyecto ofrece un ejemplo: una pequena aplicacion kanban. Desarrollarla por completo con Opus cuesta $14,18. Mediante dsh-baton, con DeepSeek como ejecutor, la factura fue de $3,16. Eso supone un ahorro cercano al 78%, o un costo aproximadamente 4,5 veces menor. En ambos casos, el conjunto de pruebas se completo con exito: 55 de 55.

El autor de la publicacion senala de inmediato la contrapartida: el tiempo de ejecucion aumento de 39 a 93 minutos. Es 2,4 veces mas. Se trata del clasico intercambio de dinero por tiempo, y resulta perfectamente razonable para muchas tareas. Si el agente trabaja durante la noche o en segundo plano, una hora adicional no molesta a nadie. Si se espera el resultado frente a la pantalla, la ventaja se reduce considerablemente.

Como interpretar estos resultados

Conviene recordar que se trata de un solo ejemplo incluido en el README del propio proyecto, no de un benchmark independiente. Una aplicacion kanban con 55 pruebas es una tarea clara y no especialmente compleja. No hay datos sobre como se comportara el esquema en una base de codigo grande, con dependencias poco evidentes o pruebas inestables. La publicacion obtuvo cero visualizaciones, por lo que todavia no existe debate ni verificacion por parte de la comunidad.

Tambien hay riesgos ocultos. Las pruebas en verde solo dicen algo sobre lo que cubren. Si el modelo revisor examina unicamente el resultado final, pueden pasar inadvertidos errores que las pruebas no detecten. Ademas, toda delegacion tiene costos indirectos: transferencia de contexto, nuevas ejecuciones y posibles errores del ejecutor.

Que hacer en la practica

El paso mas sensato no es adoptar el esquema por completo, sino probarlo con tareas propias. Estos son buenos candidatos:

• tareas grandes pero claramente descritas y con una buena cobertura de pruebas;
• ejecuciones en segundo plano donde el tiempo no sea critico: migraciones, refactorizacion basada en plantillas y generacion de pruebas;
• proyectos en los que el limite del modelo caro se agote habitualmente antes de tiempo.

Compare tres cifras para una misma tarea: costo, tiempo y numero de cambios necesarios despues de la revision. Si el ahorro sigue siendo de varias veces y hacen falta pocos cambios, el esquema puede consolidarse. Si el tiempo crece mas de lo que esta dispuesto a tolerar, deje las tareas complejas al modelo caro y delegue en el barato solo el trabajo rutinario y repetitivo.

El panorama general deja clara la tendencia principal: el mercado de los agentes de programacion esta pasando de usar un solo modelo para todo a combinar modelos, con uno caro que planifica y revisa y otro barato que ejecuta. dsh-baton es un ejemplo temprano y, por ahora, poco validado de este enfoque, pero la logica es clara y merece un experimento.