Guía para desarrolladores de Gemini 3.6 Flash

Gemini 3.6 Flash es un modelo potente, rápido y rentable de la familia Gemini 3. Diseñado para ofrecer capacidades agénticas casi de nivel Pro sin comprometer el rendimiento ni el valor, el modelo ya está disponible de forma general (DG) para los desarrolladores que usan la API de Gemini y para las empresas que usan Gemini Enterprise Agent Platform.

En este documento, se explica qué novedades incluye 3.6 Flash, cómo se integra en la familia de modelos de Gemini, cómo migrar a 3.6 Flash y se proporciona una guía de inicio rápido para usar 3.6 Flash.

¿Cómo se integra en la familia de Gemini?

Gemini 3.6 Flash es el principal modelo de trabajo de agentes de la familia Gemini 3. Cierra la brecha entre los modelos Pro de razonamiento profundo y los modelos Flash-Lite de alta capacidad de procesamiento. En comparación con Gemini 3.5 Flash, 3.6 Flash ofrece una calidad significativamente mayor en la organización de herramientas de varios pasos, la refactorización de código de pila completa y el razonamiento visual, a la vez que usa menos tokens y turnos de razonamiento. Ofrece capacidades casi de nivel Pro con la velocidad y el precio de Flash.

Especificaciones y comparaciones de modelos

En la siguiente tabla, se comparan algunas de las especificaciones entre 3.6 Flash, 3.5 Flash y 3.1 Pro:

Gemini 3.6 Flash Gemini 3.5 Flash Gemini 3.1 Pro
ID de modelo gemini-3.6-flash gemini-3.5-flash gemini-3.1-pro-preview
Etapa de lanzamiento DG DG Vista previa
Tipos de entrada Texto, imagen, audio y video Texto, imagen, audio y video Texto, imagen, audio y video
Tipos de salida Texto Texto Texto
Ventana de contexto 1,048,576 1,048,576 1,048,576
Longitud máxima de los tokens de salida 65,536 65,536 65,536
Regiones admitidas Global, multirregional Global, Multirregión, América, Europa, Asia-Pacífico Global
Niveles de pensamiento admitidos MINIMAL, LOW, MEDIUM, HIGH
(Predeterminado: MEDIUM) 		MINIMAL, LOW, MEDIUM, HIGH
(Predeterminado: MEDIUM) 		LOW, MEDIUM, HIGH
(Predeterminado: HIGH)
Enfoque principal Flujos de trabajo de agentes de alta eficiencia, organización de varios pasos y programación de pila completa Tareas equilibradas, llamadas a herramientas y razonamiento intermedio Tareas de razonamiento profundo y alta complejidad

Consulta la página del modelo 3.6 Flash para ver la lista completa de funciones, herramientas y opciones de consumo compatibles.

¿Qué novedades hay en Gemini 3.6 Flash?

3.6 Flash está optimizado para la organización de varios pasos, la refactorización de código de pila completa y el razonamiento general con una eficiencia de tokens significativamente mejor que la de sus predecesores.

Actualizaciones de capacidades y rendimiento

A continuación, se muestra la lista de cambios en las capacidades y el rendimiento de 3.6 Flash en comparación con los modelos anteriores:

  • Reducción de tokens y turnos: Consume menos tokens y completa flujos de trabajo de varios pasos en menos pasos de razonamiento y turnos de conversación que 3.5 Flash.
  • Generación de código mejorada: Produce código más limpio con tasas más bajas de fallas de compilación y revisión en los entornos de creación de aplicaciones, creación de prototipos y agentes de IDE.
  • Sesgo de acción reducido: Resuelve tareas de diagnóstico de solo lectura sin realizar ediciones no solicitadas en el espacio de trabajo ni mutar el estado de forma prematura.
  • Razonamiento multimodal y espacial: Ofrece un mejor rendimiento en la interpretación de gráficos, la conversión de planos visuales y la generación de diseños web con varios elementos.
  • Asistencia para el uso de computadoras: Se admite como una herramienta integrada para la automatización de la IU de agentes.
  • Preferencia de estilo de IU: Es mejor para crear código funcional, aunque los evaluadores humanos notaron una preferencia por los modelos anteriores para la presentación de frontend y el diseño visual. Esto se puede mitigar proporcionando lineamientos de diseño explícitos.

