Reasonix: Un agente de programación al estilo Claude Code en DeepSeek

Si te gusta la forma de trabajar de Claude Code: un agente de programación que vive en tu terminal, lee archivos, ejecuta comandos y corrige sus propios errores; pero prefieres pagar apenas una fracción de centavo por tarea en lugar de suscribirte mensualmente, esta es la solución: Reasonix, un agente CLI al estilo de Claude Code que apunta a la API de DeepSeek.

¿Qué obtienes al final?

Primero, la versión actual:

$ reasonix --version
1.18.0

Luego, el flujo de trabajo: abres un terminal en un proyecto, escribes reasonix y describes lo que deseas: “añade una opción --dry-run a este script y actualiza el README”. El agente lee los archivos pertinentes, los edita, ejecuta el script para verificar su trabajo y te informa; es el mismo ciclo que conocen los usuarios de Claude Code. Las diferencias radican en la infraestructura:

• El cerebro es DeepSeek, con facturación por tokens. Dos niveles cubren todo: un modelo flash para ediciones cotidianas y tareas menores, y un modelo pro de razonamiento para refactorizaciones complejas y depuración. Mi conjunto de agentes siempre activos utiliza estos dos niveles y costaron $24.08 en un mes completo ($9.54 por el modelo flash y $14.54 por el pro); la misma carga de trabajo costaría entre $475 y $915 en las API principales.
• Puedes programarlo a tu gusto. Al no haber licencias por usuario, puedes dejarlo trabajando en tareas largas y repetitivas —refactorizaciones masivas, escritura de pruebas, revisión de documentación— sin preocuparte por el consumo de tokens.
• El estado se guarda en tu directorio personal. Reasonix crea una carpeta oculta (~/.reasonix/) con su archivo de configuración, además del historial y la memoria por proyecto; así recuerda el contexto de cada repositorio entre ejecuciones.

Paso 1: instalación

Se trata de un paquete global de npm:

npm install -g reasonix
reasonix --version

Eso es todo para la instalación. Si tienes Node instalado en una ruta no estándar, anota la ruta completa a npm; la necesitarás luego para el sistema de actualización del paso 4.

Paso 2: apuntarlo a DeepSeek

Crea una clave API en la plataforma de DeepSeek (pago por uso; mis agentes consumieron $2.23 en los primeros once días de julio). Luego define el proveedor en ~/.reasonix/config.toml:

# ~/.reasonix/config.toml — the shape, not a paste of mine
default_model = "deepseek-flash"

[[providers]]
name        = "deepseek"
base_url    = "https://api.deepseek.com"
models      = ["deepseek-v4-flash", "deepseek-v4-pro"]
api_key_env = "DEEPSEEK_API_KEY"    # NAME of the variable, not the key itself

Los nombres de los campos varían entre agentes CLI, pero todos reducen a lo mismo: URL base, credencial y ID(s) del modelo. Dos reglas básicas aplican a cualquier herramienta:

• chmod 600 todos los archivos que contengan la clave; nunca la pases por línea de comandos, ya que quedaría en el historial del shell y en la salida de ps. La indirección mediante api_key_env existe precisamente para separar el secreto de la configuración: el archivo de configuración es algo que podrías pegar en un chat para pedir ayuda, mientras que el archivo .env no debe compartirse.
• Define ambos niveles de modelo. El flash para tareas habituales y el pro para casos difíciles es toda la lógica de costos: la mayoría de las operaciones son baratas, y solo escalas al modelo más caro cuando este demuestra dificultades.

Paso 3: subagentes y habilidades

Los subagentes son trabajadores especializados que el agente principal genera —“busca en el código fuente todas las llamadas a esta función”— y, en un modelo de pago por tokens, también son la palanca para controlar costos: los subagentes pueden ejecutarse en el nivel flash mientras el agente principal razona usando el pro. Las habilidades son archivos de instrucciones que el agente carga bajo demanda; así, un procedimiento de despliegue o una convención para escribir pruebas se definen una sola vez en lugar de explicarse en cada sesión.

