Reasonix: un agente de codificación al estilo Claude Code sobre DeepSeek

Categoría
IA y LLM Local
Publicado
11 julio 2026
Actualizado
1 agosto 2026
Por
Jacob Lloyd — escrito con ayuda de IA, después del proyecto
Tiempo de lectura
10 min de lectura

En palabras simples: Reasonix es un programa que corres en una terminal y que actúa como un asistente de codificación con IA: le dices en lenguaje sencillo qué quieres y él lee, escribe y prueba código por ti. En vez de una suscripción mensual, habla con DeepSeek, un servicio de IA de pago por uso muy barato, así que la ayuda real para programar cuesta centavos. Este artículo muestra cómo instalarlo, conectar tu clave, y mantenerlo actualizado automáticamente.

Si te gusta la forma de trabajar de Claude Code — un agente de codificación que vive en tu terminal, lee archivos, ejecuta comandos, corrige sus propios errores — pero prefieres pagar fracciones de centavo por tarea en vez de una suscripción mensual, esta es la receta: Reasonix, un agente CLI al estilo Claude Code, apuntado a la API de DeepSeek.

tl;dr

  • Qué es: Reasonix, un CLI de codificación agéntico cortado con el mismo molde que Claude Code — subagentes, skills, memoria por proyecto — configurado para usar modelos de DeepSeek en vez de un plan de pago.
  • Qué cuesta: pago por token, sin suscripción. Para dar una idea: un mes completo de mis agentes siempre activos con estos mismos niveles de DeepSeek salió en $24.08.
  • Qué necesitas: Node.js + npm, una clave de API de DeepSeek, diez minutos.
  • Qué obtienes: un agente de codificación de terminal, una configuración que sobrevive a las actualizaciones, y un actualizador programado para que se mantenga al día sin que tengas que pensar en ello.

Lo que obtienes

Abres una terminal en un proyecto, escribes reasonix, y describes lo que quieres: «añade una opción --dry-run a este script y actualiza el README». El agente lee los archivos relevantes, los edita, ejecuta el script para comprobar su propio trabajo, y reporta — el mismo ciclo que ya conocen los usuarios de Claude Code. Las diferencias están en la fontanería:

  • El cerebro es DeepSeek, facturado por token. Dos niveles cubren todo: un modelo flash para ediciones del día a día y trabajo de pegamento, y un modelo de razonamiento pro para refactors complicados y depuración. Mi stack de agentes siempre activos corre sobre estos mismos dos niveles y costó $24.08 en un mes completo ($9.54 flash + $14.54 pro) — la misma carga de trabajo sale a un precio de entre $475 y $915 en las APIs insignia.
  • El horario es cosa tuya. Como no hay licencia por puesto, puedes dejarlo trabajando en tareas largas y tediosas — refactors por lotes, escritura de tests, pasadas de documentación — sin vigilar un medidor de uso.
  • El estado vive en tu directorio home. Reasonix guarda una carpeta oculta (~/.reasonix/) con su archivo de configuración más el historial de sesión y la memoria por proyecto, así que recuerda el contexto de cada repositorio entre ejecuciones.

Paso 1: instalar

Es un paquete global de npm:

npm install -g reasonix
reasonix --version

Eso es toda la instalación. Si tienes Node bajo un prefijo no estándar, apunta la ruta completa a npm — la vas a necesitar de nuevo para el actualizador del paso 4.

Paso 2: apúntalo a DeepSeek

Crea una clave de API en el sitio de la plataforma de DeepSeek (pago por uso; los primeros once días de julio de todo mi stack de agentes costaron $2.23). Después describe el proveedor en ~/.reasonix/config.toml:

# ~/.reasonix/config.toml — la forma, no un pegado literal del mío
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"    # NOMBRE de la variable, no la clave en sí

Actualizado para v1.18 — la clave ya no va dentro de config.toml. Nombras una variable de entorno con api_key_env, y el valor vive en el propio ~/.reasonix/.env de Reasonix. Si estás siguiendo un tutorial más viejo que muestra un campo api_key en línea, esa es la parte que cambió. Todo lo demás aquí sigue siendo válido.