Cambios en el comportamiento y los parámetros de la API

A continuación, se muestra la lista de cambios de comportamiento y de parámetros de la API para 3.6 Flash con respecto a los modelos anteriores:

  • Pasos concisos: Usa menos pasos de razonamiento que 3.5 Flash. Si bien esto reduce la latencia y el costo en la refactorización de código y los flujos de trabajo de herramientas, puede causar salidas anticipadas en seguimientos conversacionales extendidos de varios turnos en los que se necesitan cadenas de iteración más largas.
  • Inspección programática inicial: Prefiere ejecutar secuencias de comandos de diagnóstico (execute_code) para inspeccionar problemas antes de mutar el estado con más frecuencia que 3.5 Flash. Si bien esto mejora la precisión del diagnóstico en la refactorización compleja del backend, en ocasiones, puede generar la ejecución de pasos de inspección exploratorios adicionales en tareas sencillas de secuencias de comandos y de la Web de frontend, en las que la versión anterior generaría código directamente.
  • Esfuerzo predeterminado: Se mantiene el nivel de esfuerzo predeterminado medio introducido en 3.5 Flash.
  • No hay anulaciones de muestreo: Ya no se admiten los valores personalizados para los parámetros temperature, top-k o top-p. La configuración de valores personalizados se ignorará en la superficie de la API. En su lugar, usa thinking_level o esquemas JSON estructurados para controlar el determinismo de los resultados.
  • Restricciones de penalización de frecuencia y presencia: Ya no se admiten valores personalizados para estos parámetros. Si las configuras, se generará un error de API activa.
  • No se admiten las solicitudes a la API en las que el último turno de entrada tenga un rol de "Modelo".
  • Se descartan los turnos vacíos en el historial de conversaciones.
  • Las firmas de pensamiento no válidas ahora producirán errores.
  • Llamada a funciones estricta: FunctionResponse debe coincidir estrictamente con el id, name y el recuento de ejecuciones del FunctionCall anterior. Agrega instrucciones intercaladas directamente dentro del texto de respuesta de la función, separadas por dos saltos de línea (\n\n).

Guía de inicio rápido

Antes de comenzar, debes autenticarte en Agent Platform con las credenciales predeterminadas de la aplicación (ADC) o una clave de API. Consulta Comienza a usar Gemini Enterprise Agent Platform para obtener más información.

En los siguientes bloques de código, reemplaza PROJECT_ID por el ID de tu proyecto.

Instalación

Asegúrate de usar el SDK de google-genai más reciente:

pip install --upgrade google-genai

Solicitud básica

Python

from google import genai

client = genai.Client(enterprise=True, project="PROJECT_ID", location="global")

response = client.models.generate_content(
  model="gemini-3.6-flash",
  contents="How does AI work?",
)
print(response.text)

REST

curl -X POST \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/global/publishers/google/models/gemini-3.6-flash:generateContent \
-d '{
  "contents": {
    "role": "USER",
    "parts": { "text": "Why is the sky blue?" },
  },
}'

Migra a 3.6 Flash desde 3.5 Flash o 3.1 Pro