Las versiones actuales permiten definir ese enrutamiento explícitamente, en lugar de confiar en los valores por defecto; este bloque de configuración merece atención porque determina el costo:

[agent]
# planner_model  = "deepseek-pro"    # two-model collaboration: pro plans, flash executes
# subagent_model = "deepseek-pro"    # default tier for spawned workers
# subagent_models = { review = "deepseek-pro", security_review = "deepseek-pro" }
# recovery_model = "deepseek-pro"    # steps in when a turn fails

El mapa de habilidades en la tercera línea es el relevante. La mayoría de las tareas delegadas —buscar texto, renombrar archivos, escribir pruebas básicas— son operaciones para el modelo flash. En cambio, una revisión de código o un análisis de seguridad no lo son; en estos casos, un modelo barato suele generar respuestas plausibles pero erróneas. Asignar los pocos casos críticos al nivel pro garantiza buen juicio donde realmente importa, dejando todo lo demás en el modelo más económico; esto es mejor que asignar un único nivel a todos los subagentes.

Paso 4: mantenerlo actualizado automáticamente

Los agentes CLI evolucionan rápido, y uno desactualizado pierde mejoras importantes. Ahora existe un mecanismo integrado para esto, que es la respuesta inicial correcta:

reasonix upgrade

Con el canal de actualización seleccionado en la configuración:

[cli]
update_channel = "stable"   # stable | preview

Si prefieres que ocurra sin tu intervención, programa una tarea. La mía funciona sola y el CLI ya va por la v1.18.0 sin que yo haya tenido que intervenir. El siguiente script invoca directamente a npm; vale la pena leerlo aunque uses el mecanismo integrado, porque un simple npm update -g programado tiene dos modos de fallar que conviene prevenir:

#!/usr/bin/env bash
set -euo pipefail
LOG="$HOME/logs/update-reasonix.log"
NPM="$(command -v npm)"

# 1. Lock guard — two overlapping npm runs corrupt the install
exec 9>"${LOG%.log}.lock"
flock -n 9 || { echo "update already running"; exit 0; }

# 2. Log rotation — cron logs grow forever unless you trim them
[ -f "$LOG" ] && tail -n 5000 "$LOG" > "$LOG.tmp" && mv "$LOG.tmp" "$LOG"

echo "before: $("$NPM" list -g reasonix --depth=0 | grep reasonix)" >> "$LOG"
"$NPM" update -g reasonix >> "$LOG" 2>&1
echo "after:  $("$NPM" list -g reasonix --depth=0 | grep reasonix)" >> "$LOG"

Conéctalo a cron o a un temporizador de systemd; ambos funcionan. Registrar la versión antes y después es más importante de lo que parece: si el comportamiento del agente cambia de la noche a la mañana, el registro te indicará si fue por una actualización.

Uso en un proyecto real

Lo anterior es la configuración global. Lo que hace útil a un agente CLI es la capa por proyecto; Reasonix resuelve la configuración siguiendo un orden específico que conviene conocer:

flag  >  ./reasonix.toml  >  ~/.reasonix/config.toml  >  built-in defaults

Así, un archivo reasonix.toml incluido en la raíz de un repositorio se convierte en las instrucciones permanentes del proyecto, mientras que el archivo global guarda las credenciales y tus preferencias personales. Algunos campos son exclusivos para la configuración global —el canal de actualización, preferencias del CLI—; esto evita que un repositorio ajeno modifique cómo se actualiza tu instalación. Es un límite razonable y explica por qué es seguro aceptar un archivo por proyecto enviado por otra persona.

El estado de sesión y la memoria también son específicos por proyecto, bajo ~/.reasonix/projects/<project>/sessions/. Si ejecutas el agente desde un directorio de proyecto en lugar de desde tu carpeta personal, mantendrás la continuidad por repositorio: recordará lo que aprendió del código la última vez, en lugar de empezar desde cero. Funciona también si lo lanzas desde $HOME, pero obtendrás un montón de contexto indiferenciado, algo que conviene evitar si trabajas con varios repositorios.

