Claude Opus 4.8: El único ajuste que lo decide todo

Claude Opus 4.8: El único ajuste que lo decide todo

Lo que me convenció de Claude Opus 4.8 no fue el gráfico de benchmarks. Fue una refactorización que venía postergando.

Tenía una clase de servicio en Laravel que, tras cuatro meses de acumulación de funcionalidades, se había convertido en un monstruo de 600 líneas — el tipo de archivo donde cambias un método y tres tests no relacionados se ponen en rojo. Con Opus 4.7, había intentado dos veces que el modelo desenredara el código. Ambas veces se detuvo a mitad de camino, declaró el trabajo "sustancialmente completo" y me dejó con un trait a medio extraer y una suite de tests rota. Clásico 4.7. Seguro de sí mismo, y después silenciosamente perezoso.

La mañana del 28 de mayo, el día en que salió Claude Opus 4.8, lo apunté al mismo archivo. Mismo prompt. Mismo repositorio. Subí el nivel de esfuerzo a max, presioné enter y fui a prepararme un café.

Cuando volví, había extraído tres clases cohesivas, reescrito los bindings en el service provider, actualizado cada test, ejecutado la suite, encontrado dos edge cases reales que había introducido y los había corregido — sin preguntar. Luego me dijo, con toda naturalidad: "Tengo bastante confianza en la extracción, pero no toqué la capa de caché porque el comportamiento original era ambiguo y no quise adivinar." Esa última frase es toda la historia de esta versión. No solo que terminó el trabajo. Sino que me dijo exactamente dónde no intervino.

Ya llevo más de una semana usando Opus 4.8 como mi herramienta diaria — trabajo con clientes, el pipeline de contenidos de este blog, un proyecto SaaS secundario a medio terminar. Este es el veredicto real más allá del gráfico de Anthropic, y el único ajuste que decide si terminas amando este modelo o maldiciéndolo.

Qué lanzó Anthropic realmente el 28 de mayo

Claude Opus 4.8 salió en vivo el 28 de mayo de 2026, construyéndose directamente sobre Opus 4.7. El propio enfoque de Anthropic en el anuncio oficial es inusualmente contenido: se construye sobre 4.7 con "juicio más agudo, más honestidad sobre su propio progreso y la capacidad de trabajar de forma independiente por más tiempo que sus predecesores."

Dos cosas prácticas importan antes de meternos con el modelo en sí.

Primero: el precio no cambió. Opus 4.8 se lanzó el mismo día al mismo coste por token que 4.7 — 5 $ por millón de tokens de entrada y 25 $ por millón de tokens de salida a velocidad estándar. Eso suena aburrido hasta que has vivido suficientes lanzamientos de modelos para conocer el patrón habitual: "modelo más inteligente, factura más abultada." Esta vez no. Anthropic también abarató el modo rápido. Y hay una ganancia de eficiencia más silenciosa enterrada en la documentación: high effort en 4.8 consume aproximadamente los mismos tokens en una tarea de programación que la antigua configuración xhigh en 4.7 — con una puntuación más alta. Obtienes más capacidad de razonamiento por token, no solo más razonamiento por dólar.

Segundo: los rate limits de Claude Code subieron. Anthropic elevó los límites específicamente para acomodar el mayor consumo de tokens con los nuevos niveles de esfuerzo — una señal clara de cómo este modelo está diseñado para ser utilizado. Esperan que gastes más tokens en tareas difíciles. Construyeron el margen. Si has seguido cómo Anthropic duplicó los rate limits de Claude Code a principios de este año, esta es la misma trayectoria: más potencia computacional dirigida a quienes realmente construyen con ella.

Así que el titular no es "Opus 4.8 es un poco más inteligente." Es "Opus 4.8 es más inteligente, cuesta lo mismo y te da un nuevo dial para controlar cuánto piensa." Ese dial es todo el juego. Llegaremos a ello. Primero, abordemos el gráfico, porque ya lo has visto y tienes preguntas.

Los números de benchmark — incluyendo el único que pierde

Aquí está la comparación que Anthropic publicó, directamente del anuncio. Reproduzco las cifras exactas porque las brechas cuentan más que el titular.

Fíjate en el salto de SWE-Bench Pro: de 64,3 % a 69,2 %. Casi cinco puntos de ganancia en programación agéntica en un point release, mientras GPT-5.5 se queda en 58,6 % y Gemini 3.1 Pro va detrás con 54,2 %. Eso no es un error de redondeo. Es la diferencia entre un modelo que termina un cambio en múltiples archivos y uno que se atasca.

