Migración a Gemini 3.6 Flash: cinco cambios de API y un fallo silencioso

TL;DR Migrar a gemini-3.6-flash o gemini-3.5-flash-lite implica cinco cambios en la solicitud. Cuatro de ellos devuelven HTTP 400, así que te enteras de inmediato. Uno no: temperature, top_p y top_k ahora se aceptan y se ignoran. Si tu pipeline depende de temperature=0 para obtener una salida estable, seguirá devolviendo 200 OK mientras la garantía con la que contabas deja de existir. Corrige ese primero, y luego los cuatro ruidosos.

Last verified: 2026-07-21

Si vas a cambiar un ID de modelo en un archivo de configuración esperando que todo lo demás siga funcionando, lee la primera sección antes de desplegar.

Los cinco cambios, ordenados por lo rápido que te enteras

Cuatro de estos cinco fallos se anuncian solos. Tus pruebas de integración los detectan, tu rastreador de errores te avisa, los corriges en una tarde. El primero es el que llega a producción.

El peligroso: temperature, top_p y top_k ahora se ignoran

Lee esa secuencia con atención, porque el orden te importa. Hoy el parámetro es un no-op. Más adelante se convierte en un error. Eso significa que el período en el que es más probable que te equivoques sobre tu propio sistema es justo ahora, mientras todo sigue devolviendo 200.

Qué pipelines se rompen sin dar error

Un no-op silencioso solo es peligroso si dependías del parámetro. Cuatro configuraciones comunes lo hacían:

• Pipelines de determinismo. Cualquier cosa que fije temperature=0 para que las llamadas repetidas coincidan entre sí: claves de caché construidas a partir de la salida del modelo, pasadas de deduplicación, trabajos de clasificación que alimentan una máquina de estados aguas abajo. El ajuste ahora es inerte, así que la estabilidad de salida que te compraba ya no se compra.
• Pruebas golden-file y de snapshot. Suites que fijaban temperature=0 y comparan (diff) la salida del modelo contra una cadena esperada guardada. Empiezan a fallar de forma intermitente tras el cambio de modelo, y esa intermitencia parece una regresión de calidad del modelo en lugar de un problema de configuración, lo que te manda a depurar en la dirección equivocada.
• Salida estructurada sostenida por temperatura baja. Equipos que nunca adoptaron los structured outputs y en su lugar mantenían temperature cerca de cero más un top_p ajustado para que el modelo emitiera JSON parseable de forma fiable. Ambas perillas quedan inertes a la vez.
• Configuraciones ajustadas por ruta. Productos que exponen un control deslizante de creatividad, o que enrutan "resumir" a una temperatura y "hacer lluvia de ideas" a otra. El control deslizante todavía se mueve en tu UI. Ya no mueve nada en el modelo.

Ninguno de estos produce un stack trace. Producen una salida ligeramente distinta de la que validaste, en un sistema que se declara sano.

Tu gateway tampoco te advertirá

Esta es la parte que atrapa incluso a equipos cuidadosos. Los gateways de modelos publican metadatos legibles por máquina que describen qué parámetros soporta cada modelo, y el tooling lee esos metadatos para decidir qué enviar.

Qué reemplaza a temperature

El reemplazo que Google indica no es otro parámetro. Es la system instruction: escribe el comportamiento que quieres como una regla que el modelo lee, en lugar de como una constante de muestreo.

Ese es un cambio real en cómo expresas la intención, así que traduce en lugar de borrar:

Cómo encontrar cada sitio de llamada antes de desplegar

Busca en tu código los nombres de los parámetros en lugar de confiar en la capa de configuración, porque estos valores suelen fijarse en varios sitios por distintas personas:

# Formas nativas de Gemini y compatibles con OpenAI, más los objetos de configuración que las llevan
grep -rn "temperature\|top_p\|topP\|top_k\|topK\|candidate_count\|candidateCount" \
  --include="*.py" --include="*.ts" --include="*.js" --include="*.go" --include="*.java" .

# Los wrappers que las esconden
grep -rn "generation_config\|generationConfig\|GenerateContentConfig\|thinking_budget\|thinkingBudget" .

Revisa los resultados también fuera del código de aplicación: configuración YAML y JSON, herramientas de gestión de prompts, notebooks, arneses de evaluación, y cualquier Terraform o consola de administración que almacene ajustes de modelo. Una perilla puesta en un dashboard hace seis meses es exactamente el tipo de cosa que sobrevive a un code review.

