Modelo y esfuerzo en Claude Code: saber más frente a esforzarse más

Claude Code te ofrece dos parámetros que parecen "mejorar la respuesta": el modelo y el nivel de esfuerzo. Pero, ¿qué impacto tienen realmente en el resultado? ¿Y cómo saber si debes usar un modelo diferente o simplemente ajustar el nivel de esfuerzo?

Es fácil suponer que elegir un modelo más grande como Fable te dará una respuesta más inteligente que Sonnet, y que un nivel de esfuerzo más alto simplemente significa que Claude piensa más tiempo antes de responder.

La primera suposición es cierta. Nuestros modelos más grandes son más capaces, según los estándares de la industria.

Pero el esfuerzo significa más que "tiempo de pensar". El esfuerzo controla cuánto trabajo hace Claude en tu solicitud en general. Esto incluye cuánto tiempo piensa, pero también:

• cuántos archivos lee;
• cuánto verifica; y
• qué tanto avanza en una tarea de varios pasos antes de consultarte.

Con un nivel de esfuerzo más alto, Claude realiza más de esas acciones (leer archivos, ejecutar pruebas, verificar) antes de volver a consultarte. Con un nivel más bajo, prefiere pedirte más contexto que gastar tokens resolviendo algo por su cuenta.

Cómo funciona la selección del modelo

Para entender qué controla realmente el parámetro del modelo, ayuda empezar desde el principio, desde el momento en que presionas Enter.

Claude Code ensambla tu mensaje junto con el prompt del sistema, las definiciones de herramientas, tu archivo CLAUDE.md, el historial de la conversación y cualquier archivo en contexto. Todo esto se envía como una sola solicitud a la API.

Todo lo que tiene Claude Code se empaqueta en una sola solicitud de API. En el servidor, el texto se tokeniza antes de llegar al modelo.

Sin embargo, el modelo nunca ve nada de eso como texto plano. Lo primero que sucede en el servidor es la tokenización: el texto se divide en piezas, y cada pieza se asigna a un número entero de un vocabulario fijo con el que se entrenó el modelo. const podría asignarse a 1978, await podría asignarse a 4293. A partir de aquí, tu prompt es un arreglo de números enteros.

El tokenizador divide tu texto en piezas y asigna cada pieza a un número entero en un vocabulario fijo. Cada fragmento en la fila superior se convierte en su ID de token (fila inferior); los ID mostrados son ilustrativos.

El trabajo del modelo es tomar ese arreglo y predecir qué token viene a continuación. Para ello, calcula una probabilidad para cada token en su vocabulario y elige entre los más probables. Después de "const x = await", un modelo bien entrenado asigna una alta probabilidad a "fetch" (muy probable) y casi cero a "banana" (no es nada probable).

La predicción del modelo es una probabilidad para cada token en su vocabulario. La diferencia entre la mejor opción y una no relacionada es enorme.

Lo que convierte tus tokens de entrada en esas probabilidades son los pesos (también llamados parámetros): miles de millones de números organizados en grandes matrices. Para predecir un token, el modelo procesa tu entrada a través de esas matrices (una larga cadena de multiplicaciones de matrices) y lee las probabilidades al final. Los pesos son donde vive todo lo que el modelo "sabe".

Los pesos de cada modelo se establecen durante el entrenamiento y, para cuando envías solicitudes, son de solo lectura. Nada en tu prompt, tu archivo CLAUDE.md o tu contexto los cambia. Si te has topado con el término inferencia, eso es todo lo que significa: usar el modelo después de que el entrenamiento ha terminado, con los pesos fijos.

Tu prompt entra, las probabilidades salen. Los pesos en el medio no cambian.

Todo lo que Claude sabe sobre TypeScript, frameworks populares o cualquier otro conocimiento general de programación se codificó en esos pesos durante el entrenamiento.

Tu prompt y contexto aún pueden dirigir la predicción. Poner tu código real frente a Claude es dirigirlo, y funciona muy bien. Sin embargo, esto no agrega nada a los pesos en sí mismos.