Los números de razonamiento se mueven en la misma dirección. Humanity's Last Exam sin herramientas sube de 46,9 % a 49,8 %, y con herramientas a 57,9 % — ambos liderando con claridad. Trabajo de conocimiento en GDPval-AA salta de 1753 a 1890, lo cual en esa escala es un margen significativo sobre los 1769 de GPT-5.5 y está a años luz del 1314 de Gemini.

Ahora la parte honesta. Opus 4.8 no gana en todo.

En programación agéntica en terminal — Terminal-Bench 2.1 — GPT-5.5 sigue ganando, 78,2 % frente a 74,6 %. Esa es una derrota real, no un margen de error, y mentiría si dijera lo contrario. Si tu flujo de trabajo depende mucho del terminal — cadenas largas de comandos shell, orquestación de CI, bucles agénticos de bash puro — GPT-5.5 y Codex todavía tienen ventaja ahí. Ejecuté ambos en paralelo en el mismo repositorio durante varios días, y la diferencia es visible: Codex es simplemente un poco más seguro cuando toda la tarea vive en el terminal. Ya escribí antes sobre ejecutar Claude Code y Codex en paralelo en el mismo repo, y 4.8 reduce esa brecha de terminal respecto a donde estaba 4.7 (66,1 %) — pero no la cierra.

Si viniste aquí buscando que "Opus 4.8 destruye todo" — esa no es la verdad. La verdad es: lidera en seis de siete categorías, a menudo por mucho, y pierde una — programación en terminal — frente a GPT-5.5. Guarda ese asterisco en mente. Será importante cuando hablemos de qué modelo elegir en cada momento.

Pero aquí está lo que el gráfico no puede mostrarte. Ninguno de estos números significa nada hasta que entiendas la palanca que los controla.

Niveles de esfuerzo: El ajuste que lo decide todo

La función estrella de Opus 4.8 no es un benchmark. Es un control deslizante.

Dentro de Claude Code, ahora puedes configurar el nivel de esfuerzo del modelo en cinco pasos: low → medium → high (por defecto) → max → ultra. Esto es lo más importante que debes entender de esta versión, porque es la diferencia entre el modelo que resolvió brillantemente mi refactorización y el modelo que la habría arruinado.

Así se comportan los niveles en la práctica:

El modelo mental que me funcionó: el nivel de esfuerzo es un presupuesto de pensamiento. Súbelo y el modelo razona con más intensidad, mantiene más contexto en memoria de trabajo y persiste en tareas que de otro modo abandonaría. Bájalo y obtienes respuestas rápidas y baratas que son perfectas para una consulta pero se desmoronan ante una refactorización real.

Una nota sobre nomenclatura, porque me confundió y a ti también te confundirá. La propia documentación de Anthropic describe los niveles subyacentes de razonamiento como low, high (por defecto) y un nivel superior "extra"/xhigh — y en Claude Code, el nivel más alto se muestra como ultracode, que combina razonamiento xhigh con orquestación automática de workflows. El modelo de cinco niveles (low / medium / high / max / ultra) es el modelo mental más limpio para el uso diario, y así lo trataré aquí, pero si investigas en el anuncio oficial y encuentras "xhigh" y "ultracode", es la misma marcha superior con diferente etiqueta. No dejes que el vocabulario te confunda — todo es el mismo dial.

Ese nivel superior merece su propio párrafo. Ultra (también conocido como ultracode en Claude Code) es esfuerzo máximo más workflows dinámicos, donde el modelo planifica el trabajo y luego lanza sub-agentes paralelos para abordar problemas a gran escala de forma autónoma. Esta es la parte que genuinamente me sorprendió: los workflows dinámicos pueden orquestar hasta 1.000 sub-agentes paralelos en una sola sesión (ese es el límite duro que Anthropic estableció), y en 4.8 esos agentes funcionan durante más tiempo antes de agotarse. Piensa en "reescribe este módulo, migra los tests, actualiza la documentación y verifica el build" como una sola instrucción, con el modelo escribiendo su propio plan de orquestación y secuenciando las subtareas en lugar de esperar a que tú se las des con cuchara una por una. Luego verifica sus propios resultados antes de informar. Es el sucesor espiritual del trabajo orientado a objetivos que cubrí cuando los comandos /for y /goal cambiaron mi flujo de trabajo con Claude Code — excepto que ahora la orquestación es tarea del modelo, no un comando que le añades encima. Importante saber: los workflows dinámicos se lanzaron como research preview, así que espera algún borde rugoso en este nivel.

