Nano Banana Pro es el modelo Gemini 3 Pro Image Preview. En la API debes usar gemini-3-pro-image-preview, mientras que en la app de Gemini se accede desde “Crear imagenes → Thinking”.
La diferencia clave es que el apodo aparece en la interfaz, pero el model ID oficial es el que importa en el código. Google lo deja claro en la documentación de generación de imágenes, aunque la mayoría de resultados no lo explican de forma directa.
A 28 de marzo de 2026, el mapa oficial es:
| Apodo Nano Banana | Modelo oficial | API model ID | Dónde aparece |
|---|---|---|---|
| Nano Banana Pro | Gemini 3 Pro Image Preview | gemini-3-pro-image-preview | App Gemini (Thinking), AI Studio, Gemini API, Vertex AI |
| Nano Banana 2 | Gemini 3.1 Flash Image Preview | gemini-3.1-flash-image-preview | Carril por defecto en la app, AI Studio, Gemini API |
| Nano Banana | Gemini 2.5 Flash Image | gemini-2.5-flash-image | Carril rápido antiguo, fallback en API |
Si necesitas máxima calidad y texto legible, Nano Banana Pro es la mejor opción. Para velocidad y volumen, Nano Banana 2 suele ser más adecuado. Comparación: Gemini 3.1 Flash Image Preview vs Gemini 3 Pro Image Preview.
Resumen rápido
- Nano Banana Pro = Gemini 3 Pro Image Preview, en API usa
gemini-3-pro-image-preview. - En la app: Crear imagenes → Thinking.
- En AI Studio: selecciona Gemini 3 Pro Image Preview.
- Para velocidad: Nano Banana 2 (Gemini 3.1 Flash Image Preview).
| Qué quieres saber | Primer paso | Por qué |
|---|---|---|
| “¿Qué es Nano Banana Pro?” | Trátalo como Gemini 3 Pro Image Preview | Es el nombre oficial |
| “¿Qué ID uso en la API?” | gemini-3-pro-image-preview | Es el ID oficial |
| “¿Dónde está en la app?” | Crear imagenes → Thinking | La app muestra el apodo |
Regla simple: el apodo vive en la UI, el model ID vive en el código. Si dudas, usa gemini-3-pro-image-preview.
Por qué existe el apodo (y por qué el model ID importa)
Google usa nombres amigables en productos de usuario, pero en desarrollo manda el model ID. La documentación define Nano Banana como la generación nativa de imágenes y luego lo mapea a modelos concretos. Por eso verás “Nano Banana Pro” en la app, pero en código debes usar gemini-3-pro-image-preview.
Si trabajas en equipo, unifica el model ID desde el inicio.
Esto evita configuraciones sutiles: alguien sigue el apodo en la UI y otra persona asume un ID distinto en el API.
En documentación interna, escribe “Nano Banana Pro (Gemini 3 Pro Image Preview / gemini-3-pro-image-preview)” para evitar confusiones.
Cuando se mezclan roles de producto, marketing y desarrollo, poner ambos nombres juntos ahorra idas y vueltas.
Si compartes prompts o plantillas internas, incluye el model ID en el titulo o en la cabecera. Eso evita que alguien copie solo el apodo y llame al modelo incorrecto.
Si alguien pega el apodo directo en un snippet, la llamada puede fallar o apuntar a otro modelo. Estandariza el ID en ejemplos internos para prevenirlo.
Errores comunes de nombre (y cómo evitarlos)
Un error común es confundir “Gemini 3 Pro” con “Gemini 3 Pro Image Preview”. El primero es texto, el segundo es imágenes.
Si un articulo dice solo “Gemini 3 Pro” sin “Image” o “Image Preview”, verifica que realmente hable de generacion de imagenes antes de copiar la recomendacion.
Otro error es copiar alias de proveedores. En el API nativo el ID correcto es gemini-3-pro-image-preview.
Si usas el alias en el lugar equivocado, la solicitud puede fallar o enrutarse a otro modelo sin avisar.
Si ves resultados raros o demasiado rapidos, sospecha de un alias mal resuelto antes de cambiar tus prompts.
También es un error quitar “Preview”. El modelo sigue en preview y el nombre puede cambiar.
Mantener “Preview” en tus notas internas ayuda a recordar que el nombre y la disponibilidad pueden moverse.
Cuando cambie un doc oficial, vuelve a revisar tu mapeo para no quedarte con un nombre viejo.
Además, Pro no es el carril más rápido. Si necesitas tiempo real, usa Nano Banana 2 como base y reserva Pro para calidad.
En flujos de alto volumen, Nano Banana 2 suele ser el default y Pro queda para tareas donde la fidelidad es critica.
No asumas que Pro es el default en todas partes: en la app suele primar el carril rapido y Pro aparece solo al elegir Thinking.
Dónde ver Nano Banana Pro (app / AI Studio / API)
Nano Banana Pro aparece en canales de usuario, desarrollador y empresa, pero la etiqueta cambia según la superficie.
Lo importante no es memorizar cada interfaz, sino traducir cualquier etiqueta al model ID correcto. En la UI veras apodos, pero el API exige el string exacto.
- App Gemini: Crear imagenes → Thinking.
- Google AI Studio: aparece Gemini 3 Pro Image Preview.
- Gemini API / Vertex AI: usar
gemini-3-pro-image-preview.
En la app, algunos planes pueden volver al carril rapido despues de varias generaciones. Revisa la etiqueta antes de generar y toma el model ID como referencia final.
La disponibilidad depende de plan, región y producto. Si no lo ves, suele ser rollout gradual.
Si no aparece en la app, prueba en AI Studio o verifica en el API; a veces el modelo llega primero a un canal antes que a otro.
Si tu equipo usa Gemini API y Vertex AI, el model ID es el mismo en ambos. Eso permite reutilizar configuraciones sin cambiar la capa de nombres.
En empresas, el model ID es el mismo tanto en Gemini API como en Vertex AI, así que puedes reutilizarlo.
| Superficie | Etiqueta | Qué elegir |
|---|---|---|
| App Gemini | Nano Banana Pro (apodo) | Crear imagenes → Thinking |
| Google AI Studio | Gemini 3 Pro Image Preview | Seleccionar modelo |
| Gemini API / Vertex AI | gemini-3-pro-image-preview | Usar ID en la solicitud |
Memoriza esta tabla y podrás traducir cualquier etiqueta a un model ID correcto.
En entornos enterprise, ese mismo ID funciona tanto en Gemini API como en Vertex AI, por lo que no necesitas cambiar la capa de nombres entre productos.
Cuando des soporte, recuerda que la etiqueta de la UI es solo una capa de presentacion; el model ID es lo que define el comportamiento real.
AI Studio es la mejor verificación rápida; la API es el contrato real.
Para validaciones rapidas del nombre oficial, AI Studio suele ser el camino mas directo. Para produccion, el API es la fuente de verdad.
Si tu equipo es mixto, guardar el model ID en configuraciones compartidas evita que cada rol use nombres diferentes.
Si manejas varios entornos (dev, staging, prod), documenta el model ID por entorno y evita defaults implicitos. Reduce sorpresas cuando cambian planes o accesos.
Precio: Gemini 3 Pro Image Preview Pricing. Límites: Gemini 3 Pro Image Preview Rate Limit.
Cómo verificar el nombre oficial
Si dudas, ve a las fuentes:
Cualquier cambio allí es señal de actualización.
Si cambian los docs o los model cards, actualiza tu tabla interna de mapeo y los materiales de onboarding.
No esperes a que falle una integracion en produccion: un cambio en la documentacion suele ser la primera señal de que el nombre o la disponibilidad se movieron.
Anota la fecha de verificacion en tu doc interno y usa esa fecha para planificar la siguiente revision. Eso reduce sorpresas cuando cambian nombres o accesos.
Los model cards sirven como referencia de fecha. Si se actualizan, revisa tus notas internas.
Un update reciente suele ser el mejor indicador para revalidar naming y disponibilidad.
Para cambios de preview o estado, revisa el Gemini API changelog.
El changelog tambien es util para limites y disponibilidad. Si ves cambios, reejecuta QA interno.
Si tu producto depende de cupos o regiones, revisa el changelog cada vez que haya un anuncio relevante.
Si trabajas con compliance o clientes regulados, guarda una nota de la version de docs usada en cada release.
Un historial de verificacion con fecha, fuente y enlace evita discusiones cuando alguien cuestiona el nombre del modelo.
Si puedes, agenda revisiones mensuales o trimestrales y actualiza el onboarding cuando cambie cualquier fuente oficial.
Nano Banana Pro vs Nano Banana 2 vs Nano Banana
La regla básica es calidad vs velocidad.
- Nano Banana Pro (Gemini 3 Pro Image Preview): máxima calidad y texto.
- Nano Banana 2 (Gemini 3.1 Flash Image Preview): rapidez y volumen.
- Nano Banana (Gemini 2.5 Flash Image): carril rápido antiguo.
Si necesitas tipografía estable, Pro; si necesitas rapidez, Nano Banana 2.
Pro se parece a un carril de calidad de estudio: mejor texto, composicion y control. Flash prioriza velocidad y costo, ideal para iteracion rapida.
Regla simple:
- Pro: calidad, texto, branding.
- Nano Banana 2: velocidad y volumen.
- Nano Banana: solo como fallback.
Muchos equipos empiezan con Pro para fijar el liston de calidad y luego prueban Nano Banana 2 para velocidad. Esa secuencia evita perder fidelidad por cambiar demasiado pronto.
Si migras desde un modelo antiguo o de otro proveedor, usa Pro como linea base y despues evalua si el carril rapido es suficiente.
Para resultados con texto legible, interfaces o branding, Pro suele dar menos sorpresas. El carril rapido es excelente para volumen, pero no siempre mantiene la misma fidelidad tipografica.
Si tu prioridad es consistencia visual, empieza con Pro y solo baja a Nano Banana 2 cuando la velocidad sea critica.
Cómo confirmar que usas Pro
En la app
- Abre Crear imagenes y revisa el modelo.
- Selecciona Thinking.
- Si vuelve a un carril rapido tras varias generaciones, revisa plan o cuota.
En Google AI Studio
- Selecciona Gemini 3 Pro Image Preview.
- Si solo aparecen modelos Flash, tu cuenta o region puede no tener acceso a Pro.
En la API
- Usa
gemini-3-pro-image-preview. - Registra el model ID en logs.
- Guarda el model ID en el payload para poder auditarlo en monitoreo.
Si el modelo no coincide, suele ser rollback, límites de plan/región o un ID incorrecto.
Si integras a traves de un SDK o gateway, registra el model ID resuelto en tiempo de ejecucion para evitar confusiones entre Pro y Flash.
En produccion, ese log es la forma mas rapida de detectar cambios de default o rutas inesperadas.
Si notas diferencias entre app y API, revisa si el request se resolvio a otro modelo por defecto.
Si usas varias capas (gateway, SDK, orquestador), registra el model ID en cada una para detectar overrides.
Marcas de agua y verificación
Los docs dicen que todas las imágenes incluyen SynthID. En productos de usuario puede aparecer una marca visible según el plan.
- SynthID siempre presente
- Marca visible depende del plan/rollout
- Si necesitas salida limpia, revisa la política actual
La marca visible es un tema de experiencia; SynthID es un tema de trazabilidad. Antes de prometer entregables sin marca, confirma la politica vigente.
Si entregas a clientes, agrega una nota corta sobre posibles marcas visibles para alinear expectativas.
En procesos de compliance, trata SynthID como parte de la trazabilidad y no como un simple detalle visual.
Aunque no haya marca visible, SynthID sigue estando ahi; es util para auditoria y pruebas de origen.
Soluciones rápidas
- No aparece Nano Banana Pro → actualizar app / plan / región
- Vuelve a Nano Banana → límite o fallback
- API falla → revisar
gemini-3-pro-image-preview - Velocidad primero → Nano Banana 2
Si alguien no ve Pro, pide plan, region y version de la app; con esos datos puedes confirmar si es rollout o acceso.
Si es posible, pide una captura del selector de modelo; ayuda a confirmar si la app esta mostrando el apodo correcto.
Guarda “model ID + fecha” para evitar confusiones.
Recuerda: UI y API no son lo mismo; el model ID es la base.
Si tienes usuarios de app y desarrolladores de API en el mismo equipo, pon apodo, nombre oficial y model ID en una sola tabla. Reduce discusiones y acelera la verificacion.
Si aun hay dudas, vuelve a los docs oficiales y al anuncio de lanzamiento para confirmar que el nombre y el rollout no han cambiado.
Un consejo practico: guarda una tabla unica con apodo, nombre oficial y model ID, y actualizala cada vez que revises la documentacion.
Si algo no cuadra, revisa primero los docs oficiales y los model cards antes de cambiar tu integracion.
Mantener esa tabla en el onboarding evita que nuevos miembros usen el apodo en lugar del ID.
Si ya tienes un playbook interno, incluye el model ID en cada ejemplo para que no se pierda en el contexto.
Una linea de resumen al inicio del playbook con el ID correcto reduce errores de copia y pega.
Cuando alguien reporte un problema, pide primero el model ID exacto y la fecha de verificacion; con eso se resuelve mucho mas rapido.
Un chequeo mensual de app, AI Studio y API ayuda a detectar cambios antes de que lleguen a produccion.
Guarda el resultado en un doc compartido para que el equipo tenga la misma referencia y fecha de verificacion.
Si ves diferencias, actualiza la tabla y comunica el cambio al equipo cuanto antes.
Anadir la fecha de la ultima verificacion en la tabla evita dudas cuando se discute un cambio. Si hay varias sedes, comparte el mismo registro para que todos vean el mismo estado.
Ese registro tambien sirve para auditorias internas y para pasar contexto a nuevos integrantes del equipo.
Con cinco minutos al mes suele bastar para mantener la tabla al dia.
Mantenerlo actualizado evita sorpresas cuando cambian nombres o accesos.
No suele requerir mas de unos minutos.
Con un recordatorio mensual es suficiente.
Es un esfuerzo pequeño comparado con el beneficio.
Vale la pena mantenerlo al dia.
No hace falta mas que un vistazo rapido.
Con eso basta.
Eso es suficiente.