Si una biblioteca no existía cuando se entrenó el modelo, no está en los pesos. Puedes poner la documentación en el contexto y Claude la usará, pero eso es dirigir, no enseñar. La respuesta de Claude solo se ve influenciada para esa solicitud en particular, pero el modelo subyacente no ha retenido nada.

Cuando Claude llama con confianza a una API que no existe (una alucinación), eso es que los pesos producen una secuencia de tokens que parece plausible según los patrones de entrenamiento, no una búsqueda fallida.

Entonces, ¿qué hace realmente cambiar el modelo? Intercambia qué conjunto de pesos congelados maneja tu solicitud.

El modelo no genera una respuesta completa de una vez. Predice un token, lo agrega a la secuencia y vuelve a ejecutar todo el cálculo para obtener el siguiente. Una respuesta de 200 tokens son 200 pases separados a través de los pesos. Este bucle es de donde proviene la mayor parte de tu tiempo de espera (y tu costo de salida).

La secuencia crece exactamente un token por paso. El modelo vuelve a leer todo el arreglo cada vez para predecir qué viene después.

El parámetro del modelo decide qué pesos manejan tu solicitud, y también decide cuánto cuesta cada token de salida.

Lo que no decide es cuántos tokens se generan. Ese número puede variar mucho para el mismo prompt, dependiendo de cuánto trabajo decida hacer Claude.

Que es exactamente lo que controla el esfuerzo.

Cómo funciona el esfuerzo

Mientras Claude Code trabaja en una tarea, los tokens que genera se dividen en algunas categorías:

• Razonamiento: el razonamiento que ves en streaming antes y entre las acciones.
• Llamadas a herramientas: bloques estructurados que nombran una herramienta como Read o Edit y sus argumentos, que luego Claude Code analiza y ejecuta.
• Texto para ti: el plan, las actualizaciones de progreso, el resumen al final.

Todos estos son tokens de salida ordinarios del mismo bucle, facturados a la misma tarifa. Los tokens de razonamiento, por ejemplo, se generan exactamente como los otros tokens de salida y permanecen en el contexto durante el resto de ese turno.

Para cuando Claude pasa a escribir código, su razonamiento anterior ya es parte de la entrada, al igual que un archivo que leyó.

Toda la salida de Claude son tokens. El razonamiento, las llamadas a herramientas y el texto para ti se generan desde el mismo bucle.

Entonces, ¿cómo cambia el esfuerzo todo esto? El nivel de esfuerzo se envía al modelo como parte de la solicitud, junto con tu prompt. El modelo fue entrenado para comprender cómo comportarse en cada nivel de esfuerzo, y ese comportamiento aprendido está integrado en los pesos congelados.

Cuando llega tu solicitud, el esfuerzo es solo una entrada más a la que el modelo responde, de la misma manera que responde al texto de tu prompt. Establece qué tan minucioso, y qué tan seguro, debe estar Claude antes de considerar la tarea completada. Esto se sopesa en cada turno, y una mayor confianza requiere más tokens para alcanzarla.

Mismo prompt, dos niveles de esfuerzo. La ruta de alto esfuerzo genera aproximadamente 7 veces más tokens para alcanzar una respuesta de mayor confianza.

En niveles de esfuerzo más altos, Claude a menudo comienza creando un plan, y el nivel de esfuerzo influye en la profundidad y amplitud de ese plan. Pero el plan no está escrito en piedra. A medida que Claude obtiene resultados de sus acciones, actualiza su imagen de cuánto progreso ha hecho y qué tan seguro está del resultado acumulado.

Cuando el paso 1 de un plan de depuración de tres hipótesis encuentra el error, "investigar las hipótesis 2 y 3" puede que ya no sea necesario. Claude generalmente dirá esto explícitamente (por ejemplo, "la primera verificación lo encontró, por lo que las comprobaciones restantes no son necesarias") y saltará adelante. Ves que esto sucede en Claude Code cuando las listas de tareas se revisan a mitad de la ejecución.

Un mayor esfuerzo hace que Claude sea más propenso a verificar dos veces, como confirmar la respuesta que encontró, o aún investigar las hipótesis que podría haber omitido. Sin embargo, generalmente no inflará artificialmente el uso en una tarea simple solo porque el nivel de esfuerzo está al máximo. "Pensar demasiado" es algo que nuestro equipo específicamente monitorea durante el entrenamiento del modelo, ya que degrada la efectividad.

Elegir un nivel de esfuerzo

Para la mayoría de las tareas, usa el nivel de esfuerzo predeterminado del modelo. El valor predeterminado es el nivel en el que Claude escala su uso de tokens a lo que la mayoría de las personas querría gastar en una tarea.

Piensa en el esfuerzo como una anulación manual de qué tan duro y durante cuánto tiempo trabaja Claude. Recurre a él deliberadamente cuando tengas una fuerte preferencia por la minuciosidad o la velocidad según tu dominio o el tipo de trabajo que realizas, y trátalo como una preferencia general, no como una decisión tarea por tarea.

Una nota práctica tras el lanzamiento de Opus 4.8: en nuestras pruebas, la configuración de esfuerzo predeterminada en Opus 4.8 produce mejores resultados por aproximadamente la misma cantidad de tokens que la configuración de esfuerzo predeterminada en Opus 4.7 para la misma tarea.

Qué cambiar cuando Claude se equivoca

Cuando Claude se equivoca, tu primer instinto no debería ser cambiar una configuración. Debería ser revisar el contexto que le diste. ¿Tu prompt es demasiado vago? ¿Claude está conectado a las herramientas adecuadas? ¿Tiene las habilidades correctas?

Si estás aumentando el esfuerzo en una tarea que no debería necesitarlo, la solución suele estar antes: en tu contexto, en tu archivo CLAUDE.md, o en cómo está definida la tarea.

Pero supongamos que has dado un contexto claro y Claude aún se equivoca. La pregunta que debes hacerte es: ¿no intentó lo suficiente, o no sabía lo suficiente?

Modelo: el problema era demasiado difícil

Elige un modelo más grande cuando el problema sea realmente difícil, como errores sutiles, dominios desconocidos o decisiones de arquitectura. Un modelo más grande es lo que quieres cuando el modelo más pequeño está equivocado con seguridad sin importar cuánto contexto le des.

Los modelos más grandes también son mejores para manejar la ambigüedad. En modelos más pequeños, las instrucciones específicas que dirigen la ejecución son una mejor receta para el éxito.

Elige un modelo más pequeño cuando el trabajo sea rutinario: ediciones que puedas describir con precisión, cambios mecánicos, preguntas sobre código que ya está en contexto. No hay razón para pagar por una capacidad que la tarea no necesita.

Si Claude tenía todo el contexto pertinente, claramente lo intentó y aún así se equivocó; esa es una señal para elegir un modelo más grande. Y si estás en el modelo más grande y el trabajo ha sido rutinario por un tiempo, reducirlo aumentará la velocidad y generalmente reducirá el costo sin afectar la calidad del resultado.

Esfuerzo: Claude no intentó lo suficiente

Elige un nivel de esfuerzo más alto si Claude lo hizo mal por no intentar lo suficiente: omitir un archivo, no ejecutar las pruebas o no verificar su trabajo. Esto es más relevante si has seleccionado un nivel de esfuerzo por debajo del valor predeterminado del modelo.

El especialista, el experto y el generalista

Una forma en la que me gusta pensar en estas dos configuraciones es que Fable es un especialista que puede manejar problemas que casi nadie más puede, Opus es el experto, y Sonnet es un generalista realmente bueno. El nivel de esfuerzo decide cuánto tiempo cualquiera de ellos dedica a tu tarea.

Opus con poco esfuerzo es como tener cinco minutos con un experto que tiene una profunda experiencia con problemas como el tuyo. Traen conocimiento que no está en ninguna parte de tu base de código; patrones que han visto antes, trampas que saben que deben verificar, el tipo de experiencia que solo se obtiene resolviendo muchos problemas similares. Pero cinco minutos significan una lectura rápida de tu código, no un paso cuidadoso por cada archivo.

