Tres modelos, una recomendación y cuándo desviarse

Módulo 1 · Fundamentos del producto · Lección 2 de 3

Al terminar esta lección podrás recomendar un modelo para un nuevo despliegue de Claude Code y defender esa elección frente a objeciones de costo, velocidad y capacidad.

La familia de modelos: Haiku es el más barato, Opus el más preciso, y Sonnet es donde cae la mayor parte del trabajo de producción.

Modelo	Nivel de costo y contexto	Descripción	Mejor para
Claude Haiku 4.5	Nivel de costo más bajo · contexto de 200k	El más rápido y barato. Úsalo cuando el volumen y la velocidad importan más que la profundidad de razonamiento.	Aplicaciones en tiempo real, subagentes, pipelines de CI/CD, autocompletado en línea y tareas automatizadas de alto volumen en las que dominan la latencia y el costo.
Claude Sonnet 4.6	Costo intermedio · contexto de 1M	El valor por defecto de producción para la mayoría del trabajo con Claude Code. Mejor equilibrio entre velocidad e inteligencia.	Flujos de trabajo diarios de desarrollo, escritura de funciones, generación de tests, documentación y la mayoría del trabajo de funcionalidades. Es donde empiezan la mayoría de los pilotos.
Claude Opus 4.8	Nivel de costo más alto · contexto de 1M	El razonamiento más preciso. Úsalo para trabajo complejo, de horizonte largo y alta autonomía, donde la precisión pesa más que el costo.	Refactorizaciones autónomas, tareas de varias horas, revisión de arquitectura y cualquier trabajo en el que acertar a la primera justifica el sobreprecio.

Los niveles de costo son relativos dentro de la familia, no cifras exactas. Verifica las tarifas vigentes en anthropic.com/pricing antes de cualquier conversación con un cliente.

La decisión: empieza con Sonnet, pasa a Opus para el razonamiento sostenido y recurre a Haiku cuando dominan el volumen y el costo.

La mayoría de los pilotos empiezan con Sonnet y se expanden desde ahí. Los casos de alto volumen o de alta autonomía son donde la mezcla de modelos se vuelve más deliberada.

flowchart TD
  C["Carga de trabajo del cliente"] --> Q1{"¿Volumen alto o sensible al tiempo?"}
  Q1 -- "Sí" --> H["Haiku 4.5: ruta rápida"]
  Q1 -- "No" --> Q2{"¿Tareas complejas o de horizonte largo?"}
  Q2 -- "Sí" --> O["Opus 4.8: ruta de mayor capacidad"]
  Q2 -- "No" --> S["Sonnet 4.6: punto de partida habitual"]

Empezar rápido (ruta Haiku)

Carga de alto volumen o sensible al tiempo: pipelines de subagentes, scripts de CI/CD, prototipado rápido y despliegues sensibles al costo. Cuando importan más el rendimiento y la latencia que la profundidad de razonamiento.

Empezar con capacidad (ruta Opus)

Tareas complejas o de horizonte largo: refactorizaciones autónomas, tareas de varias horas y trabajo en el que acertar a la primera pesa más que el costo. Sonnet cubre todo lo intermedio.

La palanca del esfuerzo: antes de cambiar de modelo, prueba a ajustar el esfuerzo. Es una jugada más barata.

El parámetro de esfuerzo (effort) ajusta la profundidad de razonamiento dentro de un nivel sin cambiar de modelo. En Opus 4.8, xhigh está disponible y es el ajuste recomendado para trabajo de programación y agéntico; a menudo es una mejor primera palanca que pagar un nivel superior. En Sonnet 4.6, el parámetro llega hasta high, una palanca útil antes de comprometerte con el precio de Opus.

Escribir tests unitarios para una función utilitaria de 20 líneas produce el mismo resultado con el esfuerzo por defecto que con pensamiento extendido (extended thinking). Una refactorización de varios archivos con análisis de dependencias entre módulos es donde un esfuerzo mayor produce resultados materialmente mejores.

La simulación de la palanca del esfuerzo en Opus 4.8 está en la sección de comprensión al final de la lección.

Para recordar

La selección de modelo es una decisión de arquitectura; el ajuste del esfuerzo es una palanca de rendimiento. Sabe cuál de las dos estás usando antes de hacer una recomendación.

Comprueba tu comprensión

Escenario: tu cliente despliega Claude Code para 50 desarrolladores con trabajo rutinario de funcionalidades.

