La función más útil de esta actualización no es que el modelo sea más listo. Es que por fin puedes decidir cuánto esfuerzo le pones a cada cosa, desde la app normal, sin tocar código.
Hasta hace poco el control de esfuerzo vivía solo en la API y en la terminal. Ahora está en el Claude de todos los días. Eso significa que la misma suscripción te rinde distinto según cómo la uses, y la mayoría de la gente ni sabe que existe la perilla.
Esto es lo que trae Opus 4.8, qué cambia en la práctica y qué revisar si construiste algo sobre la API.
Qué es el esfuerzo, en una frase
Es cuánto piensa el modelo antes de contestar, y cuántos tokens está dispuesto a gastar en llegar a la respuesta.
No cambia qué tan capaz es. Cambia qué tan a fondo trabaja. Un esfuerzo bajo te da una respuesta rápida y suficiente; uno alto explora, verifica y se tarda. Es la diferencia entre preguntarle algo a un colega en el pasillo y pedirle que se siente una hora a revisarlo.
Los cuatro niveles
1. Bajo low
Reescrituras de una vez, dar formato, resúmenes cortos. Todo lo que puedes revisar de un vistazo y corregir en diez segundos.
Para qué: limpiar un texto, cambiar el tono de un correo, sacar los puntos de una nota.
2. Medio medium
Correos que sí quieres que alguien lea dos veces, borradores de contenido, tareas normales de código. Es el punto donde la calidad ya se nota y el tiempo todavía no molesta.
Para qué: el 60% del trabajo de oficina de un día normal.
3. Alto high
El que viene por defecto en 4.8. Análisis, cualquier cosa de varios pasos, código que de verdad tiene que funcionar.
Que sea el default importa: si nunca tocaste la perilla, ya estás aquí. Bajarle a medio en tareas simples te ahorra tiempo y consumo sin que la calidad se note distinta.
Para qué: lo que va a tomar una decisión o llegar a un cliente.
4. El nivel extra de Claude Code xhigh
Un escalón arriba del alto, disponible en la terminal. Está pensado para migraciones complejas y para depurar cosas que llevan horas sin resolverse.
Aquí el intercambio es explícito: se tarda bastante más y consume bastante más. Vale la pena cuando el problema ya te costó dos días.
Para qué: trabajo largo y autónomo, no conversación.
El paso que todo mundo se salta: subir el esfuerzo no arregla una instrucción vaga. Si le pediste algo ambiguo, el modelo va a pensar más profundo sobre la pregunta equivocada y te va a entregar una respuesta desenfocada, más lenta y más cara. El orden correcto es: primero escribe bien la petición con esfuerzo medio, y cuando ya salga bien tres veces seguidas, ahí decides si subirle.
Cómo lo uso en un día de trabajo
Aterrizado a una operación real, así se reparte en una semana:
- Bajo para la limpieza de transcripciones de juntas y el formato de reportes que ya vienen armados.
- Medio para el copy de campañas, los seguimientos comerciales y la primera versión de cualquier documento.
- Alto para revisar contratos, armar el análisis de por qué se cayó una campaña, y cualquier cosa que le voy a mandar a un cliente sin que pase por otra revisión.
- El nivel extra solo cuando estoy en la terminal peleándome con un proceso que lleva días sin correr bien.
La regla de dedo: si el error se detecta en un vistazo y corregirlo cuesta poco, bájale. Si el error se descubre tres días después con un cliente enojado, súbele.
El cambio que menos se anuncia y más importa
4.8 es medible más honesto que la versión anterior. Baja la tasa de respuestas incorrectas y es bastante menos probable que deje pasar una falla al revisar código.
Suena aburrido comparado con "es más inteligente", y es lo contrario. En una operación real, el costo no está en las respuestas que salen bien: está en las que salen mal y suenan convincentes. Un modelo que se equivoca menos y que admite más seguido que no sabe te ahorra el trabajo de verificar todo dos veces.
Lo que no cambia: sigue necesitando que tú sepas cuándo dudar. Un modelo más honesto no es un modelo infalible, y en cualquier cosa que toque dinero o datos de clientes la revisión humana sigue siendo obligatoria.
Notas de migración si construyes sobre la API
Aquí es donde algunos flujos se rompen sin aviso. El identificador del modelo es claude-opus-4-8.
- Los parámetros de muestreo se fueron.
temperature,top_pytop_kya no se aceptan. Si tu código los manda, la petición falla. La forma de guiar el comportamiento ahora es el prompt, no la perilla. - El presupuesto fijo de pensamiento se fue. Ya no se define un número de tokens de razonamiento. Se usa pensamiento adaptativo y se controla la profundidad con el nivel de esfuerzo.
- Los mensajes de sistema a media conversación ya no rompen el caché. Este es el cambio que más dinero ahorra en agentes largos: antes, meter una instrucción nueva a la mitad invalidaba todo el prefijo cacheado y volvías a pagar el contexto completo. Ahora no.
- Las negativas vienen con categoría. Cuando el modelo se rehúsa, la respuesta trae un detalle estructurado con el motivo, en vez de un texto que tenías que interpretar a mano. Si tu flujo tenía lógica de reintento basada en leer el mensaje, cámbiala a leer el campo.
Sobre el costo: es el modelo más caro del catálogo de Claude, y esa es toda la decisión. Úsalo donde una respuesta mejor te ahorra dinero real —problemas nuevos, análisis que sostienen una decisión, código que no se puede caer— y usa modelos más baratos en el volumen repetitivo. Los precios exactos por millón de tokens cambian; confírmalos en la documentación oficial antes de presupuestar.
El error que veo más seguido
Poner el esfuerzo más alto en la parte más repetitiva del proceso.
Alguien monta un flujo que clasifica trescientos correos al día, le pone el máximo porque "así sale mejor", y a fin de mes la factura llega tres veces más alta con exactamente la misma calidad. Clasificar un correo no necesita razonamiento profundo: necesita consistencia.
Haz el ejercicio contrario. Toma tu flujo más caro, bájale un nivel de esfuerzo, y corre veinte casos comparando contra la versión anterior. En la mayoría de los procesos operativos no vas a poder distinguir cuál es cuál, y acabas de bajar el costo sin tocar nada más.