Saltar al contenido principal

Claude Opus 5: el modelo frontier diario que los equipos de Claude Code pedían

· 11 min de lectura
Claude Dev
Claude Dev
Claude Dev

Anthropic lanzó Claude Opus 5 el 24 de julio de 2026, posicionándolo como el modelo frontier diario dentro de la familia Claude 5: cerca de la inteligencia de Claude Fable 5, pero con el mismo precio de Opus 4.8: 5 dólares por millón de tokens de entrada y 25 dólares por millón de tokens de salida.

Ese precio es la historia.

Fable 5 sigue siendo el modelo para el trabajo más difícil, largo y autónomo. Sonnet 5 es el modelo agente por defecto que la mayoría de equipos puede usar ampliamente. Opus 5 queda entre ambos: suficientemente fuerte para ingeniería seria, menos restringido que Fable en flujos normales, y con precio para uso diario repetido en vez de escalaciones raras.

El feedback temprano de la comunidad es positivo, pero todavía no está asentado. En X domina el entusiasmo por la calidad en medium effort y la eficiencia de tokens. Reddit y Hacker News son más cautos: límites de uso, churn de modelos, safety fallbacks y si otro Opus realmente se siente mejor dentro de sesiones de coding desordenadas. Esa cautela es correcta.

Qué lanzó Anthropic​

Claude Opus 5 reemplaza a Opus 4.8 como el modelo Opus general más fuerte de Anthropic. La documentación oficial lo describe como un salto frente a Opus 4.8, con mejoras en razonamiento profundo, agentic coding, tareas de largo horizonte, test-time compute scaling, code review, visión, contexto largo, trabajo de oficina y coordinación multiagente.

Detalles operativos:

  • Model ID: claude-opus-5
  • Ventana de contexto: 1M tokens por defecto y como máximo
  • Salida máxima: 128k tokens
  • Precio: 5 dólares por millón de tokens de entrada y 25 dólares por millón de tokens de salida
  • Disponibilidad: Claude API, planes Claude.ai, Claude Code, Amazon Bedrock, Google Cloud y Microsoft Foundry
  • Fast mode: disponible en Claude API a 10 dólares input y 50 dólares output por millón de tokens
  • Prompt cache minimum: baja de 1.024 tokens en Opus 4.8 a 512 tokens
  • Thinking: activado por defecto
  • Escalera de effort: low, medium, high, xhigh y max

La migración no es solo cambiar el model ID. En Opus 4.8 las requests corrían sin thinking salvo que activaras adaptive thinking. En Opus 5, thinking está activado por defecto, y effort pasa a ser el control principal de profundidad, latencia y coste.

También hay un breaking change real: si desactivas thinking, effort debe ser high o inferior. Las requests que combinan thinking: {"type": "disabled"} con xhigh o max devuelven 400.

Para usuarios de Claude Code, la lectura es simple: Opus 5 quiere pensar y actuar más por defecto. Eso puede ser bueno. También puede quemar presupuesto si tus prompts aún incluyen andamiaje antiguo como "double check everything" o "always use a verifier agent."

Lectura de la comunidad: entusiasmo con límites​

La señal del día de lanzamiento es activa, pero irregular.

En X, las reacciones positivas más fuertes giran alrededor de medium effort y eficiencia. Techmeme recogió posts tempranos que llaman impresionante a Opus 5, especialmente en medium effort, pero también menciona workflows rotos e impresiones mixtas de usuarios probándolo en herramientas reales.

En Reddit el tono es más práctico. Las comunidades relacionadas con Claude están menos interesadas en celebrar rankings y más en:

  • si Opus 5 consumirá demasiado rápido los límites de Claude Pro y Max;
  • si es significativamente mejor que Opus 4.8 en Claude Code;
  • si Fable 5 sigue valiendo la pena;
  • si los safety fallbacks interrumpirán trabajo normal de seguridad e investigación;
  • si Anthropic está lanzando modelos más rápido de lo que los equipos pueden evaluarlos.

