Sonnet 5 vs Sonnet 4.6: lee el benchmark, no la reacción negativa
La respuesta corta
«Sonnet 5 solo es bueno para vencer a Sonnet 4.6» es un titular contundente, pero oculta la pregunta útil: ¿qué modelo es mejor para tu carga de trabajo, con tus ajustes, a un coste y latencia aceptables?
Anthropic describe Sonnet 5 como su Sonnet más agentivo, con mejoras en programación, uso de herramientas, planificación y trabajo profesional. Su propia system card es más matizada que el resumen del lanzamiento. Sonnet 5 adelanta muchas evaluaciones destacadas, pero algunos resultados especializados son inferiores a los de Sonnet 4.6. Eso es normal para un modelo nuevo y es una razón para evaluar, no evidencia de que el marketing o las críticas de la comunidad sean universalmente correctos.
Qué respalda la evidencia oficial
El anuncio de Sonnet 5 dice que el modelo trae capacidades que recientemente requerían modelos más grandes al nivel Sonnet. Se lanzó en los productos Claude y en la API con una ventana de contexto nativa de un millón de tokens.
La system card documenta las condiciones reales de evaluación y muestra resultados mixtos. Por ejemplo, en una tarea de diseño de secuencias biológicas, la puntuación de diseño de la mejor secuencia de Sonnet 5 fue menor que la de Sonnet 4.6, mientras que su resultado de predicción fue ligeramente mejor. Otras evaluaciones usan diferentes ajustes de esfuerzo, herramientas, andamiajes, presupuestos de tokens y número de ensayos.
Ese contexto no es letra pequeña. Un modelo puede liderar un benchmark de programación y aun así sentirse peor en un repositorio particular porque edita de forma demasiado agresiva, sigue menos las convenciones locales o dedica más tiempo a razonar. También puede perder un benchmark científico estrecho mientras es sustancialmente mejor en trabajo de software multi‑paso.
Por qué tanto los gráficos de lanzamiento como la reacción negativa pueden engañar
El material de lanzamiento selecciona evaluaciones que explican las fortalezas previstas de un modelo. Los informes de la comunidad seleccionan fallas memorables. Ambos son insumos útiles, pero ninguno es una decisión a nivel de carga de trabajo.
Vigila cuatro errores comunes al comparar:
- Entornos de evaluación diferentes — el acceso a herramientas, los prompts, la compactación y la política de reintento pueden mover las puntuaciones agentivas de forma sustancial.
- Ejecuciones únicas — los modelos no deterministas necesitan ensayos repetidos; un éxito o fallo impresionante es una anécdota.
- Defaults cambiados — el nivel de esfuerzo, el comportamiento de razonamiento y el andamiaje de Claude Code pueden diferir entre versiones.
- Sustitución de benchmark — un resultado en SWE-bench no mide tu estilo de frontend, la canalización de datos o la precisión en revisiones de código.
Incluso una victoria agregada válida puede ocultar regresiones en una tarea estrecha. A la inversa, un puñado de publicaciones airadas puede derivar de sorpresas en la migración en lugar de una disminución amplia de capacidad.
Una prueba práctica de migración
Construye un pequeño conjunto de evaluación con trabajo que ya entiendas. Cinco a veinte tareas son suficientes para exponer diferencias direccionales:
- Incluye una corrección de bug, una funcionalidad acotada, un refactor, una tarea de escritura de tests y una tarea de revisión de código.
- Arranca cada modelo desde el mismo commit y las mismas instrucciones.
- Empareja nivel de esfuerzo y permisos de herramientas tanto como permitan los productos.
- Ejecuta las tareas importantes más de una vez.
- Puntúa primero la corrección, luego cambios innecesarios, calidad de tests, seguimiento de instrucciones, latencia y coste.
Mantén el resultado esperado fuera del prompt para que el modelo no pueda simplemente reflejar la rúbrica. Revisa el parche, ejecuta las mismas comprobaciones automatizadas y registra si un humano tuvo que intervenir.
Cuándo mantener Sonnet 4.6
Permanece en Sonnet 4.6 cuando ya es fiable en un flujo de trabajo de producción estable y Sonnet 5 no ha demostrado suficiente mejora para justificar el riesgo de migración. Un modelo conocido con modos de fallo medidos puede ser más valioso que una puntuación promedio de benchmark más alta.
Cámbiate a Sonnet 5 cuando tu evaluación emparejada muestre mejor tasa de finalización, menos turnos de reparación o mejor rendimiento ajustado por coste en el trabajo que importa. Para cargas mixtas, el enrutamiento es una respuesta válida: mantén el modelo anterior para una tarea donde gana y usa Sonnet 5 para programación agentiva donde sus mejoras se noten.
Conclusión
Sonnet 5 no necesita ganar todos los benchmarks para ser una actualización valiosa, y un gráfico de lanzamiento no lo convierte en la mejor opción para cada tarea. Trata tanto el anuncio como la reacción negativa como hipótesis. Tu evaluación repetida y versionada es la decisión.
Reclamaciones verificadas contra el Sonnet 5 announcement, la Sonnet model page y la Claude Sonnet 5 system card.