Anthropic reduce en secreto el esfuerzo de Claude Code en una prueba A/B
Anthropic appears to be A/B testing reduced effort levels in Claude Code
Una publicación en X revela que Anthropic está realizando una prueba A/B en Claude Code, reduciendo la escala de esfuerzo en versiones 2.1.236 y superiores. El modelo ahora interpreta 'high' como 10 de 100, el valor que antes correspondía a 'low', sin que el changelog lo mencione. Los usuarios afectados notan un rendimiento inferior, pero el cambio es del lado del servidor y no afecta a versiones anteriores ni a Opus 5.
Desde la versión 2.1.237, el modelo lee el esfuerzo 'alto' como 10 de 100, el número exacto que solía tener 'bajo', y el changelog no dice ni una palabra.
- pizzafeelsright
Lo que sea que esté haciendo Opus 5 no debería pasar.
El prompt era "lee y actualiza el archivo de configuración con los nuevos datos". Este trabajo en 4.6 toma menos de 2 minutos para leer el archivo, parsear los nuevos datos y aplicar el parche.
Resultado de Opus 5: 43 minutos de descargar contenedores, ejecutar sandboxes, crear suites de pruebas, que incluían evaluar todo el repositorio más allá del alcance del archivo de configuración.
Ambos: una modificación de archivo.
- trq_
Hola a todos, soy Thariq del equipo de Claude Code. Publiqué esto en Twitter, pero lo repito aquí:
A veces probamos configuraciones de servidor de API en Claude Code antes de implementarlas, y una que está activa ahora mapea el valor numérico de esfuerzo de manera diferente.
Por eso Claude puede decirles a algunos de ustedes que está en "10" en alto. La escala no es 0-100, el número no es significativo por sí solo, y el esfuerzo que seleccionaste es el esfuerzo que estás obteniendo. Hemos ejecutado evaluaciones en profundidad para confirmar que esto no afecta el rendimiento del modelo.
Esta debería ser la misma experiencia, pero si ves una regresión clara, por favor usa /feedback y envíame el ID. Daré créditos.
- boredumb
No específicamente de Anthropic, pero ¿por qué permitimos que la facturación se realice en tokens que son nebulosos y totalmente controlados por los operadores que no tienen incentivos alineados?
Si tengo una entrada de usuario y luego la sanitizo y la inyecto en un prompt para hacer algo, no tengo idea de cuánto va a costar eso y no tengo una forma real de medirlo adecuadamente. Un ejemplo paralelo es Digital Ocean o AWS: puedo ir y medir/limitar mi cómputo, sistema de archivos, memoria, tiempos de inicio, etc., y aunque puede ser imposible llegar al último flop de dinero asignado, puedo ejecutar cosas con un presupuesto real y con restricciones reales, en contraste con un LLM donde tengo que... pre-ejecutar un prompt de usuario sanitizado a través de un tokenizador y luego pedirle a un LLM que adivine lo que puede hacer y dar estimaciones de consumo de tokens y luego actuar sobre ellas de manera sensata para el usuario.
Quizás me estoy perdiendo algo para hacer rieles realistas y estáticos, pero no veo una forma seria a escala de usar el modelo de facturación por tokens manejando cosas que requieren entrada de texto libre del usuario, aparte de tener que ir a mendigar dinero de capital de riesgo para tirar dinero hasta que alguien más lo resuelva.
*Para aclarar mi divagación...
Deberían facturarnos y darnos controles basados en el uso de recursos en sí, y no en un concepto opaco de tokens además de no poder girar ninguna perilla que controle su uso de recursos.
- hpone91
Actualización de Thariq en Twitter. https://x.com/trq212/status/2091247114869432543
"A veces probamos configuraciones de servidor de API en Claude Code antes de implementarlas, y una que está activa ahora mapea el valor numérico de esfuerzo de manera diferente.
Por eso Claude puede decirles a algunos de ustedes que está en '10' en alto. La escala no es 0-100, el número no es significativo por sí solo, y el esfuerzo que seleccionaste es el esfuerzo que estás obteniendo. Hemos ejecutado evaluaciones en profundidad para confirmar que esto no afecta el rendimiento del modelo.
Esta debería ser la misma experiencia, pero si ves una regresión clara, por favor usa /feedback y envíame el ID. Daré créditos."
- monideas
Este fenómeno fue tan malo y tan notable con Fable que degradé mi suscripción Max ($200) a Pro ($20). Es básicamente inútil. Codex 5.6 Sol es en realidad muy bueno, simplemente crearé otra cuenta para obtener más uso.
- Insimwytim
Los usuarios de LLM no quieren esforzarse, así que delegan tareas al LLM.
¡El LLM tampoco parece estar dispuesto a esforzarse!
¿Es esto AGI?
- N_Lens
Sospecho que no es solo esto; hay muchas 'optimizaciones' en torno a los límites de uso elásticos y al enrutamiento a un modelo diferente en el backend. Los incentivos son demasiado fuertes.
- ricardobeat
Uso Opus 5 casi exclusivamente con esfuerzo bajo y obtengo buenos resultados. Especialmente en alto parece irse por tangentes que no se le pidieron. Parece que lo mismo es cierto para Sonnet 5. Los modelos más antiguos no se comportaban así.
El cambio de humor en solo seis meses es salvaje; en febrero de este año Claude era el LLM más querido con diferencia.