Gemini Thinking Level no aparece: causas reales y cómo gestionarlas

Si de un día para otro ha desaparecido el “Thinking level” o la opción Pro de Gemini en tu cuenta, no eres la única persona. Entre cambios silenciosos en la interfaz, ajustes internos de razonamiento y errores de configuración entre modelos 2.5, 3.0 y 3.1, es normal que el mensaje “Thinking level is not supported for this model” o la ausencia del modo Pro te dejen con cara de póker.

En las últimas semanas se han juntado varios temas: degradaciones percibidas en Gemini 3.1 Pro, desaparición temporal del modo Pro en algunas suscripciones personales, cambios en los parámetros de pensamiento y confusión entre thinking_level y thinking_budget. Además, Google ha ido limitando o escondiendo funciones como “Mostrar pensamiento” o “Deep Think”, lo que ha hecho que mucha gente hable de “lobotomía”, “bait and switch” y otras lindezas.

De la polémica del “esfuerzo 0,5” a la desaparición de “Mostrar pensamiento”

Uno de los detonantes del cabreo general ha sido el descubrimiento, mediante el antiguo botón de “Mostrar pensamiento” (Show thinking), de que Gemini llevaba por dentro una especie de control de “esfuerzo” fijado en 0.5. En capturas filtradas por usuarios se veía texto interno del modelo del estilo: “El límite de tokens está bien. Esfuerzo 0.5. Ya terminé. Silenciar todos los pensamientos internos…”.

Esto llevó a muchos a concluir que Google lanzó Gemini 3.1 Pro muy “vitaminado” y, a las pocas semanas, bajó el nivel de razonamiento por defecto. El término “bait and switch” se ha repetido bastante: primero te muestran al modelo trabajando al máximo, y después ajustan el “esfuerzo” a la baja sin avisar claramente, mientras la cuota de suscripción sigue siendo la misma.

Para rematar, Google retiró de la interfaz la opción visible de “Mostrar pensamiento”. Antes, en algunos modos, podías ver un resumen del proceso de razonamiento del modelo; durante un tiempo, por un bug, se filtró contenido interno con mensajes técnicos que dejaban entrever cómo estaba configurado el esfuerzo de razonamiento. Una vez detectado, desapareció del UI y ya no es posible ver ese monólogo interno directamente, lo que aumenta la sensación de opacidad.

En paralelo, otra parte de la comunidad denuncia que Gemini se siente más “corto”, más prudente y con menos profundidad en respuestas complejas que en sus primeras semanas de vida. Todo esto ha alimentado la narrativa de que Google está “frenando” a propósito a Gemini, sobre todo en los modos Pro y en algunas Gems personalizadas, mientras el modo Canvas parece librarse algo de estos recortes.

El lío del modo Pro que desaparece y vuelve sin explicación

Más allá de la parte técnica, ha habido casos muy concretos de usuarios con suscripción “Google AI Pro (2TB)” en los que el selector de modelos dejaba de mostrar la opción “Pro” y solo quedaban “Fast” y “Thinking”. Esto es especialmente sangrante porque, aunque el modo Pro no aparecía, la factura sí seguía llegando completa.

Algunas personas compararon sus cuentas personales con las corporativas y vieron que en la cuenta de empresa seguían apareciendo “Fast / Thinking / Pro”, mientras que en la personal solo “Fast / Thinking”. Es decir, dos cuentas activas, mismo producto de pago, pero diferentes opciones disponibles en la interfaz. De ahí surgió la pregunta razonable: “¿Qué está haciendo Google?”

En uno de estos casos documentados, el usuario contactó con el soporte de Google. Primero le hicieron probar lo típico: modo incógnito, navegadores distintos, app móvil… y en todos faltaba Pro. Finalmente, el soporte reconoció que parecía un “error de sistema”, abrió un ticket y prometió respuesta por correo en 1-2 días.

Lo preocupante es que, durante varios días, no hubo solución técnica clara ni comunicación pública que explicara qué pasaba con el modo Pro. El afectado llegó a plantearse cancelar la suscripción: sin Pro, según él, Gemini dejaba de ser competitivo frente a la propia búsqueda con IA gratuita de Google, que “piensa un poco más” que el servicio de pago capado.

