- Claude Opus 4.7 mejora razonamiento, visión y control del esfuerzo manteniendo el precio y contexto de 4.6.
- La configuración de Claude Code (CLAUDE.md, settings, Skills y hooks) es clave para consistencia y costes.
- El nuevo tokenizer y el esfuerzo xhigh exigen ajustar prompts, niveles de esfuerzo y routing de modelos.
- Task budgets, Auto Mode y /ultrareview permiten workflows agénticos potentes sin perder control ni seguridad.
Claude Opus 4.7 se ha convertido en el modelo estrella del ecosistema Anthropic para programación, agentes y trabajo profesional intenso. Llega apenas un par de meses después de Opus 4.6, pero no es un simple parche: introduce un tokenizer nuevo, un nivel de esfuerzo xhigh, cambios en cómo interpreta las instrucciones y una mejora enorme en visión y workflows de Claude Code. Si ya venías cómodo con Opus 4.6, con 4.7 vas a notar que “piensa” más y mejor… y también que puede gastar más tokens si no lo domas bien.
El objetivo de esta guía es que tengas un manual completo de configuración de Claude Code + Opus 4.7: cómo elegir el esfuerzo correcto, cómo controlar los costes con task budgets, cómo migrar desde 4.6 sin romper prompts, cómo montar un setup consistente con CLAUDE.md, settings.json, Skills y hooks, y en qué casos te conviene seguir usando Sonnet o Haiku. Todo aterrizado a un español de España, pensando en equipos que facturan en dólares pero pagan la infraestructura con presupuestos ajustados.
Qué aporta Claude Opus 4.7 respecto a 4.6
Lo primero que hay que tener claro es que Opus 4.7 no cambia de precio ni de ventana de contexto: sigues teniendo hasta 1M de tokens por interacción, con el mismo coste que 4.6 (5 $/MTok de entrada, 25 $/MTok de salida), sin recargo por contexto largo. La diferencia está en cómo usa esos tokens y en el control que te da como desarrollador.
En benchmarks de programación, Anthropic reporta que Opus 4.7 resuelve muchas más tareas reales que 4.6, especialmente en pruebas tipo SWE-Bench y suites internas de 93 tareas de coding. A la práctica esto se traduce en menos reintentos cuando le pides refactors grandes, debugging de bichos raros o decisiones de arquitectura. Se nota también en la forma de razonar: planifica mejor, comete menos errores tontos y es más confiable en flujos agénticos largos.
Otro cambio clave es la visión mejorada con resolución hasta ~3,75 MP y 2.576 px de lado largo. Esto multiplica por tres la fidelidad con la que entiende capturas de pantalla, diagramas técnicos, esquemas de bases de datos o PDFs escaneados. Si ya usabas la Vision API con 4.6, ahora puedes meterle capturas bastante más grandes sin perder detalle (ten en cuenta que más resolución también son más tokens de entrada).
Además, Opus 4.7 adopta un nuevo tokenizer que cuenta más tokens para el mismo texto: según el contenido, puedes ver entre 1,0x y 1,35x el número de tokens frente a 4.6. Código, JSON y alfabetos no latinos son los que más “engordan” la cuenta. Esto importa porque, aunque el precio por millón de tokens sea igual, si el texto se trocea en más unidades, pagarás algo más por la misma carga de trabajo si no optimizas prompts y esfuerzo.
Por último, la interpretación de instrucciones se vuelve mucho más literal. Donde 4.6 rellenaba huecos con cierta flexibilidad (“resúmelo corto” te daba algo razonable de 150 palabras), 4.7 tiende a obedecer al pie de la letra (te entregará un párrafo mínimo salvo que especifiques longitud). Esto tiene impacto directo en los prompts que ya tenías afinados para 4.6.
Niveles de esfuerzo en Opus 4.7: low, high, xhigh y max
Con 4.7 llega un cambio de chip importante: el razonamiento pasa a ser adaptativo. Ya no vas ajustando un presupuesto fijo de “thinking tokens” como antes, sino que el modelo decide cuánto pensar según la complejidad de la tarea y el nivel de esfuerzo que configures.
Los niveles disponibles en Opus 4.7 son low, medium, high, xhigh y max. La gracia está en el nuevo xhigh: se sitúa justo entre high y max, pensado para programación difícil y agentes de largo recorrido, sin llegar al coste brutal de max. En Claude Code, Opus 4.7 viene de serie con xhigh como esfuerzo por defecto, porque Anthropic detectó que high se quedaba algo corto para workflows de desarrollo agéntico.
Resumiendo el abanico, el comportamiento típico sería este: con low/medium priorizas latencia y coste (soporte, extracción, pequeñas transformaciones); con high cubres la mayoría de tareas de coding, análisis de documentos y revisiones normales; con xhigh apuntas a refactors multiproyecto, diseño de arquitectura, debugging finísimo; y max lo reservas para demostraciones, pruebas formales o auditorías de seguridad donde quieres que agote cada rama de razonamiento aunque tarde y cueste más.
En el CLI de Claude Code puedes jugar con el esfuerzo en caliente usando el comando /effort: eliges el nivel en un selector interactivo o pasas directamente /effort xhigh, por ejemplo. A nivel de API, se controla vía el campo de configuración de pensamiento/adaptive thinking. Si necesitas forzar un enfoque más ligero en ciertas rutas, puedes bajar a high para scripts concretos o subagentes secundarios.
Un detalle importante: el nivel max no se queda persistente entre sesiones. Sirve para tareas puntuales en la sesión actual; cuando vuelvas a abrir Claude Code, seguirás con el esfuerzo que tuvieses configurado de forma persistente (típicamente xhigh). Esto evita que te olvides en max y quemes tokens sin querer durante horas.
Task budgets, Auto Mode y /ultrareview en Claude Code
La llegada de Opus 4.7 coincide con una tanda de mejoras muy potentes en Claude Code. Tres funciones destacan si trabajas a diario con el CLI: presupuestos de tarea, Auto Mode más accesible y el comando /ultrareview para revisiones profundas.
Los task budgets (presupuestos de tareas) permiten fijar un límite de tokens para una sesión de Claude Code, algo crítico cuando el modelo actúa como agente autónomo y encadena lecturas, ediciones, tests y llamadas a herramientas. Puedes configurarlo con algo tipo /config task_budget 50000: si el agente se acerca al tope, se detiene y te pregunta si sigues o paras. Es una barrera de seguridad para evitar que algo que parecía “un ratito” se lleve medio presupuesto del mes.
El Auto Mode —que en la práctica es el sustituto sensato del antiguo --dangerously-skip-permissions— se ha expandido a usuarios Max en combinación con Opus 4.7. Funciona con un clasificador aparte (Sonnet 4.6) que revisa cada acción (bash, MCP, ediciones) y comprueba si concuerda con tu intención y si es segura. Para tareas donde ya confías en el modelo y lo que quieres es que “haga lo suyo” sin confirmaciones constantes, este modo es oro.
Otra pieza estrella es /ultrareview, un comando de barra que dispara una revisión de código en profundidad con un protocolo estructurado. Lanza el modelo con esfuerzo muy alto, recorre arquitectura, corrección lógica, seguridad, rendimiento y mantenibilidad, y te devuelve un informe organizado con ficheros señalados y recomendaciones. Los planes Pro y Max cuentan con varias ejecuciones gratuitas por ciclo; a partir de ahí se factura por tokens como cualquier otra sesión de Opus 4.7.
Para reducir aún más las interrupciones de permisos, Anthropic publicó una skill tipo “fewer-permission-prompts” que escanea tu historial de sesiones, detecta comandos bash/MCP repetidos que siempre apruebas y propone añadirlos a listas de permitidos en settings.json. Es la forma civilizada de pasar de “¿me dejas hacer esto?” cada dos por tres a un flujo más fluido sin abrir demasiado la mano.
El nuevo tokenizer: impacto real en costes y cómo medirlo
Uno de los cambios menos vistosos pero más peligrosos para el bolsillo es el tokenizer actualizado de Opus 4.7. El mismo prompt que usabas en 4.6 ahora genera entre un 0% y un 35% más de tokens, según el tipo de contenido. En prosa inglesa el cambio es casi plano, pero en código fuente, JSON, datos estructurados y algunos idiomas no latinos se nota.
A nivel de factura, esto significa que si antes gastabas 1.000 $/mes con 4.6 usando sólo Opus, con 4.7 podrías verte entre 1.000 y 1.350 $ simplemente por el re-tokenizado, sin haber cambiado nada en tu producto. Y como el modelo además piensa más (esfuerzo xhigh, razonamiento adaptativo), la suma puede crecer aún más en workflows pesados.
Para no ir a ciegas, Anthropic expone un endpoint de conteo de tokens que te deja pasar tus prompts reales por el tokenizer de 4.7. Desde el SDK de Python puedes llamar a client.messages.count_tokens con model="claude-opus-4-7" y ver el número exacto de tokens de entrada para tu prompt de producción. Comparas con el mismo conteo en 4.6 y ya tienes tu multiplicador real, no el teórico.
Una vez detectado el impacto, la mitigación pasa por tres frentes: bajar esfuerzo donde no hace falta, limitar salidas y dirigir tareas simples a modelos más baratos. Puedes instruir al modelo explícitamente para que sea conciso (“responde en máximo 150 palabras, sin explicaciones extra”), reducir max_tokens en llamadas rutinarias y sacar resúmenes largos a tareas batch con descuento en vez de hacerlo en tiempo real.
Si combinas además prompt caching y Batch API (que cobra la mitad por tokens con 24h de margen de respuesta), puedes compensar buena parte del sobrecoste del tokenizer. La clave es que no todo pase por Opus 4.7 a xhigh en modo interactivo, porque ahí es donde más pica.
Migración desde Opus 4.6 a 4.7 sin romper nada
Pasar de 4.6 a 4.7 no es sólo cambiar un ID de modelo; hay cinco pasos que conviene seguir si ya tienes cosas en producción: actualiza identificador, revalida prompts, mide tokens, ajusta esfuerzo y prueba en tráfico real antes de ir al 100%.
Lo primero es bastante mecánico: buscar en el código todas las referencias a claude-opus-4-6 y sustituirlas por claude-opus-4-7. Un grep recursivo por .py, .ts, .json, .yaml te sacará todo. Si usas alias como opus en Claude Code, el salto será aún más sencillo porque el alias ya apunta a la versión nueva en muchos planes, pero para infraestructura de backend lo recomendable es fijar el ID explícito.
Después toca revisar prompts clave. Como 4.7 sigue las instrucciones de manera más literal, prompts vagos pueden degradar resultados. Un ejemplo clásico: si tenías “Resume este documento. Que sea corto.”, es probable que 4.6 te diera algo de 150 palabras con viñetas razonables; 4.7 puede devolverte 40-50 palabras y ya. La solución es ser explícito (“Haz un resumen de 100-150 palabras con los 3 puntos clave”).
El tercer paso es benchmarkear el uso de tokens con count_tokens para algunos prompts representativos, sobre todo los de mayor volumen (flows de soporte, RAG, pipelines de evaluación). Calculas la diferencia porcentual y ajustas estimaciones de coste. Aquí también conviene mirar max_tokens de salida y recortarlo donde tengas techos excesivamente generosos.
En cuarto lugar, decide si quieres fijar de forma explícita el esfuerzo en tus llamadas. Claude Code ya viene con xhigh en Opus 4.7, pero si vienes de 4.6 con esfuerzo high, quizá te interese mantener ese nivel en algunos flows declarando esfuerzo high en la configuración del proyecto o en la llamada a la API.
Por último, no migres el 100% del tráfico a la vez. Redirige un 5-10% hacia 4.7, compara calidad, coste, latencia y errores, y sólo cuando estés cómodo completas la transición. Los cambios de tokenizer y de interpretación literal son positivos a medio plazo, pero a corto pueden destapar supuestos frágiles en tus prompts.
Configurar Claude Code para consistencia: CLAUDE.md, settings y Skills
La mayoría de quejas de “Claude no es consistente” no se deben al modelo, sino a que no hay configuración persistente por proyecto. Si cada vez que abres una sesión nueva tienes que recordar que usas TypeScript estricto, arrow functions, Vitest en vez de Jest y ciertas convenciones de stores, el problema no es la IA: es que falta un sitio donde declararlo una vez.
Ese sitio es CLAUDE.md en la raíz del repo. Claude Code lee ese archivo automáticamente al empezar cada conversación en ese proyecto. Ahí es donde debes poner el stack concreto, las convenciones de código, los patrones preferidos, los bugs conocidos y las restricciones de entorno. Nada de filosofía genérica de programación; al modelo eso ya le sobra.
La propia herramienta trae un comando /init que analiza el código y genera un CLAUDE.md inicial. No es perfecto (a veces mete obviedades o se deja cosas), pero sirve como base. A partir de ahí, la clave es mantenerlo ligero y centrado en el contexto del proyecto. No pegues patrones de código largos; esos van a Skills.
Luego está settings.json, donde defines permisos permanentes, variables de entorno visibles para Claude y hooks que se ejecutan siempre antes o después de ciertas acciones. La jerarquía es en cascada: configuración global de usuario (~/.claude/settings.json) y configuración específica del proyecto (.claude/settings.json). Cuando chocan, gana la más específica (la del proyecto), lo que viene genial para aplicar políticas distintas entre repos.
Un patrón sensato es dejar cosas amplias en la config de usuario (por ejemplo, permitir leer ficheros del código o correr el linter) y refinar en el proyecto lo que no quieres que haga sin preguntar (scripts de despliegue, migraciones, acceso a secretos). Si no existe settings.json en el repo, te comerás el comportamiento global, que muchas veces es demasiado laxo o, al revés, te obliga a aceptar siempre lo mismo.
Estrategias de coste: cuándo usar Opus 4.7, Sonnet 4.6 y Haiku 4.5
Opus 4.7 es una bestia, pero no tiene por qué ser tu martillo para cada clavo. Anthropic mantiene una familia de modelos para poder jugar con el coste: Haiku 4.5, Sonnet 4.6 y Opus 4.7 cubren casi todo el espectro de necesidades.
Haiku 4.5 es el modelo ligero: rápido y muy barato. Ideal para clasificación, extracción sencilla, generación de metadatos, resúmenes cortos y, sobre todo, para subagentes que hacen exploración y búsquedas de archivos. Si tienes un sistema que lanza muchos subagentes a escanear repos, logs o documentación, poner Haiku ahí reduce la factura una barbaridad.
Sonnet 4.6 es el caballo de batalla equilibrado: precio medio, inteligencia suficiente para la mayoría de tareas de desarrollo diario (escribir código, arreglar bugs, generar tests, hacer refactors razonables). Tiene también contexto de 1M tokens y pensamiento adaptativo, así que puedes manejar codebases grandes sin necesidad de tirar siempre de Opus.
Opus 4.7 lo deberías reservar para aquello en lo que la calidad no es negociable: decisiones de arquitectura, debugging delicado, análisis de seguridad, coordinación de equipos de agentes o proyectos donde un fallo cuesta mucho más que unos dólares de tokens. En muchas empresas la estrategia ganadora es rutear por tipo de tarea: simple/moderada a Sonnet o Haiku, compleja a Opus.
Si montas una capa de routing que observe el tipo de petición y la complejidad, puedes conseguir reducciones del 40-60% en costes sin perder calidad donde de verdad importa. De hecho, Anthropic documenta equipos que, sólo por separar tareas simples hacia Sonnet y Haiku, se han salvado de facturas desorbitadas.
Al final, si montas bien CLAUDE.md, settings, Skills, routing de modelos, permisos y hooks, Opus 4.7 deja de ser “un modelo más grande” para convertirse en un copiloto de desarrollo bastante serio. Te permite delegar trabajo pesado sin estar pendiente del tokenómetro cada dos por minutos, siempre que combines bien el esfuerzo, los task budgets, el sandbox y la elección de modelo por tarea. Si vienes de 4.6, el salto se nota en razonamiento, visión y fiabilidad de los agentes; si empiezas de cero, tiene sentido arrancar directamente con 4.7, pero planificando tu configuración y tus costes desde el primer día para no llevarte sustos a final de mes.
Soy un apasionado de la tecnología que ha convertido sus intereses «frikis» en profesión. Llevo más de 10 años de mi vida utilizando tecnología de vanguardia y trasteando todo tipo de programas por pura curiosidad. Ahora me he especializado en tecnología de ordenador y videojuegos. Esto es por que desde hace más de 5 años que trabajo redactando para varias webs en materia de tecnología y videojuegos, creando artículos que buscan darte la información que necesitas con un lenguaje entendible por todos.
Si tienes cualquier pregunta, mis conocimientos van desde todo lo relacionado con el sistema operativo Windows así como Android para móviles. Y es que mi compromiso es contigo, siempre estoy dispuesto a dedicarte unos minutos y ayudarte a resolver cualquier duda que tengas en este mundo de internet.