La propia guía de migración de Anthropic te dice que elimines las instrucciones de verificación que llevas dos años escribiendo.
Ocho cambios de comportamiento, una nueva guía de prompting y la silenciosa llegada de capas de orquestación con fecha de caducidad.
La frase más extraña del lanzamiento de ayer no está en la página de precios ni en el gráfico de benchmarks. Está escondida en un documento de migración y te dice, literalmente, que elimines parte de tu propio trabajo: quita las instrucciones de verificación y autocomprobación heredadas de modelos anteriores, porque provocan una verificación excesiva en Claude Opus 5.
Vuelve a leerlo con tus prompts de producción abiertos.
La línea «incluye un paso final de verificación», que hacía que Opus 4.8 resultara confiable, ahora se convierte en un centro de coste.
La instrucción «sé conservador y reporta únicamente problemas de alta gravedad» dentro de tu prompt de revisión de código ahora puede hacer que el modelo reporte menos problemas.
Y el nivel de effort que utilizabas para acortar las respuestas ya no necesariamente las acorta.
Nadie quiere tocar una biblioteca de prompts heredada.
Esta es la que Anthropic acaba de dejar obsoleta.
Foto de Sally Crierie en Unsplash.
¿Qué te pidió realmente Anthropic que eliminaras?
Dos documentos contienen prácticamente toda la historia, y ninguno recibió demasiada atención durante el lanzamiento.
La sección dedicada a Opus 5 dentro de la guía de migración parece una lista de cosas que debes quitar. Y la guía de prompting, publicada esa misma mañana, es uno de los documentos específicos sobre comportamiento de modelos más extensos que Anthropic ha publicado.
Casi todas sus secciones describen algo que el modelo ahora hace por sí solo.
Si colocas ambos documentos uno al lado del otro, aparecen ocho cambios de comportamiento.
Los ocho están verificados utilizando documentación oficial, no deducidos a partir de impresiones, y pueden organizarse claramente en tres grandes grupos.
Cosas que el modelo ahora hace sin que se lo pidas, así que puedes eliminar la instrucción
Verificación.
Autocorrección.
Narración del progreso.
Cada una de estas tareas tenía un patrón de prompting que hace ocho meses podía considerarse una buena práctica y que ahora puede convertirse simplemente en consumo innecesario de tokens.
Cosas que el modelo ahora hace demasiado, así que debes limitarlas
Alcance de las tareas.
Delegación a subagentes.
Conservadurismo en las revisiones de código.
Cada una necesita ahora una nueva instrucción que probablemente no exista en tu biblioteca actual, porque ese comportamiento antes no formaba parte del modelo.
Controles que se han desacoplado y necesitan volver a ajustarse
El nivel de effort ya no controla la longitud de la respuesta.
Los niveles de effort fueron recalibrados, por lo que reutilizar una configuración anterior es incorrecto por definición.
Y el razonamiento, que ahora está activado de forma predeterminada, puede producir nuevos artefactos de salida cuando decides desactivarlo.
Esto es lo que hace que esta migración sea diferente de prácticamente todas las notas de migración de modelos anteriores.
Antes te decían que cambiaras un parámetro.
Esta vez te están diciendo que cambies tu propio criterio sobre cómo debe ser un buen prompt.
¿Qué hace ahora el modelo sin necesidad de que se lo pidas?
Empecemos por el cambio que probablemente pueda ahorrarte más dinero.
Opus 5 verifica su propio trabajo sin necesidad de que se lo indiques, y la guía de prompting es bastante clara sobre las consecuencias.
Instrucciones como «incluye un paso final de verificación para cualquier tarea que no sea trivial» o «utiliza un subagente para verificar el resultado» pueden provocar una verificación excesiva.
Eliminarlas reduce el gasto innecesario de tokens sin que se produzca una pérdida de calidad. Esto está verificado.
La guía extiende exactamente la misma recomendación a lo que denomina legacy harness scaffolding: el andamiaje heredado dentro de la capa de orquestación.
Es decir, no se refiere únicamente a lo que escribiste dentro del prompt. También incluye pasos independientes de verificación que hayas incorporado en la lógica de orquestación de tu sistema.
La autocorrección entra en la misma categoría.
El modelo detecta y corrige sus propios errores, de modo que instrucciones como «comprueba nuevamente tu respuesta» o «vuelve a verificar antes de responder» se acumulan sobre un comportamiento que ya está ocurriendo.
El resultado puede ser más coste sin una mejora real de la respuesta. También está verificado.
Ahora viene la parte que convierte este consejo en un argumento mucho más serio.
La propia system card de Anthropic documenta qué ocurre cuando la autoverificación funciona sin límites a gran escala.
Durante tareas abiertas de investigación biológica, Opus 5 llegó a quedarse atrapado verificando repetidamente su propio trabajo y terminó abandonando campañas de diseño de proteínas de 24 horas a mitad de ejecución. Está verificado.
Es decir, el propio proveedor está describiendo a su modelo estrella fallando por verificar demasiado.
Si tu prompt le dice que verifique todavía más, estás empujándolo justamente en la dirección de ese fallo.
La narración del progreso completa esta primera familia de cambios.
El modelo tiende a explicar con facilidad lo que está haciendo durante trabajos agénticos. Anuncia qué está a punto de hacer y, durante sesiones con agentes, genera más contenido por mensaje que modelos anteriores. Esto también está verificado.
Si tu capa de orquestación contiene una regla como «después de cada tres llamadas a herramientas, resume el progreso», ese andamiaje puede haberse vuelto redundante frente al comportamiento incorporado en el propio modelo.
Piensa en el prompt de un agente como si fuera el conjunto de instrucciones permanentes que entregas a una nueva persona que entra a trabajar en tu equipo.
Opus 5 llegó haciendo ya por sí solo tres de las cosas que tus instrucciones permanentes siguen exigiéndole.
De pronto, esas órdenes empiezan a parecer insistencia innecesaria.
El modelo las cumple, porque está entrenado para hacerlo.
Y tú terminas pagando dos veces por el mismo comportamiento.
Si solo recuerdas una cosa de esta sección, que sea esta:
Cada instrucción del tipo «verifica tu trabajo» dentro de tu biblioteca puede haberse convertido ahora en una factura, no en una medida de seguridad.
¿Qué hace ahora demasiado?
La segunda familia de cambios es más complicada, porque exige instrucciones que probablemente nunca habías necesitado escribir.
Opus 5 puede ampliar el alcance de una tarea.
Puede añadir pasos que no fueron solicitados y aplicar su propio criterio sobre lo que considera que debería incluir la tarea. Esto está verificado.
La solución recomendada en la guía de prompting es introducir explícitamente disciplina sobre el alcance.
Entrega exactamente lo que se solicitó y con el alcance previsto.
Toma por tu cuenta las decisiones rutinarias necesarias.
Si consideras que la solicitud contiene un posible error, indícalo brevemente.
Y después continúa realizando la tarea solicitada en lugar de ampliarla silenciosamente.
Puedes observar ese mismo comportamiento en algunas de las declaraciones utilizadas durante el lanzamiento, aunque allí aparece presentado como una ventaja.
Un ingeniero principal de uno de los clientes que tuvo acceso anticipado describe cómo el modelo cuestionó un diseño propuesto y mantuvo su objeción incluso después de que él insistiera.
Finalmente, el modelo redujo su objeción a una única pregunta y propuso una solución intermedia. Esta información procede del proveedor.
El criterio propio y la expansión del alcance son dos caras del mismo comportamiento.
Una puede mejorar tu producto.
La otra puede terminar reescribiendo tu ticket.
La delegación es el segundo punto, y su evolución resulta especialmente reveladora.
Opus 4.7 generaba menos subagentes que Opus 4.6.
Opus 5, en cambio, vuelve a delegar con más facilidad que modelos anteriores.
Ambos comportamientos están verificados.
La recomendación cambió de dirección dos veces en aproximadamente ocho meses.
Ahora la solución consiste en indicar explícitamente en qué escenarios está justificada la delegación o establecer un límite determinista sobre cuántos agentes pueden lanzarse.
El tercer punto es uno que yo pondría en la pared de cualquier equipo que trabaje con revisiones automáticas de código.
Si tu prompt de revisión dice «reporta únicamente problemas de alta gravedad» o «sé conservador», Opus 5 puede seguir esa instrucción literalmente y reportar menos problemas.
Esto está verificado.
La recomendación de Anthropic es pedirle que reporte todo lo que encuentre y realizar el filtrado en una segunda pasada.
Detente un momento a pensar en lo que acaba de ocurrir.
La instrucción original se escribió para reducir falsos positivos en un modelo que generaba demasiados.
El nuevo modelo encuentra errores reales con una tasa elevada y produce pocos falsos positivos.
Por lo tanto, esa misma instrucción ahora puede estar suprimiendo descubrimientos que sí querías recibir.
Tu prompt defensivo se convirtió en el problema.
Y probablemente nada dentro de tu suite de pruebas te avisará, porque una revisión que simplemente reporta menos resultados puede seguir pasando todos tus tests.
¿Qué controles dejaron de significar lo mismo?
El parámetro effort es uno de los lugares donde reutilizar configuraciones anteriores puede provocar errores silenciosos.
Para Opus 4.7 y Opus 4.8, la recomendación de Anthropic era comenzar utilizando xhigh en tareas de programación y trabajos agénticos.
Para Opus 5, la recomendación es comenzar en high, que además es el valor predeterminado, y utilizar low y medium con mucha más libertad como controles principales del coste de tokens y del tiempo de respuesta siempre que tus evaluaciones indiquen que la calidad se mantiene.
Esto está verificado.
El punto de partida recomendado bajó un nivel en una sola generación.
Si eso fuera todo, simplemente estaríamos hablando de ajustar una configuración.
Pero aquí aparece la verdadera tarea de migración.
La cantidad de tokens asignada internamente a cada nivel de effort cambia en Opus 5. También está verificado.
La etiqueta permaneció.
Su significado interno cambió.
Una carga de trabajo configurada en xhigh porque una evaluación realizada con Opus 4.8 indicaba que era la mejor opción ahora está ejecutándose con una configuración que nunca has probado, aunque el nombre te resulte familiar.
Por eso la documentación recomienda realizar una nueva evaluación completa en lugar de reutilizar directamente la configuración anterior.
Hay otros dos detalles más pequeños que también merece la pena tener presentes.
Configurar effort como high es exactamente equivalente a no enviar el parámetro. Está verificado.
Eso significa que buena parte de las configuraciones explícitas de effort que probablemente existen en muchas bases de código no están haciendo nada.
Además, cambiar el nivel de effort entre solicitudes no conserva los prefijos almacenados en caché.
Por eso la documentación establece ahora una recomendación clara: elige un nivel al inicio de una sesión con caché y mantenlo constante durante esa sesión.
Esto también está verificado.
Después tenemos un control que directamente dejó de hacer lo que muchas personas creían que hacía.
El effort controla el volumen de razonamiento, no la longitud visible de la respuesta.
En Opus 5, reducir el effort no reduce de forma confiable la extensión de la respuesta. Está verificado.
Si estabas utilizando effort como control de verbosidad, ya no puedes confiar en ese comportamiento.
La sustitución es una instrucción explícita sobre la longitud.
En realidad, necesitas dos.
Las respuestas visibles para el usuario son, por defecto, más extensas que en modelos Opus anteriores.
Y, de forma independiente, los archivos que el modelo escribe en disco también tienden a ser más largos.
Ambos comportamientos están verificados.
La verbosidad de una conversación y la longitud de un entregable escrito pasan a ser dos instrucciones distintas, no una sola.
El último elemento de esta lista es una auténtica trampilla.
El razonamiento está activado de forma predeterminada en Opus 5 y solo puede desactivarse cuando el effort está configurado en high o en un nivel inferior.
Combinar razonamiento desactivado con xhigh o max devuelve un error 400.
Esto se valida de manera independiente en cada solicitud y está verificado.
Si decides desactivar el razonamiento, pueden aparecer dos tipos de artefactos.
El modelo puede escribir una llamada a una herramienta como texto visible en lugar de emitir una llamada estructurada.
En ese caso, la herramienta nunca se ejecuta y el texto filtrado permanece dentro del historial de la conversación, contaminando potencialmente los turnos posteriores.
También puede ocurrir que etiquetas internas aparezcan directamente en la respuesta visible.
Ambos comportamientos están verificados.
La mitigación es bastante contraintuitiva.
Una regla dentro del prompt de sistema que indique al modelo que «no piense» puede aumentar la filtración de etiquetas internas.
Además, las instrucciones que mencionan específicamente los nombres de esas etiquetas son menos eficaces que una instrucción general que prohíba mostrar etiquetas internas.
Esto está verificado.
La propia recomendación de Anthropic es dejar de desactivar el razonamiento y utilizar effort bajo en su lugar, porque el razonamiento activado con effort bajo obtiene mejores resultados que el razonamiento desactivado con un coste similar.
Si recuerdas una sola cosa de esta sección, que sea esta:
La etiqueta de effort sobrevivió a la actualización.
La calibración que existe detrás de esa etiqueta no.
Y ningún error te avisará.
¿Qué puede romperse en producción si ignoras todo esto?
Nada de lo anterior necesariamente genera una excepción.
Y esa es precisamente la característica operativa más peligrosa de esta migración.
Todos estos modos de fallo pueden ser silenciosos, caros y capaces de superar tus pruebas.
La verificación excesiva puede parecer simplemente una factura un poco más grande.
La expansión del alcance puede parecer que el modelo está intentando ayudarte.
Una revisión de código que está suprimiendo hallazgos puede parecer simplemente que tu base de código está muy limpia.
Hay tres métricas que deberían estar en algún dashboard durante esta semana.
La primera es tokens por tarea completada, no tokens por solicitud.
La verificación excesiva y la delegación agresiva inflan todo el bucle de ejecución, no necesariamente cada turno individual.
La segunda es el número de subagentes lanzados.
El comportamiento predeterminado de delegación cambió, y un límite solo existe si tú lo configuraste.
La tercera es la cantidad de hallazgos detectados por cada pasada de revisión antes y después de modificar tus prompts.
Esa puede ser la única forma de descubrir que la lógica de tu revisión se ha invertido.
Existe además un cuarto punto que no tiene que ver directamente con el comportamiento del modelo, pero podría arruinarle la semana a más de un equipo.
Opus 5 presenta dos regresiones funcionales frente a Opus 4.8:
web fetch no está disponible.
Y Priority Tier tampoco está soportado.
Ambos puntos están verificados.
La propia lista de migración de Anthropic indica que, si tu organización tiene un compromiso relacionado con Priority Tier, debes planificar la capacidad de forma independiente, porque Opus 4.8 todavía conserva esa funcionalidad.
El modelo del que te están recomendando migrar es, al mismo tiempo, el que mantiene tu garantía de capacidad.
Existe además un dato relacionado con cumplimiento que puede decidir qué modelo utilizar incluso antes de abrir cualquier benchmark.
Fable 5 y Mythos 5 requieren una retención de datos de 30 días, están clasificados como Covered Models y no están disponibles bajo configuraciones de retención cero de datos.
Una solicitud a Fable 5 realizada desde una organización cuya configuración de retención no cumpla ese requisito devuelve un error 400.
Esto está verificado.
Opus 5, en cambio, no exige un requisito general de retención de datos para poder acceder al modelo. Esta información procede del proveedor.
Para una empresa regulada, esto deja de ser una comparación de precios.
Fable no es caro.
Simplemente puede ser inaccesible.
Opus 5 se convierte en el primer modelo de ese nivel de capacidad que determinadas organizaciones pueden utilizar realmente.
Eso cambia por completo el argumento de «capacidad cercana a la frontera por la mitad del precio» para cualquier empresa que opere bajo una política de retención cero de datos.
¿Por qué la capa de orquestación está ahora acoplada a la versión del modelo?
Aléjate un poco de estos ocho cambios y observa el patrón.
Anthropic no se limitó a lanzar un modelo mejor.
También publicó un documento que te explica cuáles de tus propios artefactos de ingeniería dejan de tener sentido con ese nuevo modelo.
Y todos esos artefactos viven en la capa de orquestación:
Prompts.
Andamiaje.
Pasos de verificación.
Políticas de delegación.
Configuraciones de effort.
Sigue un único comportamiento a través de tres versiones y el patrón resulta difícil de ignorar.
La delegación a subagentes disminuyó de Opus 4.6 a Opus 4.7.
Después volvió a aumentar de Opus 4.7 a Opus 5.
La recomendación sobre effort pasó de utilizar xhigh como punto de partida en 4.7 y 4.8 a comenzar en high en Opus 5.
Además, las asignaciones internas de tokens fueron recalibradas.
La longitud de las respuestas cambió en Opus 4.7.
Después volvió a cambiar en Opus 5 y, además, quedó desacoplada del effort.
Un harness o capa de orquestación optimizada específicamente para cualquiera de esos puntos puede quedar mal ajustada en la siguiente versión.
La admisión más clara de este problema probablemente sea una herramienta.
Anthropic lanzó una skill de Claude Code específicamente para realizar esta migración.
Ejecutas un comando y la herramienta aplica el cambio del identificador del modelo, modifica los parámetros incompatibles, sustituye configuraciones de prefill y ajusta la calibración del effort a lo largo de tu base de código.
Después te entrega una lista de elementos que debes verificar manualmente.
Esto está verificado.
No construyes un agente para realizar tu propia migración a menos que esperes que esa migración sea suficientemente grande y que tenga que repetirse.
Aquí aparece la lectura incómoda para cualquiera que, como yo, esté convencida de que la ventaja duradera de un sistema de IA vive en su capa de orquestación y no únicamente en los pesos del modelo.
Sigo creyendo que es así.
Pero esa capa de orquestación ahora tiene un problema de acoplamiento con la versión que los propios pesos del modelo no tienen.
Cada mejora de comportamiento incorporada al modelo elimina algún patrón compensatorio que antes habías añadido a tu infraestructura.
Los equipos que ganen durante el próximo año probablemente no serán aquellos que tengan la capa de orquestación más elaborada.
Serán aquellos capaces de simplificarla más rápido cuando el propio modelo absorba una de sus capas.
Trata tu biblioteca de prompts como una dependencia que tiene su propio calendario de versiones.
Porque eso es exactamente en lo que se ha convertido.
Fíjala.
Versiona los cambios.
Compárala con las notas de comportamiento del proveedor cada vez que cambies de modelo.
Y reserva presupuesto y tiempo para realizar nuevas evaluaciones exactamente igual que lo harías al actualizar un framework.
El briefing del lunes
Esto es lo que debes decirle a tu equipo, en el mismo orden en que probablemente te lo preguntará.
Elimina
Busca en toda la biblioteca de prompts instrucciones relacionadas con verificación, autocomprobación, volver a verificar y resúmenes obligatorios de progreso.
Elimínalas de los flujos que utilicen Opus 5.
Revisa también la capa de orquestación, no únicamente las cadenas de texto de tus prompts.
Los pasos independientes de verificación implementados dentro de la orquestación también cuentan.
Limita
Añade instrucciones explícitas sobre el alcance para tareas que deben permanecer acotadas.
Define una política clara de delegación o establece un límite estricto sobre el número de subagentes que pueden lanzarse.
Reescribe los prompts conservadores utilizados en revisiones de código.
Pide al modelo que reporte todo y filtra los resultados en una segunda pasada.
Recalibra
Ejecuta una evaluación completamente nueva de los niveles de effort en lugar de reutilizar configuraciones anteriores.
Añade instrucciones explícitas sobre la longitud de las respuestas de chat y utiliza una instrucción diferente para los entregables escritos.
Audita cualquier solicitud que desactive el razonamiento, porque desactivar el razonamiento utilizando xhigh o max ahora devuelve un error 400.
Vuelve a establecer tu línea base
Mide tokens por tarea completada antes y después de realizar los cambios.
No te limites a medir tokens por solicitud.
Después comprueba si Priority Tier o web fetch aparecen en alguna de las cargas de trabajo que estabas a punto de migrar.
Preguntas frecuentes
¿Debería reescribir mis prompts hoy mismo?
Primero elimina antes de reescribir.
Quitar las instrucciones de verificación y autocomprobación es el cambio de menor riesgo de toda la lista.
Es una recomendación directa de Anthropic y puede reducir inmediatamente el consumo de tokens.
Guarda las nuevas instrucciones relacionadas con alcance y delegación para después de haber medido una línea base.
Esas instrucciones añaden complejidad y merecen estar respaldadas por evidencia.
¿Se aplica todo esto también a Sonnet 5?
No directamente.
Cada nota de comportamiento incluida en este artículo procede específicamente de documentación relacionada con Opus 5.
Además, ambos modelos presentan diferencias importantes.
Sonnet 5 permite utilizar razonamiento desactivado con cualquier nivel de effort.
No admite mensajes de sistema en mitad de una conversación.
Y sigue teniendo web fetch.
Consulta siempre la documentación específica de tu modelo en lugar de generalizar el comportamiento de otro.
Esa es, precisamente, una de las principales lecciones de todo este artículo.
¿Qué deberían modificar primero quienes utilizan Claude Code?
La misma lista de elementos que debes eliminar, pero aplicada a las instrucciones de tu proyecto en lugar de únicamente a los prompts de API.
Anthropic incluye una herramienta de migración dentro de Claude Code que gestiona los cambios de identificador del modelo, modificaciones incompatibles de parámetros y recalibración del effort a lo largo de una base de código.
Después devuelve una lista de comprobaciones manuales.
Empieza por ahí.
Pero considera esa lista como el comienzo del trabajo, no como el final.
Recapitulación y un experimento
Hay tres ideas que merece la pena conservar.
La primera es que Opus 5 llegó acompañado de una lista de instrucciones tuyas que ahora debes eliminar.
La más importante está relacionada con la verificación.
El modelo ahora verifica por sí mismo y la propia system card documenta situaciones en las que termina verificando demasiado.
La segunda es que los comportamientos que cambiaron de dirección —delegación, calibración del effort y control de longitud— pertenecen todos a la capa de orquestación.
Eso significa que tu harness está acoplado a la versión del modelo de una manera que fijar simplemente el identificador del modelo no puede proteger.
La tercera es que prácticamente todos los fallos asociados con esta migración son silenciosos.
No necesariamente tendrás una excepción.
No necesariamente aumentará tu tasa de errores.
Tus tests pueden seguir pasando.
El experimento que merece la pena hacer esta semana puede realizarse en una tarde.
Elige un prompt de producción que contenga una instrucción de verificación o autocomprobación.
Ejecuta veinte tareas representativas utilizando Opus 5 con esa instrucción.
Después ejecuta otras veinte tareas equivalentes eliminándola.
Mantén constante el nivel de effort para conservar estable la caché.
Mide los tokens consumidos por tarea completada y evalúa la calidad utilizando tus propios criterios.
No midas únicamente tokens por solicitud.
Si la afirmación de Anthropic se cumple, deberías obtener la misma calidad con un coste menor.
Y habrás medido directamente el beneficio de eliminar esas instrucciones antes de que tus competidores terminen siquiera de leer los gráficos de benchmarks.
Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.