You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
google_imagen offers exactly three models, and all three are now closed to new Google accounts. Any user who signs up today gets a 404 no matter which they pick, so the tool is unusable on a fresh install — while the registry still reports it as available, because availability is gated on GOOGLE_API_KEY being present rather than on the model being reachable.
The model ids are hardcoded in tools/graphics/google_imagen.py — an enum of three at L118-120 and the same default repeated at L122, L177 and L215.
Operating system
Windows 11, Python 3.12
Pipeline
Any pipeline selecting Google Imagen for stills
Runtime / renderer
n/a — fails at the API call
Steps to reproduce
Create a new Google API key (AI Studio or Cloud Console) — this matters; existing accounts are grandfathered and will not reproduce it.
Set GOOGLE_API_KEY in .env.
Run google_imagen:
registry.get("google_imagen").execute({
"prompt": "a plain grey studio backdrop",
"output_path": "out.png",
})
Repeat with model set to each of the other two enum values.
Expected behavior
An image is generated, or the tool reports itself unavailable with actionable guidance.
Actual behavior
All three models return 404. The tool reports available beforehand, so the failure only surfaces at call time, mid-pipeline.
Note the models are still listed by the API and still advertise predict, so a catalog check does not reveal the problem — only an actual call does:
imagen-4.0-generate-001 HTTP 404: This model models/imagen-4.0-generate-001 is no longer available to new users.
Please update your code to use a newer model for the latest features and improvements.
imagen-4.0-fast-generate-001 HTTP 404: This model models/imagen-4.0-fast-generate-001 is no longer available to new users.
imagen-4.0-ultra-generate-001 HTTP 404: This model models/imagen-4.0-ultra-generate-001 is no longer available to new users.
Suggested fix
The current-generation image models on the Generative Language API are reached through :generateContent, not :predict, and return the image as an inlineData part:
I could not verify these end-to-end — my account returned 429 You exceeded your current quota for image generation on the free tier, so I can confirm the old path is dead but not that the new path works. Flagging that explicitly rather than implying I tested it. Happy to verify if someone with billing enabled can confirm, or once I enable it.
Two things worth considering alongside the model list:
Don't hardcode the default in four places. L122, L177 and L215 each repeat "imagen-4.0-generate-001", so a fix has to touch all of them consistently.
get_status() currently only checks that GOOGLE_API_KEY is set. That is why this reports available and then fails. This same pattern bit me elsewhere in the repo — see .env.example inline comments load as credential values, making ~30 tools falsely report available #431, where empty keys pick up their own .env.example comment as a value and ~30 tools report available with garbage credentials. A status check that reflects reachability, not just key presence, would catch both classes.
Summary
google_imagenoffers exactly three models, and all three are now closed to new Google accounts. Any user who signs up today gets a 404 no matter which they pick, so the tool is unusable on a fresh install — while the registry still reports it asavailable, because availability is gated onGOOGLE_API_KEYbeing present rather than on the model being reachable.The model ids are hardcoded in
tools/graphics/google_imagen.py— anenumof three at L118-120 and the same default repeated at L122, L177 and L215.Operating system
Windows 11, Python 3.12
Pipeline
Any pipeline selecting Google Imagen for stills
Runtime / renderer
n/a — fails at the API call
Steps to reproduce
Create a new Google API key (AI Studio or Cloud Console) — this matters; existing accounts are grandfathered and will not reproduce it.
Set
GOOGLE_API_KEYin.env.Run
google_imagen:Repeat with
modelset to each of the other two enum values.Expected behavior
An image is generated, or the tool reports itself
unavailablewith actionable guidance.Actual behavior
All three models return 404. The tool reports
availablebeforehand, so the failure only surfaces at call time, mid-pipeline.Note the models are still listed by the API and still advertise
predict, so a catalog check does not reveal the problem — only an actual call does:Relevant logs or error output
imagen-4.0-generate-001 HTTP 404: This model models/imagen-4.0-generate-001 is no longer available to new users. Please update your code to use a newer model for the latest features and improvements. imagen-4.0-fast-generate-001 HTTP 404: This model models/imagen-4.0-fast-generate-001 is no longer available to new users. imagen-4.0-ultra-generate-001 HTTP 404: This model models/imagen-4.0-ultra-generate-001 is no longer available to new users.Suggested fix
The current-generation image models on the Generative Language API are reached through
:generateContent, not:predict, and return the image as aninlineDatapart:I could not verify these end-to-end — my account returned
429 You exceeded your current quotafor image generation on the free tier, so I can confirm the old path is dead but not that the new path works. Flagging that explicitly rather than implying I tested it. Happy to verify if someone with billing enabled can confirm, or once I enable it.Two things worth considering alongside the model list:
"imagen-4.0-generate-001", so a fix has to touch all of them consistently.get_status()currently only checks thatGOOGLE_API_KEYis set. That is why this reportsavailableand then fails. This same pattern bit me elsewhere in the repo — see .env.example inline comments load as credential values, making ~30 tools falsely report available #431, where empty keys pick up their own.env.examplecomment as a value and ~30 tools reportavailablewith garbage credentials. A status check that reflects reachability, not just key presence, would catch both classes.Related: #431.