Tras varias semanas y varios edits en el hilo original, finalmente la opción Pro reapareció sin mayor explicación. El usuario daba las gracias, pero quedaba claro que, entre la gente que decía “Pro se ha fusionado con Thinking” y las respuestas ambiguas, faltaba una comunicación transparente por parte de Google. Lo único que quedó claro es que, mientras Pro estuvo ausente, la cuota siguió corriendo.

Por qué aparece el error “Thinking level is not supported for this model”

Dejando a un lado la parte “política” y las decisiones internas de Google, hay un error muy concreto que se repite una y otra vez entre desarrolladores: “Thinking level is not supported for this model” al llamar a gemini-2.5-flash. Lo curioso es que al cambiar a gemini-3-flash-preview todo funciona sin tocar casi nada del código.

La razón es relativamente sencilla: las series Gemini 2.5 y Gemini 3 usan mecanismos de configuración de pensamiento distintos e incompatibles. Si mezclas parámetros de una con otra, te comes un 400 Bad Request.

En la serie Gemini 2.5 (Pro, Flash, Flash-Lite) el control del razonamiento se hace mediante el parámetro thinking_budget, que define cuántos tokens de “pensamiento interno” puede usar el modelo. En cambio, la serie Gemini 3 (3.0/3.1 Pro, 3 Flash, etc.) emplea el parámetro thinking_level, que trabaja por niveles semánticos (minimal, low, medium, high) en lugar de por número de tokens.

Cuando intentas llamar, por ejemplo, a gemini-2.5-flash con un parámetro thinking_level, la API de esa familia de modelos sencillamente no lo reconoce. No existe en su esquema. El resultado típico es una respuesta JSON así:

{ «error»: { «message»: «Thinking level is not supported for this model.», «type»: «upstream_error», «code»: 400 } }

La clave está en que no hay ningún puente automático que convierta thinking_level en thinking_budget. El aislamiento entre generaciones está “hard-coded”, sin compatibilidad hacia atrás ni conversión transparente. Si quieres usar 2.5, usas budget; si quieres usar 3.x, usas level.

Cómo se configura correctamente el modo de pensamiento en Gemini 2.5

Si tu proyecto depende de la serie 2.5 (por precio, estabilidad o compatibilidad), tienes que hablar su idioma. En Gemini 2.5 Flash, el parámetro válido es thinking_budget, con varias opciones muy concretas:

• thinking_budget = 0: desactiva completamente el modo de pensamiento. Ideal para instrucciones sencillas o para maximizar velocidad y abaratar costes.
• thinking_budget = -1: activa modo de pensamiento dinámico; el modelo ajusta internamente los tokens según la complejidad, hasta un máximo definido.
• thinking_budget entre 512 y 24576 (u otros rangos según variante): presupuesto fijo de tokens de razonamiento, útil cuando necesitas un control muy fino del coste.

En Gemini 2.5 Pro, el modelo está pensado para razonar siempre: no admite desactivar el pensamiento por completo. Su mínimo está alrededor de 128 tokens de pensamiento. En cambio, Gemini 2.5 Flash-Lite viene con el pensamiento apagado por defecto (thinking_budget = 0), y solo si estableces un valor ≥512 se activa el modo de razonamiento.

Un matiz importante es que los modelos de imagen como gemini-2.5-flash-image no soportan ningún parámetro de pensamiento. Si intentas pasar thinking_budget o thinking_level en extra_body, el modelo devolverá un error del estilo “This model doesn’t support thinking”. En estos casos, la configuración correcta es simplemente no enviar ningún parámetro de pensamiento.

Para quienes cambian constantemente entre modelos y combinan varias series en el mismo proyecto, hay utilidades que ayudan a adaptar automáticamente los parámetros según el nombre del modelo, mapeando intensidades genéricas como “low/medium/high/dynamic” a presupuestos concretos en 2.5 o a niveles en 3.x. Plataformas de agregación como APIYI, por ejemplo, ofrecen una API unificada compatible con todas las versiones de Gemini 2.5 y 3.0/3.1, lo que facilita probar combinaciones sin romperse la cabeza con cada cambio y además facilitan subir tus propios documentos a Gemini.