Los nombres de las claves varían entre CLIs de agentes, pero todas se reducen al mismo trío: URL base, credencial, id(s) de modelo. Dos reglas de higiene sin importar la herramienta:

  • chmod 600 a cualquier cosa que contenga la clave, y nunca la pases en una línea de comandos — termina en el historial de la shell y en la salida de ps. La indirección de api_key_env existe precisamente para que el secreto y la configuración se puedan tratar de forma distinta: el archivo de configuración es algo que podrías pegar en un chat para pedir ayuda, el .env no.
  • Declara ambos niveles. «Flash por defecto, pro para lo difícil» es toda la historia del costo: la mayoría de los turnos son baratos, y solo escalas cuando el modelo está visiblemente atascado.

Paso 3: subagentes y skills

Los subagentes son trabajadores de alcance acotado que el agente principal lanza — «busca en todo el código cada llamador de esta función» — y con facturación por token también son la palanca de costo, porque los trabajadores pueden correr en el nivel flash mientras el orquestador piensa en pro. Las skills son archivos de instrucciones que el agente carga bajo demanda, así que un procedimiento de despliegue o una convención para escribir tests se escribe una sola vez en vez de volver a explicarse en cada sesión.

Las versiones actuales te dejan fijar ese enrutamiento de forma explícita en vez de confiar en que los valores por defecto sean sensatos, y este es el bloque de configuración que vale la pena entender, porque es la factura:

[agent]
# planner_model  = "deepseek-pro"    # colaboración de dos modelos: pro planea, flash ejecuta
# subagent_model = "deepseek-pro"    # nivel por defecto para los trabajadores generados
# subagent_models = { review = "deepseek-pro", security_review = "deepseek-pro" }
# recovery_model = "deepseek-pro"    # entra cuando un turno falla

El mapa por skill de la tercera línea es el útil. La mayoría del trabajo delegado — hacer un grep de esto, renombrar aquello, escribir el test obvio — es trabajo de flash. Una revisión de código o una pasada de seguridad no lo es; esas son exactamente las tareas donde un modelo barato produce una salida confiada, plausible, y equivocada. Nombrar las pocas skills que merecen el nivel caro te da buen criterio donde importa y deja todo lo demás barato, lo cual es mejor trato que elegir un solo nivel para todos los subagentes.

Paso 4: mantenlo actualizado con un horario

Los CLI de agentes avanzan rápido, y uno desactualizado se pierde correcciones de herramientas. Ahora hay algo integrado para esto, que es la primera respuesta correcta:

reasonix upgrade

con el canal elegido en la configuración:

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

Si prefieres que pase sin que tengas que pensarlo, prográmalo. El mío corre sin supervisión y el CLI está actualmente en la v1.18.0 sin que yo lo haya pensado. El script de abajo envuelve npm directamente, y vale la pena leerlo incluso si usas lo integrado, porque un npm update -g ingenuo en un horario tiene dos modos de fallo que vale la pena cubrir:

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

# 1. Protección de bloqueo — dos ejecuciones de npm solapadas corrompen la instalación
exec 9>"${LOG%.log}.lock"
flock -n 9 || { echo "update already running"; exit 0; }

