Claude Opus 4.7, Opus 4.6 o Sonnet 4.6: qué modelo elegir

La regla práctica: Sonnet por defecto, Opus cuando duele equivocarse

Si necesitas una decisión rápida, usa esta pauta:

• Sonnet 4.6 como default cuando la mayoría de solicitudes piden velocidad, coste controlado y buena calidad general para coding, análisis de documentos, trabajo de conocimiento, diseño o planificación de agentes. La documentación lo lista como rápido y más barato que Opus 4.7 en precio por token.
• Opus 4.7 como modelo de escalado cuando el coste de un error sea mayor que el coste extra de tokens: agentes de código con muchos pasos, refactors delicados, debugging difícil, análisis de capturas o salidas largas. Anthropic lo destaca para coding, agentes, visión y tareas de varios pasos, y la documentación lista una salida máxima de 128K tokens.
• Opus 4.6 como control si ya está en producción y se comporta de forma estable. Que Opus 4.7 sea más nuevo es una razón para probarlo, no para sustituirlo sin pruebas de regresión.

Qué cambia entre Opus 4.7 y Opus 4.6

La diferencia clave es que Opus 4.7 es el Opus más nuevo y está orientado a mejorar la calidad en tareas exigentes. Anthropic describe Opus 4.7 con mejor rendimiento en coding, agentes, visión y tareas de varios pasos, además de mayor minuciosidad y consistencia en trabajos importantes.

Esto no parte de cero. Opus 4.6 ya había sido presentado con mejoras en programación, planificación más cuidadosa, agentes de ejecución larga, manejo de codebases grandes, revisión de código y debugging. Por eso, si Opus 4.6 ya resuelve bien prompts cortos y flujos estables, Opus 4.7 merece probarse justo donde suelen aparecer fallos: cadenas largas de tool calls, varias rondas de corrección, repositorios grandes, instrucciones estrictas o tareas que combinan razonamiento y visión.

Lo que conviene evitar es una migración a ciegas. La documentación oficial indica mejoras en categorías relevantes, pero no demuestra que todos tus prompts, formatos de salida, schemas o pipelines vayan a mejorar automáticamente. La forma segura de cambiar es ejecutar el mismo conjunto de evaluaciones en Opus 4.6 y Opus 4.7, y comparar tasa de finalización correcta, número de iteraciones, errores de herramientas, coste en tokens y latencia.

Qué cambia entre Opus 4.7 y Sonnet 4.6

1. El intercambio principal es calidad en tareas difíciles frente a velocidad y coste

El model overview de Anthropic coloca Opus 4.7 entre los modelos de mayor capacidad para razonamiento complejo y agentic coding, mientras que describe Sonnet 4.6 como una combinación fuerte de velocidad e inteligencia. En la práctica, esta diferencia operativa importa más que preguntar cuál es simplemente más inteligente.

Si tu producto recibe muchas solicitudes en paralelo, necesita respuestas ágiles y tiene presupuesto sensible a tokens, Sonnet 4.6 suele ser el default más razonable: la documentación lo lista con latencia rápida y precio de $3 por 1 millón de tokens de entrada y $15 por 1 millón de tokens de salida. Anthropic también indica que Sonnet 4.6 es el modelo predeterminado en claude.ai y Claude Cowork para usuarios Free y Pro.

En cambio, Opus 4.7 encaja mejor en solicitudes menos numerosas pero de mayor valor: agentes de código difíciles, software engineering de varios pasos, razonamiento largo o tareas donde la consistencia pesa más que ahorrar unos segundos o unos tokens. La documentación lista Opus 4.7 con latencia moderada y precio de $5 por 1 millón de tokens de entrada y $25 por 1 millón de tokens de salida.

2. Ambos tienen contexto de 1 millón, pero Opus 4.7 puede producir salidas más largas

Opus 4.7 y Sonnet 4.6 aparecen en el model overview con una ventana de contexto de 1 millón de tokens. Así que, entre estos dos, la pregunta no es cuál lee más contexto.

La diferencia más visible está en la salida máxima: Opus 4.7 llega a 128K tokens, mientras que Sonnet 4.6 llega a 64K tokens. Si tu flujo genera documentación extensa, planes de implementación por fases, refactors amplios o informes técnicos muy estructurados, esa mayor salida máxima puede justificar usar Opus 4.7. Para solicitudes cortas o medianas, normalmente pesan más la latencia, el coste y la estabilidad real del pipeline.

3. Los modos de thinking pueden afectar una integración API

Un detalle fácil de pasar por alto es el modo de thinking. El model overview lista Opus 4.7 con adaptive thinking, y Sonnet 4.6 con adaptive thinking y extended thinking. La system card de Opus 4.6 también incluye secciones sobre extended y adaptive thinking modes.

Si tu integración ya ajusta prompts, límites de tokens, logging o trazas alrededor de extended thinking, no conviene cambiar todo a Opus 4.7 sin comprobar compatibilidad. No es una razón para descartarlo, pero sí para probarlo con cuidado antes de un despliegue amplio.

Una estrategia de routing para producción

Una configuración práctica puede dividirse en tres rutas:

1. Ruta por defecto: Sonnet 4.6. Úsalo para la mayoría de solicitudes de usuarios finales, coding común, resúmenes, análisis de documentos, trabajo de conocimiento y planificación de agentes de riesgo moderado. La razón principal es su menor precio y la latencia rápida listada en la documentación.
2. Ruta de escalado: Opus 4.7. Actívalo cuando la tarea sea difícil, haya fallado un modelo más barato, se necesite una salida muy larga, haya muchos pasos con herramientas, exista una codebase grande o entre visión en el flujo. La razón principal es su posicionamiento más fuerte en coding, agentes, visión y trabajo de varios pasos.
3. Ruta de control: Opus 4.6. Mantenlo durante la transición si tu sistema anterior ya lo usa con estabilidad. Sirve para detectar regresiones de formato, seguimiento de instrucciones, coste o latencia antes de cambiar el modelo predeterminado.

Esta estrategia suele ser más robusta que elegir un único modelo para todo. Deja que Sonnet 4.6 absorba el volumen y reserva Opus 4.7 para los puntos donde una mejora de calidad puede valer más que el coste adicional.

Checklist antes de cambiar de modelo

Antes de sustituir el modelo por defecto, ejecuta el mismo conjunto de pruebas en las tres opciones:

• Casos reales de producción: incluye prompts que funcionaron, prompts que fallaron, solicitudes largas, tareas con tool use, codebases grandes y casos con imágenes o capturas si tu producto usa visión.
• Calidad: mide exactitud, seguimiento de instrucciones, capacidad de completar varios pasos, número de rondas de corrección, errores en llamadas a herramientas y calidad del resultado final.
• Operación: compara tokens de entrada y salida, coste, latencia p50 y p95, timeouts y porcentaje de solicitudes que deben escalar. Los precios y la latencia deberían contrastarse con el model overview vigente.
• Regresión: verifica que el modelo nuevo no rompa JSON, schemas, guías de estilo, guardrails o comportamientos de tool calling de los que dependa tu pipeline.
• Despliegue gradual: prueba primero en shadow traffic o en un canary pequeño antes de mover el tráfico principal.

Veredicto

Si hay que resumirlo en una línea: Sonnet 4.6 es el default más sensato para producción amplia, Opus 4.7 es el modelo de escalado para tareas difíciles y Opus 4.6 debe conservarse como línea base si ya está estable. Sonnet 4.6 tiene menor precio y latencia rápida en la documentación, mientras que Opus 4.7 está destacado por Anthropic para coding, agentes, visión y tareas de varios pasos, además de ofrecer una salida máxima mayor que Sonnet 4.6.

La clave no es coronar un ganador universal, sino diseñar un routing y una evaluación que reflejen tu carga real. La documentación de Anthropic ayuda a saber qué esperar; tus pruebas internas son las que dirán qué modelo funciona mejor en tu producto.