Aquí está la trampa, y caí en ella el primer día. El valor por defecto es high, y el valor por defecto está mal para la mitad de tus tareas. Demasiado bajo, y el modelo termina prematuramente o razona débilmente — exactamente la pereza de 4.7 de la que todos se quejaban, excepto que ahora es un ajuste que tú elegiste, no un defecto que heredaste. Demasiado alto, y el modelo sobreanaliza una consulta de configuración de una línea, quema 8.000 tokens y tarda 40 segundos en decirte algo que un grep habría respondido al instante.

La habilidad no es elegir el nivel más alto. La habilidad es ajustar el esfuerzo a la complejidad de la tarea. Ese es todo el juego. Enseguida nos ponemos tácticos.

Cómo se comporta Opus 4.8 de forma diferente — más allá del control deslizante

Los niveles de esfuerzo acaparan los titulares, pero el comportamiento subyacente del modelo cambió de formas que importan igual en el uso diario. Tras una semana, cuatro cambios destacan.

Razona antes de recurrir a herramientas. Este es el grande. Opus 4.7 tenía el gatillo fácil — lanzaba una llamada a herramienta o iniciaba un sub-agente antes de haber pensado realmente si lo necesitaba. 4.8 intenta resolver el problema internamente primero, y solo invoca herramientas o sub-agentes cuando el razonamiento solo no basta. En la práctica esto significa menos llamadas inútiles a herramientas, menos arranques de sub-agentes a medias, y un modelo que se siente como si estuviera pensando en lugar de agitándose sin rumbo.

Calibra la longitud de respuesta según la tarea. Hazle a 4.8 una pregunta factual rápida y obtienes una respuesta corta. Pídele analizar una decisión de arquitectura y obtienes la profundidad que la pregunta merece. 4.7 tenía un solo botón de volumen, fijado en "verboso." 4.8 lee la sala.

Es más honesto sobre su propio progreso. Anthropic ajustó esto explícitamente, y los números lo respaldan — documentaron una reducción de aproximadamente cuatro veces en fallos de código no reportados, lo que significa que 4.8 es mucho menos propenso a despachar silenciosamente un bug y dar el trabajo por terminado. Menos falsos mensajes de "¡listo!". Menos completaciones fantasma donde el modelo jura que los tests pasan y no es así. La historia de la refactorización del comienzo de este post es el ejemplo canónico — me dijo lo que no había tocado y por qué. Esa es la mayor mejora de confianza en esta versión, y es el tipo de cosa que ningún titular de benchmark captura.

El tono se volvió más cálido. Opus 4.7 tenía un toque de lo que la comunidad caritativamente llamaba "sass" — un borde ligeramente rígido, ocasionalmente contrario, más un exceso de precaución de seguridad que le hacía rechazar o vacilar ante solicitudes perfectamente razonables. 4.8 es más colaborativo. Más cálido. Empuja hacia atrás cuando debe pero no sermonea. Si te alejaste por la actitud de 4.7, esto solo podría bastarte para volver.

Hay un cambio más silencioso por debajo de los cuatro, y es en el que Anthropic más se apoyó: la orientación a objetivos es ahora un rasgo central, no un parche. Con 4.7, hacer que el modelo trabajara hacia un resultado — en lugar de solo satisfacer el texto literal de tu último mensaje — requería prompting deliberado y los comandos correctos. 4.8 mantiene el objetivo a lo largo de una tarea larga y se orienta hacia él. Cuando llega a una bifurcación ambigua, hace una pregunta más precisa en lugar de adivinar o estancarse. En una ejecución autónoma de 40 minutos, esa es la diferencia entre volver a trabajo terminado y volver a una excusa educada. También hace que 4.8 haga menos preguntas que 4.7 — pero las que hace son las que realmente desbloquean el trabajo.

Apila esos cuatro con el control deslizante de esfuerzo y obtienes un modelo que no solo puntúa más alto — se siente fundamentalmente más como un compañero de equipo y menos como una herramienta con la que hay que luchar. Lo que nos trae a la parte por la que realmente viniste: cómo usarlo.

Cómo estoy configurando Opus 4.8 en la práctica (paso a paso)

Los benchmarks son teoría. Aquí está la configuración práctica a la que llegué después de una semana de prueba y error. Cópiala y luego ajústala a tu propio trabajo.