# 2. Rotación de logs — los logs de cron crecen para siempre si no los recortas
[ -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 timer de systemd — cualquiera de los dos funciona. Registrar la versión antes y después importa más de lo que parece: cuando el comportamiento del agente cambia de un día para otro, el log te dice si fue una actualización.

Usando Reasonix en un proyecto real

Todo lo anterior es configuración global. Lo que hace que un CLI de agentes sea realmente útil es la capa por proyecto, y Reasonix resuelve la configuración en un orden específico que vale la pena conocer:

flag  >  ./reasonix.toml  >  ~/.reasonix/config.toml  >  valores por defecto integrados

Así que un reasonix.toml incluido en la raíz de un repositorio se convierte en las instrucciones permanentes de ese proyecto, mientras que tu archivo global guarda la credencial y tus preferencias personales. Algunos campos son deliberadamente solo-globales — el canal de actualización, las preferencias del CLI — para que un repositorio que clonaste no pueda cambiar en silencio cómo se actualiza tu propia instalación. Ese es un límite sensato, y es la razón por la que es seguro aceptar un archivo por proyecto de alguien más.

El estado de sesión y la memoria también están acotados por proyecto, bajo ~/.reasonix/projects/<proyecto>/sessions/. Lánzalo desde un directorio de proyecto en vez de tu carpeta home y obtienes continuidad por repositorio — recuerda lo que aprendió sobre ese código la última vez en vez de arrancar en frío. Lanzarlo desde $HOME funciona, pero obtienes un solo montón indiferenciado de contexto, lo cual vale la pena evitar si trabajas en varios repositorios.

Lo que yo pondría en un archivo de proyecto, en orden aproximado de beneficio:

  • Los comandos de compilación y prueba. La línea de mayor valor, por sí sola. Un agente que sabe cómo verificar su propio trabajo deja de adivinar.
  • El mapa de escalación — el bloque subagent_models de arriba, ajustado por repositorio. Un proyecto con superficie de seguridad quiere un valor por defecto distinto al de un sitio estático.
  • Las cosas que no debe hacer. Puertas de despliegue, archivos que nunca debe tocar, «nunca corras esto contra producción». Escríbelo una sola vez.
  • Skills para cualquier cosa procedimental — el runbook de despliegue, la lista de verificación de release — para que el procedimiento viva en el repositorio en vez de en tu memoria.

Para ejemplos concretos del tipo de proyecto al que esto le viene bien, la app de chat autoalojada, la GUI de copias de seguridad, y la reconstrucción de WordPress a estático tienen todas la misma forma: un código base definido, un comando de verificación real, y una puerta antes de que nada se publique.

Extra: ponlo en tu app de chat

Un agente de terminal no tiene por qué quedarse en la terminal. Como Reasonix es solo 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 autoalojada hace justo eso — Reasonix aparece como un «bot de terminal» junto a los agentes de chat normales, con controles de iniciar/reiniciar/detener. Toda la configuración está escrita en DisPatch: un chat de IA autoalojado.

Trampas comunes

  • Los modelos de razonamiento parecen atascados antes de responder. El nivel pro transmite su pensamiento antes de la respuesta; si un wrapper o gateway alrededor del agente tiene un timeout de inactividad corto, los pensamientos largos se matan a mitad de camino. Sube el timeout, no le eches la culpa al modelo.
  • Nunca pongas la clave en el argv. Solo archivo de configuración (chmod 600) o archivo de entorno. Los flags de línea de comandos se filtran por el historial y los listados de procesos.
  • Fija la ruta de npm en el actualizador. Cron corre con un PATH mínimo; npm puede resolverse distinto en una shell interactiva que en cron. Fíjala a mano o resuélvela explícitamente en el script.
  • Bloquea tu tarea de actualización. Sin flock, un registro de npm lento más un horario demasiado entusiasta eventualmente te da dos instalaciones globales concurrentes y un CLI roto.
  • Vigila el hábito de escalar. El pago por token solo se mantiene barato si flash es el nivel por defecto. Si cada tarea corre en pro «por si acaso», has reinventado la suscripción — registra el gasto durante la primera semana.
  • Las carpetas de sesión crecen. El historial por proyecto es genial hasta que un agente hablador acumula meses de él; poda de vez en cuando los datos de sesión de la carpeta oculta.
  • Los esquemas de configuración cambian debajo de ti. Esta herramienta lleva un marcador config_version precisamente porque la forma cambia entre versiones — la credencial saliendo de config.toml y pasando a api_key_env es uno de esos cambios. Si el agente de repente no puede autenticarse después de una actualización, revisa la forma de la configuración contra la documentación actual antes de regenerar tu clave.
  • Reanudar una sesión vieja no sale gratis. Reabrir una conversación después de que expiró la ventana de caché de prompts del proveedor significa que el contexto se reenvía a precio completo. Hay un ajuste para podar la salida de herramientas obsoleta en una reanudación en frío; déjalo activado. Una sesión nueva suele salir más barata que resucitar una vieja.

Lectura relacionada: la guía más amplia de DeepSeek en todas partes cubre cómo apuntar el CLI real de Claude Code al endpoint de DeepSeek compatible con Anthropic — la misma idea desde la otra dirección.


← Más de IA y LLM Local