¿DeepSeek Reasonix es un coding agent barato o solo un demo bien armado?

¿Por qué cada vez que aparece un modelo nuevo con "bajo costo" terminamos descubriendo semanas después que el costo era bajo solo para el caso que mostraron en el demo? Llevamos varios ciclos así — R1, V3, ahora Reasonix — y la pregunta que nadie se hace en serio es: ¿bajo costo comparado con qué workload, con qué prompt size y con qué frecuencia de cache hit?

Mi tesis antes del primer H2: Reasonix puede ser una apuesta legítima para flujos de agentes con prompts repetitivos y largos, pero adoptarlo sin entender el modelo de caching es exactamente la trampa. No alcanza con repetir la noticia; hay que convertirla en una decisión técnica verificable antes de meterlo en un workflow real.

DeepSeek Reasonix como deepseek native coding agent: qué señala el anuncio

El claim central de Reasonix es que combina razonamiento extendido con una capa de caching de prefijo diseñada para flujos de coding agent. En un agente de código típico, una porción significativa del prompt es contexto fijo: instrucciones del sistema, definición de herramientas, fragmentos de código base. Si ese prefijo se cachea entre llamadas, el costo de tokens de entrada cae de forma notable en escenarios con alta frecuencia de invocación.

Eso no es hype puro. Es un problema real. Cuando usás Claude Code en sesiones largas, el contexto acumulado crece y cada tool call reprocesa tokens que ya habían sido procesados. El caching de prefijo de Claude existe exactamente por eso — la diferencia es que Reasonix lo plantea como arquitectura nativa del agente, no como feature opcional de la API.

Lo que el anuncio no explica con suficiente detalle: cuánto dura ese cache entre sesiones, qué tan sensible es a cambios en el prefijo y si el caching sobrevive a rotación de modelos o es local a una instancia. Esos detalles cambian completamente el análisis de costo.

Mi punto: el valor real no está en el número de parámetros ni en el benchmark de razonamiento. Está en si el modelo de caching aguanta los patrones de uso reales de un agente iterativo — donde el prefijo cambia cada vez que actualizás el contexto del proyecto.

Qué problema real señala (y cuál no resuelve)

Un agente de código nativo tiene que manejar tres tensiones al mismo tiempo:

1. Contexto largo: el agente necesita ver archivos, tests, errores previos y el estado actual del workspace.
2. Iteraciones frecuentes: tool calls en serie significan múltiples roundtrips al modelo en minutos.
3. Coherencia de razonamiento: el modelo tiene que mantener el hilo de qué decidió antes sin perderlo entre llamadas.

El caching de prefijo ataca el punto 2 directamente. Si el system prompt y la descripción de herramientas son estables, cachearlos significa que solo los mensajes nuevos del usuario y los resultados de tools generan tokens nuevos. En escenarios de agentic loop largo, eso puede representar una fracción relevante del costo total.

Lo que Reasonix no resuelve automáticamente: la calidad del razonamiento sobre código propietario o arquitecturas no vistas en entrenamiento, la latencia de la primera llamada (que sigue siendo completa), y el problema de coherencia cuando el agente toma decisiones en paralelo. Esos límites son del diseño, no de la implementación del caching.

Cuando leí el análisis de Needle distilled de Gemini tool calling — donde un modelo de 26M parámetros ejecutaba tool calling sin hype — me quedó claro que el tamaño del modelo importa menos que el diseño del contrato de herramientas. Reasonix no escapa a esa lógica.

Checklist de decisión: cuándo tiene sentido probarlo

Antes de integrarlo en cualquier stack, hay cinco preguntas técnicas concretas que conviene responderse:

La pregunta 4 es la que más gente saltea. Si la plataforma no te expone el cache hit rate, estás tomando decisiones de costo a ciegas. Con Ollama corriendo modelos locales el costo es distinto — pero la latencia de contexto largo también — y esa comparación conviene hacerla explícita antes de elegir uno u otro.

Dónde se equivoca la gente: la receta habitual y su costo oculto

El patrón más común cuando aparece un modelo nuevo con "bajo costo" es este: se mide el costo de una llamada aislada, se proyecta linealmente al mes y se declara ahorro. El problema es que los agentes no funcionan con llamadas aisladas.

En un agentic loop real, el costo puede crecer de formas que el benchmark simple no captura:

Amplificación por reintentos: si el modelo falla en una tool call y el agente reintenta, ese contexto acumulado se vuelve a enviar. Sin caching robusto entre roundtrips, el ahorro prometido se evapora. Escribí sobre ese mecanismo en detalle en Retry no es gratis — la lógica de amplificación aplica igual para LLM agents que para servicios HTTP.

Riesgo de invalidación de cache por prefijo dinámico: en general, cualquier sistema de caching de prefijo funciona sobre secuencias de tokens idénticas. Si un agente inyecta timestamps, IDs de sesión o estado dinámico en el system prompt, es razonable esperar que el cache se invalide en esas llamadas aunque el resto del texto sea idéntico — es el comportamiento documentado en el caching de prefijo de Anthropic, y no hay motivo técnico para asumir que Reasonix se comporte distinto. No tengo una medición propia de Reasonix específicamente para confirmar el porcentaje exacto de invalidación, así que lo trato como patrón esperable a verificar, no como dato cerrado. Es el tipo de bug que no aparece en el demo pero puede destruir el modelo de costo en producción si no lo chequeás.

Latencia de primera llamada: el caching de prefijo no ayuda en la primera llamada de una sesión nueva. Si el workload tiene muchas sesiones cortas en lugar de pocas sesiones largas, el beneficio se diluye considerablemente.

Mi postura acá es clara: no es que Reasonix sea un engaño — el problema real del costo en agentes existe y la arquitectura de caching es una respuesta legítima. Lo que no compro es la proyección de ahorro sin especificar el perfil de uso. El ahorro real depende de cuántas llamadas tienen cache hit, y eso solo se sabe midiendo.

Cómo armarlo como experimento reproducible con Ollama o la API directa

Si querés evaluar si Reasonix tiene sentido para un workflow específico, acá hay un experimento mínimo reproducible:

# Paso 1: instalá el modelo vía Ollama si está disponible
# (verificá que "deepseek-r1" o el tag de reasonix esté en ollama.com/library)
ollama pull deepseek-r1

# Paso 2: armá un script de benchmark de agentic loop
# El objetivo es medir tokens de entrada por llamada en una sesión de N turnos

# benchmark_agent_loop.py
# Experimento: ¿cuántos tokens de entrada ahorra el caching entre turnos?

import time

# Simular un agentic loop de 10 turnos con prefijo estático
SYSTEM_PROMPT = """
Sos un agente de código. Tenés acceso a las siguientes herramientas:
- read_file(path): lee el contenido de un archivo
- write_file(path, content): escribe contenido en un archivo
- run_tests(): ejecuta la suite de tests y devuelve el resultado
Respondé siempre con un tool call o con una respuesta final.
"""

# El prefijo estático es lo que querés que se cachee
# Medí los tokens de este bloque vs el total de la llamada
prefijo_estatico = SYSTEM_PROMPT + "\n" + "[descripción de herramientas completa]"

conversacion = []
for turno in range(10):
    # Agregá solo el mensaje nuevo del turno
    conversacion.append({"role": "user", "content": f"Turno {turno}: revisá el archivo main.py"})
    
    # Con caching real: solo el último mensaje debería generar tokens nuevos
    # Sin caching: todo el historial se reprocesa
    # → Medí: input_tokens en la respuesta de la API
    # → Si input_tokens ≈ len(mensaje_nuevo) después del turno 1, el cache funciona
    # → Si input_tokens ≈ len(historial_completo), el cache no aplica
    
    print(f"Turno {turno}: revisando input_tokens en la respuesta...")
    time.sleep(1)  # placeholder para la llamada real a la API

La métrica que importa es el delta de input_tokens entre el turno 1 y el turno 5. Si el cache funciona, ese número debería estabilizarse cerca del tamaño del mensaje nuevo, no crecer linealmente con el historial.

Ese mismo experimento con Claude Code existe de forma implícita cada vez que activás el modo de caching de prefijo en la API de Anthropic — la diferencia está en que ahí el contrato es explícito y auditable.

Dónde están los límites: qué no podés concluir sin datos propios

Acá es donde la mayoría de los análisis se apuran y yo prefiero frenar:

• No podés asumir que el caching sobrevive entre sesiones distintas sin leer la documentación de la implementación específica. "Caching nativo" puede significar in-memory dentro de una request, o puede significar un KV store entre llamadas. Son cosas completamente diferentes.

• No podés proyectar ahorro de costo sin conocer el profile de uso propio: cuántas sesiones, cuántos turnos por sesión, qué porcentaje del prompt es prefijo estático.

