Modelos más potentes de Anthropic fallan más en herramientas, alerta desarrollador de Pi

Un hallazgo técnico detectado en Pi plantea una pregunta incómoda para la industria de IA: ¿qué pasa cuando los modelos más avanzados resuelven mejor una tarea, pero empeoran al usar herramientas externas? El caso apunta a Claude Opus 4.8 y Sonnet 5, que en ciertas condiciones inventan campos no permitidos y rompen llamadas de edición válidas.
***

• Armin Ronacher documentó que Claude Opus 4.8 y Sonnet 5 añaden claves inventadas dentro del arreglo anidado edits[] de una herramienta de edición usada por Pi.
• Las ediciones generadas eran correctas en su contenido, pero la llamada era rechazada porque los argumentos no coincidían con el esquema validado por el sistema.
• La hipótesis central es que el post-entrenamiento en entornos como Claude Code habría reforzado hábitos útiles para herramientas internas, pero problemáticos para esquemas alternativos.

Un problema detectado en Pi llevó a Armin Ronacher a una conclusión incómoda sobre el estado actual de los modelos de lenguaje con herramientas. Según explicó en Better Models: Worse Tools, los modelos más nuevos de Anthropic pueden ser peores que sus predecesores al respetar ciertos esquemas de invocación.

El fallo no apareció en modelos pequeños ni marginales. Ronacher señaló de forma explícita a Claude Opus 4.8 y Sonnet 5, mientras que dijo no haber visto el mismo comportamiento en modelos más antiguos de la misma familia.

El problema surgió en una herramienta de edición de archivos usada por Pi, que acepta múltiples reemplazos exactos de texto en una sola llamada. Esa herramienta utiliza un arreglo anidado llamado edits, donde cada objeto debe incluir únicamente oldText y newText.

En los casos fallidos, el modelo generaba una edición correcta pero añadía campos extra inventados dentro del objeto. Como el validador del sistema rechazaba cualquier clave no permitida, la llamada entera fallaba aunque el contenido principal fuera exacto.

Ese detalle es relevante para entender el alcance del hallazgo. No se trata de una edición equivocada en su lógica, sino de una ruptura en la capa que conecta al modelo con una herramienta externa.

Cómo se manifiesta la falla en las llamadas a herramientas

Ronacher recordó que las llamadas a herramientas de los LLM no son un mecanismo mágico o nativo. En la práctica, el modelo recibe una transcripción, un prompt de sistema y una lista de herramientas, y luego emite texto con una convención que el cliente o la API interpreta como una invocación.

Para una herramienta de edición, la carga útil esperada podría lucir como un objeto con una ruta de archivo y un arreglo de cambios. Dentro de ese arreglo, cada elemento debería limitarse al par oldText y newText.

Según el autor, en Anthropic ese formato probablemente se serializa con marcadores ANTML. También observó que los parámetros de cadena simples irían en línea, mientras que un arreglo de objetos se representaría mediante JSON embebido.

Ese diseño importa porque el modelo no solo debe entender el esquema. También debe producirlo con precisión token por token, incluso cuando el contenido incluye texto largo, multilínea y caracteres escapados.

Las llamadas fallidas examinadas incluían objetos como {"oldText":"...","newText":"...","requireUnique":true}. En otros casos, aparecían pares adicionales como oldText2 y newText2, que no estaban definidos por el esquema.

El repertorio de claves falsas fue amplio. Ronacher dijo haber visto nombres como type, id, kind, unique, requireUnique, matchCase, in_file, forceMatchCount, children, notes, cost, oldText2, newText2, oldText_2, newText_2 e incluso event.0.additionalProperties.

La parte más frustrante, según su descripción, fue que los valores reales de oldText y newText eran correctos a nivel de bytes. El modelo resolvía la edición y luego añadía “tonterías” al final del objeto.

Cuándo aparece y por qué no es un error trivial

