Estrenas un modelo, resuelve algo que antes se atascaba y empiezas a confiar en él. Una semana después falla una tarea sencilla. Vuelves a intentarlo y la respuesta tampoco convence. La pregunta llega sola: ¿lo han empeorado desde el lanzamiento?
Una herramienta de IA puede rendir peor después de salir. Eso no demuestra, por sí solo, que su proveedor haya reducido deliberadamente la capacidad del modelo. Para entender lo que ocurre hay que separar el modelo, el software que lo utiliza y las condiciones de la prueba.
El vídeo de Devsplainers sobre los supuestos recortes de Claude y GPT plantea este debate a partir de los primeros seguimientos de Opus 5.5. Lo hemos usado como punto de partida y contrastado con documentación, protocolos de evaluación e incidentes reconocidos. Fuentes consultadas el 5 de octubre de 2026.
Qué significa que hayan «nerfeado» una IA
En videojuegos, un nerf reduce la potencia de una habilidad o un personaje. Aplicado a la IA, el término suele mezclar situaciones distintas: menos aciertos, respuestas más cortas, más rechazos, menos tiempo de razonamiento o un cambio de modelo.
Esa mezcla complica la discusión. Si un asistente entrega código que ya no pasa las pruebas, el problema es real para quien lo usa. Pero el fallo podría estar en las instrucciones de la aplicación, en el contexto que recibe o en una actualización del agente. La pérdida de utilidad y su causa son preguntas diferentes.
Conviene formular la sospecha con precisión: «antes resolvía estas tareas con esta configuración y ahora resuelve menos». Es una afirmación que se puede comprobar. «Todos los modelos se vuelven tontos a la semana» exige mucha más evidencia.
El modelo puede estar fijo mientras cambia el servicio
Los pesos son los valores que un modelo aprende durante el entrenamiento. Anthropic afirma que cada identificador de modelo fija una versión: los pesos se mantienen, aunque pueden cambiar el enrutamiento, los clasificadores de seguridad y la lógica de muestreo. Los alias de algunas generaciones anteriores tienen reglas distintas.
Por tanto, fijar el modelo ayuda, pero no congela toda la experiencia. Un chat o un agente añade instrucciones, herramientas y gestión del contexto. Si comparas dos versiones de Code, podrías estar midiendo también cambios en ese software.
Otro caso documentado es el fallback por rechazos de seguridad en la API de Claude. Cuando está configurado, una petición puede pasar a otro modelo; la respuesta identifica quién la atendió. No implica que todas las peticiones usen un modelo inferior ni que la saturación active ese mecanismo. Para investigar una caída, registra el modelo que respondió cuando esa información esté disponible.
Qué dicen los usuarios de Claude y qué puede medir LiveNerf
El 3 de octubre de 2026, Tony (@EnvolDev) publicó una comparación de escenas de la torre Eiffel generadas con Opus 5.5. Prefiere el resultado del lanzamiento: describe menos detalle en edificios, árboles y río, aunque ve una mejora en la torre. El propio autor advierte que un solo intento no demuestra un recorte. Es una experiencia individual útil para plantear una prueba, no una medición de la calidad general del modelo.
LiveNerf sigue Opus 5.5 mediante Code con una configuración fija. Su panel reúne 78 preguntas seleccionadas porque el modelo unas veces las acierta y otras no; las respuestas se corrigen sin un juez de IA.
El protocolo publicado antes de recoger la serie usa los primeros diez días como referencia. Exige una variación de al menos tres puntos y un intervalo del 99 % que excluya cero en las dos ventanas posteriores de diez días, además de comprobar un modelo de control. Es una forma de evitar que un mal día se convierta automáticamente en una acusación.
La ficha de evaluación acota el resultado: no representa todas las tareas, el chat web, las sesiones largas ni el uso de herramientas. Tampoco identifica la causa de una variación. «No detectado» significa que la prueba no lo ha encontrado dentro de su alcance y sensibilidad; no certifica que nada haya cambiado.
Con el protocolo consultado el 5 de octubre, todavía no corresponde presentar un veredicto completo de las dos ventanas posteriores. Una curva diaria o un hilo viral no sustituyen ese resultado. Y un buen resultado en este panel tampoco garantiza que tu flujo de programación siga igual.
Sí existen caídas de calidad documentadas
En su informe de septiembre de 2025, reconoció tres fallos de infraestructura que degradaron respuestas de : problemas de enrutamiento, corrupción de salida y selección de . La empresa atribuyó los incidentes a errores y negó recortes de calidad por demanda o carga. Hay evidencia de degradación; la explicación causal es la publicada por el proveedor.
también retiró una actualización de GPT-4o en abril de 2025 porque hacía demasiado complaciente. Darte la razón puede parecer agradable y ser un peor resultado si necesitas una crítica honesta. Una actualización puede empeorar un comportamiento sin que eso se traduzca en una caída uniforme de todas las capacidades.
Existe además seguimiento independiente. Marginlab documentó cinco días de resultados inferiores con Claude Code y Opus 4.7 en mayo de 2026. Su tabla vincula la caída y la recuperación con versiones del programa, y sus autores apuntan a un problema del agente. Es una interpretación compatible con sus observaciones, no una confirmación de ni una prueba de recorte intencionado.
La recuperación que muestra la tabla comienza el 27 de mayo, antes del estreno de Opus 4.8 el día 28. Esa diferencia importa al interpretar la caída. El anuncio de Marginlab en X, del 29 de mayo, lleva al análisis y a sus datos; la causa propuesta sigue siendo una hipótesis de sus autores.
Los tres casos muestran por qué merece la pena escuchar los avisos de usuarios y conservar registros. También muestran el riesgo de atribuirles la misma causa.
¿Por qué parece que ChatGPT va cada vez peor?
La pregunta «¿ChatGPT está empeorando?» suele juntar dos comparaciones: cómo responde hoy frente al lanzamiento y cómo responde al final de una conversación frente al principio. También conviene distinguir , la aplicación, del modelo GPT que atiende la petición. Los mecanismos de descritos arriba no deben trasladarse automáticamente a .
Una conversación larga introduce decisiones anteriores, correcciones y requisitos dispersos. La investigación LLMs Get Lost In Multi-Turn Conversation encontró una caída media del 39 % en seis tareas de generación al repartir instrucciones en varios turnos frente a plantearlas completas de una vez. Es el resultado de ese experimento, no un porcentaje aplicable a cualquier chat.
Antes de comparar con el estreno, prueba la tarea en una conversación nueva con el encargo completo. Si mejora, tienes una pista sobre el contexto. No has demostrado que el proveedor sea responsable de la diferencia.
También existe variación entre respuestas. Como ejemplo matemático, si cada intento tuviera un 10 % de probabilidad de fallar y los intentos fueran independientes, tres fallos seguidos tendrían una probabilidad del 0,1 %. Entre un millón de secuencias de tres intentos esperaríamos unas mil rachas así. Son supuestos ilustrativos, no mediciones de o GPT; en la práctica, las tareas y los fallos pueden estar relacionados.
La frustración merece atención aunque una racha sea posible. Lo que no permite es distinguir, sin más datos, entre azar, cambio de configuración y degradación del servicio.
Cómo comprobarlo en tu trabajo
No necesitas reproducir un laboratorio. Necesitas una comparación que puedas repetir y una respuesta clara a qué cuenta como fallo. Este sería un punto de partida práctico:
- Conserva 20–50 tareas representativas. Un cálculo con resultado conocido, una extracción con campos obligatorios o un cambio de código que deba pasar pruebas. Es una propuesta de trabajo, no un tamaño que garantice significación estadística.
- Fija las condiciones. Guarda el prompt completo, los archivos de entrada, el modelo solicitado, el esfuerzo de razonamiento y la versión de la aplicación. Usa sesiones nuevas para una prueba aislada; evalúa aparte las conversaciones largas si forman parte de tu trabajo.
- Define la corrección antes de ejecutar. «El código pasa estas pruebas» o «aparecen estos campos» permite comparar mejor que «la respuesta parece inteligente». Para escritura, usa criterios concretos y revisión humana sin conocer qué versión produjo cada texto, cuando sea posible.
- Repite y guarda las salidas. Registra fecha, aciertos, errores, tokens, duración, rechazos y modelo efectivo si el servicio lo expone. No añadas tareas más difíciles solo a la segunda tanda.
- Decide qué harás con una caída sostenida. Puedes revisar configuración, abrir una incidencia con ejemplos o usar una alternativa ya comprobada. Un umbral operativo ayuda a actuar, pero no demuestra por sí mismo una causa ni una intención.
Los tokens son una pista adicional, no una nota de inteligencia. Menos salida puede significar menos razonamiento, un texto más breve o una tarea diferente. Cruza ese dato con aciertos y configuración. Si comparas alternativas, el comparador de precios de IA de LetBrand ayuda a estimar costes; la calidad debes medirla con tus tareas.
En una extracción como esta, comprueba por separado que el JSON sea válido y que los campos coincidan con la entrada. Conserva el mismo documento y criterio en ambas tandas. El ejemplo muestra cómo definir la corrección; no es un resultado obtenido de ni de GPT.
Entonces, ¿se vuelven peores después de salir?
Pueden empeorar en determinadas tareas y hay incidentes documentados. La evidencia revisada no establece que todos los modelos sufran un recorte deliberado después del lanzamiento. Tampoco permite descartar cualquier cambio porque los pesos estén fijos: la herramienta que utilizas incluye más piezas.
Si hoy falla algo que ayer funcionaba, guarda ese ejemplo. Comprueba la configuración y repítelo con condiciones comparables. Esos registros sirven para exigir una explicación al proveedor y para decidir si el servicio sigue siendo útil para ti.