fix(api): allow text-to-image on dual-modality models + revive HuggingFace image host

[danscMax]

Problem

Two independent defects break /v1/images/generations, both found while testing image generation end-to-end against a live instance.

1. Dual-modality models can't do text-to-image

The gate classified any model whose inputModalities include "image" as requiring an image input:

const requiresImageInput = inputModalities.includes("image");

But in the registry, ["text", "image"] means the model accepts an image (edit-capable) — it can still run pure text-to-image. Treating that as mandatory rejected legitimate text-to-image with 400 "Image input is required for image model: ...".

41 models were blocked: Together ×10, Stability ×10, LMArena ×15, NVIDIA ×3, Black Forest Labs ×2, NanoGPT ×1. Only edit-only models (["image"], no "text") should require an image.

Fix: extract modalitiesRequireImageInput() and gate on includes("image") && !includes("text").

2. HuggingFace image provider points at a retired host

The image registry used https://api-inference.huggingface.co/models, which HuggingFace has retired — it no longer resolves (fetch failed → 502 Image provider error). The chat provider already migrated to router.huggingface.co; the image entry was left behind.

Fix: https://router.huggingface.co/hf-inference/models. Verified live — both /hf-inference/models/{model} and the old host were probed: old host → connection failure (HTTP 000), new host → 401 (reachable, awaits auth). This revives 3 free models (FLUX.1-dev, FLUX.1-schnell, SDXL) on already-connected HF accounts.

Test

tests/unit/image-text-to-image-modality.test.ts — fails on base (the helper did not exist and the baseUrl was the retired host), passes with the fix. Asserts:

• modalitiesRequireImageInput classifies edit-only / dual / text-only / nullish correctly
• no dual ["text","image"] registry model is gated as image-required
• the HF image baseUrl is the live router host, and ${baseUrl}/${model} yields the router URL

npm run typecheck:core clean; eslint clean on changed files; existing image-registry-gpt56.test.ts still passes.

Scope

Surgical — only the modality gate and the HF host. Not touched (flagged for follow-up): wiring gemini/imagen into the image registry via the :predict API, and the Gemini free-tier limit: 0 cooldown classification.

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[diegosouzapw]

Thanks for tracking this down and including a live-tested regression guard — the dual-modality gate fix (BFL Kontext / Together / NVIDIA / LMArena / NanoGPT) and the HuggingFace host migration both check out, and I confirmed the new test runs correctly in test:unit.

One thing surfaced while cross-checking the registry: the same modalitiesRequireImageInput() reclassification also flips requiresImageInput to false for 10 Stability AI models — inpaint, outpaint, search-and-replace, search-and-recolor, replace-background-and-relight, creative (upscale), sketch, structure, style, style-transfer. These are exactly your "Stability x10" count, but they're all Stability's dedicated /v2beta/stable-image/{edit,control,upscale}/* endpoints (see STABILITY_EDIT_ENDPOINTS in imageGeneration.ts), which mechanically require an input image — they're not flexible text-to-image generation models like the BFL/Together/NVIDIA ones. With the current fix, calling e.g. stability-ai/inpaint with just a prompt now skips OmniRoute's clean 400 and forwards straight to Stability without an image field, which will fail with a less helpful upstream error instead.

Could you carve those 10 out of the reclassification (keep requiresImageInput=true for the STABILITY_EDIT_ENDPOINTS set specifically) and add a test asserting they still gate on image input? Everything else here looks solid — happy to take another look once that's addressed.