Migración a Opus 4.7, qué cambió para builders de API

Opus 4.7 pasó a GA el 16 de abril de 2026. A primera vista parece una release de refinamiento de rutina, el precio está sin cambios (5 dólares de input, 25 dólares de output por millón de tokens, 1 millón de contexto se mantiene), y el modelo se sigue llamando claude-opus-4-7. Pero en cuanto ves el primer error 400 en tu código de producción, sabes que la migración no es del todo trivial.

Este playbook es para ti si tienes una codebase que hace llamadas a la API de Anthropic con Opus 4.6 o anterior, y quieres asegurarte de que nada se rompa cuando el modelo suba a 4.7. Más una evaluación corta de si el nuevo nivel xhigh tiene sentido para tu caso de uso.

Tres cambios breaking en la API, errores 400 duros

Anthropic quitó tres parámetros del endpoint messages.create() que en 4.6 todavía se aceptaban. Si se los mandas a Opus 4.7, vuelve un 400 Bad Request.

Primero, thinking.budget_tokens ya no está. En 4.6 podías darle al modelo un presupuesto de tokens duro para la fase de reasoning (thinking: { type: "enabled", budget_tokens: 5000 }). En 4.7 el concepto está reemplazado por Adaptive Reasoning, el modelo decide por sí mismo cuánto piensa. Migración obligatoria, quita el campo budget_tokens por completo del request. Si necesitas control de costes (ver abajo), usa Task Budgets en la beta pública.

Segundo, temperature y top_p ya no están. Ambos estaban deprecados con un aviso en 4.6, en 4.7 están eliminados de forma dura. Si mandas temperature: 0.7 junto, error 400. Migración obligatoria, quita ambos parámetros sin reemplazo. Anthropic entrenó el modelo para que calibre por sí mismo la estrategia de sampling "correcta". En la práctica eso significa que a la API solo le das la conversación y el esquema de tools, nada más de tuning de sampling.

Tercero, top_k ya no está. Misma lógica que temperature y top_p.

En resumen, la configuración de sampling ya no es parte del contrato de la API con Opus 4.7. Es una declaración de diseño deliberada de Anthropic, quieren menos perillas del lado del builder.

Las trazas de reasoning están ocultas por defecto

Un segundo punto que llama la atención durante la migración, en 4.6 recibías por defecto los tokens completos de reasoning como stream de respuesta con thinking.type: "enabled". En 4.7 esto cambió a "summarized" como default. Es decir, recibes un resumen corto de lo que el modelo pensó, no la traza en bruto.

Si quieres la traza en bruto (debugging, infraestructura de eval, o porque quieres monitorear el estilo de reasoning), pon thinking.display: "raw" de forma explícita. Eso no es más caro, solo se pide explícitamente.

Actualización del tokenizer, de 1.0 a 1.35x más tokens

Opus 4.7 usa un tokenizer nuevo. Anthropic indica oficialmente que el mismo input de texto produce de 1.0 a 1.35 veces tantos tokens como en 4.6 según el idioma y el tipo de contenido.

En la práctica eso significa, código alrededor de 1.10x algo más caro, texto solo en inglés a 1.0 a 1.05x prácticamente igual, inputs multilingües o no occidentales hasta 1.35x notablemente más caros. Si tus facturas de API corren en alemán o español, planifica con aproximadamente un 15 a 20 por ciento más de coste de tokens. Si construyes para usuarios de habla japonesa o coreana, puede ser hasta un 35 por ciento más.

CloudZero y el Substack independiente de Karoz lo confirmaron con corpus de prueba. La declaración de Anthropic se encuentra en el documento de release notes del help center para Opus 4.7.

Extended Thinking desapareció por completo

En 4.6 tenías el interruptor thinking.type: "enabled" | "disabled" más el modo separado "Extended Thinking" para fases de reasoning agentico más largas. En 4.7 Extended Thinking ya no es un modo propio. Adaptive Reasoning es el único modo, el modelo decide por turno si piensa y cuánto.

Nota de migración, si tienes Extended Thinking activado explícitamente en tu codebase (p. ej. vía beta header extended-thinking-2026-01-15), quita el header. No pasa nada dramático si lo dejas, pero ya no tiene efecto.

Nuevo nivel de effort "xhigh" más el cambio de default de Claude Code

Anthropic introdujo un nuevo nivel de effort entre high y max, xhigh. Eso es relevante si usas la API de Claude directamente y pones el parámetro effort_level, o si usas Claude Code (CLI).