Paso 1: Deja de aceptar el nivel de esfuerzo por defecto

Lo primero que hice mal fue dejar todo en high y preguntarme por qué las tareas simples se sentían lentas y caras. No hagas eso. Antes de empezar una tarea, hazte una pregunta: ¿qué tan difícil es esto realmente?

• Buscar algo, renombrar una variable, un rápido "¿dónde está definido X?" → low. Responderá en segundos por una fracción de los tokens.
• Escribir una función enfocada, un cambio en un solo archivo, un bugfix normal → medium.
• La mayoría del trabajo real con features, cambios en múltiples archivos, cualquier cosa donde querrías que un colega pensara de verdad → high (el valor por defecto se gana su lugar aquí).
• Refactorizaciones complicadas, decisiones de arquitectura, depuración de algo genuinamente sutil → max.
• "Migra todo este módulo y verifícalo" — trabajo a escala donde quieres que el modelo planifique y secuencie subtareas → ultra con workflows dinámicos.

Consejo pro: Tengo un post-it en mi monitor que solo dice: "ajusta el dial a la dificultad." Es tonto, y me ha ahorrado más tokens que cualquier prompt ingenioso.

Paso 2: Dile al modelo qué HACER, no qué NO hacer

Este no es un consejo nuevo, pero importa más con 4.8 porque el modelo es mucho mejor siguiendo instrucciones positivas. En vez de "no rompas los tests existentes," escribe "mantén cada test existente en verde y añade nuevos para cualquier comportamiento que cambies." El encuadre positivo le da al modelo un objetivo al que apuntar en lugar de un campo minado que esquivar. La diferencia en calidad de salida es real y consistente.

Paso 3: Dale el por qué detrás de tus instrucciones

El cambio de prompting con mayor apalancamiento que hice para 4.8: explicar la razón. No digas solo "usa el patrón repository aquí." Di "usa el patrón repository aquí porque el próximo sprint vamos a cambiar la fuente de datos de MySQL a una API externa, y quiero que el código que llama no se toque cuando lo hagamos."

Cuando 4.8 entiende el por qué, tanto el cumplimiento como el juicio saltan. Toma mejores decisiones en los huecos que tus instrucciones no cubrieron, porque razona hacia tu objetivo real en lugar de hacer coincidencia de patrones con tus palabras literales. Esto encaja perfectamente con el cambio de comportamiento "razona antes de actuar" — dale buen material de razonamiento y razona bien.

Paso 4: Vigila tus tokens, especialmente en max y ultra

Mayor esfuerzo significa más tokens. Ese es el trato. Los rate limits ampliados te dan margen, pero el margen no es infinito. Mantén un rastreador de tokens activo para que puedas ver cuánto te cuestan realmente max y ultra en tareas reales. La primera vez que ejecuté una migración completa con workflow dinámico en ultra, observé el contador y recalibré inmediatamente — parte de ese trabajo no necesitaba ultra, necesitaba max con un prompt más ajustado. Si te tomas en serio los costes, mis trucos de gestión de tokens en Claude Code siguen siendo aplicables, y aplican con más fuerza ahora que tienes un dial que puede quemar silenciosamente tu presupuesto.

Paso 5: Prueba, no asumas que la mejora ayuda

Aquí está la verdad incómoda que nadie pone en posts de día de lanzamiento: un modelo más nuevo no garantiza mejores resultados para tu caso de uso. Opus 4.8 es claramente un paso adelante en conjunto. Pero tengo una tarea específica de formateo de contenido donde la salida de 4.7 era realmente más limpia para mi pipeline, y mantuve ese prompt ajustado a la manera anterior hasta que lo probé correctamente.

Ejecuta tus workflows reales. Compara. Ajusta. El modelo es un punto de partida, no una respuesta definitiva.

Si prefieres que alguien configure y ajuste todo este workflow de niveles de esfuerzo para el stack de tu equipo en lugar de aprenderlo por las malas, ese es el tipo de trabajo que asumo — puedes ver lo que he construido en fiverr.com/s/EgxYmWD.

La verdad honesta: la mayoría de los "fallos del modelo" son culpa tuya

Déjame decir lo que va a molestar a algunos. Después de una semana con Opus 4.8 y años de usar estos modelos a diario, estoy convencido de que la mayoría de las quejas de "el modelo es tonto / perezoso / rompió mi código" no son fallos del modelo. Son fallos de prompting y configuración del lado del usuario.