Los cuatro que fallan de forma ruidosa

Estos son más sencillos, porque la API te lo dice. Corrígelos en el orden en que tu suite de pruebas los saque a la luz.

thinking_budget y thinking_level no pueden estar ambos presentes

Dos valores por defecto que conviene conocer al elegir un valor, porque difieren entre los dos modelos:

• gemini-3.6-flash usa por defecto medium.
• gemini-3.5-flash-lite usa por defecto minimal, que está optimizado para throughput.

Ya no puedes prellenar un turno del modelo

Ambos objetivos se mueven a los mismos dos sitios que todo lo demás: una system instruction que indique la regla, o structured outputs cuando necesitas una forma parseable por máquina. Busca en tu código cualquier constructor de solicitudes que añada un mensaje final de asistente o de modelo, sobre todo la lógica de reintentos y de continuación, que es donde los prefills tienden a generarse de forma dinámica en lugar de escribirse literalmente.

Cada FunctionResponse necesita call_id y name

candidate_count desapareció

Antes y después: una solicitud que migra limpiamente

Aquí tienes una llamada nativa de Gemini que lleva todos los campos obsoletos, y la versión que sobrevive al cambio.

# ANTES: funciona en modelos de la era 2.5, se rompe o se comporta mal en silencio en 3.6 Flash
config = {
    "temperature": 0,          # ahora se ignora, sin error
    "top_p": 0.95,             # ahora se ignora, sin error
    "top_k": 40,               # ahora se ignora, sin error
    "candidate_count": 1,      # no soportado en Gemini 3.x
    "thinking_budget": 8192,   # 400 si coincide con thinking_level
}

# DESPUÉS: la intención se movió de las constantes de muestreo a las instrucciones
config = {
    "system_instruction": (
        "Responde en tres frases como máximo. Usa frases declarativas simples. "
        "No añadas preámbulo, no repitas la pregunta ni ofrezcas seguimientos. "
        "Si la respuesta es incierta, dilo en una frase."
    ),
    "thinking_level": "medium",
}

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["EVOLINK_API_KEY"],
    base_url="https://api.evolink.ai/v1"
)

response = client.chat.completions.create(
    model="gemini-3.6-flash",
    messages=[
        {"role": "system", "content": "Responde en tres frases como máximo. Sin preámbulo."},
        {"role": "user", "content": "Resume este informe de incidente."}
    ]
    # sin temperature, sin top_p: se aceptarían y se ignorarían aguas abajo
)

print(response.choices[0].message.content)

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env["EVOLINK_API_KEY"],
  baseURL: "https://api.evolink.ai/v1",
});

const response = await client.chat.completions.create({
  model: "gemini-3.6-flash",
  messages: [
    { role: "system", content: "Responde en tres frases como máximo. Sin preámbulo." },
    { role: "user", content: "Resume este informe de incidente." },
  ],
  // sin temperature, sin top_p
});

console.log(response.choices[0].message.content);

Un orden de migración que atrapa el fallo silencioso

La secuencia importa, porque los errores ruidosos son fáciles y el silencioso no lo es. Hazlo en este orden:

1. Inventaría primero. Ejecuta los greps de arriba y lista cada sitio donde se fija un parámetro de muestreo, incluidos almacenes de configuración y dashboards. Anota qué comportamiento estaba protegiendo cada uno.
2. Traduce la intención, no la borres sin más. Por cada temperature que encuentres, decide para qué servía y escribe la system instruction equivalente. Borrar sin traducir es como envías una regresión de calidad.
3. Corrige los 400. Cambia thinking_budget por thinking_level, elimina candidate_count, quita los turnos de modelo prellenados, añade call_id y name a cada FunctionResponse.
4. Elige un nivel de thinking a propósito, sobre todo en Flash-Lite, donde el valor por defecto minimal no es adecuado para trabajo autónomo de varios pasos. Esta es además la mayor palanca de coste de la migración: en nuestro conjunto de tareas, 3.6 Flash en minimal costó un 73,6 % menos por pasada que el mismo modelo en el valor por defecto medium, y los tokens de thinking supusieron el 85 % de la salida facturada en medium. Lo que hay que probar es si tu carga de trabajo sobrevive a la bajada, no si el ahorro es real.
5. Regenera la baseline de tus pruebas de snapshot contra el nuevo modelo antes de comparar nada. Los golden files antiguos se produjeron bajo un parámetro que ya no aplica, así que no son un punto de referencia válido.
6. Ejecuta tus evaluaciones en ambos modelos sobre el mismo conjunto de tareas y compara las distribuciones de salida, no solo las tasas de aprobado. Los cambios de comportamiento silenciosos aparecen como deriva en formato, longitud y verbosidad antes de aparecer como respuestas incorrectas.
7. Haz canary sobre tráfico real y vigila los parsers aguas abajo, no solo la tasa de error de la API. Si algo se va a romper en silencio, se rompe en el código que consume la salida del modelo, no en la llamada en sí.