Cómo funciona el pensamiento en Gemini 3 y 3.1: niveles, Deep Think y límites

Con la llegada de la serie 3, Google ha querido simplificar la vida a los desarrolladores. En vez de obligarte a decidir si quieres 2048, 8192 o 16384 tokens de pensamiento, introduce el parámetro thinking_level, que ofrece niveles semánticos: minimal, low, medium y high, según el modelo.

En la práctica, esto significa que Gemini decide por dentro cuántos tokens de pensamiento asigna para cada nivel, buscando mejorar la velocidad de inferencia (Google habla de hasta 2x más rápido respecto a la gestión manual de budgets en 2.5) y liberándote de tener que ajustar números exactos.

La matriz de soporte, eso sí, no es idéntica para todos los modelos 3.x. Por ejemplo, Gemini 3.0 Pro solo admite low y high, mientras que Gemini 3.0 Flash soporta desde minimal hasta high. En Gemini 3.1 Pro Preview hay otra vuelta de tuerca: se añade el nivel medium, que se coloca exactamente entre low y high tanto en coste como en profundidad de razonamiento.

De hecho, muchos tests comparativos indican que el antiguo modo high de Gemini 3 Pro se parece bastante al nuevo medium de Gemini 3.1 Pro. El high de 3.1 Pro activa lo que Google llama Deep Think Mini, una especie de “modo turbo” de razonamiento capaz de resolver problemas de olimpiadas de matemáticas o tareas de planificación muy complejas, a costa de latencias de varios minutos y facturas de tokens de pensamiento bastante más altas.

En cuanto a defaults, hay un detalle crítico: si no especificas thinking_level al usar modelos 3.x, el valor por defecto suele ser high (dinámico). Es decir, el modo más caro y más lento. Si solo quieres usar Gemini para traducciones sencillas, clasificación o tareas de chat ligeras, te interesa forzar low o incluso minimal (en Flash), porque de lo contrario pagarás como si todo fuese razonamiento profundo tipo Deep Think.

Resúmenes de pensamiento, firmas y facturación de tokens

Aunque la interfaz haya eliminado el botón de “Mostrar pensamiento”, la API oficial de Gemini sigue permitiendo trabajar con resúmenes de pensamiento y firmas de pensamiento, especialmente cuando usas los SDK de Google (Python, JavaScript, Go) o llamas a la API REST de forma directa.

Con la opción includeThoughts = true dentro de thinking_config, el modelo puede devolver, en la respuesta, partes marcadas como `thought: true` que contienen un resumen del razonamiento interno utilizado para llegar a la respuesta final. No son los pensamientos completos token a token, sino una versión condensada, pero ya dan bastante pista de cómo ha descompuesto el problema.

Para flujos de varios turnos, especialmente en contextos de agentes, entran en juego las “thought signatures” o firmas de pensamiento: representaciones cifradas y verificables del estado de razonamiento que el modelo genera y que deberías reenviar tal cual en las peticiones siguientes, sin mezclarlas, cortarlas ni combinarlas con otras partes. Esto permite a Gemini mantener un hilo de razonamiento consistente a lo largo de varias llamadas, en vez de empezar de cero cada vez.

En el terreno económico, hay que tener algo muy claro: los tokens de pensamiento se facturan al mismo precio que los tokens de salida. Y además, aunque solo recibas un resumen de pensamiento, la facturación se basa en todos los tokens de pensamiento realmente generados internamente para construir ese resumen. Por eso, en tareas muy complejas en nivel high, puedes ver fácilmente cifras de decenas de miles de tokens de pensamiento consumidos por una sola llamada.

Las prácticas recomendadas de Google son bastante claras: no actives niveles altos de pensamiento para tareas triviales, y usa low o minimal cuando la tarea no requiera razonamiento a varios pasos. Para debugging de resultados extraños, revisar los resúmenes de pensamiento puede ser útil, pero no es algo que quieras tener activo 24/7 si te preocupa el coste.

ThinkingLevel vs ThinkingBudget: reglas claras y errores típicos

