Sesgo declarado, como siempre: enseño Claude Code a equipos de ingeniería, así que un ajuste nuevo que controla el gasto de tokens sin tocar qué modelo usa cada persona me toca de lleno. Precisamente por eso esta pieza va de qué hace exactamente y qué te toca decidir, no de vender que ahora "gastarás menos" sin matices.
Ya cubrimos cómo tu organización puede
restringir qué modelos usa tu gente
en el selector, en --model y en ANTHROPIC_MODEL. Esto es una palanca
distinta y complementaria: no limita qué modelo se usa, sino cuánto
razona.
Qué ha cambiado
El 9 de septiembre de 2026, la
v2.1.267 de Claude Code añadió el
ajuste maxEffortLevel. La
referencia de settings
lo describe como un ajuste para limitar el nivel de effort para cada modelo o
por modelo, en cualquier proveedor.
Para situarlo hace falta recordar qué es el effort. El
nivel de effort
controla el razonamiento adaptativo: cuánto piensa el modelo en cada paso según
la complejidad de la tarea. La documentación lo resume así: "un effort más
bajo es más rápido y barato para tareas sencillas, mientras que un effort más
alto ofrece un razonamiento más profundo para problemas complejos". Los
niveles, según el modelo, van de low a medium, high, xhigh y max;
high es el valor por defecto en casi todos.
Aquí está el matiz que conviene no confundir. Ya existía effortLevel, que fija
un valor por defecto de effort. Lo nuevo, maxEffortLevel, no fija un
valor: pone un techo. Es la diferencia entre "arranca en medium" y "nunca
subas de medium". Con el techo puesto, cada quien sigue eligiendo su nivel con
/effort o el flag --effort, pero no puede pasarse del tope. Y si alguien
pide un nivel que el modelo activo no soporta, Claude Code cae al mayor nivel
soportado por debajo del pedido; el techo funciona igual.
El detalle que no te esperas: gana el techo más bajo
La mayoría de los ajustes gestionados siguen una regla simple: manda la
organización. maxEffortLevel no funciona así, y esto es lo más importante
de toda la entrega. Según la
documentación de precedencia de settings,
un techo más bajo desde cualquier ámbito —incluido --settings— se respeta
aunque los ajustes gestionados de tu organización pongan un techo más alto.
En sus palabras: "aplica el techo más bajo".
Traducido: la política va en una sola dirección. Tu organización puede impedir
que nadie suba de, pongamos, high. Y una persona puede ponerse a sí misma un
techo aún más estricto —medium— para ahorrar en su trabajo del día. Lo que
no puede hacer nadie es aflojar por encima del techo de la organización.
Un ajuste personal solo sirve para apretar, nunca para soltar. Por eso este
control es difícil de saltarse: no hay puerta lateral por --settings que valga
para subir.
Qué te afecta, según quién seas
Si administras Claude Code para un equipo. Aquí está casi todo el valor.
Tienes una palanca nueva de gasto que es ortogonal a la de modelos: puedes dejar
que tu gente use el modelo que quiera y, aun así, poner un techo al razonamiento
—y por tanto a los tokens de salida y a la latencia— de todas las sesiones. Es
útil cuando el coste se te va no por qué modelo se elige, sino porque el effort
alto se cuela en tareas que no lo necesitan. Como es un ajuste de
settings.json, vive en el mismo sitio y con la misma mecánica que el resto de
tu gobernanza; es justo el terreno del curso de
permisos, settings y seguridad, que ya
dedica una lección al settings.json gestionado. Requiere que tu equipo esté en
v2.1.267 o superior para que el techo se aplique.
Si usas Claude Code de forma interactiva. Si tu organización pone un techo,
lo notarás en /effort y en el selector de /model: podrás bajar cuanto
quieras, pero no subir por encima del tope. El nivel activo se ve en la cabecera
de la sesión, junto al nombre del modelo (por ejemplo, "with high effort"),
así que confirmas de un vistazo con qué effort estás corriendo. Y tienes una
capacidad que quizá no esperabas: puedes ponerte tú un techo más estricto
que el de tu organización en tu settings.json de usuario, para no quemar
tokens de más en trabajo rutinario, sin depender de acordarte de bajar el
/effort en cada sesión. Si estás empezando y el concepto de effort te suena a
chino, lo vemos desde cero en Intro a Claude Code.
Si no configuras nada. No se rompe nada ni cambia tu día a día. maxEffortLevel
es un techo que alguien tiene que poner; si nadie lo toca, cada modelo sigue con
su effort por defecto de siempre. Actualizar a la v2.1.267 no te capa nada por
sorpresa.
Qué llevarte
maxEffortLevel(v2.1.267) pone un techo al nivel de effort, para cada modelo o por modelo, en cualquier proveedor. Limita cuánto razona el modelo, no qué modelo se usa.- No lo confundas con
effortLevel: uno fija un valor por defecto, el otro pone un tope que no se puede rebasar. Cada persona sigue eligiendo su nivel por debajo del techo. - Gana el techo más bajo de cualquier ámbito, incluso por debajo de los
ajustes gestionados. La política solo aprieta: nadie puede aflojar por encima
del tope de la organización, ni siquiera con
--settings. - Nada cambia solo: es un control opt-in. Si nadie lo pone, todo sigue con el effort por defecto.
Preguntas rápidas
¿maxEffortLevel me obliga a razonar más?
No. Es un techo, no un suelo: impide subir por encima de un nivel, no fuerza a
nadie a subir. Por debajo del tope, cada quien elige.
Soy usuario y quiero gastar menos. ¿Puedo usarlo yo solo?
Sí. Ponte un techo en tu settings.json de usuario. Si tu organización ya tiene
uno, el tuyo se respeta mientras sea más estricto; gana el más bajo.
¿Sirve para restringir qué modelo usa mi equipo?
No, esa es otra palanca. Para limitar modelos tienes las
restricciones de modelo de la organización.
maxEffortLevel actúa sobre el razonamiento, no sobre el modelo.
¿Tu equipo controla el gasto de Claude Code a ojo? Decidir dónde poner el
techo de effort, cómo combinarlo con tu política de modelos y qué dejar abierto
para el trabajo que sí necesita razonamiento profundo es justo el tipo de
criterio que trabajamos en la
formación en directo para equipos — sobre vuestro repo, vuestro
settings.json real y vuestro presupuesto.