Para migrar a 3.6 Flash desde 3.5 Flash o 3.1 Pro, sigue estos pasos:

  1. Actualiza el ID del modelo: Cambia la cadena del modelo en tus llamadas a la API a gemini-3.6-flash.
  2. Adapta tu código a las nuevas reglas de la API de la familia Gemini 3: Gemini 3.6 Flash aplica de forma estricta las reglas de parámetros y las convenciones de la API establecidas en toda la familia Gemini 3:
    • Quita la temperatura, el top-K y el top-P: Quita estos parámetros personalizados de tu carga útil. Si bien no arrojarán un error, el modelo los ignorará por completo. En su lugar, usa el parámetro thinking_level o los resultados estructurados de json_schema para controlar el determinismo de los resultados.
    • Quita las penalizaciones de frecuencia y presencia: Quita cualquier configuración personalizada para las penalizaciones de frecuencia o presencia para evitar que tus llamadas a la API arrojen errores de tiempo de ejecución.
    • Asegúrate de que tu integración de chat no intente completar previamente el modelo: Revisa tus arrays de historial de mensajes para asegurarte de que la carga útil de tu API no termine con un turno de usuario o de modelo vacío. Si el último objeto de tu array de historial es un rol "model" (API de GenerateContent) o un tipo "model_output" (API de Interactions), reestructura la secuencia para evitar que se active un error de validación estricto.
    • Usa thinking_level: Quita las instancias del parámetro thinking_budget obsoleto y, en su lugar, usa thinking_level.
    • Aplica convenciones estrictas de llamada a funciones: El FunctionResponse debe coincidir estrictamente con el id, el name y el recuento de ejecuciones del FunctionCall anterior. Si necesitas agregar instrucciones intercaladas, colócalas directamente dentro del texto de respuesta de la función separadas por dos saltos de línea (\n\n).
  3. Considera los cambios en el flujo de trabajo:
    • Si tu aplicación se basa en bucles de conversación de varios turnos, prueba tus flujos de trabajo para asegurarte de que la nueva concisión de pasos del modelo no active salidas prematuras.
    • Si compilas agentes de frontend o de secuencias de comandos básicas, supervisa las llamadas a execute_code exploratorias innecesarias debido al nuevo sesgo del modelo hacia la inspección programática inicial.

Soluciones alternativas para los requisitos de texto previos a la herramienta

Si tu instrucción requiere que el modelo genere texto estructurado (XLM, YAML, JSON, etc.) (por ejemplo, <UPDATE>...</UPDATE>) justo antes de realizar una llamada a la herramienta, esta puede fallar de forma ocasional con un error Malformed_Function_Call. Puedes usar una de las siguientes soluciones alternativas para resolver este problema:

  • (Recomendado) Indica al modelo que coloque sus notas previas a la herramienta dentro de una llamada a función update() dedicada en lugar de texto sin procesar. Consulta la siguiente sección para obtener instrucciones detalladas sobre la implementación.
  • Indícale al modelo que escriba notas como encabezados de Markdown (por ejemplo, # UPDATE, ## PLAN) en lugar de texto estructurado.
  • No exijas que el modelo genere texto antes de las llamadas a la herramienta.

Solución recomendada: Une las notas de trabajo en una llamada a función dedicada

En lugar de la instrucción original:

Before calling a tool, in every response you MUST first output a single
`<UPDATE>` part as specified, don't skip this part or any of required sub-tags
within `<UPDATE>`.

Usa esta instrucción actualizada:

Before calling any other tool, in every response you MUST first call `update`
with all required parameters (previous_step, plan, next_step, external).

Actualiza todas las referencias al formato XML de <UPDATE> anterior en la solicitud del cliente. Luego, agrega la declaración de la función correspondiente para la función de actualización:

{
  "name": "update",
  "description": "Update working notes (previous step analysis, plan, next step, external note).",
  "parameters": {
    "type": "OBJECT",
    "properties": {
      "previous_step": {
        "type": "STRING",
        "description": "Key findings and outcomes since the previous step."
      },
      "plan": {
        "type": "STRING",
        "description": "The current status of the plan."
      },
      "next_step": {
        "type": "STRING",
        "description": "Brief explanation of the immediate next action according to the plan."
      },
      "external": {
        "type": "STRING",
        "description": "A short, plain-language note shown to the User about what you are ABOUT TO DO next."
      }
    },
    "required": [
      "previous_step",
      "plan",
      "next_step",
      "external"
    ]
  }
}

El modelo realizará dos llamadas en el mismo paso: la llamada a update() que reemplaza el XML estructurado y la llamada a función real que desea realizar.

Recursos adicionales