• No podés comparar latencia con Ollama local sin medir en el hardware donde vas a correr. Los números de latencia de Reasonix asumen infraestructura de DeepSeek, no una GPU consumer.

• No podés asumir que razona igual que R1 en tareas de arquitectura complejas solo porque comparte el nombre. El fine-tuning para coding puede mejorar algunas tareas y degradar otras.

Ese último punto me importa especialmente cuando pienso en usarlo para decisiones que tocan patrones de estado en React o N+1 en Prisma — situaciones donde el contexto del proyecto importa más que el razonamiento general.

FAQ sobre DeepSeek Reasonix como coding agent nativo

¿Reasonix reemplaza a Claude Code para agentes de código? No directamente. Claude Code tiene integración nativa con el filesystem, gestión de contexto de sesión y un contrato de herramientas probado. Reasonix es interesante como alternativa de costo para flujos específicos, pero el ecosistema de tooling alrededor todavía es menos maduro. Para decisiones críticas de arquitectura, no lo usaría como única fuente.

¿El caching de prefijo funciona igual que en la API de Anthropic? La idea es similar — cachear tokens de prefijo para no reprocesarlos — pero la implementación varía. En Anthropic el caching de prefijo es explícito: lo activás con un parámetro y el cache hit se refleja en el campo cache_read_input_tokens de la respuesta. En Reasonix, si el caching es "nativo", conviene verificar qué expone la API antes de asumir que está funcionando.

¿Tiene sentido correrlo con Ollama localmente? Depende del hardware disponible. Si tenés una GPU con suficiente VRAM para el modelo completo sin cuantización agresiva, Ollama elimina el costo por token. Pero el caching de prefijo en Ollama depende de la implementación del servidor llama.cpp/ollama — no es automático de la misma forma que en una API con KV cache gestionado.

¿Por qué importa si el prefijo es estático o dinámico? Porque el caching de prefijo funciona sobre secuencias de tokens idénticas. Si el system prompt incluye un timestamp, un ID de usuario o cualquier valor que cambia entre llamadas, es razonable esperar que el hash del prefijo cambie y el cache se invalide en esas llamadas — aunque el comportamiento exacto depende de cada implementación y conviene confirmarlo con la métrica de cache hit antes de asumir nada. Es el error más común al implementar agentes con caching, y el que menos se chequea antes de salir a producción.

¿Qué métrica debo mirar primero para validar el ahorro? input_tokens por llamada en un loop de 5-10 turnos. Si el modelo cachea correctamente, ese número debería mantenerse bajo y estable después del primer turno. Si crece linealmente, el cache no está operando o el prefijo está cambiando.

¿Reasonix tiene ventaja sobre otros modelos de razonamiento para código? En razonamiento puro sobre código estándar, compite bien según los benchmarks publicados por DeepSeek. Lo diferencial que señala el anuncio es la integración de caching como parte del diseño del agente, no solo como feature de API. Si eso se traduce en ahorro real depende del workload — y solo un experimento propio puede confirmarlo.

Mi postura: qué haría concretamente esta semana

Reasonix señala un problema real — el costo de contexto en agentes iterativos — con una solución arquitectónica que tiene sentido teórico. Lo que no compro es adoptarlo sin verificar que el caching funciona con el propio patrón de uso.

Mi recomendación práctica: antes de integrarlo en cualquier workflow, corré el experimento del benchmark de agentic loop que describí arriba. Medí input_tokens por turno en una sesión de 10 llamadas con un prefijo fijo. Si el número se estabiliza cerca del tamaño del mensaje nuevo, el caching opera. Si crece, hay algo en el prefijo o en la configuración que lo invalida — y ahí es donde vale la pena revisar si estás metiendo timestamps o IDs dinámicos donde no corresponde.

Si ya usás Claude Code para sesiones largas y querés comparar costos, el experimento es más útil todavía: corré el mismo loop en ambas APIs, mirá los cache_read_input_tokens y decidí con datos propios, no con la promesa del demo.

Lo que no haría: reemplazar un flujo que funciona basándome solo en el claim de "bajo costo" sin conocer el cache hit rate real en mi workload. Ese número es el único que importa, y por ahora cada equipo tiene que medirlo por cuenta propia.

El próximo paso concreto es tuyo: armá el script, medí dos sesiones y fijate si los números cierran. Si cierran, tenés una decisión técnica. Si no cierran, sabés exactamente por qué.