La filtración de Bug-Scope de Anthropic: un modelo que corrige un solo error y pregunta por la clase

La frase más interesante de la filtración actual de Anthropic no trata sobre inteligencia. Trata sobre alcance. Según un informe difundido en X el 19 de octubre de 2026, Anthropic está preparando un modelo que, cuando se le pide corregir un solo error, puede identificar la clase más amplia de problemas que hay detrás y luego preguntar si también debería abordarlos. Eso es una afirmación sobre dónde se detiene un modelo, no sobre lo bien que razona — y toca directamente la línea de fractura de cada agente de programación en producción, incluidos los que hoy se construyen sobre Claude Opus 5.5 y los que la gente ya supone que se ejecutarán sobre Claude Fable 5.5, el candidato no confirmado para el modelo que se describe. Anthropic no ha anunciado, nombrado ni fechado ningún modelo de ese tipo. No hay identificador, ni tarifario, ni ficha del modelo, ni evaluación. Todo lo que sigue sobre el comportamiento reportado es información no verificada y basada en una sola fuente, y todo lo que sigue sobre la línea actual proviene de la documentación propia de Anthropic.Los fallos documentados de la IA y los incidentes de agentes de programación que hay detrás de informes como este se recopilan en OrcaRouter AI Incident Archive, donde cada entrada incluye sus propias fuentes, gravedad, grado de confianza y marca de disputa.

La elección de palabras importa más de lo habitual en este caso, porque dos resúmenes del mismo informe describen dos comportamientos distintos. La que se lee como una especificación —un bug, la clase de bug que hay detrás, una pregunta sobre si ampliar la tarea— aparece en la retransmisión que nos llegó. La agregación pública del informe, leída el 19 de octubre, incluye una línea distinta: un modelo «con mejor intuición y razonamiento que puede discernir intenciones subyacentes y es mejor pensando fuera de lo convencional». No son la misma afirmación. Una se refiere a un modelo que propone más trabajo; la otra, a un modelo que interpreta lo que querías decir. Ambas pueden ser ciertas de un mismo modelo, pero solo una cambia cómo se ve un diff el lunes por la mañana, y esa es la que vale la pena desglosar.

Lo que la afirmación realmente dice, y lo que no

Despojado de adjetivos, el informe describe un comportamiento de tres pasos: se le da al modelo un defecto, este generaliza a partir de ese defecto hasta un patrón y le muestra el patrón al usuario en lugar de corregirlo en silencio. El tercer paso es el que convierte esto en una afirmación de diseño y no en una afirmación de benchmark. Un modelo que reparara silenciosamente cada instancia sería un agente autónomo con un radio de impacto ilimitado. Un modelo que encuentra el patrón y pregunta está proponiendo un cambio en el alcance de la tarea, algo que hace un ingeniero cuidadoso y algo que no debería permitirse que un agente descuidado hiciera unilateralmente.

Tampoco es una afirmación que nadie pueda evaluar todavía. No existe un conjunto de tareas público que mida «identificó la clase correctamente» frente a «inventó un patrón que no estaba ahí». Ambos comportamientos se ven idénticos en una transcripción: el modelo responde con una lista. Si la lista es una generalización genuina o una alucinación confiada solo se determina leyendo cada elemento, que es el trabajo que se suponía que el modelo te ahorraría.

Lo que el informe no dice es igual de importante. Ningún nombre de modelo. Ningún identificador de API. Ningún precio, ventana de contexto ni límite de salida. Ninguna indicación de si el comportamiento es predeterminado, un modo o algo que quien llama tiene que solicitar. Y ninguna confirmación por parte del proveedor de ningún tipo — la sala de prensa de Anthropic no ha publicado nada sobre un nuevo modelo desde Claude Haiku 5.5 el 7 de octubre de 2026, y la descripción general de modelos de Claude Platform sigue enumerando exactamente cuatro modelos: Claude Fable 5.1, Claude Opus 5.5, Claude Sonnet 5.5 y Claude Haiku 5.5.

Por qué «la clase más amplia» es una afirmación distinta de «un mejor razonamiento»

Un mejor razonamiento es la afirmación segura. Cada generación se describe así, se mide en índices públicos, y un sucesor con una puntuación más alta sería lo esperado, no una noticia. Generalizar a partir de una instancia es una operación distinta, y la razón por la que es interesante es que es el patrón de defectos reales más común en el software.

El ejemplo canónico es la inyección. Se reporta una consulta sin sanear en un manejador. La clase que hay detrás es cada uno de los demás manejadores que construyen una consulta de la misma manera. Una persona revisora que ha visto esto antes no arregla el único manejador y sigue adelante; busca el patrón con grep y luego se pregunta si la corrección pertenece a este ticket. Un modelo que hace lo mismo está realizando una revisión, no una reparación. La salida no es un parche, es un hallazgo — y los hallazgos solo son útiles si participa alguien con autoridad para ampliar el ticket.