La falla no se reprodujo de forma uniforme. Un prompt sencillo de un solo turno, como pedir una edición directa de un archivo, no generó el problema en sus pruebas.

En cambio, el comportamiento apareció en historias agentivas más largas. Es decir, en sesiones donde el modelo primero leía archivos, diagnosticaba un problema y luego preparaba una edición de varias líneas.

La dependencia del contexto hizo más difícil aislar el error. De hecho, Ronacher explicó que necesitó transcripciones compartidas por Petr Baudis para poder reproducirlo con consistencia.

Dentro de esa sesión concreta, continuar la conversación hacía que Opus 4.8 fallara alrededor del 20% de las veces. Ese dato es uno de los pocos porcentajes específicos ofrecidos en el análisis original.

El autor también observó que eliminar los bloques de pensamiento de la historia reducía la tasa de fallas aproximadamente a la mitad. Además, activar la invocación estricta de herramientas eliminó el problema en sus propias ejecuciones.

Ese último punto introduce una distinción clave para desarrolladores y operadores de agentes de IA. El comportamiento no parece ligado solamente a la comprensión semántica de la tarea, sino a cómo se fuerza o no se fuerza la forma exacta de la salida.

La hipótesis de fondo: entrenamiento en un arnés tolerante

La tesis central del texto es que esto no sería un deterioro aleatorio del modelo. Más bien, podría ser un subproducto del entrenamiento y post-entrenamiento en un entorno de herramientas muy específico.

Ronacher planteó que los modelos más modernos de Anthropic probablemente fueron reforzados con Claude Code o con un arnés muy parecido. Si ese entorno premia completar la tarea aunque la llamada llegue con pequeñas imperfecciones, el modelo puede aprender malos hábitos portables.

En esa hipótesis, una llamada a herramienta levemente mal formada aún sería aceptada, reparada o reinterpretada por el cliente. Como la tarea termina bien, habría poco gradiente de entrenamiento en contra de inventar alias, agregar campos extra o deformar un parámetro.

El problema se agrava porque la herramienta de edición de Claude Code sería más plana que la de Pi. En vez de un arreglo anidado edits[], se parecería más a campos como file_path, old_string, new_string y una bandera opcional como replace_all.

Desde esa perspectiva, un esquema alternativo puede quedar fuera de distribución aunque tenga la misma intención semántica. El modelo entiende que debe editar, pero arrastra una preferencia aprendida por una forma distinta de hacerlo.

Ronacher afirmó que este giro le preocupa porque hace unos meses su impresión era la contraria. Cuando se lanzó Opus 4.5, dijo que se adaptaba excepcionalmente bien a otras herramientas de edición.

Ahora teme que los esquemas alternativos no solo sean desconocidos, sino castigados de forma implícita por un post-entrenamiento optimizado para una ecología de herramientas concreta y permisiva. Y, remarcó, esa ecología no está documentada públicamente.

Qué revelaría Claude Code sobre la tolerancia al desorden

Aunque Claude Code es de código cerrado, Ronacher dijo haber inspeccionado código minificado para inferir parte de su comportamiento. Su conclusión fue que el cliente es notablemente indulgente con entradas imperfectas.

Según su descripción, Claude Code revisa incluso el texto visible del modelo en busca de marcado filtrado como <invoke>. Cuando lo detecta, emite telemetría y activa una máquina de estados propia para reintentar la llamada.

También tendría reparaciones explícitas para escapes Unicode rotos, incluidas secuencias uXXXX mal formadas y sustitutos solitarios en valores de cadena. Esas reparaciones no corrigen la inteligencia del modelo, pero sí amortiguan sus errores de formato.

El cliente además aceptaría alias por herramienta para varios parámetros. Ronacher mencionó ejemplos como old_str y old_string, new_str y new_string, así como path como alias de file_path.

Otra observación importante es que Claude Code filtraría en silencio claves inesperadas y no usaría modo strict. Eso convierte al arnés en una capa de absorción de errores, útil para la experiencia del usuario pero potencialmente problemática para el aprendizaje por refuerzo.