Sonnet con alto esfuerzo es el generalista con toda la tarde. Son excelentes programando, y leerán todo, ejecutarán cosas, verificarán su trabajo y terminarán comprendiendo tu código específico a fondo.

Fable es el especialista al que llamas cuando todos los demás están estancados. Incluso con poco esfuerzo, detectarán lo que nadie más haría. Ese reconocimiento también es por lo que estás pagando más, por lo que vale la pena guardarlo para las tareas que realmente lo necesitan.

Ninguno de estos es universalmente "mejor". El parámetro del modelo es aproximadamente qué tan capaz; el parámetro de esfuerzo es aproximadamente qué tan minucioso. La mayoría de las tareas reales necesitan un poco de ambos.

Esfuerzo, modelo y consumo de tokens

Entonces, ¿cómo interactúan la selección del modelo, el esfuerzo y el consumo de tokens? Depende de la tarea.

En trabajo rutinario con el mismo nivel de esfuerzo, tanto los modelos más grandes como los más pequeños generalmente lo hacen bien. El modelo más grande consume más tokens con pasos de verificación adicionales, a un precio más alto por token. Es por eso que cambiar al modelo más pequeño para tramos rutinarios ahorra dinero real sin costo de calidad.

Las curvas son solo para fines ilustrativos, mostradas para una tarea única lo suficientemente simple como para ser realizada rápidamente por ambos modelos. No representan datos de referencia reales.

En trabajos más difíciles y de varios pasos, la ecuación se invierte. El modelo más pequeño tiene que esforzarse hasta el límite de su capacidad, quemando iteraciones, mientras que el modelo más grande alcanza el mismo nivel de calidad en menos pasos.

Estás pagando más por token por el modelo más grande, pero en tareas que realmente esfuerzan al modelo más pequeño, el costo total por tarea puede resultar menor. Y lo que es más importante: el modelo más grande puede completar tareas que el más pequeño no puede, incluso en los niveles de esfuerzo más altos.

Esto es más pronunciado con Fable. En trabajos largos y de varios pasos, se distancia aún más. En nuestras pruebas, terminó trabajos que Opus y Sonnet no pueden alcanzar en ningún nivel de esfuerzo. También cuesta más por token, que es la otra razón para guardarlo para el trabajo que realmente lo necesita.

Las curvas son solo para fines ilustrativos, mostradas para una tarea única lo suficientemente difícil como para esforzar a ambos modelos. No representan datos de referencia reales.

El punto clave en los gráficos anteriores: el esfuerzo elige qué tan lejos está dispuesto a viajar Claude a lo largo de la curva. Eso no significa que Claude necesitará ir tan lejos para completar la tarea.

Por último, el esfuerzo da forma al consumo de tokens, pero no lo limita. El único límite duro en el sistema es max_tokens, que trunca una respuesta a mitad de camino cuando se alcanza, pero es un instrumento contundente y es relevante principalmente para los desarrolladores de API. Controles más suaves como los presupuestos de tarea o pedirle a Claude que sea breve en tu prompt son más útiles. Son una guía que el modelo está entrenado para seguir (buscará concluir a medida que se acerca al límite) en lugar de un muro contra el que choca.

El esfuerzo cambia cuánto trabajo hace Claude. El modelo cambia lo que Claude sabe.

Cuando no estés satisfecho con un resultado, revisa el contexto antes de tocar cualquiera de las dos configuraciones: dale a Claude un prompt claro, las herramientas y habilidades adecuadas, y una forma de verificar su propio trabajo.

Si Claude aún se equivoca, pregúntate: ¿no sabía lo suficiente, o no intentó lo suficiente? No saber lo suficiente es un problema del modelo, no intentar lo suficiente es un problema de esfuerzo.

Este artículo fue escrito por @lydiahallie, miembro del personal técnico del equipo de Claude Code.