Opus 4.7 vs Sonnet 4.6 en Claude Code: cuál elegir 2026

TL;DR

A mayo de 2026, Claude Code mantiene tres modelos vivos: Opus 4.7 (estándar, 200k de contexto), Opus 4.7 con ventana 1M y Sonnet 4.6. Opus 4.7 gana en refactors complejos y razonamiento profundo, la variante 1M solo paga su coste cuando navegas repos gigantes, y Sonnet 4.6 domina edición rápida, debugging y tareas donde el coste por token manda. Este artículo es el árbol de decisión que uso cada día para no quemar factura en tareas donde Sonnet hace el mismo trabajo.

Por qué importa elegir bien el modelo en Claude Code

La factura mensual cambia entre un 40% y un 60% según el reparto de modelos que hagas en una semana normal. No es un detalle de optimización, es la diferencia entre 25€ y 45€ mensuales en uso personal intenso, o un múltiplo en equipos.

El comando /model dentro de Claude Code es trivial. Lo que no es trivial es saber cuándo bajar a Sonnet sin perder calidad, o cuándo el contexto extendido de 1M tokens compensa el extra de coste. Aquí es donde la mayoría tira del modelo más potente por defecto y termina pagando un sobrecoste innecesario.

Los tres modelos en una tabla

Modelo	Contexto	Punto fuerte	Coste relativo	Latencia
Opus 4.7	200k tokens	Razonamiento profundo, refactors	Alto	Media
Opus 4.7 (1M)	1M tokens	Repos enormes, auditorías	Muy alto	Alta
Sonnet 4.6	200k tokens	Edición rápida, debugging	Bajo (~1/5 de Opus)	Baja

El coste relativo viene de la facturación pública de Anthropic: Sonnet 4.6 está aproximadamente a una quinta parte del precio por millón de tokens de Opus 4.7. La variante 1M aplica un recargo por encima del umbral de 200k tokens de contexto.

Qué hace bien Opus 4.7 (y qué no)

Opus 4.7 es el modelo al que recurres cuando la tarea requiere mantener varios hilos de razonamiento simultáneos: refactor que toca 8 archivos con dependencias circulares, diseño de arquitectura, migración entre frameworks, debugging donde el error está a dos saltos del síntoma.

Lo que no hace bien Opus 4.7 es ser eficiente con tareas pequeñas. Pedirle que renombre una variable o añada un endpoint trivial gasta tokens caros para un output que Sonnet daría idéntico. En mi flujo personal, el 60-70% de las interacciones diarias no necesitan Opus.

La configuración de effort en Claude Code añade otra dimensión: Opus 4.7 con effort medio suele ser más predecible que con effort máximo activado en tareas creativas, donde el modelo se desvía buscando soluciones elegantes en lugar de aplicar la obvia.

Cuándo activar Opus 4.7 con ventana 1M

La variante 1M no es "Opus pero mejor". Es Opus con un coste extra por tokens por encima de 200k y, según los reportes de la comunidad en r/ClaudeCode, con atención más dispersa cuando el contexto está realmente lleno.

Usa 1M cuando:

Auditas un repo grande sin saber dónde está el problema (más de 50 archivos relevantes).
Migras una librería que toca prácticamente todo el proyecto.
Necesitas cargar varios PDFs o transcripciones largas en una sola sesión.

No uses 1M cuando:

Tu CLAUDE.md y memoria persistente ya filtran bien el contexto relevante.
La tarea cabe en 50k tokens (la mayoría de features de día a día).
Estás iterando rápido: el modelo es perceptiblemente más lento.

El antipatrón aquí es cargar todo "por si acaso". El contexto largo no es gratis ni en coste ni en calidad: cuanta más información irrelevante metes, más se diluye la atención del modelo en lo que importa. Si tu setup de memoria en Claude Code está bien estratificado, casi nunca necesitas 1M.

El caso fuerte de Sonnet 4.6

Sonnet 4.6 sigue siendo, a fecha de hoy, el caballo de batalla razonable para la mayoría del trabajo diario en Claude Code. Estos son los escenarios donde lo prefiero sin pensarlo:

Edición puntual: añadir un campo a un endpoint, escribir un test unitario, corregir un mensaje de log.
Debugging con stack trace claro: cuando ya tienes la pista, no necesitas el cerebro de Opus.
Generación de boilerplate: CRUDs, DTOs, schemas Pydantic, configuración de Docker.
Sesiones largas iterativas: el coste se acumula, y la latencia baja de Sonnet hace que el flujo no se atasque.

Donde Sonnet 4.6 flaquea es en tareas que requieren mantener múltiples constraints en mente a la vez. Si la primera respuesta del modelo es "claramente equivocada en algo que el contexto deja claro", es síntoma de que necesitas Opus.

Recetas concretas por tipo de tarea

Estas son las reglas que aplico en mi flujo de trabajo con coding agents en 2026:

Refactor que toca 1-3 archivos → Sonnet 4.6.
Refactor que toca 4+ archivos con lógica cruzada → Opus 4.7.
Diseño de arquitectura o decisiones de stack → Opus 4.7 con effort alto.
Debugging con causa obvia → Sonnet 4.6.
Debugging donde el bug está en el "espacio entre archivos" → Opus 4.7.
Generación de tests → Sonnet 4.6 salvo lógica de negocio compleja.
Auditoría de seguridad o performance en repo grande → Opus 4.7 1M.
Documentación, READMEs, comentarios → Sonnet 4.6.

En Producción

Cuando Claude Code es parte de un flujo de equipo o de CI/CD, la elección de modelo tiene más implicaciones:

Coste por iteración: cada ciclo de PR review automatizado con Opus 4.7 puede costar entre 0,20€ y 0,80€ según el tamaño del diff. En un equipo con 30 PRs diarios, son 200-500€ mensuales solo en revisión. Mover esa carga a Sonnet 4.6 con escalada manual a Opus cuando el reviewer lo pida suele recortar un 70% del gasto.

Cache de prompts: cambiar de modelo a mitad de sesión invalida el cache. Si estás iterando en una feature, fija un modelo al inicio. Las cinco acciones que disparan cache miss en Claude Code incluyen este caso y son fáciles de evitar con disciplina.

Determinismo: Opus 4.7 es más propenso a explorar alternativas, lo que en producción significa diffs que no siempre se parecen entre ejecuciones similares. Para tareas que se repiten (como generación de migraciones a partir de schemas), Sonnet 4.6 da resultados más estables.

Sesiones largas: en jornadas de más de 4 horas sobre el mismo proyecto, mezclar modelos es realista. Yo abro con Opus 4.7 para diseñar el approach, bajo a Sonnet 4.6 para implementar y solo vuelvo a Opus si aparece un bloqueo conceptual.

Errores comunes al elegir modelo

Error: "Uso siempre Opus por seguridad" → Causa: miedo a perder calidad → Solución: medir output real con la misma tarea en ambos modelos durante una semana. La mayoría descubre que el 60-70% de tareas son indistinguibles.
Error: "Activo 1M para todo" → Causa: confundir contexto disponible con contexto necesario → Solución: usar research-first para explorar repos grandes antes de cargar todo en el modelo.
Error: "Cambio de modelo cuando una respuesta no me gusta" → Causa: tratar el modelo como variable independiente → Solución: revisar primero el prompt y el contexto. El cambio de modelo invalida cache y casi nunca soluciona prompts mal formulados.
Error: "Sonnet falla, paso a Opus en la misma sesión" → Causa: ignorar la pérdida de cache → Solución: si vas a escalar, cierra la sesión y abre una nueva con el contexto mínimo necesario.

Preguntas Frecuentes

¿Cómo cambio de modelo en Claude Code?

Con el comando /model dentro de la sesión. Se abre un selector con los modelos disponibles según tu plan. El cambio aplica al siguiente mensaje y rompe el cache de prompts de la sesión actual.

¿Merece la pena Opus 4.7 1M sobre el Opus 4.7 estándar?

Solo si tu tarea real requiere más de 200k tokens de contexto cargado simultáneamente. Para el 90% del trabajo diario, el Opus 4.7 estándar con un CLAUDE.md bien escrito y memoria persistente bien configurada rinde mejor y cuesta menos.

¿Sonnet 4.6 sirve para escribir código en producción?

Sí, sin reservas para tareas dentro de su perfil: edición puntual, boilerplate, debugging con causa clara, generación de tests. El criterio para escalar a Opus es la complejidad del razonamiento requerido, no el destino del código.

Cierre

La pregunta no es "qué modelo es mejor", sino "qué modelo es adecuado para esta tarea concreta". Opus 4.7 brilla en razonamiento profundo, la variante 1M solo paga su coste en repos enormes, y Sonnet 4.6 sigue siendo el motor razonable de la mayoría del trabajo diario. La diferencia entre una factura controlada y una explosiva está en aplicar el criterio antes de cada sesión, no después.

El siguiente paso natural es medir: durante una semana, anota qué modelo usaste para cada tarea y revisa el resultado. Vas a descubrir que ya estás pagando Opus para cosas que Sonnet resolvía igual de bien.

¿Cómo decides tú entre Opus y Sonnet cada día? Cuéntamelo en Twitter @sergiomarquezp_ o en los comentarios. En el próximo post toca cómo combinar selección de modelo con effort y memoria persistente para flujos largos sin perder contexto.