Importante, Claude Code defaultea a xhigh para todos los planes (Pro, Max, Team, Enterprise) desde 2.1.110. Es una decisión deliberada de Anthropic, la justificación está en la guía de desarrollador de NxCode para Opus 4.7 y en el artículo de Apiyi sobre el modo xhigh. En la práctica eso significa, si usas Claude Code, ahora piensas más a menudo y más largo por turno que antes de la actualización. La calidad de output mejora notablemente, pero el consumo de tokens sube.

Si necesitas control de costes en Claude Code, puedes bajar el nivel de effort por sesión a high con el comando /effort high o vía setting. Compensación, menos reasoning, respuestas más rápidas y baratas, pero en flujos agenticos un comportamiento de tool-use menos limpio.

Task Budgets como beta pública

En paralelo a 4.7, Anthropic lanzó el concepto de "Task Budgets" como beta pública. Es el reemplazo de thinking.budget_tokens, pero a un nivel más alto, es decir, todo el loop agentico (reasoning más llamadas a tools más output).

Activación vía beta header task-budgets-2026-03-13. Le das a la API un límite de tokens para toda la tarea, y el modelo lo respeta. Cuando se alcanza el límite, el modelo para de forma limpia en vez de seguir machacando. Es la palanca relevante contra la explosión de costes, sobre todo para Claude Code y frameworks agenticos.

Nota de implementación, el beta header va en el slot extra_headers del SDK. Más max_tokens_for_task como parámetro de body. La spec exacta la consultas en la guía de Verdent o en el Anthropic Help Center.

Checklist de migración, siete puntos

Si quieres migrar hoy, recorre estos siete puntos.

Uno, busca en tu codebase temperature:, top_p:, top_k: y thinking.budget_tokens. Quita todas las apariciones. Patrón más rápido, grep -rn "temperature\|top_p\|top_k\|budget_tokens" src/ y limpieza manual.

Dos, si tenías control de costes vía budget_tokens, planifica Task Budgets en su lugar. Beta header y parámetro de body.

Tres, si parseas tokens de reasoning en tu codebase (p. ej. para tus propios pipelines de eval), pon thinking.display: "raw" de forma explícita.

Cuatro, planifica un aumento de coste de tokens de aproximadamente un 15 a 20 por ciento para cargas de trabajo en alemán. Incorpora estimaciones de coste actualizadas en tus páginas de precios o dashboards internos si hace falta.

Cinco, quita el beta header de Extended Thinking (si lo usas). Sin impacto funcional, pero menos código muerto.

Seis, si usas Claude Code y no quieres una actualización de default implícita, pon el nivel de effort de forma explícita en vez de confiar en el default.

Siete, corre tus tests de eval existentes una vez contra 4.7 y compara con 4.6. Anthropic indica un salto de puntuación de 53 a 57 (Artificial Analysis Intelligence Index), eso debería reflejarse en tus tests del mundo real. Si no, tienes un prompt que estaba optimizado específicamente para el comportamiento de 4.6. Re-ajusta o quédate en 4.6 a propósito (claude-opus-4-6 sigue disponible).

¿Deberías migrar siquiera

Anthropic puso 4.7 como default para nuevas llamadas a la API. 4.6 se mantiene direccionable explícitamente como claude-opus-4-6, pero ya no es el default en la documentación ni en Claude Code. Recomendación práctica, si tu codebase se desarrolla activamente y recibes releases frescas, migra en las próximas 4 a 8 semanas. Si tu codebase está congelada y solo pagas facturas de API, puedes quedarte en 4.6 hasta que Anthropic anuncie una fecha de sunset.

A fecha de mayo de 2026 Anthropic no ha publicado ninguna fecha oficial de sunset para 4.6, pero el patrón del sunset de 4.5 fue de aproximadamente 6 a 9 meses tras la GA del sucesor. Es decir, planifica con que 4.6 se deprecará a más tardar en el Q4 de 2026.

Qué viene después

Si estás migrando Claude Code 2.1+ en paralelo, el playbook "claude-code-update-strategie" explica el ritual de actualización y qué releases son estables. Si quieres tomarte en serio el control de coste de tokens vía Task Budgets, "claude-code-cost-controls" tiene el flujo de trabajo adecuado. Para monitoreo de coste de API a nivel de proveedor, "claude-code-headless-in-ci-cd" muestra cómo medir el consumo de tokens por run.

Fuentes principales si quieres profundizar, post de noticias de Anthropic sobre Opus 4.7 (anthropic.com/news/claude-opus-4-7), release notes del help center (support.claude.com/en/articles/12138966-release-notes), pre-release review de Artificial Analysis, y la guía de desarrollador de NxCode para los detalles de la API relevantes para la migración.