Buena parte de los errores de integración giran en torno a una confusión muy simple: thinkingLevel y thinkingBudget no son intercambiables y no pueden usarse a la vez. Cada uno va asociado a una familia de modelos y mezclar ambos en una misma llamada provoca errores 400 inmediatos.

La regla rápida es la siguiente: serie Gemini 3.x → thinkingLevel; serie Gemini 2.5 → thinkingBudget. Intentar poner thinkingBudget en un modelo 3.1 Pro, aunque en teoría haya cierta compatibilidad hacia atrás, puede degradar el rendimiento o, directamente, fallar si la implementación de la API ha endurecido las validaciones.

Escenarios típicos que rompen cosas:

• Llamar a gemini-2.5-flash con thinking_level: «medium»: el modelo no sabe qué hacer con ese parámetro, y devuelve “Thinking level is not supported for this model”.
• Llamar a gemini-3.1-pro-preview con thinking_budget: 8192: aunque parte de la documentación hable de compatibilidad, algunas implementaciones lo rechazan o dan un rendimiento impredecible.
• Enviar a la vez thinking_level y thinking_budget en la misma petición: la API responde con un 400 indicando conflicto en la configuración de pensamiento.

Una táctica bastante sensata, especialmente si trabajas con múltiples versiones o si estás migrando de 2.5 a 3.x, es implementar funciones de adaptación de parámetros por modelo o apoyarte en plataformas como APIYI que ya exponen una capa de compatibilidad. De esta forma puedes seguir pensando en términos de “simple / medium / complex” a nivel de negocio, mientras el código traduce eso internamente a budgets o niveles concretos según el modelo activo.

En procesos de migración, es habitual mapear los presupuestos clásicos de 2.5 (0, 512, 2048, 8192, 16384, -1) a niveles aproximados en 3.x (minimal, low, medium, high). Por ejemplo, pasar de un thinking_budget -1 (dinámico) en 2.5 Flash a un thinking_level high en 3.0 Flash suele dar un rendimiento razonable y, además, más rápido gracias a las optimizaciones de esta nueva generación.

Entre los malentendidos más frecuentes está la idea de que el modo HIGH debería usarse siempre porque “da más calidad”. En realidad, en tareas sencillas apenas aporta mejora respecto a MEDIUM o incluso LOW, pero multiplica el coste de tokens de pensamiento por varias veces. También es falso que LOW “no razone”; sigue siendo superior a modelos sin pensamiento, simplemente gasta muchos menos tokens internos.

En conjunto, todo este entramado de niveles, budgets, firmas y resúmenes, sumado a los cambios silenciosos en el UI (“Mostrar pensamiento” que desaparece, “Enable Thinking” que no aparece con ciertos modelos en extensiones como Cline, el modo Pro que va y viene…), explica por qué tanta gente siente que Gemini está cambiando bajo sus pies sin la transparencia deseable. Entendiendo bien cómo se conectan las piezas técnicas y cómo se facturan, resulta mucho más fácil decidir qué modelo usar, qué nivel de pensamiento tiene sentido para cada caso y cuándo merece la pena pagar por razonamiento profundo o, por el contrario, limitarse a un modo de pensamiento mínimo o incluso desactivado cuando el modelo lo permite.

Related article:

Gemini responde ahora: así funciona el nuevo botón para obtener respuestas instantáneas

Alberto Navarro

Soy un apasionado de la tecnología que ha convertido sus intereses «frikis» en profesión. Llevo más de 10 años de mi vida utilizando tecnología de vanguardia y trasteando todo tipo de programas por pura curiosidad. Ahora me he especializado en tecnología de ordenador y videojuegos. Esto es por que desde hace más de 5 años que trabajo redactando para varias webs en materia de tecnología y videojuegos, creando artículos que buscan darte la información que necesitas con un lenguaje entendible por todos.

Si tienes cualquier pregunta, mis conocimientos van desde todo lo relacionado con el sistema operativo Windows así como Android para móviles. Y es que mi compromiso es contigo, siempre estoy dispuesto a dedicarte unos minutos y ayudarte a resolver cualquier duda que tengas en este mundo de internet.