Lo vi pasar en tiempo real durante la era 4.7. La gente dejaba el modelo en configuraciones agresivas por defecto, le daba instrucciones vagas de una línea sin justificación, sin contexto, sin objetivo claro, y luego publicaba capturas quejándose de que el modelo "se había rendido." El modelo no se rindió. Hizo exactamente lo que produce una instrucción subespecificada al nivel de esfuerzo incorrecto.

Opus 4.8 lo hace aún más claro, porque ahora el nivel de esfuerzo está en tus manos. Si ejecutas una refactorización difícil en esfuerzo bajo, el modelo terminará prematuramente — y eso no es pereza, eres tú diciéndole que piense superficialmente. Si ejecutas una consulta trivial en ultra, sobreanalizará y quemará tokens — y eso no es hinchazón, eres tú girando el dial más allá de lo que la tarea necesita.

No exonero totalmente a Anthropic. El lanzamiento inicial tuvo bugs — algunas personas tuvieron comportamiento inestable en las primeras 48 horas, y yo mismo atrapé un bucle extraño de sub-agentes antes de que se estabilizara. El sentimiento de la comunidad es mixto-pero-positivo, lo cual es honesto: la gente ama la programación y el estilo de colaboración más cálido, algunos encontraron bordes ásperos en el lanzamiento. Anthropic itera basándose en feedback y logs de usuarios, así que los puntos ásperos tienden a suavizarse en días. Ese ha sido el patrón a lo largo de 4.6 y 4.7.

Pero la lección duradera se mantiene: el modelo es más capaz de lo que tus valores por defecto le permiten ser. Arregla los valores por defecto antes de culpar al modelo. Ese único cambio de mentalidad hará más por tu producción que esperar la versión 4.9.

Lo que realmente estoy viendo en el uso diario

No voy a inventar cifras precisas que no pueda respaldar — esa es una gran manera de perder tu confianza. Pero puedo contarte los patrones consistentes de una semana de trabajo real en repos de clientes, mi pipeline de contenido y un proyecto secundario.

En tareas de programación agéntica, la diferencia entre 4.7 y 4.8 es más obvia en trabajos largos. El tipo de refactorización en múltiples archivos que 4.7 habría abandonado a dos tercios del camino, 4.8 la lleva a completar — y eso encaja exactamente con el salto de SWE-Bench Pro de 64,3 % a 69,2 %. La autonomía sostenida es la función estrella en la práctica. Simplemente sigue adelante donde 4.7 se detenía.

La eficiencia de tokens es lo que estoy vigilando más de cerca. Anthropic afirma mejoras, y el comportamiento de "razona antes de recurrir a herramientas" debería significar menos llamadas inútiles. En mi uso se cumple en general — menos llamadas basura a herramientas en esfuerzo medio y alto. Pero max y ultra son genuinamente caros, y eso no es una regresión, es el diseño. Ganancias de eficiencia en la gama baja a media, gasto deliberado en la gama alta. Verifícalo en tus propias cargas de trabajo antes de confiar en cualquier afirmación general de "es más barato", incluida la mía.

La mejora en honestidad es la que silenciosamente ha cambiado cómo trabajo. Porque 4.8 es más fiable al señalar lo que no terminó o de lo que no estaba seguro, paso menos tiempo verificando completaciones fantasma. Ese es un ahorro de tiempo real que no aparecerá en ningún gráfico — y a lo largo de una semana de uso diario, suma hasta que el modelo se siente confiable de una manera que 4.7 nunca logró del todo. Para el panorama más amplio de cómo cambiaron los valores por defecto a través de estas versiones, mi análisis anterior de Claude Opus 4.7 sigue estableciendo la línea base sobre la que 4.8 construye.

La expectativa a fijar: esto es un paso adelante genuino, pero la mejora que sientes es proporcional a lo bien que lo conduces. Déjalo en piloto automático y obtendrás un 4.7 ligeramente mejor. Ajusta los niveles de esfuerzo a tus tareas y obtendrás un modelo que termina trabajo que el anterior no podía.

¿Deberías cambiar? Mi respuesta directa

Si ya estás en Opus 4.7 en Claude Code: sí, cámbiate ahora. Mismo precio, mejoras reales, y el control deslizante de esfuerzo por sí solo vale el cambio. No hay razón para quedarse en 4.7 excepto la inercia.