El propio Ronacher sugirió una razón práctica para esa decisión. Dijo que Anthropic impone límites de complejidad a las definiciones de herramientas con modo strict, lo que puede hacer que ciertas solicitudes de API fallen.

Strict mode, Harmony y el contraste con otros modelos

El artículo también comparó este comportamiento con otros enfoques de invocación de herramientas. Ronacher explicó que existen dos caminos generales: pedir al modelo que produzca JSON válido y validarlo después, o restringir el muestreo para impedir estructuras inválidas desde el inicio.

Ese segundo enfoque es conocido como decodificación restringida o consciente de la gramática. En teoría, si el esquema solo permite las claves oldText y newText, el muestreador no debería dejar pasar nombres como in_file o type.

El autor trajo a colación el formato Harmony de OpenAI, donde un marcador como <|constrain|>json puede indicar a la pila de inferencia que cambie a muestreo restringido para el cuerpo de la llamada. Ese detalle volvería más directa la aplicación de una gramática sobre la salida.

En el caso de Anthropic, Ronacher cree que algo similar podría existir al menos en modo strict. A su juicio, el hecho de que activar esa opción remedie la falla sugiere que el servidor deja de permitir claves no contempladas por el esquema JSON.

También ofreció una explicación puntual sobre el momento exacto en que surgiría el error. Dijo que las claves falsas aparecen en el punto de mayor entropía de la tarea, justo después de cerrar una cadena newText extensa y escapada, cuando el modelo debe decidir entre terminar el objeto o añadir otro campo.

Su intuición es que Opus 4.8 y Sonnet 5 aprendieron un prior fuerte sobre cómo luce una operación de edición, probablemente influido por el esquema de Claude Code. Bajo la forma anidada de Pi, el modelo sabría que “debería” existir un campo opcional, pero no tendría un nombre estable entrenado para él.

Por eso, en lugar de repetir siempre el mismo alias, produciría nombres plausibles y diferentes en cada ocasión. Ronacher añadió que, hasta el momento de escribir su texto, los modelos Codex que probó no mostraban esa regresión, salvo la versión 5.6, a la que aún no tenía acceso.

Implicaciones para desarrolladores, agentes y productos de IA

La conclusión más amplia del análisis es que los esquemas de herramientas no serían neutros para todos los modelos. Un contrato formal puede parecer abstracto para el desarrollador, pero en la práctica algunas formas están más cerca de la distribución de entrenamiento que otras.

Eso introduce una restricción importante para quienes construyen agentes, asistentes de programación o automatizaciones empresariales. No basta con definir un esquema correcto, porque la facilidad de uso por parte del modelo depende de cómo fue condicionado durante el post-entrenamiento.

Ronacher admitió que antes era más escéptico respecto de la invocación de herramientas con restricciones gramaticales estrictas. Aun así, dijo que este error movió sus priors de forma significativa.

Su razonamiento es práctico. Si los modelos más nuevos mejoran al resolver la tarea, pero empeoran al emitir con fidelidad un esquema alternativo, entonces el arnés necesita garantías adicionales en algún lugar.

En otras palabras, confiar solo en la “inteligencia general” del modelo puede dejar expuestos a los productos a fallas difíciles de depurar. Ese riesgo aumenta cuando el proveedor no documenta el entorno real donde entrenó el uso de herramientas.

Para el ecosistema de IA aplicada, el caso deja una advertencia clara. Cuanto más domine un arnés específico en el post-entrenamiento, más probable es que otros entornos hereden de forma indirecta sus sesgos, tolerancias y rarezas.

Ronacher cerró invitando a revisar el issue correspondiente en el tracker de Pi para profundizar o discutir el tema. Más allá del bug puntual, su análisis abre una pregunta estratégica para toda la industria: si los modelos cerrados aprenden a trabajar bien solo con las herramientas de casa, la interoperabilidad real puede terminar siendo más frágil de lo que muchos asumían.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín