[FEATURE] Add support for gemini 2.5 image (Nano banana) on the `.paint` action

[myxoh]

Scope check

• This is core LLM communication (not application logic)
• This benefits most users (not just my use case)
• This can't be solved in application code with current RubyLLM
• I read the Contributing Guide

Due diligence

• I searched existing issues
• I checked the documentation

What problem does this solve?

The Gemini 2.5 image family requires a different calling pattern to generate an image with the .paint command - my goal is to add support for this model on the famifly of supported image models

Proposed solution

When calling the API for Gemini models - we should check whether the image models supports predict or generateContent - and decide the API params and structure accordingly

Why this belongs in RubyLLM

This is the best image model as per various benchmarks and it is currently not possible to call it using .paint

[myxoh]

I've got a PR upcoming - trying to figure out the models.json situation right now

[crmne]

Hey @myxoh would be great if you can figure it out but I'm skeptical.

Making #paint use the #chat interface depending on the model would mean knowing which model uses the chat interface and which uses the paint one. I don’t see an easy way of doing this that doesn’t involve a manual list. Maintaining such a list is infeasible.

Also this would mean patching a significant quirk of a provider and I'm not a big fan of that.

What I'm a big fan of is education: expose the magic to the user by documenting which RubyLLM API uses which provider API.

What do you think?

[myxoh]

Hey sorry for the slow response @crmne:
https://github.com/crmne/ruby_llm/compare/main...Singulate-AI:ruby_llm:myxoh/gemini-2-5-flash-image?expand=1

What I meant - rather than using #paint use the #chat interface - is there's a specific set of API parameters we can use to call the model to only respond with an image.

So I just want to have the latest image model available through the #paint interface.

With regards to provider quirks - that is of course up to you whether you want to support that - but it seems to me that new image models from Google will be following the new API so it seems like a good idea to support the new API as oppose to only the older one?

Let me know your thoughts?

[myxoh]

One thing I'm struggling with (maybe should be a separate issue) is that calling rake models without having all the API keys configured is making modifications to a lot of unrelated providers I don't have configured.

It makes it hard to do work with specific providers like here.

I'm also getting a lot of errors running some of the specs in main- is main meant to be green?

Noticing a number of issues raising:

) RubyLLM::Transcription basic functionality vertexai/gemini-2.5-flash can transcribe with language hint
Failure/Error: @source.is_a?(ActiveStorage::Blob) ||

NameError:
 uninitialized constant ActiveStorage::Blob

Will check with colleagues soon to check if this is a local issue - do you need help setting some CI to this repo? I've done some similar work for grape-js