Deja que la skill de migración de Google haga la primera pasada

npx skills add google-gemini/gemini-skills --skill gemini-interactions-api --global

Luego, en un agente de codificación, apúntalo a tu proyecto:

Vale la pena ejecutarla. Se ocupa del trabajo mecánico: encontrar campos obsoletos, reescribir la construcción de solicitudes, actualizar sitios de llamada, lo que cubre la mayor parte del paso 3 de arriba.

Calendario de retirada: cuándo la elección deja de ser tuya

Computer Use: cuatro páginas oficiales, dos respuestas

Una cuestión de capacidad no puede resolverse ahora mismo desde la documentación. Si estos modelos soportan Computer Use se afirma de forma inconsistente en el propio material de Google:

• La documentación de modelos de la API de Gemini marca Computer Use como soportado (preview) para 3.6 Flash, mientras que la página de plataforma empresarial del mismo modelo lo lista como no soportado.
• Para 3.5 Flash-Lite, las páginas de modelo dicen que no está soportado, mientras que el anuncio de lanzamiento y la guía para desarrolladores de Gemini 3 dicen que funciona.

Cuatro páginas oficiales, dos respuestas contradictorias, sin forma de resolverlo leyendo. Si Computer Use está en tu ruta crítica, pruébalo en tu propia cuenta y endpoint antes de comprometerte, y ten un modelo de reserva conectado. Esta sección se actualizará con una respuesta probada y la fecha en que se observó. Todos los demás cambios de esta guía están documentados de forma consistente; este no.

Qué significa esto si esta semana estás reeligiendo proveedor

Una migración que no habías planificado ha aterrizado en tu sprint, y el trabajo es un día o dos de edición cuidadosa en lugar de una reescritura de fin de semana. Como ya estás tocando cada sitio de llamada, este es un momento natural para mirar cómo te llega el modelo en primer lugar.

Vale la pena comprobar dos cosas mientras estás ahí:

• ¿Puedes ejecutar los modelos viejo y nuevo en paralelo durante el cambio? El paso 6 de arriba lo requiere. Si tu montaje hace que ejecutar gemini-3.5-flash y gemini-3.6-flash contra el mismo conjunto de tareas sea incómodo, esa fricción seguirá ahí para la próxima migración también, y habrá una próxima: Google ha dicho que estas reglas se aplican a todos los modelos que se publiquen de aquí en adelante.
• ¿Con qué rapidez se vuelve invocable un nuevo modelo para ti? gemini-3.6-flash llegó a disponibilidad general sin sufijo preview el primer día. La brecha entre que un modelo se lanza y que tu código pueda invocarlo es un coste que pagas en cada lanzamiento.

FAQ

Fuentes

• Using the latest Gemini models (Google AI for Developers): parámetros de muestreo obsoletos, thinking_level, candidate_count, restricción de prefill, requisitos de FunctionResponse, comando de la skill de migración
• Gemini deprecations (Google AI for Developers): fechas de apagado y reemplazos recomendados
• Gemini API models (Google AI for Developers): IDs de modelo, matriz de soporte de capacidades
• Gemini 3 developer guide (Google AI for Developers): comportamiento de solicitud y capacidades de Gemini 3
• Gemini 3.6 Flash on Gemini Enterprise Agent Platform (Google Cloud): listado de capacidades empresariales y valores por defecto de parámetros mostrados
• Introducing Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber (Google): anuncio de lanzamiento y fecha de publicación
• google-gemini/gemini-skills (GitHub): la skill de migración oficial
• OpenRouter models endpoint (OpenRouter): metadatos del gateway que listan temperature, top_p y seed como parámetros soportados para ambos modelos, observado el 2026-07-21
• Catálogo de modelos de EvoLink, rastreador de lanzamiento de Gemini 3.6 Flash, Gemini 3.6 Flash vs Gemini 3.5 Flash, guía de migración de Gemini 3.5 Flash vs Gemini 3 Flash Preview, guía de deprecación de Gemini 3 Pro, URL base de la API de EvoLink