Claude Opus 4.5 vs Claude Sonnet 4.5: cuándo pagar más para corregir incidencias de código y cuándo no

La decisión no es qué modelo parece mejor, sino qué incidencia resuelve con menor coste total

Comparar Claude Opus 4.5 y Claude Sonnet 4.5 para mantenimiento de software exige acotar la pregunta. El precio por token, una demostración aislada o un resultado de benchmark no responden por sí solos qué opción conviene para un equipo. La unidad de decisión debe ser la incidencia correctamente resuelta y aceptada: un cambio que reproduce el contexto del fallo, supera las pruebas objetivo y de regresión, no amplía indebidamente el alcance y necesita una revisión humana razonable.

En esta comparación, una prima de precio para Opus 4.5 solo estaría justificada si se traduce en un resultado operativo medible. Puede ser una tasa mayor de resolución completa, menos regresiones, menos iteraciones de un ingeniero o un tiempo menor hasta disponer de un parche aceptable. Si Sonnet 4.5 alcanza los mismos umbrales de aceptación con menos coste, pagar más no aporta necesariamente valor para ese tipo de tickets.

El análisis debe separar el coste de inferencia del coste de trabajo. Un modelo barato que genera parches incompletos, obliga a depurar su diagnóstico o produce cambios fuera de alcance puede resultar más caro tras sumar reintentos, ejecución de herramientas y revisión. A la inversa, un modelo de tarifa superior no debe recibir crédito por un parche que parece plausible pero no supera una batería de pruebas representativa.

Esta pieza no declara un ganador general. Propone una prueba local que permita a responsables de ingeniería, equipos de plataforma de IA y compradores decidir con evidencia propia. También es compatible con el índice de comparativas, con las fichas de Claude Opus 4.5 y Claude Sonnet 4.5, y con la información de Anthropic sobre los modelos y sus canales de acceso.

Prepare un corpus congelado y reproducible antes de ejecutar los modelos

La prueba empieza con el corpus, no con el prompt. Cada incidencia debe quedar asociada a un repositorio, un commit base inmutable, un entorno de ejecución y una definición verificable del fallo. Conserve el ticket original, pero redacte una versión de tarea que elimine información posterior al momento que se quiere simular, como el enlace a la corrección ya conocida o comentarios que revelen la solución.

Para cada caso, cree una reproducción mínima que falle sobre el commit base y una batería que permita comprobar la corrección. La evaluación debe diferenciar una modificación cosmética de un arreglo funcional. Una práctica sólida consiste en definir pruebas que debían fallar antes de la corrección y pruebas que ya pasaban y deben seguir pasando. Este planteamiento coincide con la lógica de validación usada para distinguir resolución y regresión en SWE-bench Verified, aunque los resultados de un corpus interno no deben mezclarse con los de ese benchmark.

SWE-bench es una referencia metodológica útil, no un sustituto del corpus local. El trabajo original describe un conjunto de incidencias extraídas de repositorios Python reales; eso ayuda a entender las exigencias de una tarea de edición de repositorio. Sin embargo, su distribución de lenguajes, dependencias, antigüedad de incidencias y reglas de evaluación puede diferir de las del equipo. Un resultado interno debe publicarse como resultado interno.

Excluya tickets sin reproducción razonablemente estable, cambios que dependan de servicios externos no controlados, vulnerabilidades que requieran un proceso específico de divulgación y tareas cuyo criterio de aceptación sea puramente subjetivo. Registrar estas exclusiones evita que la muestra final parezca más representativa de lo que es.

Mantenga condiciones equivalentes, pero no suponga que equivalentes significa idénticas

Registre el identificador exacto de cada modelo, la fecha y hora de la ejecución, el canal de acceso, la región o endpoint, el proveedor de infraestructura, la configuración de contexto y las herramientas concedidas. Para Opus 4.5, la documentación de Anthropic identifica el modelo de API claude-opus-4-5-20251101. La documentación de ciclo de vida de modelos debe revisarse al inicio de cada campaña para confirmar que ambos identificadores siguen activos y para anticipar retiradas.

El anuncio de Sonnet 4.5 documenta su acceso mediante API y su precio de lanzamiento de entrada y salida. Ese dato no basta para calcular un coste definitivo: la facturación puede depender del canal, del uso de caché, de la región, de herramientas y de condiciones comerciales vigentes. En Amazon Bedrock, por ejemplo, la documentación del proveedor describe diferencias entre endpoints globales y regionales, además de condiciones específicas de disponibilidad. No compare una ejecución regional de un modelo con una ejecución global del otro sin declarar la diferencia.