• Lo que describe la afirmación: ante un defecto, identifique el patrón y plantéelo antes de actuar.

• Qué hace una corrección normal: cambia el código que señalaste y se detiene.

• Lo que hace un agente descuidado: modifica el código que le indicaste y luego sigue adelante, y la primera noticia que tienes de ello es el diff.

• Lo que el informe deja abierto: si «asks» significa una pregunta bloqueante en una sesión interactiva o una nota añadida a un cambio ya completado.

Esa última línea es donde la fuga deja de ser calificable. La diferencia entre esas dos lecturas es la diferencia entre una herramienta que respeta el control de cambios y una que documenta su propia expansión del alcance a posteriori.

La propia guía de Anthropic ya se sitúa en ambos lados de este asunto.

Esto es lo que hace que la afirmación sea creíble y no aleatoria. La guía publicada de Anthropic para Claude Code ya pide exactamente este instinto en un lugar y advierte contra él en otro, y los dos consejos están separados por un párrafo.

«Aborda las causas fundamentales, no los síntomas» es una de las estrategias documentadas en la guía de buenas prácticas de Claude Code, ilustrada con un fallo de compilación: corrige el error y verifica que la compilación se realice correctamente, y no suprimas el error. Se trata de una instrucción directa de mirar más allá de la instancia reportada. Unas secciones antes, la misma guía dice: «Delimita el alcance de la tarea. Especifica qué archivo, qué escenario y las preferencias de prueba», con el ejemplo de pedir una prueba que cubra un caso límite en lugar de pruebas en general. La razón dada es que Claude puede inferir la intención, pero no puede leer tu mente.

La guía también pone un límite según el tamaño del diff: el modo plan vale la pena cuando la sobrecarga está justificada, es decir, cuando un cambio afecta a varios archivos o el enfoque es incierto, y «si pudieras describir el diff en una sola frase, omite el plan». Un modelo que expande un bug a una clase está, por construcción, convirtiendo un diff de una frase en un plan. Así que el comportamiento que describe la filtración no es ajeno a la filosofía de producto de Anthropic: es el momento en que dos de sus principios declarados colisionan, y actualmente la colisión la resuelve el usuario, no el modelo.

Hay una segunda razón, menos cómoda, por la que la afirmación es plausible. La propia documentación de A​nthropic reconoce con franqueza que un modelo se detiene cuando el trabajo parece terminado, y que, sin algo que el modelo pueda ejecutar —una suite de pruebas, un código de salida de compilación, un diff contra un fixture—, «parece terminado» es la única señal disponible. Un modelo que generaliza a partir de un solo error hacia una clase es un modelo que ha encontrado una señal más allá de «parece terminado». Ese es el argumento más fuerte a favor de la capacidad y el argumento más fuerte para preguntar antes de actuar en consecuencia.

Dónde se toma realmente la decisión hoy

Lo útil de esta filtración es que los controles que necesitaría ya existen, y puedes inspeccionarlos sin esperar a un modelo. Tres de ellos importan.

• Esfuerzo — A{{1}}nthropic ofrece cinco niveles, desde bajo, pasando por medio y alto, hasta xhigh y max, y el ajuste determina cuánto trabajo realiza el modelo por sí solo. Claude Opus 5.5 y Claude Haiku 5.5 usan medio de forma predeterminada; los demás modelos actuales usan alto de forma predeterminada. El esfuerzo se aplica a todos los tokens de salida, incluidas las llamadas a herramientas, lo que significa que un modelo que amplía el alcance con esfuerzo alto es un modelo que amplía el alcance con una factura más elevada.

• Plan mode — Claude Code separa la exploración de la ejecución, y el umbral documentado para usarlo es precisamente el caso de varios archivos que implica una clase de error. El control no es un filtro sobre las ideas del modelo; es una etapa en la que llegas a ver el alcance ampliado antes de que se convierta en un diff.

• Compuertas deterministas: los hooks ejecutan una comprobación como script y pueden impedir que un turno termine hasta que pase. Es la única de las tres que no depende de que el modelo elija preguntar. Si el comportamiento reportado alguna vez llega a producción, la forma honesta de usarlo es detrás de una compuerta que tú hayas escrito, porque “{{1}}pregunta si debería abordarlos{{/1}}” es una promesa sobre el criterio de un modelo, y un hook de parada es una promesa sobre el tuyo.

Nada de eso es una crítica a la afirmación. Es la razón por la que la afirmación resulta interesante: un modelo que propone un alcance más amplio solo constituye una mejora si esa ampliación es visible antes de aplicarse, y todo mecanismo que la hace visible es algo que configura quien llama, no algo que el modelo garantice.

Cuánto costaría si funcionara

