En el benchmark diario de SWE-Bench-Pro (conjunto curado), al ver claude code se nota algo interesante
En el tramo del 10/4 al 20/4, el runtime se redujo a la mitad (653 s→345 s), las tool calls también a la mitad (3.3K→1.8K) y los tokens bajaron un 18%, pero la pass rate más bien subió +16 pp. No es un patrón común que las cuatro métricas se muevan al mismo tiempo en una dirección favorable
Los 3 incidentes que explotaron en ese proceso son el postmortem del 23/4, y si los ves, todos pasaron por “intentar reducir tokens/latency”
En cambio, codex (gpt-5.4-xhigh) casi no se movió en el mismo período. La pass rate se mantuvo fija cerca del 56%, y los tokens/runtime/tool calls siguieron en un nivel que es el doble del de claude code
Aunque nadie lo use, sigo desarrollando con ganas por mi cuenta mi librería npm de compañía, y la estoy optimizando en rendimiento.
La hipótesis que se me había ocurrido terminó siendo que casi ninguna funciona después de correr los benchmarks, así que voy a intentar sacar con esto algunas medidas adicionales de optimización de rendimiento.
¿Cómo es que las tres causas de la falla están todas directamente relacionadas con recortar costos? jajajaja
Parece que de verdad andan muy, muy cortos de recursos de GPU como para que el rendimiento baje así de tanto...
En cuanto aplicaron el parche, la cuota de 5 horas que antes tardaba 3-4 horas en agotarse empezó a consumirse en solo 30 minutos; pero como las cuentas de empleados no tienen cuota de 5 horas, o al menos no es tan limitada como para tener que trabajar mirando /usage a cada rato, seguro que tardaron bastante en detectarlo.
Vaya... no sabía que hasta la cuenta oficial del equipo se iba a poner a bromear. Quisiera borrarlo, pero no puedo... así que al menos te daré un upvote... T_T
Si lo usas por solo 2 horas, te vas a volver daltónico.
Algo como un abogado del diablo sería cómodo si lo dejas configurado con una función como Gems de Gemini.
En el benchmark diario de SWE-Bench-Pro (conjunto curado), al ver claude code se nota algo interesante
En el tramo del 10/4 al 20/4, el runtime se redujo a la mitad (653 s→345 s), las tool calls también a la mitad (3.3K→1.8K) y los tokens bajaron un 18%, pero la pass rate más bien subió +16 pp. No es un patrón común que las cuatro métricas se muevan al mismo tiempo en una dirección favorable
Los 3 incidentes que explotaron en ese proceso son el postmortem del 23/4, y si los ves, todos pasaron por “intentar reducir tokens/latency”
En cambio, codex (gpt-5.4-xhigh) casi no se movió en el mismo período. La pass rate se mantuvo fija cerca del 56%, y los tokens/runtime/tool calls siguieron en un nivel que es el doble del de claude code
Aunque nadie lo use, sigo desarrollando con ganas por mi cuenta mi librería npm de compañía, y la estoy optimizando en rendimiento.
La hipótesis que se me había ocurrido terminó siendo que casi ninguna funciona después de correr los benchmarks, así que voy a intentar sacar con esto algunas medidas adicionales de optimización de rendimiento.
Más que “debería”, sería algo como “sería mejor que lo hiciera”, ¿no?
También sentí que la usabilidad de la web de claude.ai se degradó un poco en varios detalles... hasta apagué la memoria para ahorrar tokens.
Siento que, después de ver este anuncio, confío todavía menos en Anthropic.
Arriba hay dos publicaciones relacionadas, y son dos textos con 7 meses de diferencia. Los problemas son exactamente los mismos, tres en cada caso.
Postmortem de tres problemas recientes de degradación de calidad en Claude 2025-09-19
Actualización sobre reportes recientes de calidad de Claude Code 2026-04-24
¿No será más bien un post mortem de reducción de costos en lugar de un post mortem de una caída del servicio?
Esa es la respuesta correcta, pero qué larga la excusa jajaja
¡¡Estoy enojado hasta por $5 de crédito!!
Opus 4.6...
Es el típico código de boquilla.
¿Cómo es que las tres causas de la falla están todas directamente relacionadas con recortar costos? jajajaja
Parece que de verdad andan muy, muy cortos de recursos de GPU como para que el rendimiento baje así de tanto...
Obligar al personal interno a usar la compilación pública real reduce la discrepancia con las compilaciones para pruebas internas.
jajajaja
Hace mucho que dejó de ocupar el lugar de SOTA..
La herramienta usada en el video: https://www.conductor.build/
En cuanto aplicaron el parche, la cuota de 5 horas que antes tardaba 3-4 horas en agotarse empezó a consumirse en solo 30 minutos; pero como las cuentas de empleados no tienen cuota de 5 horas, o al menos no es tan limitada como para tener que trabajar mirando
/usagea cada rato, seguro que tardaron bastante en detectarlo.Qué lengua tan larga..
Tengo expectativas... ojalá vuelva a recuperar el lugar de SOTA y se arme un panorama competitivo de nuevo..
Vaya... no sabía que hasta la cuenta oficial del equipo se iba a poner a bromear. Quisiera borrarlo, pero no puedo... así que al menos te daré un upvote... T_T