Cambiar de modelo merece una evaluación de tus tareas, además de mirar una tabla de benchmarks. En el video del 16 de abril de 2026 analicé Opus 4.7, su visión, sus opciones de esfuerzo y los cambios que podían afectar el trabajo con agentes.
Esta guía toma esa lectura de documentación como punto de partida. Las tablas que aparecen son evaluaciones publicadas por Anthropic, no benchmarks que yo haya ejecutado. El objetivo es entender qué revisar antes de cambiar una configuración que ya usas. Puedes ver el análisis original en YouTube.
Cómo leer este análisis meses después
Opus 4.7 corresponde a una generación anterior a otros modelos publicados después. Eso no convierte automáticamente cada integración existente en inútil. Al revisar esta guía, Anthropic todavía lo lista como activo en su registro de modelos y retiros.
La pregunta útil es si cambiar mejora el resultado de tu trabajo. Un proceso estable puede requerir validación antes de actualizarse, especialmente si produce documentos, usa herramientas o depende de parámetros concretos de la API.
Por eso el video funciona también como ejemplo de cómo leer un lanzamiento: separar lo que el proveedor afirma, lo que tu herramienta permite configurar y lo que efectivamente cambia en tus resultados.
Qué te dice un benchmark y qué falta comprobar
En la grabación revisé tablas de programación, navegación, visión y razonamiento. Cada una mide una tarea diferente bajo un entorno determinado. Una mejora en un examen de código no demuestra que tu agente vaya a preparar mejores propuestas comerciales ni que navegue mejor por tu CRM.
Tampoco todas las comparaciones tienen el mismo presupuesto de herramientas o tiempo. Antes de usar un porcentaje para decidir, conviene preguntar qué recibió el modelo, qué herramientas tuvo disponibles y cómo se puntuó la salida.
Para tu propia prueba, elegiría ejemplos que ya conozcas. Uno que el sistema actual resuelva bien, uno que falle de manera repetida y uno que represente el trabajo más frecuente. Así puedes observar mejoras y regresiones, en lugar de quedarte con el ejemplo más vistoso.
Visión: de entender una imagen a completar una tarea
Una de las capacidades comentadas en el video es la lectura de imágenes y pantallas con más detalle. Su utilidad aparece cuando el resultado depende de observar una interfaz, un gráfico o un documento, y después actuar correctamente sobre esa información.
Pero reconocer un botón no garantiza completar el flujo. Puedes identificar bien un campo y escribir en la cuenta equivocada, o leer una cifra sin comprender su período. En una evaluación visual, el criterio debería cubrir la tarea completa.
Un ejemplo sería pedir que encuentre un dato en una tabla, identifique su unidad y lo use en un resumen con referencia a la fuente. Otro sería comprobar una interfaz en móvil y escritorio, explicar el problema observado y mostrar el resultado tras corregirlo. La guía de Claude Design y Claude Code ilustra por qué diseño y comprobación deben ir juntos.
La corrección importante sobre el tokenizer
En el video hay una explicación oral que conviene corregir: el cambio de tokenizer no significa que el mismo texto use un 35% menos de tokens. El anuncio oficial de Opus 4.7 indica que la misma entrada puede representar aproximadamente entre 1 y 1,35 veces los tokens, según el contenido.
Eso obliga a medir, especialmente si envías documentos extensos o mantienes sesiones largas. Una tarifa por millón de tokens, aislada, no te dice cuánto costará terminar un trabajo. También importan la cantidad de entrada, la salida, las repeticiones y el uso de caché cuando corresponde.
No necesitas optimizar cada palabra de un prompt antes de empezar. Sí necesitas una muestra representativa y un registro de consumo. Comparar dos sesiones con materiales distintos no permite atribuir la diferencia al tokenizer.
Esfuerzo y presupuesto de tarea no son lo mismo
En el video aparecen las opciones de esfuerzo y los presupuestos de tareas agénticas. Son controles relacionados con el trabajo del modelo, pero responden a preguntas distintas: cuánto esfuerzo dedicar y qué presupuesto orientar para un recorrido más amplio.
La documentación de task budgets define el presupuesto como una orientación para el ciclo agéntico, no como un tope duro de facturación. También aclara que se utiliza mediante la Messages API en modelos compatibles, no como una función disponible de la misma forma en Claude Code o Cowork.
Por eso conviene separar la intención del control operativo. Si una aplicación tiene que detenerse después de cierto número de acciones, ese límite debe existir en la aplicación. Pedir al modelo que “gaste poco” no sustituye una condición que detenga el trabajo.
Qué revisar si ya usas la API
Una actualización puede cambiar más cosas que el identificador del modelo. Anthropic documenta cambios en parámetros de muestreo para Opus 4.7 y posteriores. Antes de reutilizar una solicitud antigua, consulta la guía de migración y evita asumir que todo parámetro previo sigue funcionando igual.
Prepararía una copia del flujo y verificaría tres elementos: que la petición sea aceptada, que la respuesta tenga la estructura esperada y que el resultado conserve la calidad necesaria. Un error visible es fácil de detectar; una respuesta válida con contenido peor requiere una revisión real.
Si tu sistema usa herramientas, prueba también un paso fallido. Es útil saber si el modelo reconoce un error, vuelve a intentar de forma razonable y deja evidencia de lo que quedó pendiente. Esa conducta importa tanto como una respuesta brillante en una pregunta aislada.
Una ficha sencilla para comparar modelos
Esta es una propuesta editorial para tus pruebas, no una evaluación ya realizada en el canal:
| Campo | Qué registrar |
|---|---|
| Tarea y entrada | La misma instrucción y los mismos archivos |
| Resultado esperado | Condiciones concretas de aceptación |
| Configuración | Modelo, esfuerzo, herramientas y límites |
| Resultado observado | Aciertos, errores y pasos incompletos |
| Trabajo total | Tiempo, consumo y correcciones humanas |
Repite los casos donde una diferencia altere tu decisión. Guarda ejemplos de errores y no solo la salida ganadora. El resultado útil es saber qué configuración usar para qué trabajo, y qué limitaciones debe conocer quien la opera.
La guía de agentes, contexto y memoria ayuda a recordar que el comportamiento final depende del sistema completo. Un modelo mejor no repara automáticamente instrucciones ambiguas o herramientas mal conectadas.
Video completo y recursos
Ve el análisis de Opus 4.7 en YouTube, teniendo presente la corrección sobre tokens y el contexto de su publicación en abril. Para tus decisiones actuales, revisa el catálogo y la documentación del proveedor.
En Imperio Agéntico trabajamos estos criterios sobre casos de implementación. Puedes suscribirte a mi canal para seguir las comparaciones con contexto práctico.
Preguntas frecuentes
¿Opus 4.7 usa un 35% menos de tokens para el mismo texto?
No. El anuncio oficial indica que la misma entrada puede representar aproximadamente entre 1 y 1,35 veces los tokens, según el contenido. Esta guía corrige esa interpretación oral del video.
¿Los benchmarks del video son pruebas realizadas por Benjamín Cordero?
No. La grabación analiza evaluaciones y documentación publicadas por Anthropic. No presenta un benchmark propio ejecutado con los mismos casos y presupuestos.
¿Task budget es un límite duro de gasto?
No. Es una orientación para el ciclo agéntico. Si necesitas una condición que detenga el trabajo, debe existir un control operativo adicional en la aplicación.
¿Esta guía presenta Opus 4.7 como el modelo más reciente?
No. Es un análisis del video publicado en abril de 2026. La guía conserva lo útil para evaluar cambios de modelo y remite al catálogo vigente para comprobar disponibilidad.
¿Qué debería comparar al cambiar de modelo?
Calidad del resultado, errores, tiempo total, consumo y correcciones humanas. Mantén iguales las entradas y herramientas, y registra la configuración para que la comparación tenga sentido.