Tu cliente va a desplegar Claude Code para 50 desarrolladores que hacen trabajo rutinario de funcionalidades (escribir funciones, generar tests, actualizar documentación). Un grupo pequeño también ejecutará refactorizaciones autónomas nocturnas sobre módulos heredados. ¿Cuál es tu recomendación de modelo?

• A. Haiku 4.5 para todas las tareas: costo eficiente a escala, manteniendo la factura baja para 50 desarrolladores.
• B. Opus 4.8 para todas las tareas: garantiza la mejor calidad de salida en todo tipo de trabajo.
• C. Sonnet 4.6 por defecto; Opus 4.8 para las ejecuciones nocturnas: ajusta el modelo al tipo de tarea.
• D. Sonnet 4.6 para todas las tareas: un solo modelo para todo el equipo mantiene la configuración simple.

Ver respuesta

Respuesta correcta: C.

A. Haiku funciona para tareas sencillas y de alto volumen, pero la refactorización compleja, la revisión de arquitectura y las tareas agénticas de varios pasos requieren Sonnet u Opus. Usar Haiku para todo degrada la calidad en las tareas que más importan al cliente. Las ejecuciones autónomas nocturnas de este escenario necesitan una profundidad de razonamiento que Haiku no puede ofrecer de forma fiable.

B. Opus es la opción adecuada para las ejecuciones autónomas nocturnas, pero usarlo con 50 desarrolladores en trabajo rutinario de funcionalidades añade aproximadamente un 65 % de costo sin una mejora de calidad significativa. Sonnet gestiona la escritura de funciones, la generación de tests y las actualizaciones de documentación con una calidad comparable y a una fracción del costo. Ajusta el modelo al trabajo, no a un único techo.

C. Correcta. Sonnet 4.6 gestiona bien el trabajo rutinario de funcionalidades a un costo razonable. Opus cubre las ejecuciones autónomas nocturnas, donde la complejidad y la duración de la tarea justifican el sobreprecio. Este enfoque escalonado ofrece al cliente eficiencia de costo en el trabajo diario de alto volumen, al tiempo que preserva la profundidad de razonamiento para las tareas que la necesitan.

D. Sonnet para todas las tareas es un valor por defecto seguro, pero pagas de más por tareas scripteadas de alto volumen que Haiku gestiona igual de bien. Haiku gestiona tareas sencillas y de alto volumen, como la generación de docstrings o los autocompletados en línea, a menor costo y menor latencia, sin una penalización de calidad relevante para esos casos. La mayoría de los equipos empresariales obtienen mejores resultados con un modelo escalonado que con un único modelo para todo.

Simulación: prueba la palanca del esfuerzo en Opus 4.8. Los niveles son Default, High y xhigh. Los ejes del control son la profundidad de razonamiento y el costo relativo. Elige un nivel para ver lo que implica.

• Default
• High
• xhigh

Ver respuesta

xhigh es la opción recomendada para trabajo de programación y agéntico en Opus 4.8.

• Default: adecuado para trabajo acotado y de baja ambigüedad. Escribir tests unitarios para una utilidad de 20 líneas produce aquí el mismo resultado que con un esfuerzo mayor, así que no pagues por una profundidad que no vas a usar.
• High: más razonamiento por paso para tareas de complejidad moderada. Un punto medio razonable antes de comprometerte con el máximo.
• xhigh: el ajuste recomendado para trabajo de programación y agéntico en Opus 4.8. Obtienes el razonamiento más profundo que ofrece el nivel, a menudo una mejor primera jugada que pagar por un modelo superior.

Ideas clave

Al terminar esta lección puedes asociar el perfil de carga de trabajo de un cliente con una recomendación de modelo y explicar las compensaciones entre costo, latencia y profundidad de razonamiento.

• Sonnet 4.6 es el valor por defecto de producción para la mayoría del trabajo con Claude Code; Haiku 4.5 es para volumen y latencia; Opus 4.8 para razonamiento complejo y de horizonte largo.
• La decisión: empieza con Sonnet, sube a Opus para tareas complejas o de varias horas, y baja a Haiku cuando dominan el volumen y el costo.
• Ajustar el esfuerzo (xhigh en Opus 4.8, high en Sonnet 4.6) es una palanca de rendimiento más barata que cambiar de modelo.
• La selección de modelo es una decisión de arquitectura; el esfuerzo es una palanca de rendimiento.
• Usar un único modelo para todo el equipo suele costar más en tareas de alto volumen sin ganar calidad donde no hace falta.

Siguiente: Opciones de plataforma