Google: Gemini 3.8 Flash (batch)

Gemini 3.8 Flash es el modelo de Google con salida de texto para trabajos continuados de ingeniería de software, agentes de varios pasos y flujos de trabajo complejos basados en conocimiento. Se basa en Gemini 3.7 Flash, con mejoras en ingeniería de software y trabajo de conocimiento mediante agentes. Acepta texto, imágenes, audio, vídeo y PDF, por lo que una tarea puede combinar un objetivo escrito con el material real necesario para resolverla. El resultado útil es un cambio de código, un análisis explicado, una respuesta escrita o un registro estructurado.

Para una tarea de programación, proporciona el requisito, los archivos pertinentes, el comportamiento observado y las restricciones que deben conservarse. Una captura de pantalla puede mostrar la interfaz deseada, mientras que los registros o un ejemplo reproducible muestran el fallo. Para una tarea de depuración, pide al modelo que rastree una discrepancia entre el estado visible de un formulario y su valor almacenado, identifique la ruta de código responsable y proponga una corrección acotada. Mantén claro el entregable final previsto para que una secuencia más larga de investigación y uso de herramientas siga teniendo una condición de finalización concreta.

Para trabajos de mayor duración, utiliza pasos de razonamiento más pequeños, llamadas iterativas a herramientas y comprobaciones de los resultados intermedios. Los niveles de razonamiento bajo, medio y alto controlan la cantidad de razonamiento; medio es la opción predeterminada documentada. El nivel bajo es adecuado para un borrador rápido o un análisis acotado, mientras que el alto está destinado a tareas difíciles de matemáticas, programación o varios pasos. Gemini 3.8 Flash no admite el nivel de razonamiento mínimo. Por tanto, una tarea prolongada de depuración y una extracción sencilla de campos necesitan distintas opciones de razonamiento, en lugar del mismo ajuste para todas las solicitudes.

Las herramientas documentadas incluyen llamadas a funciones, ejecución de código, búsqueda de archivos, fundamentación mediante búsquedas, fundamentación con Google Maps y contexto de URL, mientras que Computer Use figura como una capacidad en versión preliminar. Las salidas estructuradas definen un resultado legible por máquina. Las funciones deben tener una finalidad y una definición de parámetros claras: el modelo puede solicitar una función, mientras que la aplicación conectada realiza la operación y devuelve su resultado. Conserva las identidades de las funciones y el material realmente devuelto entre turnos. Una respuesta final útil explica qué pruebas respaldan la corrección propuesta o el valor extraído.

La guía de migración a 3.8 utiliza controles de nivel de razonamiento en lugar de la configuración heredada del presupuesto de razonamiento y aconseja eliminar los parámetros de muestreo obsoletos y los turnos de modelo prerrellenados. También exige conservar las firmas de razonamiento en el flujo de trabajo sin estado correspondiente y vincular las respuestas de las funciones con sus llamadas por identidad y nombre. Estos detalles importan al continuar una tarea de varios pasos: el siguiente turno necesita el contexto anterior real, en lugar de una versión reescrita que pierda el resultado de la herramienta o la firma. Mantén explícitos la pregunta y el resultado solicitado en el nuevo turno del usuario.

Para trabajar con conocimiento multimodal, identifica las páginas pertinentes del documento, el gráfico, el intervalo de audio o el evento del vídeo e indica cómo deben contribuir a la respuesta. Una comparación de documentos puede solicitar una tabla de diferencias con pasajes de las fuentes; una pregunta sobre un gráfico puede pedir los valores visibles y la conclusión que respaldan. Un análisis de vídeo puede solicitar una descripción de los acontecimientos que justifican un hallazgo. El modelo devuelve texto a partir de estas entradas. Las imágenes generadas, la voz y la interacción de audio Live corresponden a perfiles de modelo independientes.

Sus límites en Gemini API son de 1 048 576 tokens de entrada y 65 536 tokens de salida, que corresponden al contexto de hasta 1M y a la salida de texto de 64K del modelo nativo. Las instrucciones, el historial de conversación y los medios proporcionados consumen contexto de entrada, y el razonamiento o un entregable final extenso deben caber en el límite de salida documentado. Google también incluye almacenamiento en caché, procesamiento por lotes y procesamiento Flex y Priority para este perfil del desarrollador. Para elementos independientes, conserva un identificador estable de cada elemento y un formato de salida explícito, de modo que cada resultado siga vinculado a su fuente.

Las posibles limitaciones incluyen alucinaciones, lentitud ocasional o tiempos de espera agotados y un mayor consumo de tokens con niveles de esfuerzo más altos. Su fecha de corte de conocimiento es marzo de 2026, aunque algunos ámbitos siguen limitados a enero de 2025. Proporciona pruebas actuales o utiliza las herramientas de fundamentación documentadas cuando la tarea dependa de información posterior. Contrasta las citas de fuentes, los cálculos y el código propuesto con las entradas reales y los resultados de ejecución. El entregable final útil debe distinguir un hallazgo respaldado de una cuestión sin resolver, sin dar por supuesto que una respuesta fluida acredita el resultado solicitado.