El ajuste de “esfuerzo máximo” de Claude Opus 5 dispara el precio de una solicitud rutinaria de $0,76 a $19,21, ofreciendo esencialmente el mismo resultado funcional. El gasto adicional compra una pasada de auditoría interna, no una mejor solución, y solo muestra mejoras medibles en tareas que comienzan con una baja cobertura de pruebas.
Lo que mostró la prueba
El experimento comparó el nivel de esfuerzo predeterminado de Claude Opus 5 con el control de “esfuerzo máximo” en dos tipos de prompts: tareas de programación cotidianas y problemas deliberadamente difíciles.
- Para una tarea típica, la ejecución de bajo esfuerzo terminó en dos minutos y costó $0,76. Al subir el ajuste al máximo, la factura subió a $19,21; sin embargo, la puntuación de cobertura de requisitos —la métrica que el modelo reporta sobre qué tan bien cumplió con la instrucción— se mantuvo idéntica.
- La transcripción muestra un cambio de la creación a la revisión. El modelo dejó de generar código nuevo y comenzó a pulir lo que ya había escrito. Las ediciones superaron a las nuevas escrituras en una proporción de 2,4 a 1. Las llamadas a la herramienta “read” aumentaron dieciocho veces, y las invocaciones de la herramienta “bash” se multiplicaron por seis. En la práctica, el modelo volvió a leer módulos, volvió a ejecutar sus propias pruebas, realizó linting e incluso pruebas de mutación sin que se le pidiera.
El control de “esfuerzo máximo” no introduce un nuevo algoritmo; simplemente aumenta el presupuesto que el modelo puede gastar. Una vez que el presupuesto es lo suficientemente grande, el modelo cambia a un modo de autoauditoría, buscando cualquier ajuste en el que pueda justificar el gasto.
Por qué se dispara el coste
Cuando el modelo decide auditar, cada lectura o llamada a bash adicional se suma a la factura, y los efectos multiplicadores disparan rápidamente el coste total.
El modo de auditoría es una elección de diseño explícita. El modelo trata el presupuesto más amplio como un permiso para “buscar algo que valga la pena arreglar”. Si nada parece mejorable, el gasto extra no produce ningún beneficio funcional.
Cuándo tiene sentido un mayor esfuerzo
El modo de auditoría brilla solo cuando el resultado inicial deja margen de mejora. En un proyecto de Go con una cobertura de pruebas de 0,73, aumentar el esfuerzo al máximo elevó la cobertura a 0,88.
Por el contrario, una tarea de Python que ya había alcanzado una cobertura de 0,98 no experimentó cambios cuando se aumentó el presupuesto. El modelo simplemente volvió a comprobar el mismo código de alta calidad, inflando el coste sin añadir valor.
Posibles desventajas
- Descontrol presupuestario – Los usuarios acostumbrados al precio del nivel de bajo esfuerzo pueden sorprenderse por un aumento de veinticinco veces para el mismo entregable.
Guía práctica para desarrolladores
- Mantenga las solicitudes rutinarias en el nivel de esfuerzo predeterminado. Obtendrá el mismo resultado funcional por una fracción del precio.
- Reserve el “esfuerzo máximo” para el código que no cumpla con un umbral de calidad claro: baja cobertura de pruebas, advertencias de linting ausentes u otras brechas medibles.
- Trate el ajuste como un modo separado: una pasada de autorevisión opcional en lugar de un dial de velocidad para obtener mejores respuestas.
Conclusión
El interruptor de esfuerzo máximo de Claude Opus 5 cambia dinero por un control de calidad interno, no por un mejor código. Úselo con moderación, solo cuando sus resultados base dejen un vacío cuantificable que llenar; de lo contrario, el valor predeterminado económico ofrece el mismo resultado sin el precio del modo de auditoría.
Discusión de la comunidad: https://t.me/GyaanSetuAi