Lo que yo incluiría en un archivo por proyecto, por orden de utilidad:

• Los comandos de compilación y pruebas. Es la línea más valiosa. Un agente que sabe cómo validar su propio trabajo deja de adivinar.
• El mapa de escalado —el bloque subagent_models mencionado antes, adaptado al proyecto. Un sitio con riesgos de seguridad requiere un ajuste distinto al de una página estática.
• Las restricciones que debe respetar. Reglas de despliegue, archivos prohibidos, “nunca ejecutar esto en producción”. Escríbelo una sola vez.
• Habilidades para procesos recurrentes —el manual de despliegue, la lista de verificación de lanzamientos—; así el procedimiento queda guardado en el repositorio y no solo en tu memoria.

Como ejemplos prácticos de proyectos adecuados, el chat autohospedado, la interfaz gráfica de respaldo y la reconstrucción de WordPress a estático siguen el mismo patrón: código definido, comandos reales de verificación y barreras antes de cualquier despliegue.

Bonus: úsalo en tu app de chat

Un agente terminal no tiene por qué quedarse en el terminal. Como Reasonix es simplemente un CLI sobre un PTY, puedes transmitirlo a una interfaz web con xterm.js y usarlo desde cualquier dispositivo de tu red. Mi app de chat autohospedada hace exactamente eso: Reasonix aparece como un “bot terminal” junto a los demás agentes de chat, con controles para iniciar, reiniciar o detenerlo. Todo el proceso se describe en DisPatch: un chat IA autohospedado.

Posibles problemas

• Los modelos de razonamiento parecen “detenerse” antes de responder. El nivel Pro transmite el proceso de pensamiento del modelo antes de enviar la respuesta; si el wrapper o gateway que rodea al agente tiene un tiempo de espera muy corto, los procesos de razonamiento largos se interrumpen a mitad de camino. Aumente ese tiempo de espera; no culpe al modelo.
• Nunca coloque la clave en argv. Úsela únicamente en un archivo de configuración (con permisos chmod 600) o en un archivo de entorno. Los parámetros de línea de comandos pueden quedar registrados en el historial y en las listas de procesos.
• Especifique la ruta de npm en el actualizador. El cron se ejecuta con un PATH mínimo; por eso, npm puede resolverse de forma distinta en un shell interactivo que en cron. Indique la ruta de forma explícita en el script.
• Bloquee el proceso de actualización. Sin usar flock, un registro de npm lento y un horario de ejecución demasiado frecuente pueden provocar dos instalaciones globales simultáneas y un CLI defectuoso.
• Controle el uso de tokens. El modelo de pago por token sigue siendo económico solo si “flash” es el modo predeterminado. Si todas las tareas se ejecutan en el nivel Pro “por si acaso”, estará recreando un sistema de suscripción; haga un seguimiento del gasto durante la primera semana.
• Las carpetas de sesión crecen sin control. El historial por proyecto es útil, pero si el agente genera muchos datos, estas carpetas se vuelven enormes; elimine periódicamente los datos de sesión almacenados en la carpeta oculta.
• Los esquemas de configuración cambian con las versiones. Esta herramienta incluye un marcador config_version precisamente porque su estructura varía entre versiones; por ejemplo, las credenciales ya no se guardan en config.toml, sino en api_key_env. Si tras una actualización el agente no puede autenticarse, verifique la estructura de configuración comparándola con la documentación actual antes de generar una nueva clave.
• Reanudar una sesión antigua no es gratis. Al reabrir una conversación después de que haya expirado el periodo de almacenamiento de prompts del proveedor, el contexto se envía de nuevo, lo que implica un coste total. Existe una opción para eliminar los resultados de herramientas obsoletos al reanudar sesiones; déjela activada. En muchos casos, iniciar una sesión nueva resulta más económico que recuperar una antigua.

Lectura recomendada: la guía general DeepSeek-everywhere wiring guide explica cómo configurar la CLI de Claude Code para que apunte al endpoint compatible con Anthropic de DeepSeek; es decir, el mismo concepto visto desde el otro lado.