Use el mismo prompt de sistema, descripción de tarea, formato de respuesta, directorio de trabajo, permisos de lectura y escritura, comandos autorizados, acceso a red y límite de iteraciones. Si un modelo dispone de una modalidad o capacidad que el otro no tiene en el canal elegido, no la trate como una prueba estrictamente equivalente. Puede medirla como escenario operativo separado, pero debe etiquetarla como tal.

También deben fijarse la política de reintentos y los límites. Un reintento tras un error transitorio de infraestructura puede ser razonable; múltiples reinicios porque el primer resultado fue malo cambian la intervención disponible. La regla debe aplicarse a los dos modelos y contabilizar todos los intentos facturables.

Separe los tickets por dificultad y por mecanismo de fallo

Una media global puede ocultar la información que realmente determina la compra. Clasifique los casos antes de ejecutar los modelos. Un primer estrato puede reunir correcciones localizadas: una validación incorrecta, una condición de borde o una transformación de datos limitada a uno o pocos archivos. Son tareas donde un modelo más económico puede alcanzar pronto el umbral de aceptación.

Un segundo estrato debe incluir fallos que requieren rastrear dependencias entre módulos. Por ejemplo, una modificación de una interfaz interna que rompe serialización, validación y consumidores remotos, o un defecto en el que el síntoma aparece en una capa distinta de la causa. Aquí es razonable investigar si una mayor capacidad de planificación o exploración reduce iteraciones, pero el resultado debe medirse y no inferirse de la categoría del modelo.

El tercer estrato corresponde a incidencias ambiguas o difíciles de reproducir. Pueden involucrar concurrencia, estado compartido, configuraciones particulares o requisitos incompletos. El objetivo no es premiar una explicación extensa: es comprobar si el modelo formula hipótesis comprobables, obtiene evidencia mediante las herramientas permitidas y limita el cambio a la causa más sustentada.

Etiquete además lenguaje, tamaño del repositorio, superficie modificada, tipo de prueba y existencia de dependencias externas. Esas etiquetas permiten saber si una diferencia procede de la dificultad real o de una concentración accidental de tickets en un lenguaje o módulo.

Defina éxito completo antes de ver los resultados

El criterio de éxito debe combinar validación automática y revisión humana. Clasifique como éxito completo únicamente un parche que supere las pruebas objetivo, mantenga las pruebas de regresión pertinentes y cumpla la rúbrica de alcance. Si el repositorio dispone de pruebas amplias que son viables dentro del presupuesto, ejecútelas; si no, declare qué cobertura quedó fuera y por qué.

La revisión humana debe ser ciega respecto al modelo. Entregue a los revisores el diff, el diagnóstico producido, los resultados de pruebas y el ticket, pero no el nombre del modelo ni el coste. Pida una decisión definida: aceptar, aceptar con cambios menores, rechazar por corrección incompleta, rechazar por regresión, rechazar por alcance excesivo u otra categoría previamente especificada.

Conviene conservar la categoría de éxito parcial, pero no usarla para inflar la tasa de resolución. Un parche que localiza correctamente el componente afectado pero falla una condición de borde puede ser útil para investigar la calidad del diagnóstico. No es equivalente a una incidencia resuelta. Del mismo modo, un arreglo correcto que modifica ficheros ajenos sin justificación puede requerir intervención suficiente para no contar como éxito completo.

Las instrucciones de revisión deben prohibir aceptar cambios que desactiven pruebas, reduzcan aserciones o introduzcan excepciones genéricas solo para hacer desaparecer un error. También deben señalar que una prueba nueva no demuestra por sí sola que la implementación sea correcta.

Mida costes, intervención y tiempo de extremo a extremo

La métrica principal puede expresarse como coste total del lote dividido entre el número de éxitos completos aceptados. En el numerador incluya entrada, salida, caché y cualquier concepto facturado aplicable al canal. Sume reintentos, llamadas fallidas, uso de herramientas cuando tenga coste y tiempo humano de revisión o corrección, si el objetivo es decidir el coste operativo y no solo el coste de API.

Informe también la tasa de éxito completo, la tasa de éxito parcial, las regresiones detectadas, el número de intervenciones humanas y la latencia de extremo a extremo. La latencia no equivale necesariamente al tiempo de modelo: un agente puede esperar herramientas, repetir pruebas o bloquear recursos de integración continua. Registre por separado el tiempo de inferencia, el de herramientas y el humano cuando sea posible.

