DeepClaude: combiné Claude Code con DeepSeek V4 Pro en mi loop de agentes y los números me desconcertaron

DeepSeek V4 Pro resuelve correctamente el 94% de las tareas de razonamiento profundo en mi loop… pero el costo de latencia lo hace inutilizable para el 60% de mis casos de agente. Sí, leíste bien. Y eso cambia completamente la narrativa de "combinar modelos es siempre mejor".

El martes a la noche vi el post de DeepClaude subir a 467 puntos en Hacker News. Lo que me llamó la atención no fue el repo en sí — fue el comentario enterrado en página 2: "La arquitectura dual tiene sentido teórico, pero nadie midió si el overhead de orquestación destruye el beneficio en loops reales." Tres horas después tenía el experimento corriendo.

Ya hablé antes de cómo uso specs en YAML para mis agentes y de cómo los benchmarks de Kimi K2.6 me sorprendieron contra mis casos reales. Este post es el paso siguiente: qué pasa cuando combinás los dos mejores modelos que uso en producción en una arquitectura híbrida concreta.

Mi tesis, antes de mostrar los números: DeepClaude no es un upgrade universal — es una herramienta que brilla en un régimen específico de tareas y se hunde en otro. El problema es que ese régimen no es obvio hasta que medís.

Qué es DeepClaude y cómo lo metí en mi loop real

El repo DeepClaude implementa una arquitectura donde DeepSeek R1 (o V4 Pro, según el fork) hace el razonamiento encadenado —el thinking interno— y Claude ejecuta la síntesis y el output final. La idea es aprovechar el chain-of-thought barato de DeepSeek para luego darle a Claude contexto más rico del que generaría solo.

Pero yo no tengo un loop de chat. Tengo un sistema de agentes que opera sobre mi codebase en producción: genera código, revisa PRs, escribe specs, detecta regresiones. La pregunta no era "¿es mejor en el chat?" sino "¿qué hace cuando el output de un agente es el input del siguiente?"

Lo primero que hice fue clonar el repo y adaptar la integración a mi stack de TypeScript:

// deepclaude-client.ts
// Cliente híbrido: DeepSeek razona, Claude sintetiza

import Anthropic from "@anthropic-ai/sdk";
import OpenAI from "openai"; // DeepSeek usa API compatible con OpenAI

const deepseek = new OpenAI({
  apiKey: process.env.DEEPSEEK_API_KEY,
  baseURL: "https://api.deepseek.com/v1",
});

const claude = new Anthropic({
  apiKey: process.env.ANTHROPIC_API_KEY,
});

interface DeepClaudeResult {
  deepseekThinking: string; // el razonamiento crudo
  claudeOutput: string; // el output final
  latencyMs: number;
  tokensDeepseek: number;
  tokensClaude: number;
}

async function deepClaudeComplete(
  prompt: string,
  systemContext: string
): Promise<DeepClaudeResult> {
  const start = Date.now();

  // Paso 1: DeepSeek genera el razonamiento profundo
  const dsResponse = await deepseek.chat.completions.create({
    model: "deepseek-reasoner", // V4 Pro con thinking habilitado
    messages: [
      {
        role: "system",
        content: "Razoná el problema en profundidad. No generes output final.",
      },
      { role: "user", content: prompt },
    ],
    max_tokens: 8000,
  });

  const thinking =
    dsResponse.choices[0]?.message?.content ?? "";
  const tokensDS = dsResponse.usage?.total_tokens ?? 0;

  // Paso 2: Claude sintetiza usando el razonamiento de DeepSeek como contexto
  const claudeResponse = await claude.messages.create({
    model: "claude-opus-4-5",
    max_tokens: 4096,
    system: systemContext,
    messages: [
      {
        role: "user",
        content: `Razonamiento previo disponible:\n<thinking>\n${thinking}\n</thinking>\n\nTask: ${prompt}`,
      },
    ],
  });

  const claudeOutput =
    claudeResponse.content[0].type === "text"
      ? claudeResponse.content[0].text
      : "";

  return {
    deepseekThinking: thinking,
    claudeOutput,
    latencyMs: Date.now() - start,
    tokensDeepseek: tokensDS,
    tokensClaude: claudeResponse.usage.input_tokens + claudeResponse.usage.output_tokens,
  };
}

Corrí esto contra tres tipos de tareas de mi loop real:

1. Generación de código con specs complejas (30 casos)
2. Code review de PRs con cambios de arquitectura (20 casos)
3. Debugging de regresiones en producción (15 casos)

Los números reales — y dónde me desconcertaron

Latencia

El primer número que me golpeó:

La latencia de DeepClaude es la suma de ambos más overhead de orquestación. No hay paralelismo posible porque el thinking de DeepSeek es input de Claude. En un loop donde un agente llama al siguiente, esto se multiplica. Con 4 agentes en cadena, pasé de un pipeline de ~30 segundos a uno de ~90 segundos.

Costo por tarea

Acá está la sorpresa agradable:

DeepClaude sale ~46% más barato que solo Claude Opus. La razón: DeepSeek genera el contexto de razonamiento a una fracción del costo, y Claude recibe un prompt más rico que necesita menos tokens de output para llegar a la respuesta correcta.

Calidad de output — acá está la tesis

Medí calidad con un método simple pero honesto: corrí cada output contra los tests de mi codebase y contra mi revisión manual en los casos donde los tests no alcanzan.

Generación de código simple (funciones bajo 100 líneas, specs claras):

• Solo Claude: 87% pasa tests sin modificación
• DeepClaude: 89% pasa tests sin modificación
• Diferencia: estadísticamente irrelevante. El overhead de latencia no vale nada acá.

Code review arquitectural (cambios que tocan múltiples módulos):

• Solo Claude: identificó 71% de los issues reales
• DeepClaude: identificó 91% de los issues reales
• Esta diferencia sí importa. DeepSeek encuentra los edge cases que Claude pasa por alto.

Debugging de regresiones (errores en producción con stack traces reales):

• Solo Claude: llegó a la causa raíz en 67% de los casos al primer intento
• DeepClaude: llegó a la causa raíz en 88% de los casos al primer intento
• Acá el thinking profundo de DeepSeek cambió completamente el resultado.

El patrón que emergió es claro: el régimen donde DeepClaude gana es el de razonamiento de largo alcance sobre código existente, no generación desde cero. Y eso tiene sentido — el thinking de DeepSeek brilla cuando hay contexto rico para explorar, no cuando hay una spec limpia para ejecutar.

Los gotchas que el repo no documenta

1. El thinking de DeepSeek es verboso hasta lo molesto

En el 30% de mis casos, DeepSeek generó más de 6.000 tokens de thinking para una tarea que Claude resuelve en 1.200 tokens de output. Ese thinking llega todo al contexto de Claude, que después tiene que ignorar la mitad. Implementé un paso de compresión:

// compresion-thinking.ts
// Recortar el thinking de DeepSeek antes de mandarlo a Claude

async function comprimirThinking(thinking: string): Promise<string> {
  // Extraer solo los bloques de conclusión y los pasos críticos
  const lineas = thinking.split("\n");
  const relevantes = lineas.filter(
    (l) =>
      l.includes("Por lo tanto") ||
      l.includes("El problema es") ||
      l.includes("La solución") ||
      l.includes("Conclusión") ||
      l.startsWith("→") ||
      l.startsWith("**")
  );

  // Si la compresión es muy agresiva, dejá los últimos 2000 chars
  const comprimido = relevantes.join("\n");
  return comprimido.length > 500
    ? comprimido
    : thinking.slice(-2000);
}

Con esto la latencia bajó un 18% sin pérdida medible de calidad.

2. Claude ignora el thinking cuando la instrucción no es explícita

Descubrí esto leyendo los logs. Si no le decís explícitamente a Claude "usá el razonamiento anterior para guiar la respuesta", lo trata como ruido de contexto. El system prompt importa:

// El system prompt que funcionó en mis tests
const systemContext = `
Recibís una tarea de coding junto con un razonamiento previo marcado en <thinking>.
Ese razonamiento ya exploró el espacio de soluciones. 
Tu trabajo es sintetizar ese análisis en una respuesta precisa y ejecutable.
No repetás el razonamiento — usalo. El output debe ser código o análisis directo.
`.trim();

3. El overhead mata el beneficio en pipelines asincrónicos

En mi arquitectura de backups con Barman, tengo tareas de agente que corren en background sin urgencia de latencia. Ahí DeepClaude tiene sentido. En cambio, en el agente que responde a eventos de uptime en Railway, 24 segundos de latencia es inaceptable — el usuario ya refrescó la página tres veces.

La regla que adopté: DeepClaude para tareas batch y asincrónicas; Claude solo para tareas síncronas con usuario esperando.

4. Los errores de DeepSeek se amplifican

Encontré dos casos donde el thinking de DeepSeek llegó a una conclusión incorrecta y Claude la tomó como verdad. El modelo no tiene mecanismo de validación cruzada — si DeepSeek razona mal, Claude sintetiza mal. Implementé un fallback:

// Validación básica: si Claude expresa incertidumbre, hacer rollback a solo Claude
async function deepClaudeConFallback(prompt: string, system: string) {
  const resultado = await deepClaudeComplete(prompt, system);
  
  // Detectar señales de incertidumbre en el output de Claude
  const senalesDeError = [
    "no estoy seguro",
    "podría ser incorrecto",
    "el razonamiento anterior sugiere",
    "según el análisis previo, aunque",
  ];
  
  const outputLower = resultado.claudeOutput.toLowerCase();
  const tieneIncertidumbre = senalesDeError.some((s) =>
    outputLower.includes(s)
  );
  
  if (tieneIncertidumbre) {
    // Fallback: Claude solo, sin el thinking contaminado
    console.log("[deepclaude] Fallback activado — thinking posiblemente corrupto");
    return await soloClaudeComplete(prompt, system);
  }
  
  return resultado;
}

FAQ: DeepClaude en loops de agentes de producción

¿DeepClaude reemplaza a Claude Code por completo? No, y sería un error pensarlo así. Claude Code tiene integración nativa con el sistema de archivos, shell y contexto de proyecto. DeepClaude es una arquitectura de completions, no un agente integrado. Los usos son diferentes: Claude Code para interacción iterativa con el codebase; DeepClaude para tareas de razonamiento pesado dentro de un pipeline propio.

¿DeepSeek V4 Pro es el mismo que DeepSeek R1? No exactamente. V4 Pro es la versión más reciente con mejoras en razonamiento multimodal y contexto largo. El repo DeepClaude original fue diseñado con R1, pero la arquitectura es compatible. En mis tests usé el modelo deepseek-reasoner que es el que expone la API pública actualmente.

¿Cuánto cuesta correr DeepClaude en producción con volumen real? Con mi volumen actual (~200 tareas de agente por día), DeepClaude cuesta aproximadamente $8/día versus $15/día solo Claude Opus, pero solo para las tareas donde lo activé (batch asincrónicas, ~40% del volumen). El ahorro neto mensual es de ~$210. No es transformador, pero tampoco es despreciable.

¿Vale la pena para un proyecto chico con pocos agentes? Probablemente no. El overhead de setup, la complejidad de orquestación y la gestión de dos APIs distintas tienen un costo de mantenimiento real. Si corrés menos de 50 tareas de agente por día, Claude solo con un buen system prompt va a darte el 90% del valor sin la complejidad.

¿El thinking de DeepSeek es visible o es una caja negra? Es visible en la respuesta de la API — es texto plano en el campo content. Eso es una ventaja enorme para debugging: podés loguear el razonamiento y entender por qué el pipeline llegó a una conclusión incorrecta. En mis logs de Railway, el thinking fue la mejor herramienta de diagnóstico que tuve.

¿Cómo afecta esto a la estrategia de specs que describí antes? Bastante directamente. En mi sistema de specs YAML para agentes, la spec le dice al agente qué hacer y cómo estructurar el output. Con DeepClaude, la spec sigue siendo el input de Claude, pero el thinking de DeepSeek actúa como un paso de "elaboración de contexto" antes de que Claude la consuma. El efecto neto: Claude necesita specs menos detalladas porque el thinking ya resolvió las ambigüedades.

Lo que acepto, lo que no compro y lo que me dejó pensando

Acepto: DeepClaude es una arquitectura legítima para un subconjunto de tareas. El ahorro de costo es real y el salto de calidad en razonamiento profundo es medible. No es marketing.

No compro: La narrativa de "siempre mejor que cada uno solo". Los números muestran claramente que en generación de código simple, la diferencia es ruido estadístico y el costo de latencia es un regalo envenenado. El hype de HN está overfitteado a casos de razonamiento complejo.

Lo que me dejó pensando: El verdadero valor de esta arquitectura puede no ser el output final sino el logging del thinking. Tener el razonamiento intermedio de DeepSeek en mis logs de producción me da un nivel de observabilidad sobre el proceso de decisión del agente que no tenía antes. Eso solo — independientemente de si mejora el output — puede valer el overhead.

La pregunta que me hago ahora, después de ver cómo Spotify está marcando contenido humano y cómo los modelos se diferencian en nichos específicos: ¿el futuro de los agentes de coding es un orquestador que enruta cada tarea al modelo más apropiado dinámicamente? DeepClaude es un primer paso tosco hacia eso. Y los números dicen que hay algo real acá, aunque el repo todavía no lo explote bien.

Si lo implementás en producción, empezá con batch asincrónico. Medí latencia antes y después. Y loguéate el thinking — es el dato más valioso de todo el sistema.

Fuente original: Hacker News