feat(models): register Gemini image models for hero_slides Generate All #67

Merged

mik-tf merged 1 commit from development_mik into development

2026-05-10 12:14:32 +00:00

mik-tf commented

2026-05-10 12:13:28 +00:00

Owner

Closes #66.

Summary

Adds two model entries to modelsconfig.yml under the openrouter provider:

gemini-3.1-flash-image-preview → google/gemini-3.1-flash-image-preview (regular tier, $0.5/$3.0 per Mtoken)
gemini-3-pro-image-preview → google/gemini-3-pro-image-preview (premium tier, $2.0/$12.0 per Mtoken)

Both OpenRouter slugs verified against the live catalog (https://openrouter.ai/api/v1/models); both models declare modalities in: [image, text] and modalities out: [image, text]. Pricing pulled directly from the OpenRouter model entries.

Why

hero_slides_lib::models::BASIC_IMAGE_MODEL_ID (and PRO_IMAGE_MODEL_ID) hardcode these two slugs as the canonical image-generation models for the slides pipeline. Today the dashboard's Generate All button reaches aibroker → no entry by that name → cheapest-routing falls through to a Qwen image model → upstream returns HTTP 400: property 'image_config' is unsupported because Qwen doesn't speak Gemini's image-config shape.

With these entries registered, by-name lookup succeeds, OpenRouter passes image_config through verbatim to Gemini, and Generate All produces images on any workstation that has OPENROUTER_API_KEY in hero_proc secrets.

Why `capabilities: [vision]` (not `[tool_calling, vision]` like gemini-flash)

These models output images, not chat with tool calls. vision matches the existing convention for image-aware models in the file. Capability strings are free-form (no enum) and nothing in the broker filters image lookups by capability today, so this is descriptive only — but more honest than tagging an image-generation model as tool_calling.

Verification

On a workstation with OPENROUTER_API_KEY in hero_proc secrets: restart hero_aibroker, confirm models.list includes the two new entries.
From hero_slides admin: open Example Deck → click Generate All → verify a .png lands in the deck's output/ and proc logs get hero_aibroker shows the outbound OpenRouter call to a google/gemini-3.*-image-preview slug (no Qwen fallback).

Out of scope

Adding a top-level Gemini provider (today access via OpenRouter is fine).
Changing the cheapest-routing strategy.
Changing hero_slides' default image-model meta tags (they're correct).

Signed-off-by: mik-tf

Closes https://forge.ourworld.tf/lhumina_code/hero_aibroker/issues/66. ## Summary Adds two model entries to `modelsconfig.yml` under the openrouter provider: - `gemini-3.1-flash-image-preview` → `google/gemini-3.1-flash-image-preview` (regular tier, $0.5/$3.0 per Mtoken) - `gemini-3-pro-image-preview` → `google/gemini-3-pro-image-preview` (premium tier, $2.0/$12.0 per Mtoken) Both OpenRouter slugs verified against the live catalog (`https://openrouter.ai/api/v1/models`); both models declare `modalities in: [image, text]` and `modalities out: [image, text]`. Pricing pulled directly from the OpenRouter model entries. ## Why `hero_slides_lib::models::BASIC_IMAGE_MODEL_ID` (and `PRO_IMAGE_MODEL_ID`) hardcode these two slugs as the canonical image-generation models for the slides pipeline. Today the dashboard's Generate All button reaches aibroker → no entry by that name → cheapest-routing falls through to a Qwen image model → upstream returns `HTTP 400: property 'image_config' is unsupported` because Qwen doesn't speak Gemini's image-config shape. With these entries registered, by-name lookup succeeds, OpenRouter passes `image_config` through verbatim to Gemini, and Generate All produces images on any workstation that has `OPENROUTER_API_KEY` in hero_proc secrets. ## Why `capabilities: [vision]` (not `[tool_calling, vision]` like gemini-flash) These models output images, not chat with tool calls. `vision` matches the existing convention for image-aware models in the file. Capability strings are free-form (no enum) and nothing in the broker filters image lookups by capability today, so this is descriptive only — but more honest than tagging an image-generation model as `tool_calling`. ## Verification - [ ] On a workstation with `OPENROUTER_API_KEY` in hero_proc secrets: restart hero_aibroker, confirm `models.list` includes the two new entries. - [ ] From hero_slides admin: open Example Deck → click Generate All → verify a `.png` lands in the deck's `output/` and `proc logs get hero_aibroker` shows the outbound OpenRouter call to a `google/gemini-3.*-image-preview` slug (no Qwen fallback). ## Out of scope - Adding a top-level Gemini provider (today access via OpenRouter is fine). - Changing the cheapest-routing strategy. - Changing hero_slides' default image-model meta tags (they're correct). Signed-off-by: mik-tf

mik-tf added 1 commit

2026-05-10 12:13:28 +00:00

feat(models): register Gemini image models for hero_slides Generate All

Build and Test / build-and-test (pull_request) Failing after 3s

Details

fc1b3a47b1

Adds gemini-3.1-flash-image-preview and gemini-3-pro-image-preview to
modelsconfig.yml under the openrouter provider. Both slugs verified
against the OpenRouter models catalog.

Without these entries, hero_slides asks aibroker for
"gemini-3.1-flash-image-preview" (per hero_slides_lib::models::
BASIC_IMAGE_MODEL_ID), the lookup misses, cheapest-routing falls back
to a Qwen image model, and the request fails at upstream with
HTTP 400 "property 'image_config' is unsupported" because Qwen
doesn't accept Gemini's image_config shape.

Closes #66

Signed-off-by: mik-tf