Para evaluar el diagnóstico, use una rúbrica sencilla: identificación de síntomas, hipótesis causal, evidencia recogida, explicación de la modificación y limitaciones conocidas. Un diagnóstico puede ser útil incluso en un fracaso, pero debe evaluarse sin confundir calidad narrativa con corrección. La puntuación debe tener ejemplos de referencia y, si hay varios revisores, una regla para resolver desacuerdos.

Reporte distribuciones y resultados por estrato, no solo promedios. Un pequeño número de incidencias complejas puede dominar el coste medio. Asimismo, repita una parte o la totalidad del lote: la variabilidad entre ejecuciones puede cambiar la conclusión si la diferencia entre modelos es pequeña.

Interprete la prima de Opus 4.5 mediante umbrales, no mediante prestigio de modelo

Opus 4.5 justificaría una prima en un estrato concreto si su mejora en resoluciones completas compensa sus costes adicionales y la revisión que evita. Esto podría ocurrir en incidencias con relaciones entre módulos, diagnósticos ambiguos o ciclos de prueba costosos, pero es una hipótesis que el experimento debe confirmar. La comparación debe mostrar cuántos casos adicionales acepta la revisión y qué coste humano deja de ser necesario.

Sonnet 4.5 alcanza el umbral operativo cuando cumple la tasa de aceptación, límite de regresiones, plazo y coste definidos por el equipo. En correcciones localizadas, la decisión puede favorecerlo aunque Opus obtenga una puntuación media mayor, si la diferencia no reduce un coste relevante. En tareas más difíciles, el resultado puede ser mixto: Sonnet para triage y arreglos acotados, Opus para una cola definida de incidencias que supera un criterio de complejidad.

No convierta la segmentación en una regla basada solo en intuición. Una política inicial puede usar señales como número de módulos afectados, ausencia de reproducción clara o necesidad de analizar trazas extensas. Después debe validarse contra los resultados. Si esas señales no predicen una mejora suficiente con Opus, añaden complejidad sin aportar una decisión mejor.

Los anuncios y tarjetas técnicas del proveedor pueden aportar información de disponibilidad, configuración y evaluaciones internas. No reemplazan esta prueba, porque las herramientas, los repositorios, los prompts, el presupuesto y la definición de éxito pueden no coincidir con los de su equipo.

Aplique análisis de sensibilidad y declare los límites

Repita la comparación con presupuestos de iteración distintos, límites de contexto y permisos de herramientas restringidos. Un resultado que depende de un presupuesto muy alto puede no ser aplicable a una operación con límites estrictos. Del mismo modo, una ventaja observada con acceso de red o con una herramienta propietaria no debe atribuirse únicamente al modelo.

No agregue resultados de SWE-bench Verified, Terminal-Bench u otras evaluaciones al resultado interno. Es válido presentarlos como contexto metodológico si se identifica la diferencia de corpus y harness, pero no como filas comparables de una misma tabla. Cambiar las pruebas, la política de herramientas o la definición de aceptación cambia la tarea medida.

Esta prueba tampoco acredita seguridad del código, autorización para desplegar, capacidad de mantenimiento continuo ni desempeño en todos los lenguajes. Un parche aceptado en un entorno aislado puede introducir riesgos no cubiertos por el conjunto de pruebas. La decisión de producción debe conservar controles de revisión, integración continua y gestión de cambios.

Finalmente, documente los casos perdidos: tickets excluidos, errores de infraestructura, revisiones sin consenso y pruebas inestables. Ocultarlos puede hacer que la conclusión parezca más robusta de lo que realmente es. La transparencia es especialmente importante si la diferencia de coste o aceptación entre ambos modelos es reducida.

Plantilla final para tomar una decisión repetible

Antes de elegir, establezca por escrito el objetivo: por ejemplo, reducir el coste por corrección aceptada de incidencias de mantenimiento sin superar un límite de regresiones ni de tiempo de revisión. Después, ejecute ambos modelos sobre el mismo lote congelado y publique los parámetros suficientes para repetir el cálculo internamente.

La conclusión debe adoptar una forma condicional. Por ejemplo: Sonnet 4.5 es la opción predeterminada para el estrato localizado porque alcanza el umbral de aceptación con menor coste total; Opus 4.5 se reserva para el estrato intermodular si la repetición confirma una reducción suficiente de rechazos o intervención humana. Si la diferencia no persiste tras repetir el lote, la conclusión responsable es que no hay evidencia suficiente para pagar una prima en ese entorno.

Revise la decisión cuando cambien los identificadores de modelo, los precios aplicables, el canal, las herramientas disponibles o la composición de la cola de incidencias. Una evaluación reproducible no es una compra única: es un control periódico sobre una decisión que depende de sistemas y condiciones que evolucionan.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.