Guía para desarrolladores de Gemini 3.6 Flash

Gemini 3.6 Flash es un modelo potente, rentable y de alta velocidad de la familia Gemini 3. Diseñado para ofrecer capacidades de agente casi de nivel Pro sin comprometer el rendimiento ni el valor, el modelo ahora 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 adapta a 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 adapta a la familia de Gemini?

Gemini 3.6 Flash es el caballo de batalla principal de los agentes en la familia Gemini 3. Salva la brecha entre los modelos Pro de razonamiento profundo y los modelos Flash-Lite de alto rendimiento. 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, al mismo tiempo que usa menos tokens y turnos de razonamiento. Ofrece capacidades casi de nivel Pro con la velocidad y los precios de Flash.

Especificaciones y comparaciones del modelo

En la siguiente tabla, se incluye una comparación que abarca 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, video Texto, imagen, audio, video Texto, imagen, audio, video
Tipos de salida Texto Texto Texto
Ventana de contexto 1,048,576 1,048,576 1,048,576
Longitud máxima de tokens de salida 65,536 65,536 65,536
Regiones admitidas Global, multirregión Global, multirregión, América, Europa, Asia-Pacífico Global
Niveles de razonamiento 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 codificación de pila completa Tareas equilibradas, llamadas a herramientas y razonamiento intermedio Razonamiento profundo, tareas de alta complejidad

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

¿Qué novedades incluye 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 sus predecesores.

Actualizaciones de capacidades y rendimiento

A continuación, se incluye 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 conversacionales que 3.5 Flash.
  • Generación de código mejorada: Produce código más limpio con tasas más bajas de errores de compilación y revisión en la creación de aplicaciones, la creación de prototipos y los entornos de agentes de IDE.
  • Sesgo de acción reducido: Resuelve tareas de diagnóstico de solo lectura sin realizar ediciones no solicitadas del espacio de trabajo ni mutar el estado de forma prematura.
  • Razonamiento multimodal y espacial: Ofrece un rendimiento mejorado en la interpretación de gráficos , la conversión de planos visuales y la generación de diseño web de varios elementos.
  • Compatibilidad con 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 si se proporcionan lineamientos de diseño explícitos.

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

A continuación, se incluye la lista de cambios en el comportamiento y los parámetros de la API de 3.6 Flash en comparación con los modelos anteriores:

  • Concisión de pasos: 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 provocar salidas tempranas en seguimientos conversacionales de varios turnos extendidos en los que se necesitan cadenas de iteración más largas.
  • Inspección programática inicial: Prefiere ejecutar secuencias de comandos de código 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 llevar a ejecutar pasos de inspección exploratorios adicionales en tareas simples de frontend web y de secuencias de comandos en las que la versión anterior generaría código directamente.
  • Esfuerzo predeterminado: Continúa con el nivel de esfuerzo predeterminado medio introducido en 3.5 Flash.
  • No se anulan las muestras: Ya no se admiten valores personalizados para los parámetros temperature, top-k, o top-p. Se ignorará la configuración de valores personalizados en la superficie de la API. En su lugar, usa thinking_level o esquemas JSON estructurados para controlar el determinismo de la salida.
  • Restricciones de penalización de frecuencia y presencia: Ya no se admiten valores personalizados para estos parámetros. Si los configuras, ahora se mostrará un error de API activo.
  • No se admiten las solicitudes a la API en las que el último turno de entrada tiene el rol "Modelo".
  • Se descartan los turnos vacíos en el historial de conversaciones.
  • Las firmas de pensamiento no válidas ahora producirán errores.
  • Llamadas a funciones estrictas: FunctionResponse debe coincidir estrictamente con el id, el name y el recuento de ejecución del FunctionCall anterior. Agrega instrucciones intercaladas directamente dentro del texto de respuesta de la función, separadas por dos líneas nuevas (\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 Cómo comenzar 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 estrictamente las reglas de parámetros y las convenciones de la API establecidas en 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 mostrarán un error, el modelo los ignorará por completo. En su lugar, usa el parámetro thinking_level o las salidas estructuradas json_schema para controlar el determinismo de la salida.
    • 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 muestren errores de tiempo de ejecución.
    • Asegúrate de que tu integración de chat no intente completar previamente el modelo: Revisa tus arrays del historial de mensajes para asegurarte de que tu carga útil de la 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 activar un error de validación estricto.
    • Usa thinking_level: Quita las instancias del parámetro obsoleto thinking_budget y usa thinking_level en su lugar.
    • Aplica convenciones estrictas de llamadas a funciones: El FunctionResponse debe coincidir estrictamente con el id, el name y el recuento de ejecución del FunctionCall anterior. Si necesitas agregar instrucciones intercaladas, colócalas directamente dentro del texto de respuesta de la función, separadas por dos líneas nuevas (\n\n).
  3. Ten en cuenta los cambios en el flujo de trabajo:
    • Si tu aplicación depende de bucles conversacionales 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 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>) inmediatamente antes de realizar una llamada a la herramienta, es posible que la llamada a la herramienta falle ocasionalmente con un Malformed_Function_Call error. 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 formato. Consulta la siguiente sección para obtener instrucciones detalladas de implementación.
  • Indica al modelo que escriba notas como encabezados de Markdown (por ejemplo, # UPDATE, ## PLAN) en lugar de texto estructurado.
  • No requieras que el modelo genere texto antes de las llamadas a la herramienta.

Solución recomendada: Incluye 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 <UPDATE> anterior en la solicitud del cliente. Luego, agrega la declaración de 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 update() que reemplaza el XML estructurado y la llamada a función real que desea realizar.

Recursos adicionales