No existe una API oficial gratuita e ilimitada de Nano Banana Pro. En la documentación actual de Google, Nano Banana Pro corresponde a gemini-3-pro-image; es una ruta pagada, vinculada al proyecto, a la facturación, a los límites activos y a las reglas de seguridad.
Antes de pagar por una oferta “ilimitada”, separa quién es responsable de la promesa: Google Gemini API, tu proyecto de Google Cloud, Batch/Flex, un proveedor externo o la configuración de seguridad. Cada responsable tiene una prueba distinta.
| Si la promesa es... | Responsable | Qué verificar primero |
|---|---|---|
| Acceso al modelo oficial | Google Gemini API | gemini-3-pro-image, precio actual, estado de facturación |
| Más volumen o concurrencia | Tu proyecto de Google Cloud | Límites activos en AI Studio, tier, topes de gasto |
| Menor coste o trabajo asíncrono | Google Batch/Flex | Precio, latencia, disponibilidad y misma frontera de política |
| “Ilimitado” del proveedor | Contrato del proveedor | Logs, límites, facturación, reembolsos, soporte, prueba de carga |
| Menos bloqueos de seguridad | Política de Google | Umbrales ajustables y protecciones integradas; BLOCK_NONE no es ausencia de reglas |
Regla de parada: si una ruta no prueba el modelo, los límites activos, el responsable de facturación, las reglas de fallo, los reembolsos y el soporte, no pongas tráfico de producción en ella.
Resumen
- La ruta oficial de Google no es un endpoint gratuito e infinito. Nano Banana Pro se usa como gemini-3-pro-image y está limitado por proyecto, facturación, tier y política.
- El 14 de junio de 2026, la página de precios de Google indicaba que gemini-3-pro-image no tenía Free Tier. El output estándar figuraba a $0.134 por imagen 1K/2K y $0.24 por imagen 4K; Batch/Flex figuraba a $0.067 y $0.12.
- Los límites de Gemini API se aplican por proyecto, no por API key. Crear más claves dentro del mismo proyecto no amplía la capacidad.
- Una API key hereda el estado del proyecto y de la cuenta de facturación. Saldo Prepay, estado Postpay, spend caps, tier y enlace de billing importan más que la cadena de la clave.
- Batch/Flex cambia coste y forma de entrega, pero no elimina identidad del modelo, dueño del proyecto ni reglas de seguridad.
- Un proveedor puede ofrecer un wrapper útil, pero solo prueba su propia ruta, contrato, panel, logs y soporte. No prueba que Google haya quitado los límites oficiales.
- BLOCK_NONE es un ajuste de umbral para categorías documentadas. Las protecciones integradas y las comprobaciones no ajustables siguen activas.
Qué puede significar “ilimitada”
“Ilimitada” no describe un solo estado técnico. En Nano Banana Pro API suele mezclar cinco promesas: poder llamar al modelo, enviar más tráfico, reducir coste, evitar límites propios del proveedor o reducir bloqueos de seguridad. Para una decisión de producción, esas promesas deben separarse.
| Afirmación | Nombre más preciso | Responsable | Prueba útil |
|---|---|---|---|
| Puedo llamar al modelo | Acceso oficial al modelo | Google Gemini API | Model ID actual, endpoint, disponibilidad de billing |
| Puedo enviar más volumen | Capacidad del proyecto | Tu proyecto Cloud | Límites activos de AI Studio, tier, spend caps |
| Puedo pagar menos | Economía asíncrona | Google Batch/Flex | Disponibilidad, latencia, precio de output |
| No hay tope diario | Contrato del wrapper | Proveedor | Logs, concurrencia, throttling, política de fallos |
| Puedo relajar seguridad | Umbral de seguridad | Política de Google | Ajustes documentados y protecciones no ajustables |
La pregunta práctica no es qué API es ilimitada. La pregunta útil es quién hizo la promesa y si ese responsable puede demostrarla antes de que tu producto dependa de la ruta. Esa separación evita tres errores caros: activar facturación no borra reglas de seguridad, una clave nueva no crea una cuota nueva del mismo proyecto, y el marketing de un proveedor no se convierte en derecho oficial de Google.
En español, “gratis”, “ilimitado”, “sin restricciones”, “sin marca de agua”, “API key” y “wrapper” pueden aparecer juntos. Para un equipo técnico, cada término debe ir a una verificación distinta: modelo, proyecto, billing, fallo, contrato y seguridad.
Confirma primero el model ID actual
La documentación de generación de imágenes de Google identifica Nano Banana Pro como gemini-3-pro-image. En el mismo conjunto de documentos, Nano Banana 2 aparece como gemini-3.1-flash-image y Nano Banana como gemini-2.5-flash-image. Esa identidad debe confirmarse antes de comparar precios, límites o proveedores.
Tutoriales antiguos, paneles de proveedores, ejemplos de SDK y fragmentos cacheados pueden seguir mostrando nombres con preview. Si la ruta actual no prueba el backend model en documentación, request path, logs o metadata, trata gemini-3-pro-image-preview como una etiqueta antigua o específica de una ruta.
El control mínimo tiene cuatro pasos. Confirmar el nombre público del modelo en Google. Confirmar el model ID usado en tu request. Si hay wrapper, confirmar logs o metadata del proveedor. Después clasificar fallos: 404, 403, 429, safety, timeout upstream o empty output. Sin esa clasificación, una comparación de coste o capacidad es prematura.
Si falta uno de esos pasos, la ruta sirve para un experimento pequeño, no para decidir presupuesto ni tráfico de producción.
Precios oficiales y límites de facturación
El 14 de junio de 2026, la página de precios de Google mostraba gemini-3-pro-image sin Free Tier. El output estándar figuraba a $0.134 por imagen 1K/2K y $0.24 por imagen 4K. Batch/Flex output figuraba a $0.067 y $0.12. Image input y Google Search grounding tenían líneas de coste separadas.
Esos números solo sirven cuando el dueño de la facturación está claro. Las Gemini API keys oficiales no llevan un estado de billing independiente. Heredan el proyecto y la cuenta de facturación. Una key creada en un proyecto sin ruta de pago útil no se convierte en una ruta pagada de alto volumen por moverla a otro backend.
La documentación de billing de Google describe estados operativos que afectan al tráfico. Un saldo Prepay puede llegar a cero y detener claves vinculadas. Postpay status y spend caps pueden limitar un proyecto aunque exista cuenta de facturación. El usage tier afecta la elegibilidad de cuota. Los welcome credits de cuentas nuevas después del 2 de marzo de 2026 no son fuente de pago válida para Gemini API y AI Studio.
Para planificar coste, separa precio por imagen útil y precio por request intentado. Una generación bloqueada, fallida o con timeout puede haber consumido trabajo. El panel del proveedor debe separar successful images, failed attempts, refunds, balance changes e invoice rows. Si solo muestra imágenes exitosas, no sirve para presupuesto de producción.
Cuotas, claves y límites activos
Los límites de Gemini API son project-scoped. Google describe dimensiones como RPM, input TPM y RPD; exceder cualquiera puede producir un rate-limit error. Los límites públicos no están garantizados, así que los límites activos deben revisarse en AI Studio para el proyecto real.
El error común es crear más API keys dentro del mismo proyecto y esperar más capacidad. Eso solo añade credenciales. Puede ayudar a separar entornos, rotar secretos y reducir daño por filtración, pero no cambia project tier, billing state ni active limit.
La ruta correcta empieza por abrir el proyecto dueño de la key. Revisa billing linkage, Prepay o Postpay, spend caps, usage tier y active model limits en AI Studio. Guarda el texto exacto de 429 o quota error. Luego identifica si falló RPM, TPM, RPD, batch tokens o throttling del proveedor. Solo entonces puedes elegir tier upgrade, cola, Batch/Flex, cache o proveedor probado.
En un equipo, conviene mantener una tabla con key, project, billing account, entorno y dashboard. Sin esa tabla, un saldo agotado o un spend cap se puede confundir con una avería del modelo.
Batch/Flex ayuda al coste, no a la autorización
Batch/Flex es útil cuando la carga tolera ejecución diferida. Variantes de catálogo, assets localizados, colas nocturnas, backlogs de diseño y trabajos creativos masivos pueden beneficiarse de un flujo asíncrono.
No cambia tres cosas. Nano Banana Pro sigue necesitando gemini-3-pro-image. El dueño del proyecto, la facturación y el límite activo siguen importando. Los ajustes de seguridad y las protecciones integradas siguen aplicándose.
Usa Batch/Flex si el problema es coste, forma de cola o tolerancia a la latencia. No lo uses como respuesta a bloqueos de política, falta de billing, IDs preview antiguos o promesas de proveedor sin pruebas. Si el usuario espera resultado inmediato, la arquitectura de respuesta pesa más que el descuento.
Cómo auditar una promesa de proveedor
Un wrapper puede ser útil. Puede ofrecer un endpoint OpenAI-compatible, unificar modelos, simplificar operación, dar un contrato comercial diferente, manejar saldo, retries o soporte. Pero una promesa del proveedor sigue siendo contrato del proveedor, no una declaración de cuota de Google.
Si evalúas laozhang.ai u otro wrapper, la prueba debe venir de su panel, logs, términos, política de reembolso y soporte. No traslades precios oficiales de Google, límites de proyecto de Google o lenguaje de seguridad de Google a una promesa del proveedor sin verificación propia.
Antes de mover producción, valida seis puntos. Model proof: logs o metadata muestran gemini-3-pro-image o una ruta equivalente documentada. Capacity proof: una prueba pequeña cubre concurrency, queueing, retry y throttling. Billing proof: el panel separa successful images, failed attempts, refunds, balance changes e invoices. Failure proof: 429, safety blocks, upstream failures, timeouts y empty outputs se pueden diagnosticar. Contract proof: términos explican usage rights, refund rules, support escalation y exclusiones. Exit proof: tu código puede volver a Google oficial o a otro proveedor.
Una ruta barata solo es útil si es observable. Si no muestra modelo, límites, cobros y fallos, puede servir para demo, pero no para producción.
Safety settings no son un interruptor de política
Google permite ajustar umbrales de categorías documentadas, incluido BLOCK_NONE en contextos de API admitidos. Esto ayuda a reducir bloqueos excesivos para aplicaciones legítimas donde la clasificación se gestiona también en la capa del producto.
Pero BLOCK_NONE no elimina las protecciones integradas. La documentación de Google indica que core protections, incluidas protecciones de seguridad infantil, permanecen bloqueadas y no pueden ajustarse. Output-side image checks y otras protecciones no ajustables pueden detener una solicitud incluso con umbrales relajados.
Esto importa al evaluar proveedores. Un proveedor puede ofrecer acceso más cómodo o contrato distinto, pero no puede prometer honestamente que las protecciones no ajustables de Google han desaparecido. Si una ruta se vende como forma de quitar todos los controles, es una condición de parada.
Después de un bloqueo real, guarda status code, finish reason, safety category, provider log row y billed amount. Reintentar sin esos datos aumenta coste e incertidumbre.
Reglas de decisión
| Situación | Mejor siguiente paso | Primera prueba | Condición de parada |
|---|---|---|---|
| Necesitas API oficial | Configura o revisa el proyecto Gemini API | Docs actuales y request path muestran gemini-3-pro-image | No se prueba model ID o endpoint |
| Necesitas más volumen | Revisa active limits y billing tier | AI Studio y texto exacto del 429 | La solución principal es crear más keys en el mismo proyecto |
| Necesitas menor coste | Compara Standard, Batch/Flex y proveedor | Precio fechado y tolerancia a latencia | Precio sin fuente actual o panel verificable |
| Necesitas bulk async | Usa Batch/Flex o proveedor con cola | Queue behavior y completion logs | El usuario necesita respuesta síncrona |
| Necesitas wrapper | Haz due diligence del proveedor | Model logs, caps, billing rows, support path | No muestra modelo, límites, reembolsos o fallos |
| Necesitas menos safety blocks | Ajusta settings documentados y prompts dentro de política | Finish reason y safety evidence | Promete quitar non-adjustable protections |
La decisión más sólida suele salir de dos pruebas pequeñas: una en proyecto oficial y otra en proveedor. Envía el mismo conjunto representativo de prompts, registra model ID, latency, success rate, failure class, billed amount y support response. Si una ruta falla ahí, no debe recibir carga grande.
Siguientes verificaciones
Para entender si una key puede ser gratuita, usa Nano Banana Pro API key gratis. Para implementación oficial, usa Nano Banana Pro API guide.
Si el problema es cuota o 429, revisa aumentar cuota de Nano Banana Pro API. Para coste, compara Nano Banana Pro pricing con Batch API cost optimization y con cualquier contrato de proveedor.
Si el problema es una respuesta fallida, usa Nano Banana Pro error y conserva error string, log row y billing row antes de reintentar.
Preguntas frecuentes
¿La API oficial de Nano Banana Pro es ilimitada?
No. El acceso oficial es pagado, project-tiered y policy-bound. Más capacidad viene de active limits, billing status, tier eligibility, Batch/Flex o un contrato de proveedor probado.
¿gemini-3-pro-image-preview sigue siendo el model ID correcto?
En la documentación de Google revisada el 14 de junio de 2026, Nano Banana Pro corresponde a gemini-3-pro-image. Los IDs con preview deben tratarse como legacy o route-specific hasta que una ruta actual los pruebe.
¿Crear más API keys aumenta la cuota?
No dentro del mismo proyecto. Los límites se aplican al proyecto. Más keys ayudan a higiene de credenciales, pero la capacidad depende de project limits, billing, tier y route owner.
¿Batch/Flex elimina límites?
No. Batch/Flex cambia coste, latencia y forma del workflow. No elimina model identity, project ownership, billing requirements ni safety protections.
¿Un proveedor puede ofrecer acceso de alto volumen?
Puede, pero debe demostrarlo en su ruta: model logs, capacity behavior, billed rows, failure classes, refund rules, support escalation y una prueba pequeña de carga.
¿BLOCK_NONE elimina todos los safety blocks?
No. BLOCK_NONE ajusta umbrales documentados donde se admite. Las protecciones integradas y otros controles no ajustables siguen activos.