Claude Opus 4.7: buen candidato para coding y agentes, pero no para un cambio ciego

La novedad más relevante para agentes es task budgets, es decir, presupuestos por tarea para controlar mejor flujos largos. La documentación de Claude API también señala que Opus 4.7 usa un tokenizador nuevo: el mismo contenido puede contarse de forma distinta que en Opus 4.6, y puede requerir aproximadamente entre 1x y 1,35x tokens al procesar texto, según el contenido.

Sobre precio, algunos sitios de seguimiento y cobertura técnica sitúan Opus 4.7 en torno a $5 por 1 millón de tokens de entrada y $25 por 1 millón de tokens de salida, en línea con Opus 4.6. Aun así, antes de llevarlo a producción conviene revisar la página oficial de precios de Claude API, porque separa tokens base de entrada, escrituras de caché, aciertos de caché y tokens de salida; además, prompt caching y batch processing tienen reglas propias.

Dónde probarlo primero

La trampa del coste: el precio por token no es la factura final

Si solo miras el precio por millón de tokens, Opus 4.7 puede parecer una actualización sencilla: varias fuentes de seguimiento lo sitúan alrededor de $5 por tokens de entrada y $25 por tokens de salida por cada millón. Pero en producción la factura suele venir de la combinación de prompts largos, respuestas largas, llamadas a herramientas, reintentos, caché de prompts y número de rondas que necesita el agente.

El punto que hay que volver a medir es la tokenización. Anthropic indica que el tokenizador nuevo de Opus 4.7 puede usar aproximadamente entre 1x y 1,35x tokens frente a modelos anteriores, dependiendo del contenido; el endpoint /v1/messages/count_tokens también puede devolver un conteo distinto en Opus 4.7 que en Opus 4.6.

Por eso, la métrica útil no es solo coste por millón de tokens, sino coste por tarea completada. Si Opus 4.7 resuelve tareas difíciles con menos rondas de corrección, menos rollbacks o menos intervención humana, pagar más tokens puede salir a cuenta. Si la calidad apenas cambia y el conteo de tokens sube, la migración empeora el margen.

Cómo hacer un A/B test serio en un equipo de ingeniería

Un buen piloto debe usar trabajo real, no solo prompts de demostración. Toma una muestra suficiente de tu backlog, bugs antiguos o pull requests ya mergeados, y divídela por tipos de tarea:

• Bug fixes pequeños con tests claros.
• Refactors que tocan varios archivos.
• Code reviews de pull requests complejos.
• Tareas agentic de varios pasos: leer el repositorio, planificar, modificar código, ejecutar tests y autocorregir fallos.
• Casos donde el modelo actual suele fallar o necesita muchas aclaraciones.

Ejecuta Opus 4.7 en paralelo con el modelo que ya usas, manteniendo el mismo prompt, las mismas herramientas, el mismo acceso al repositorio y los mismos criterios de evaluación. Como mínimo, mide:

1. Tasa de éxito por tarea: si la tarea queda realmente resuelta según lo pedido.
2. Intervenciones humanas: cuántas veces alguien debe corregir el rumbo, repetir instrucciones o revertir cambios.
3. Errores de herramientas: si el agente lee archivos equivocados, llama mal a una herramienta o ejecuta comandos inadecuados.
4. Tokens totales y coste por tarea: hay que recontar, porque Opus 4.7 usa un tokenizador nuevo y el endpoint de conteo puede devolver resultados distintos frente a Opus 4.6.
5. Tiempo hasta completar: cuánto tarda en pasar tests, recibir aprobación de review o quedar listo para merge.
6. Calidad de la revisión o del parche: comentarios bloqueantes, errores lógicos restantes y legibilidad del cambio.

Si no tienes tests automáticos, usa revisión ciega o una rúbrica fija. Sin datos internos, es fácil confundir un benchmark general con una mejora real para tu código.

Checklist rápido de migración

• Añade claude-opus-4-7 como opción de modelo, sin cambiar todavía el valor por defecto de todo el sistema.
• Empieza con un canary en tareas difíciles: refactors, debugging en varios archivos, code review complejo y bucles agentic.
• Recuenta tokens con el endpoint de token counting, porque Opus 4.7 puede devolver un número distinto al de Opus 4.6.
• Mide coste por tarea completada, no solo tokens totales por día.
• Prueba task budgets si tu flujo de agentes necesita controlar presupuesto en tareas de varios pasos.
• Revisa los precios oficiales antes de producción, sobre todo si usas prompt caching, cache hits, cache writes o batch processing.

Veredicto

Claude Opus 4.7 merece una adopción más amplia si aumenta la tasa de finalización en tareas difíciles, reduce intervenciones humanas, baja los errores de herramientas o permite que tus agentes completen trabajos que el modelo actual suele abandonar. La razón para pilotarlo es clara: Anthropic lo posiciona como más fuerte en coding, agentes y tareas de varios pasos, y ya ofrece el identificador de modelo para usarlo vía API.

En cambio, mantén tu modelo actual como predeterminado si tu carga principal son tareas cortas, repetitivas y con poco razonamiento de varios pasos, o si tu A/B test muestra que el coste por tarea sube sin una mejora clara de calidad. Con Claude Opus 4.7, actualizar bien no significa mover todo el tráfico: significa enrutar las tareas difíciles donde una mejor calidad puede ahorrar suficiente retrabajo como para compensar.