La expansión del alcance es el tipo más costoso de utilidad, porque multiplica la salida en lugar de la entrada. En la tarifa actual de Anthropic, Claude Fable 5.1 cuesta $10 por millón de tokens de entrada y $50 por millón de salida, mientras que Claude Opus 5.5 cuesta $4 y $20; además, la propia documentación de Anthropic dirige primero a los desarrolladores a Claude Opus 5.5 y solo pasa a Fable cuando las evaluaciones de Opus con mayor esfuerzo siguen sin ser suficientes. Un modelo cuyo argumento de venta es encontrar más trabajo que hacer va directamente en contra de ese consejo, ya que el nivel barato es aquel cuya salida quieres multiplicar y el nivel caro es aquel en el que un ticket ampliado es una partida presupuestaria.

Hay un coste de segundo orden que no aparece en la factura de tokens: la revisión. Un parche a una función se puede leer en un minuto. Un hallazgo que nombra otros nueve puntos de llamada tiene que verificarse elemento por elemento, y la verificación es el mismo trabajo que el modelo afirmaba eliminar. Eso no es un argumento en contra de la capacidad —un buen revisor con una lista de verificación es más rápido que uno sin ella—, pero sí significa que el valor depende de la precisión. Un modelo que muestra cinco instancias verdaderas y una inventada te ha costado el tiempo de refutar la inventada, y te ha enseñado a confiar un poco menos en la lista.

Qué puedes llamar hoy, y la respuesta honesta sobre este.

Nada nuevo. No hay ningún identificador del modelo en el informe, y nuestro propio catálogo es una buena prueba de ello: si le pedimos anthropic/claude-fable-5.5 devuelve model not found, y lo mismo ocurre con anthropic/claude-haiku-5.5. Esas cadenas no están entre los 209 modelos que enrutamos. Lo que sí se resuelve es la línea actual al precio de lista de Anthropic — anthropic/claude-opus-5.5 con una ventana de contexto de 1M de tokens, un límite de salida de 128K y 4 $ / 20 $ por millón, y anthropic/claude-fable-5.1 a 10 $ / 50 $. Cualquier plataforma que anuncie en este momento acceso al «nuevo modelo de caza de errores de Anthropic» está vendiendo un nombre.

La pregunta práctica que realmente tiene un lector no es cómo se llama el modelo. Es cómo averiguar si un modelo que amplía el alcance ayuda o perjudica en tu base de código sin apostar una ruta de producción a un rumor. Esa es una cuestión de enrutamiento, y es el único punto en el que una plataforma demuestra valer la pena: enviar una parte de las solicitudes al modelo no probado con un modelo que ya hayas medido como respaldo, para que una mala generalización te cueste una revisión y no un incidente. Los cambios de precios y los nuevos lanzamientos de Anthropic llegan a OrcaRouter el mismo día con un 0% de recargo, así que cuando aparezca una tarifa, el coste del experimento es el precio de lista y nada más. Puedes ver exactamente cuánto cuesta la cúspide actual de la gama en la página del modelo Claude Opus 5.5, y compararlo con la página de Claude Fable 5.1 antes de decidir a cuál debería recurrir por defecto tu carga de trabajo.

¿Qué cambiaría esta pieza?

Tres cosas, y la primera es la que lo resolvería más rápido.

Una frase de primera parte. Una sola línea en la documentación de Anthropic que describiera cuándo amplía el alcance el modelo, y si esa ampliación es la opción predeterminada o una opción que se debe aceptar explícitamente, convertiría toda la filtración en una especificación. La ausencia de esa línea es la razón por la que toda afirmación que se hace aquí tiene que matizarse.

Una evaluación publicada. «Encontró la clase» solo tiene sentido frente a «inventó la clase», y ningún proveedor publica un conjunto de tareas que separe ambas cosas. Hasta que exista uno —precisión y exhaustividad en la identificación de clases de defectos, puntuadas por alguien distinto del laboratorio—, una afirmación sobre la generalización a partir de un solo defecto es la descripción de una intención, no una capacidad que se pueda comparar entre modelos.

Un nombre y una tabla de tarifas, juntos. La convención de nomenclatura se ha mantenido estable en Fable 5, Fable 5.1, Opus 5.5, Sonnet 5.5 y Haiku 5.5, y el identificador lleva el nivel: un claude-fable-5-5 implicaría $10 / $50 y un claude-opus-5-6 implicaría $4 / $20. Una sola cadena en la descripción general de modelos resuelve la pregunta a la que la filtración dedica mil palabras.

Hasta entonces, la postura honesta es que, según los informes, un laboratorio de vanguardia está avanzando hacia un comportamiento sobre el que toda organización de ingeniería ya tiene una política, y nadie ha publicado esa política. Si un modelo debería corregir el error que reportaste, o el error que no sabías que tenías, no es una cuestión de capacidad. Es una cuestión de quién tiene el botón de merge, y la filtración —que dice que el modelo pregunta— es una respuesta más tranquilizadora que la que dan actualmente la mayoría de los agentes de programación, que es seguir adelante y dejar que el diff se explique por sí mismo.