Reglas de Selección de Modelos: Cuándo Usar Opus, Sonnet o Haiku

Estas son las reglas enumeradas que este sitio utiliza para hacer coincidir una tarea con un nivel de modelo de Claude — Haiku, Sonnet, Opus o Fable — basándose en la complejidad y la latencia, condensadas de la cobertura más profunda de la familia de modelos en este sitio a formato de reglas.

Cómo Usar Esta Lista de Verificación

• Aplica estas reglas por cada sitio de llamada, no una vez para toda la aplicación; una sola aplicación generalmente abarca varios niveles.
• Empieza con la regla del "nivel predeterminado" para tu categoría de tarea, luego aplica las reglas de escalada y desescalada para ajustar.
• Revisa las asignaciones de nivel cada vez que Anthropic lance un nuevo modelo; una regla ajustada al perfil de coste de Sonnet 4.6 puede que ya no sea válida para Claude Sonnet 5.
• Registra el razonamiento para cualquier elección de nivel no predeterminada en la revisión de código, no solo en el código mismo.

Nivel Predeterminado por Tipo de Tarea

1. La clasificación y extracción tienen como valor predeterminado Haiku. Tareas cortas y bien definidas —etiquetar un ticket de soporte, extraer un campo de un formulario, enrutar una solicitud— rara vez necesitan más que la profundidad de razonamiento de Claude Haiku 4.5, y es el nivel más rápido y barato.
2. El chat de propósito general y la generación de contenido tienen como valor predeterminado Sonnet. Claude Sonnet 5 es el nivel de modelo predeterminado del sitio por una razón: maneja la mayoría de las tareas conversacionales, de redacción y de razonamiento moderado con una calidad cercana a Opus sin la latencia o el coste de Opus.
3. El razonamiento multi-paso y las tareas de codificación complejas tienen como valor predeterminado Opus. Claude Opus 4.8 es el valor predeterminado correcto cuando una tarea requiere mantener muchas restricciones simultáneamente, planificar a través de varios pasos o producir código que debe ser correcto a la primera.
4. El trabajo más exigente y de agente de largo alcance tiene como valor predeterminado Fable. Claude Fable 5 se reserva para tareas que realmente necesitan su razonamiento extendido y coherencia de largo alcance — migraciones autónomas a gran escala, investigación profunda o bucles de agente que se ejecutan durante muchos minutos sin supervisión.
5. Nunca elijas un nivel porque "se siente más seguro". Un nivel elegido por precaución en lugar de evidencia es una decisión de coste y latencia tomada sin datos; exige una brecha de calidad real antes de escalar.

Reglas de Escalada (Subir un Nivel)

6. Escala cuando la salida de un nivel inferior falle en la revisión de una muestra representativa. Ejecuta primero 20-50 ejemplos reales a través del nivel más barato; escala solo si la tasa de fallos es lo suficientemente alta como para importar para el caso de uso.
7. Escala cuando la tarea requiera mantener más que un puñado de restricciones a la vez. El razonamiento multi-restricción — "satisfacer estas cinco reglas de negocio simultáneamente" — es donde los niveles inferiores se degradan primero.
8. Escala para bucles de agente autónomos y sin supervisión con efectos secundarios en el mundo real. Un humano que revisa cada paso tolera más errores del modelo que un agente que realiza pagos o presenta tickets por sí solo.
9. Escala temporalmente durante una transición de modelo, no permanentemente por defecto. Si un nuevo tipo de tarea no está probado, empieza en un nivel superior para establecer una línea base de calidad, y luego desescala una vez que tengas evidencia de que el nivel más barato se mantiene.
10. Escala cuando el coste de una respuesta incorrecta sea asimétrico. Una ticket de soporte mal clasificado es barato de arreglar; una respuesta incorrecta en un contexto financiero o médico no lo es; deja que el coste del fallo, no solo la complejidad de la tarea, impulse el nivel.

Reglas de Desescalada (Bajar un Nivel)

11. Desescala una vez que la salida de una tarea haya sido estable a través de suficientes ejecuciones de evaluación. Si Sonnet ha igualado la calidad de Opus en tu conjunto de evaluación para un tamaño de muestra significativo, baja la ruta y sigue monitorizando.
12. Desescala cualquier ruta donde la salida sea determinista o basada en plantillas. Las tareas con una forma de salida estrecha y bien especificada rara vez necesitan la profundidad de razonamiento del nivel superior, independientemente de cómo se lea la tarea en prosa.
13. Desescala primero las rutas síncronas y sensibles a la latencia. Un usuario que espera una respuesta siente directamente la latencia añadida de Opus o Fable; si la calidad se mantiene en Sonnet o Haiku, la ganancia de latencia por sí sola justifica bajar de nivel.
14. Desescala antes de escalar el tráfico, no después de que llegue la factura. Ejecutar una evaluación de coste/calidad antes de que una función vaya a tráfico completo de producción es más barato que reaccionar a una factura grande.

Reglas de Latencia

15. Trata el presupuesto de latencia y la complejidad de la tarea como ejes independientes. Una tarea puede ser compleja pero tolerante a la latencia (un trabajo por lotes nocturno) o simple pero crítica en latencia (autocompletado); decide cada eje por separado antes de elegir un nivel.
16. Dirige las solicitudes síncronas orientadas al usuario lejos del nivel más pesado por defecto. Opus y Fable intercambian rendimiento por profundidad; solo ponlos en una ruta de solicitud en vivo cuando la tarea realmente necesite esa profundidad y la experiencia de usuario pueda tolerar la espera.
17. Mueve el razonamiento pesado tolerante a la latencia a procesamiento asíncrono o por lotes. Si una tarea necesita razonamiento a nivel de Opus o Fable pero el usuario no necesita la respuesta de forma síncrona, ejecútala como un trabajo en segundo plano en lugar de bloquear una solicitud.

Reglas de Gobernanza

18. Escribe la decisión del nivel para cada ruta de producción, no solo para las excepciones. Un comentario corto o una entrada de configuración que nombre el modelo y la razón evita que el próximo ingeniero la cambie silenciosamente sin saber por qué.
19. Revisa las asignaciones de nivel en una cadencia fija, no solo cuando algo se rompe. Una revisión trimestral de las rutas de producción detecta rutas que deberían haber sido desescaladas hace meses.
20. Nunca permitas que la preferencia local de un solo ingeniero establezca el nivel para una ruta compartida. El nivel del modelo es una decisión a nivel de equipo con consecuencias de coste y fiabilidad; canalízalo a través de la misma revisión que cualquier otro cambio de configuración de producción.

Preguntas Frecuentes

Relacionado

• Cómo las Reglas de Opinión Previenen Incidentes de Producción de Claude - por qué escribir estas reglas es más importante que cualquier elección de nivel individual.
• Las Reglas Centrales de Claude: Una Lista de Referencia Rápida - la versión condensada de estas reglas junto con todas las demás categorías.
• Reglas de Control de Costes: Almacenamiento en Caché, Procesamiento por Lotes y Disciplina de Presupuesto de Tokens - cómo el almacenamiento en caché y el procesamiento por lotes se combinan con las elecciones de nivel realizadas aquí.
• Mejores Prácticas de Reglas de Claude - cada regla de esta sección reformulada como una lista de verificación.

Versiones de Stack: Escrito contra la línea de modelos de Claude actual a partir de ~junio de 2026 — Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (el predeterminado), y Claude Haiku 4.5 — y el SDK oficial de anthropic para Python (última versión 0.x). Los nombres de los modelos, los precios y las versiones del SDK cambian rápidamente; verifica los detalles actuales en platform.claude.com/docs antes de confiar en ellos.