Hacker News muestra el mismo patrón. Algunos quieren un modelo diario más fuerte. Otros están cansados del model churn y quieren menos regresiones en sesiones reales de coding. La crítica útil no es "los benchmarks son falsos"; es que el único benchmark que importa para ingeniería pagada es si el modelo puede completar tareas caóticas de varias horas sin crear deuda de revisión costosa.

Ese es el marco correcto para Opus 5. No debe juzgarse por sonar más inteligente en chat, sino por reducir agent loops fallidos, falsos positivos en code review, implementaciones parciales y token burn innecesario.

Por qué Opus 5 importa más que Opus 4.8​

Opus 4.8 ya era fuerte. Opus 5 importa porque Anthropic está haciendo que la capa Opus sea más operativa.

La nueva documentación enfatiza niveles de effort bajos. low y medium no son solo modos baratos para prompts fáciles; Anthropic dice que conservan calidad fuerte con una fracción de tokens y latencia frente a high effort. Si eso se sostiene en cargas reales de Claude Code, Opus 5 deja de ser un modelo de "usar solo cuando estás atascado" y pasa a ser una capa diaria de routing.

Eso cambia cómo pensar el stack Claude:

  • Sonnet 5 para implementación rutinaria, refactors pequeños y automatización amplia.
  • Opus 5 medium/high para edits complejos, code review, debugging y agent loops de mayor confianza.
  • Opus 5 xhigh/max para arquitectura difícil, investigaciones profundas y migraciones grandes.
  • Fable 5 para el trabajo autónomo más difícil y largo cuando coste y restricciones de retención son aceptables.

Es una forma mejor que un modelo por defecto más un modelo caro. Da a los equipos Claude Code una escalera real de coste-rendimiento dentro de la misma familia.

El riesgo oculto de migración: sobreverificación​

El cambio de prompting más importante es fácil de pasar por alto.

Anthropic dice que Opus 5 verifica su propio trabajo con más disposición que modelos Opus previos. Suena como mejora pura, pero crea riesgo para harnesses de agentes que ya fuerzan pasos de verificación.

Si tu wrapper de Claude Code dice:

  • ejecutar siempre una verificación final;
  • crear un verifier subagent;
  • revisar dos veces cada conclusión;
  • explicar cada corrección;
  • no terminar hasta revisar de nuevo todo el cambio;

entonces Opus 5 puede apilar esas instrucciones con su propio comportamiento. Resultado: trabajo más lento, más tool calls, más narración y más tokens gastados en comprobar que en entregar.

El patrón mejor es verificación condicional:

  • verificar cuando cambian archivos;
  • verificar cuando un comando prueba directamente el resultado;
  • usar subagents solo para trabajo paralelo independiente;
  • no pedir un segundo verificador en tareas pequeñas;
  • limitar tool use y número de subagents en el harness.

Opus 5 no elimina la necesidad de verificar. Cambia dónde debe vivir la verificación: en gates de ingeniería explícitos, no en rituales vagos de prompt.

Safety y fallbacks: menos fricción que Fable, pero no invisibles​

Opus 5 llega tras un mes ruidoso para los modelos de alta capacidad de Anthropic. Fable 5 y Mythos 5 tuvieron restricciones de acceso, cyber safeguards y frustración de usuarios por fallback. Opus 5 responde en parte a ese hueco de producto.

Reuters informó que Anthropic ve Opus 5 como la opción de valor y reserva Fable 5 para proyectos autónomos de varios días. The Verge y otros medios también enmarcaron Opus 5 como menos restrictivo que Fable 5 en contextos de ciberseguridad, aunque mantiene safeguards.

El nuevo modo API fallback importa. Los desarrolladores pueden optar por fallbacks "default", dejando que Anthropic enrute requests marcadas por clasificadores de seguridad hacia modelos fallback recomendados, sin que cada app mantenga su propia lista.

Es útil, pero los equipos deben diseñar para ello:

  • comprobar stop_reason, incluido refusal;
  • registrar stop_details cuando esté disponible;
  • informar a usuarios cuando ocurrió un fallback;
  • medir diferencias de calidad entre Opus 5 y respuestas fallback;
  • no asumir que cada HTTP 200 significa que respondió el modelo solicitado.

Esto es especialmente relevante para Claude Code, security review e investigación. Un fallback puede ser mejor que un bloqueo duro, pero sigue siendo un evento de model routing.

Qué deberían probar primero los equipos Claude Code​

No empieces con un prompt benchmark genérico. Empieza por el trabajo que realmente duele.

Una eval útil de Opus 5 debería incluir:

  1. Un bug fix multifichero

Dale un test real que falla o una traza de producción. Mide si encuentra la causa raíz correcta sin reescribir código no relacionado.

  1. Una pasada de code review

Pide todos los problemas accionables y filtra severidad después. Las docs de prompting de Anthropic señalan que pedirle ser conservador puede hacer que Opus 5 reporte de menos.

  1. Una tarea de implementación en medium effort

Ejecútala en medium, high y xhigh. Compara calidad final, tokens, número de comandos y esfuerzo de revisión.

  1. Una tarea de repo con contexto largo

Usa una codebase grande o historial de diseño largo. Observa si el seguimiento de instrucciones se mantiene estable profundo en el contexto.

  1. Un agent loop cargado de tools

Comprueba si narra demasiado, delega demasiado o verifica de más. Ajusta el harness antes de cambiar defaults para todo el equipo.

La métrica debe ser coste por cambio aceptado, no coste por millón de tokens. Opus 5 puede ser más caro por llamada y aun así más barato por feature entregada si necesita menos turnos, encuentra bugs reales antes y evita rework.

Checklist práctica de migración​

Para equipos que pasan desde Opus 4.8:

1. Actualizar el model ID​

Mueve workloads de prueba de:

claude-opus-4-8

a:

claude-opus-5

Mantén Opus 4.8 en la tabla de routing hasta que tus evals pasen.

2. Revisar max_tokens​

Thinking está activado por defecto, y max_tokens cubre thinking más salida visible. Si tu integración Opus 4.8 usaba límites ajustados, Opus 5 puede truncar antes de lo esperado.

3. Barrer niveles de effort​

No asumas que xhigh es el default correcto. Prueba medium, high y xhigh en tus tareas reales. Usa max solo cuando la tarea justifique el reasoning budget extra.

4. Quitar boilerplate viejo de verificación​

Elimina instrucciones de prompt que fuerzan self-review global o verificación por subagent. Sustitúyelas por gates precisos ligados a archivos cambiados, tests o nivel de riesgo.

5. Activar prompt caching donde ahora encaja​

El mínimo de cache de 512 tokens hace cacheables system prompts estables más cortos. Es una palanca de coste pequeña pero útil para herramientas con prefijos repetidos.

6. Tratar fallback como evento observable​

Si usas fallback server-side, regístralo. La confianza del usuario depende de saber cuándo cambió el modelo bajo el capó.

Conclusión​

Claude Opus 5 no es simplemente "Fable 5 pero más barato." Ese marco es demasiado simple.

Es el intento de Anthropic de hacer que el trabajo agentic de nivel frontier sea operativo: suficientemente fuerte para coding serio, más barato que Fable, disponible en más plataformas y ajustable por effort en vez de una inteligencia fija.

La reacción mixta de la comunidad es correcta. Los desarrolladores están entusiasmados porque Opus 5 puede elevar el techo del trabajo diario en Claude Code. Son cautos porque usage limits, safety fallbacks, verbosity, subagent spawning y model churn son costes reales de workflow.

El movimiento correcto no es cambiar ciegamente cada tarea difícil a Opus 5. Enruta deliberadamente:

  • Sonnet 5 para ejecución rutinaria;
  • Opus 5 medium/high para trabajo difícil diario;
  • Opus 5 xhigh/max para investigaciones serias;
  • Fable 5 para el trabajo raro que necesita autonomía máxima y justifica sus restricciones.

Si Opus 5 rinde en repos reales como sugieren las docs de Anthropic y las reacciones tempranas, se convertirá en el nuevo modelo de escalación por defecto para equipos Claude Code. Pero quienes más se beneficiarán serán los equipos que ajusten effort, eliminen lastre de prompts viejos y midan trabajo aceptado en vez de vibes de lanzamiento.

Fuentes revisadas​