Reasoning effort, fast mode o ultracode: cuál usar y cuándo

¿Qué es el effort y cómo decide cuánto piensa el modelo?

El effort es el ajuste con el que eliges cuánto trabajo pone el modelo en una respuesta; en OpenAI se llama reasoning effort y en Google, thinking level. En el artículo sobre SWE-bench contamos que el mismo modelo obtiene otra puntuación cuando solo cambia el effort, y en el artículo sobre subagentes, cómo heredan el effort los subagentes. Este artículo pone el effort junto a dos ajustes con los que se confunde a menudo:

Los tres proveedores ya no regulan el razonamiento con un número de tokens, sino con un nivel que tiene nombre. La documentación de Anthropic dice claramente qué es ese nivel: no un presupuesto, sino una indicación al modelo («a behavioral signal, not a strict token budget»). No afecta solo al razonamiento, también al texto y a las llamadas a herramientas; cuanto más bajo es el effort, menos llamadas a herramientas hace el modelo, y más breves.

Fuente: documentación de las API de los tres proveedores, 20 de octubre de 2026. GPT-6.1 Sol no admite los niveles none y minimal. En Google, el nivel minimal no garantiza que el razonamiento esté apagado, ni siquiera en los modelos que lo admiten.

En los tres, el límite estricto es el de tokens de salida: max_tokens en Anthropic, max_output_tokens en OpenAI y Google. Anthropic lo resume así: el effort es una indicación flexible y max_tokens, un límite estricto. Si el modelo llega a ese límite mientras razona, la respuesta se corta o vuelve vacía; OpenAI y Google dicen claramente que el razonamiento gastado se factura igual.

Este año cambiaron dos cosas. La primera: el antiguo presupuesto de tokens se va. En Anthropic, budget_tokens está obsoleto en los modelos 4.6, y los modelos 4.7 y posteriores lo rechazan; en Google, thinking_budget está obsoleto para Gemini 4 Argon. En Opus 5.5 y en Gemini 4 Argon ni siquiera se puede apagar el razonamiento; el único mando que tienes es el nivel. La segunda: los valores por defecto bajaron. Opus 5.5, Haiku 5.5, GPT-6.1 Sol y Gemini 4 Argon empiezan en medium; así, Opus 5.5 empieza un nivel por debajo de Opus 5. El valor por defecto de Sonnet 5.5 depende de dónde se ejecute: high en la API de Claude, medium en Claude Code.

No compares nombres de nivel entre modelos. La documentación de Claude Code dice que la escala se calibra para cada modelo por separado, así que el mismo nombre no significa la misma cantidad de razonamiento en modelos distintos; los niveles de Sonnet 5.5 se recalibraron respecto a Sonnet 5. La documentación de Codex también dice que los niveles no se corresponden exactamente entre generaciones de modelos.

Cambiar el effort a mitad de conversación tiene un precio. En Anthropic, cambiar el effort de toda la petición invalida la caché del prompt; el effort por mensaje (beta) cambia el nivel conservando la caché, y funciona en Opus 5.5, Sonnet 5.5 y Haiku 5.5. En OpenAI, configuration_update hace lo mismo desde el 3 de septiembre. Por qué se rompe la caché lo contamos en el artículo sobre prompt caching.

¿Cómo se ajusta el effort en las cinco herramientas?

Las cinco herramientas te dejan elegir el nivel con un comando o un ajuste. Se diferencian en el valor por defecto y en si hay un modo superior que reparte el trabajo entre subagentes. La tabla la sacamos el 20 de octubre de 2026 de la documentación y las notas de versión de cada herramienta:

Fuente: documentación y notas de versión de cada herramienta, 20 de octubre de 2026. «No figura en la documentación»: en las páginas que leímos ese día no encontramos ninguna frase que lo diga. --effort llegó a Copilot CLI con la versión 1.0.10 (20 de marzo), y max para los modelos de Anthropic con la 1.0.60 (5 de junio). /effort llegó a Antigravity CLI con la versión 1.1.5 (21 de julio), y /boost a la aplicación de Antigravity con la 2.12.0 (2 de septiembre). HydraFusion Max se anunció el 14 de octubre.

En Claude Code, /effort abre un control deslizante; también puedes escribir el nivel directamente, por ejemplo /effort high. effortLevel en el archivo de ajustes admite valores de low a xhigh; max no se acepta ahí y solo se puede elegir para una sesión. También se puede poner effort en la definición de una skill o de un subagente; mientras esa skill o ese subagente se ejecuta, ese valor sustituye al nivel de la sesión.

En Codex, el nivel lo fija model_reasoning_effort en ~/.codex/config.toml; qué niveles puedes elegir depende del modelo y del cliente. Para el modo Plan puedes dar un valor propio; si lo dejas vacío, el modo Plan usa su propio valor por defecto. Un ejemplo:

model_reasoning_effort = "high"
plan_mode_reasoning_effort = "xhigh"

La página de modelos de Codex distingue los dos niveles más altos: Max da a una sola tarea más tiempo para razonar, y Ultra reparte las partes separadas de un trabajo complejo entre subagentes en paralelo. La misma página dice que la mayoría de las tareas no necesita ninguno de los dos.

En Copilot CLI, --effort (nombre largo --reasoning-effort) admite cinco niveles, de low a max; max solo existe en los modelos de Anthropic. Desde la versión 1.0.88, el reasoningEffort de la definición de un agente personalizado se aplica cuando se selecciona ese agente; un nivel que pases explícitamente en la línea de comandos sigue teniendo prioridad. En VS Code, el nivel se elige en el submenú «Thinking Effort», que se abre al pulsar la flecha junto al nombre del modelo en el selector, y se recuerda por sesión. La documentación de GitHub también indica el precio: un nivel más alto gasta más tokens y, por tanto, más créditos de IA; empieza en el nivel normal y súbelo solo para las tareas difíciles.

En Cursor, el plan Plus ejecuta los modelos propios de Cursor con ajustes fijos: effort medium, Fast desactivado. Para elegir un nivel de effort y Fast hace falta Premium o superior. El Max Mode de los antiguos planes por peticiones no es un nivel de effort, sino una opción aparte que amplía la ventana de contexto del modelo.

En Antigravity CLI, /effort elige el nivel y lo guarda para las sesiones siguientes; --effort vale solo para esa ejecución. La mayoría de los modelos ofrecen low, medium y high; xhigh y max solo existen en algunos. Si todavía usas Gemini CLI: en su lista de comandos no hay ninguno para el effort, y el ajuste del razonamiento está solo en las definiciones de modelos de la configuración. Google sustituyó Gemini CLI por Antigravity CLI para los usuarios del nivel gratuito y de Google One el 18 de junio de 2026; con claves de API de pago, Gemini CLI se puede seguir usando.

¿Qué es ultracode y en qué se diferencia del effort?

Según la documentación de Claude Code, ultracode no es un nivel de effort, sino un ajuste de Claude Code. Cuando está activado, Claude planifica un flujo de trabajo dinámico (dynamic workflow) para cada tarea de cierta envergadura: escribe un script de JavaScript que divide el trabajo en partes y dirige a muchos subagentes, y lo ejecuta en segundo plano. Según la documentación de los flujos de trabajo, una sola petición puede convertirse en varios flujos seguidos: uno para entender el código, otro para hacer el cambio y otro para verificarlo.

El effort, en cambio, decide cuánto piensa un solo agente. Los dos son independientes: ultracode funciona en el nivel en que esté la sesión. Esta separación es nueva. Cuando ultracode se anunció junto con los flujos de trabajo dinámicos el 28 de mayo, subía el effort a xhigh. Desde la versión 2.1.284 (28 de septiembre) es un interruptor aparte dentro de /effort y no toca el nivel. Lo que se escribió antes de esa fecha describe el comportamiento antiguo. Queda una excepción: si inicias la sesión con claude --effort ultracode, el nivel también pasa a xhigh. Las cuatro formas de activar ultracode las contamos en el artículo sobre subagentes.

Para el coste no hay multiplicador. Anthropic no publica cuántas veces más tokens gasta ultracode; la documentación dice que cada petición gastará más tokens y tardará más, y que con una suscripción llegarás antes a un límite de sesión o semanal. Con ultracode activado se quitan dos frenos: no aparece el aviso «Large workflow» de los flujos que prevén más de 25 agentes o 1,5 millones de tokens, y el límite de subagentes simultáneos de la sesión no se aplica a los subagentes que se lanzan con la herramienta Agent. Los límites propios del flujo de trabajo siguen en su sitio: por defecto 16 a la vez y como máximo 1.000 agentes por ejecución. Ultracode no se activa si los flujos de trabajo están desactivados o si el modelo no admite xhigh.

Las demás herramientas tienen su versión de la misma idea. Ninguna es lo mismo que el effort:

Fuente: documentación de Claude Code, Codex, HydraFusion y Antigravity, 20 de octubre de 2026. En Codex, Ultra aparece como un nivel del control deslizante de effort (de Light a Ultra); en cambio, no está entre los valores de reasoning.effort de la API de OpenAI.

Ultrathink, de nombre parecido, es otra cosa. Si escribes ultrathink en un prompt, Claude Code añade para ese turno una instrucción que pide pensar más a fondo, pero el nivel de effort que se envía a la API no cambia. Así que ultrathink es una petición para un solo mensaje, el effort es el ajuste de la sesión y ultracode es con cuántos agentes se hace el trabajo.

En las fuentes que leímos no hay ninguna medición que compare ultracode activado y desactivado, ni tampoco para los modos parecidos. Por eso, prueba ultracode en un trabajo grande que se pueda dividir, y primero en una porción pequeña. La documentación de los flujos de trabajo también recomienda empezar por una sola carpeta para ver el gasto antes de lanzar un trabajo grande.

¿Qué acelera el fast mode y cuánto cuesta?

El effort cambia cuánto piensa el mismo modelo; el fast mode, a qué velocidad escribe su respuesta el mismo modelo. Los proveedores venden el mismo modelo a varias velocidades: más barato para quien puede esperar, más caro para quien tiene prisa. Los datos de la tabla los sacamos el 20 de octubre de 2026 de la documentación de precios y de niveles de servicio de los proveedores:

Fuente: documentación de precios y de niveles de servicio de los proveedores, 20 de octubre de 2026. Precios por MTok, entrada / salida. En OpenAI, Priority pasó a llamarse Fast mode el 30 de julio. El Flex de Google está en versión preliminar. En Anthropic, el fast mode no se puede usar junto con la Batch API.

La documentación de Anthropic distingue qué acelera el fast mode: aumenta los tokens de salida por segundo, no el tiempo hasta que llega el primer token. El modelo y su inteligencia no cambian. La diferencia se nota en una respuesta larga o en un diff largo; en preguntas cortas apenas la notarás. Tiene otro coste: las peticiones a velocidades distintas no comparten la caché. La documentación de Claude Code explica la consecuencia: la primera vez que activas el fast mode en una conversación, pagas todo el contexto acumulado al precio del fast mode sin caché. Por eso lo más barato es activarlo al empezar la sesión.

Así están las cinco herramientas:

• Claude Code: /fast lo activa y lo desactiva. En Opus 5.5 la velocidad de salida se multiplica hasta por 2,5, a $8 / $40 por MTok. En los planes de suscripción no se paga con el límite del plan, sino con créditos de uso (usage credits). En la API, el fast mode de Opus 5.5 salió de la research preview el 15 de octubre; la página del fast mode de Claude Code seguía diciendo «research preview» el 20 de octubre de 2026.
• Codex: /fast en la CLI; de forma permanente, service_tier = "fast", que en la petición se envía como priority. Según la documentación, el fast mode descuenta del límite de tu suscripción 2,5 veces la tarifa estándar, y de los créditos comprados 2 veces. Desde el 8 de octubre, GPT-6.1 Sol también tiene Ultrafast: 8 veces del límite, 6 veces de los créditos; solo en Pro $500 y en los planes Enterprise y Edu que cumplan los requisitos.
• GitHub Copilot: no hay un interruptor de velocidad para toda la herramienta; la versión rápida aparece en el selector de modelos como un modelo aparte. «Claude Opus 4.8 (fast mode)» está en versión preliminar desde el 29 de junio de 2026 y cuesta más que Opus 4.8 estándar; en Business y Enterprise tiene que activarlo un administrador.
• Cursor: Fast es una opción aparte en la tabla de modelos; en modelos como Grok 4.7 se puede elegir por el doble de precio. En el plan Plus está desactivado.
• Antigravity: la documentación no dice nada de un nivel de velocidad de pago.

El precio de los niveles baratos es esperar o que te rechacen. El nivel flex de OpenAI puede devolver 429 con carga; esas peticiones no se cobran. El Flex de Google no sube una petición por su cuenta al nivel estándar cuando la capacidad está llena; te deja a ti el reintento. En un trabajo que alguien espera delante de la pantalla, eso es una sorpresa; en un trabajo por lotes que corre de noche, es la mitad del precio.

¿Más effort significa un resultado mejor?

Hasta cierto punto. Miramos tres tipos de pruebas: la medición del propio fabricante, un índice independiente y nuestros propios registros. Los resultados que declara el fabricante están marcados como tales.

El barrido de effort de la documentación de costes de Anthropic lo dibujamos en el artículo sobre SWE-bench: en un subconjunto de SWE-bench Pro que eligió la propia Anthropic, Opus 5.5 resuelve cada vez más tareas al pasar de low a xhigh, y el coste por tarea se multiplica. El mismo documento tiene una idea más útil: en vez de ejecutarlo todo en un nivel alto, ejecutar primero en low y repetir en high solo los fallos. En low falló el 13 % de las tareas; al repetirlas en high, se resolvió cerca del 97 % de las tareas, a unos $0,17 por tarea. Con todo en high, el resultado fue del 95,3 % a $0,29. Es un resultado declarado por el fabricante y tiene dos condiciones: hace falta una señal que indique el fallo (allí, los propios tests del benchmark), y cada tarea que falla al primer intento espera dos ejecuciones.

En el lado independiente, el Coding Agent Index de Artificial Analysis mide el mismo modelo en cada nivel de effort, dentro de una herramienta de programación: 303 tareas, 3 intentos por tarea. Los resultados del 20 de octubre de 2026:

Fuente: Artificial Analysis, la página en directo el 20 de octubre de 2026; una sola instantánea. Cada celda da la puntuación del índice y el coste medio por tarea. La página no da intervalo de confianza; una diferencia de pocos puntos puede ser ruido. Cuando un modelo se niega por motivos de seguridad, otro modelo puede terminar el intento, y el intento cuenta igual: en las filas de Sonnet 5.5, eso pasó en entre 18 y 45 de 909 intentos. Los nombres de nivel se calibran para cada modelo por separado, así que lee la tabla columna a columna, no fila a fila.

Los tres modelos muestran tres cosas distintas. Sonnet 5.5 sube en cada nivel, pero el coste por tarea es de $0,48 en low y de $14,19 en max; la duración media de una tarea también pasa de unos 6 minutos a 87 minutos. En Haiku 5.5, max cuesta 4,2 veces lo que xhigh y puntúa menos. GPT-6.1 Sol es casi plano entre niveles: entre su puntuación más baja y la más alta hay 5,7 puntos.

En las mediciones del propio fabricante, la ganancia también se aplana en los niveles más altos. Según la system card de Opus 5.5 (declarado por el fabricante), el modelo obtuvo un 66,4 % en Terminal-Bench 4.0 con xhigh y un 64,8 % con max; Anthropic considera la diferencia dentro del ruido (error estándar ±2,6 puntos). En la misma ficha, la mejor puntuación de Opus 5.5 en FrontierCode (54,6 %) está en medium; por encima de medium la puntuación baja, y en max vuelve en gran parte. FrontierCode penaliza los cambios que la tarea no pedía; cómo el modelo se sale del alcance con un effort alto lo contamos en el artículo sobre SWE-bench.

En nuestros propios registros vimos otra cosa. diffox es una herramienta de revisión de código con IA; ejecutamos varias veces el modelo de Claude que usamos sobre los pull requests de un conjunto de benchmark público, cambiando solo el effort. Cada ejecución consta de las mismas 100 llamadas al modelo. Como los tokens de razonamiento se facturan dentro de los tokens de salida, contamos si una llamada había pensado mirando si su respuesta tenía un bloque thinking:

En medium no pensó ninguna llamada; el modelo escribió la respuesta directamente. En high pensaron la mayoría de las llamadas, en xhigh todas, y la salida y el tiempo por llamada crecieron en consecuencia. Es decir, con adaptive thinking el effort cambia más si el modelo piensa o no que cuánto tiempo piensa. La documentación de Anthropic dice lo mismo: en modo adaptativo, el effort decide con qué frecuencia y con qué profundidad piensa el modelo, y en los niveles bajos puede saltarse el razonamiento por completo en problemas sencillos. Un segundo conjunto de benchmark dio el mismo cuadro: en medium no pensó ninguna de 200 llamadas; en high pensaron 88 de 200. Max solo lo probamos en dos llamadas: las dos pensaron, con 61.470 y 83.150 tokens y 423 y 745 segundos por llamada.

Que subir el effort haga detectar más errores es algo que nuestros registros no muestran. Para decirlo hacen falta ejecuciones repetidas en cada ajuste; tenemos una o dos ejecuciones por ajuste, y la diferencia no es mayor que la oscilación normal entre dos ejecuciones. Por qué no contamos lo que sale de una sola ejecución como un resultado lo explicamos en el artículo sobre LLM-as-a-judge.

¿Qué ajuste elegir para cada trabajo?

Las fuentes coinciden en esto: empieza con el valor por defecto del modelo y súbelo solo midiendo en tu propio trabajo. OpenAI dice que veas el effort como un mando de ajuste fino, no como la vía principal para recuperar calidad. Google propone probar los tres niveles en tu propia evaluación y quedarte con el más bajo que cumpla tu listón. Un resumen para los trabajos más habituales:

Los motivos detrás de las tarjetas están en la documentación. La documentación de Claude Code advierte de rendimientos decrecientes y de exceso de razonamiento en max, y pide probarlo antes de adoptarlo en general; la de Codex también dice que la mayoría de las tareas no necesita ni Max ni Ultra. OpenAI incluye la seguridad y la revisión de código entre los usos habituales de xhigh, pero solo cuando tu propia evaluación muestra un beneficio claro. Los modos ultra sirven cuando puedes dividir el trabajo en partes con sentido; en un único problema difícil que no se puede dividir, tiene más sentido que un solo agente piense más tiempo. Para bots de pull request y trabajos de CI, elige el nivel estándar: flex puede rechazar peticiones con carga y batch puede tardar horas.

Ayudan otras tres costumbres:

• Añade una instrucción de alcance. Si la salida va a ser un diff destinado al merge, añade al prompt una frase corta que le pida al modelo no salirse del alcance de la tarea. Según Anthropic, por encima de high Opus 5 hizo más cambios de los que pedía la tarea, y con esta instrucción la puntuación se recuperó en la mayoría de esas tareas.
• Cambia el effort por mensaje. En una sesión larga, cambiar el nivel de toda la petición invalida la caché. El effort por mensaje de Anthropic y el configuration_update de OpenAI cambian el nivel conservando la caché.
• Primero el nivel barato, luego el caro. Si puedes comprobar la salida con un test o un verificador, ejecutar primero en un nivel bajo y repetir solo los fallos en un nivel alto salió más barato en la medición de Anthropic que ejecutarlo todo en high.