Error 500 en Nano Banana Pro antes de generar la imagen

Higgsfield API error (HTTP 500). Internal Server Error

Nano Banana Pro devolvió ese mensaje al instante. No creó ninguna tarea ni generó ninguna imagen.

El comando que fallaba usaba nano_banana_2 con una imagen de referencia, --aspect_ratio auto y --resolution 4k. El fallo se repetía tanto si proporcionaba una ruta local como si usaba un ID de subida.

Lo primero fue sospechar del archivo de referencia. Pero eso solo era parte del problema.

Dos problemas distintos con los parámetros estaban provocando la misma respuesta del servidor, que no ayudaba a identificar la causa.

auto se admitía sobre el papel, pero fallaba en la práctica

El esquema del modelo incluía auto entre los valores admitidos para aspect_ratio. Aun así, enviarlo provocaba un HTTP 500.

Esto importa porque un valor incluido en la lista de opciones suele parecer más seguro que una proporción elegida manualmente. Yo esperaba que el servidor examinara la imagen de origen y eligiera por mí. En cambio, la petición fallaba antes de crear una tarea.

El segundo problema era la opción --image. Esa opción también provocaba un error 500 con este modelo.

Nano Banana Pro esperaba recibir la referencia mediante input_images. No bastaba con meter el ID de subida en un array. El array debía contener objetos con una estructura concreta:

[
  {
    "id": "<upload-id>",
    "type": "media_input"
  }
]

Un array de cadenas de texto fallaba con Input should be a valid object. Un objeto que contenía el ID pero no el tipo fallaba con Field required.

Esos mensajes de validación eran más útiles que el error 500 original. Mostraban que el servidor no necesitaba solo una imagen subida. Necesitaba una entrada multimedia estructurada.

Reduje la petición antes de volver a probar en 4K

No seguí enviando el comando completo de aumento de resolución. Preparé una prueba mínima en 1K.

Primero subí el original:

higgsfield upload create <path> --json

Eso devolvió el ID de subida que necesitaba input_images.

Después comprobé las dimensiones de la imagen de origen. Utilicé PIL:

python -c "from PIL import Image; print(Image.open(p).size)"

Una vez conocidas las dimensiones, elegí la relación de aspecto explícita más cercana entre las admitidas por el modelo. Los dos originales de este caso correspondían a 2:3 y 4:3.

No envié auto.

Luego guardé el objeto multimedia en un archivo JSON y lo pasó mediante:

--input_images @file.json

La prueba usaba 1K para comprobar la estructura de la petición antes de pasar a la salida definitiva. Cuando esa petición creó y completó una tarea, utilicé la misma estructura para las generaciones en 4K.

Los dos aumentos de resolución a 4K se completaron. Lo verifiqué el 11 de junio de 2026.

Por qué fue útil la prueba mínima

Los aumentos de resolución originales fallaron tres veces con la combinación de --image y auto. Repetir ese comando no aclaraba si la causa era la imagen, la proporción, la resolución o la estructura de la petición.

La prueba pequeña permitió separar esas variables.

Los errores de validación establecieron la estructura necesaria del objeto. Las proporciones explícitas eliminaron el valor auto, que fallaba. Solo volví a la salida prevista en 4K después de que ambos cambios funcionaran en 1K.

El coste adicional fue una prueba en 1K.

No había motivo para probar en 8K. Tanto Nano Banana Pro como Bytedance Image Upscale tienen un límite de 4K en la plataforma.

Comprueba si la petición fallida llegó a crear una tarea

Un HTTP 500 inmediato puede parecer costoso porque llega de la API y no de una validación local. En este caso, el fallo se produjo antes de crear la tarea y no consumió créditos.

Aun así, lo compruebo en lugar de darlo por hecho.

Después de un error 500 inmediato, consulto:

higgsfield generate list

Si no se creó ninguna tarea, sí que la petición falló antes de entrar en la cola de generación. Eso permite distinguir una petición mal formada de un resultado generado que falló más tarde.

También cambia mi forma de depurar. Un error 500 previo a la creación de la tarea exige revisar los parámetros. No exige otro intento a resolución completa con los mismos argumentos.

La regla que aplico ahora

Con nano_banana_2, nunca uso --aspect_ratio auto. Compruebo las dimensiones del original y elijo la proporción explícita admitida que más se aproxima.

También paso las referencias mediante input_images como un array de objetos. Cada objeto incluye tanto el ID de subida como "type": "media_input".

Antes de cualquier tanda de pago, envío una petición mínima en 1K. Esa prueba confirma la estructura de la entrada multimedia, la proporción y el proceso de creación de la tarea con la prueba más pequeña documentada.

Si Nano Banana Pro te devuelve hoy un error 500 inmediato, revisa primero la lista de tareas. Después sustituye auto, deja de usar --image y prueba una petición con input_images estructurado en 1K.

---

Cada solución de este artículo empezó con un error que pagué yo. Mejor en mi película que en tu marca.