Si vives en la terminal — cadenas pesadas de bash, orquestación de CI, bucles agénticos de shell puro: ten en cuenta que GPT-5.5 sigue ganando en programación de terminal con 78,2 % frente a 74,6 %. Para ese trabajo específico, mantén Codex en tu caja de herramientas. Para todo lo demás, Opus 4.8 es la opción más fuerte por amplio margen. Usar ambos no es cubrirse — es simplemente usar la herramienta correcta para el trabajo correcto, la misma conclusión a la que llegué cuando comparé GPT-5.5 y Opus 4.7 con código idéntico.

Si eres nuevo en todo esto: empieza con Opus 4.8, déjalo en high, y solo empieza a tocar el control deslizante cuando hayas sentido dónde high se pasa y dónde se queda corto. El dial es potente, pero tienes que desarrollar intuición para él.

Preguntas frecuentes

¿Qué son los niveles de esfuerzo en Claude Opus 4.8?

Los niveles de esfuerzo son un presupuesto de pensamiento controlable en Claude Code con cinco configuraciones: low, medium, high (por defecto), max y ultra. Mayor esfuerzo significa razonamiento más profundo, más tokens y respuestas más lentas; menor esfuerzo significa salida más rápida, más barata y más superficial. Ajusta el nivel a la complejidad de tu tarea. Consulta "Niveles de esfuerzo: El ajuste que lo decide todo" arriba para el desglose completo.

¿Es Claude Opus 4.8 mejor que GPT-5.5?

Opus 4.8 lidera en seis de siete benchmarks publicados, incluyendo programación agéntica (69,2 % vs. 58,6 % en SWE-Bench Pro) y razonamiento. GPT-5.5 sigue ganando en programación agéntica de terminal, 78,2 % frente a 74,6 %. Para la mayoría del trabajo de programación y razonamiento, Opus 4.8 es más fuerte; para workflows intensivos de terminal, GPT-5.5 mantiene ventaja.

¿Claude Opus 4.8 cuesta más que Opus 4.7?

No. Opus 4.8 se lanzó el 28 de mayo de 2026 al mismo precio por token que Opus 4.7. Anthropic también elevó los rate limits de Claude Code para acomodar el mayor uso de tokens con los nuevos niveles de esfuerzo. Ten en cuenta que los niveles max y ultra consumen significativamente más tokens por tarea.

¿Qué son los workflows dinámicos en Claude Code?

Los workflows dinámicos son una función de Claude Code, activada en el nivel de esfuerzo ultra, donde Opus 4.8 planifica y orquesta múltiples pasos y subtareas para resolver problemas a gran escala de forma autónoma. En lugar de que tú secuencies cada paso, el modelo descompone el trabajo y lo resuelve por su cuenta.

¿Debo usar siempre el nivel de esfuerzo más alto?

No — ese es el error más común. Max y ultra sobreanalizan tareas simples y queman tokens innecesariamente, mientras que el esfuerzo bajo causa terminación prematura en trabajo difícil. La habilidad es ajustar el esfuerzo a la dificultad de la tarea: low para consultas, high para trabajo real de features, max para refactorizaciones complicadas, ultra para trabajos autónomos a gran escala.

La refactorización que me convenció

¿Recuerdas ese monstruo de 600 líneas en Laravel del comienzo de este post? Lleva seis días en producción. Tres clases limpias, cobertura completa de tests, y la capa de caché que Opus 4.8 deliberadamente se negó a tocar — porque me dijo que no estaba seguro — resultó tener una sutileza que yo mismo había olvidado. Si el modelo la hubiera reescrito "con confianza" como habría hecho 4.7, habría desplegado un bug.

Esa es la mejora real. No los cinco puntos en SWE-Bench Pro. No el tono más cálido. Es un modelo que conoce el límite de su propia competencia y te dice dónde está. Combina esa honestidad con un control deslizante de esfuerzo que realmente sabes manejar, y tienes el primer Claude que se siente menos como una herramienta que supervisas y más como un colega en quien confías.

Así que aquí está tu tarea para las próximas 24 horas: abre Claude Code, toma la tarea más difícil que tengas hoy, configura el nivel de esfuerzo en max, y dale el por qué detrás de lo que le pides. Luego observa qué pasa cuando dejas de pelear contra los valores por defecto y empiezas a conducir el modelo con intención.

Trabajemos juntos

¿Buscas construir sistemas de IA, automatizar workflows o escalar tu infraestructura tecnológica? Me encantaría ayudar.

• Fiverr (desarrollo a medida e integraciones): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluciones empresariales): ramlit.com
• ColorPark (diseño y branding): colorpark.io
• xCyberSecurity (servicios de seguridad): xcybersecurity.io