Matemática de Costes de Agentes de IA: Cuándo Haiku Gana a Sonnet (y Cuándo No)

Tabla de contenidos

Actualizado junio 2026.

TL;DR: Elegir Claude Haiku en lugar de Sonnet puede reducir el coste por llamada en un orden de magnitud, pero solo cuando la tarea tolera la menor tasa de éxito de Haiku. La métrica que importa es el coste por resultado exitoso — coste de la llamada más reintentos más limpieza humana — no el precio de etiqueta por token. Enruto por tarea, y una parte significativa de mis pasos de alto volumen corren en Haiku mientras que las decisiones de criterio se quedan en Sonnet.

Lectura del operador: Manejo más de 100 agentes, y la inferencia es una partida real. Pero he visto equipos “ahorrar dinero” forzando todo al modelo más barato y luego pagar el coste en reintentos, escalaciones y clientes enfadados. La matemática de costes solo funciona cuando mides todo el embudo.

El modelo más barato no es el que tiene el menor precio por token. Es el que tiene el menor coste total para hacer el trabajo bien. Esos son números distintos, y la brecha entre ellos es donde se tuercen la mayoría de las decisiones de coste de agentes.

La economía de tokens, dicha sin rodeos

Anthropic cobra por Claude por millón de tokens, facturando entrada y salida por separado, con la salida costando varias veces más que la entrada. Los números exactos cambian con el tiempo, así que consulta los precios actuales de Anthropic — pero es la estructura lo que impulsa la decisión:

• Haiku es el nivel barato y rápido — con diferencia, el menor coste por token de la familia.
• Sonnet se sitúa en el medio — notablemente más caro que Haiku, notablemente más barato que Opus.
• Opus es el nivel premium para el razonamiento más difícil.

De aquí se siguen dos cosas. Primera, los tokens de salida dominan el coste en tareas generativas, así que un modelo que es verboso cuesta más incluso al mismo precio por token. Segunda, la brecha de precio por token entre Haiku y Sonnet es lo bastante grande como para que en un paso de alto volumen se note absolutamente en la factura. Ese es el argumento a favor de Haiku. Ahora el argumento en contra.

La métrica que realmente importa: coste por resultado exitoso

El coste por llamada es un número de vanidad. Esta es la fórmula que de verdad uso:

coste_por_exito = (coste_llamada × intentos) + coste_limpieza
                   ÷ tasa_de_exito

Donde intentos contabiliza los reintentos, y coste_limpieza es el coste esperado de que un humano arregle los fallos que se cuelan. Mira lo que esto le hace a la comparación.

Supón que Haiku cuesta aproximadamente una décima parte de Sonnet por llamada. Si Haiku tiene éxito el 80% de las veces en una tarea y Sonnet el 98%, el ahorro por llamada parece enorme. Pero si cada fallo de Haiku dispara un reintento y 1 de cada 10 todavía necesita un humano que cuesta dinero real, el término de limpieza puede engullir el ahorro en tokens. En una tarea de bajo riesgo y alto volumen, la matemática favorece a Haiku abrumadoramente. En una tarea donde un fallo le envía un correo al cliente equivocado, puede invertirse por completo.

No puedes tomar esta decisión sin medir la tasa de éxito por modelo — que es exactamente lo que te da un arnés de evaluación. Ejecuta el mismo conjunto de evaluación contra ambos modelos y lee las tasas de éxito desde la misma vara de medir.

Dónde gana Haiku de forma decisiva

Haiku es la elección correcta cuando la tarea es estrecha, estructurada y verificable:

• Clasificación y enrutamiento — “¿este mensaje entrante es una reserva, una queja o spam?” Tres categorías, fácil de verificar, corre constantemente. Haiku todo el día.
• Extracción con un esquema — sacar una fecha, un nombre, un importe de un texto, validado con Zod. Si la salida se parsea, casi con certeza está bien.
• Reescrituras cortas y formateo — ajustes de tono, resumir una entrada que ya sabes buena, normalizar datos.
• Filtrado de primera pasada — Haiku tría, y solo los casos ambiguos se escalan a Sonnet. Este es el patrón de mayor apalancamiento.

El hilo común: el coste de un error de Haiku es bajo y el error es barato de detectar. Cuando la verificación es barata y el riesgo es bajo, gana el modelo barato.

Dónde Sonnet se gana su precio

Sonnet (y a veces Opus) vale la pena cuando la tarea es abierta, de múltiples pasos o cara de equivocar:

• Bucles de agente multiherramienta donde una llamada de herramienta equivocada se propaga en cascada. Una mayor fiabilidad de razonamiento se compone a lo largo de los pasos — los patrones de orquestación que cubro en orquestación multiagente dependen de que el modelo no pierda el hilo.
• Generación de cara al cliente donde una salida mala cuesta confianza, no solo un reintento.
• Cualquier cosa donde la verificación sea difícil en sí misma. Si no puedes saber de forma barata si la salida es correcta, no puedes permitirte un modelo que se equivoca con frecuencia.

Un fallo aquí no cuesta un reintento — cuesta un reembolso, un cliente perdido, o mi tiempo. Frente a eso, la prima por token es un error de redondeo.

La regla de enrutamiento que de verdad despliego

No elijo un modelo por agente. Enruto por tarea dentro del agente, normalmente con un clasificador barato que decide qué modelo posterior maneja el trabajo:

function pickModel(task: Task): string {
  // Barato, verificable, de alto volumen → Haiku
  if (task.type === "classify" || task.type === "extract") {
    return "claude-haiku";
  }
  // Abierto o de cara al cliente → Sonnet
  if (task.customerFacing || task.steps > 2) {
    return "claude-sonnet";
  }
  return "claude-sonnet"; // por defecto, la opción segura
}

Hay dos principios codificados aquí. Por defecto, el modelo seguro, no el barato — optimizas el coste hacia abajo desde una base que funciona, nunca la fiabilidad hacia arriba desde una rota. Y escala, no apuestes: deja que Haiku maneje el 80% fácil y entrega el 20% difícil a Sonnet. Ese híbrido casi siempre gana a correr todo en cualquiera de los dos modelos por separado.

También está el caché de prompts para añadir encima: si tu prompt de sistema es grande y reutilizado, el caché reduce sustancialmente el coste de entrada independientemente del nivel, lo que a veces hace que Sonnet sea lo bastante barato como para que la cuestión de Haiku sea irrelevante.

Un ejemplo trabajado de mi propio stack

Toma un paso de triaje de mensajes entrantes de alto volumen. Corre miles de veces, la tarea es una clasificación de tres vías, y un fallo solo significa que el elemento aterriza en una cola de revisión — barato de detectar, bajo riesgo. Esa es una tarea de Haiku de manual, y sacarla de Sonnet redujo significativamente el coste de ese paso sin un impacto medible en el resultado que importaba.

Ahora toma el paso que redacta la respuesta real al cliente. Menor volumen, abierto, y un mal borrador saliendo cuesta confianza. Ese se queda en Sonnet. Mismo agente, dos modelos, enrutados por riesgo. Vigilo el coste por ejecución y las métricas de éxito de ambos, como describo en cómo mido si un agente de IA realmente funciona — y solo empujo un paso a un nivel inferior después de que la evaluación diga que el modelo más barato mantiene la tasa de éxito.

FAQ

¿Es Claude Haiku siempre más barato que Sonnet en la práctica?

Por token, sí — por un amplio margen. Por resultado exitoso, no siempre. Si la menor tasa de éxito de Haiku dispara reintentos y limpieza humana, el coste total puede superar al de Sonnet en tareas donde los errores son caros de detectar o arreglar.

¿Cómo decido entre Haiku y Sonnet para una tarea dada?

Puntúa la tarea en dos ejes: cuán verificable es la salida y cuán costoso es un error. El trabajo barato de verificar, de bajo riesgo y alto volumen va a Haiku; el trabajo abierto, de cara al cliente o difícil de verificar va a Sonnet. Enruta por tarea, no por agente.

¿Cuál es la única métrica de coste que debo seguir?

Coste por resultado exitoso — coste de la llamada por intentos más coste de limpieza esperado, dividido por la tasa de éxito. El precio por llamada por sí solo esconde reintentos y tiempo humano, que es donde los modelos baratos se vuelven caros sin que te des cuenta.

¿Puedo usar ambos modelos en un agente?

Sí, y normalmente deberías. El patrón más fuerte es una primera pasada barata (Haiku clasifica o filtra) que escala solo los casos ambiguos a Sonnet. Ese híbrido normalmente gana a correr todo en un solo nivel.