{"id":40427,"date":"2026-09-09T07:00:00","date_gmt":"2026-09-09T14:00:00","guid":{"rendered":"https:\/\/cloudinary.com\/blog\/?p=40427"},"modified":"2026-09-09T12:17:55","modified_gmt":"2026-09-09T19:17:55","slug":"i-stopped-choosing-image-models-manually","status":"publish","type":"post","link":"https:\/\/cloudinary.com\/blog\/i-stopped-choosing-image-models-manually","title":{"rendered":"I Stopped Choosing Image Models Manually"},"content":{"rendered":"\n

Every few weeks there’s a new image model everyone says you should be using: FLUX, Recraft, Ideogram, GPT Image. Each one has different strengths, different tradeoffs, and another decision for developers to make before they’ve even written a line of code.<\/p>\n\n\n\n

So when I started experimenting with Cloudinary’s new Image Generation API<\/a>, I caught myself doing something familiar:<\/p>\n\n\n

generate_image(\nprompt=prompt,\nmodel=\"flux\"<\/span>\n)<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Then I realized I shouldn’t be choosing the model at all.<\/p>\n\n\n\n
I’ve spent the last few years building AI agents that decide what actions to take based on context. They choose tools, call APIs, verify their own work. So I stopped making this decision myself.<\/p>\n\n\n\n
The Problem With Hardcoding Models<\/h2>\n\n\n\n
Most examples, including the ones you’ll find in documentation, explicitly choose a model. That makes perfect sense for a quickstart, but production applications don’t receive the same prompt over and over again.<\/p>\n\n\n\n
One request might be “create a photorealistic product shot.” Another might be “design a conference poster with large readable typography.” Another might be “generate a hand drawn sketchnote from these lecture notes.” You probably wouldn’t use the same model for all three. Different models have genuinely different strengths. Some are better at photorealism, others produce stronger illustrations, others handle typography more effectively.<\/p>\n\n\n\n
So instead of asking which model I should hardcode, I started asking whether my agent should decide instead.<\/p>\n\n\n\n
My First Attempt Was Simple<\/h2>\n\n\n\n
I wrote a choose_model()<\/code> function that matches keywords in the prompt to model strengths:<\/p>\n\n\n
def choose_model_simple(prompt: str) -> dict:\nprompt_lower = prompt.lower()\n\nif<\/span> any(w in<\/span> prompt_lower for<\/span> w in<\/span> [\"text\"<\/span>, \"poster\"<\/span>, \"logo\"<\/span>, \"typography\"<\/span>, \"sign\"<\/span>]):\n    return<\/span> {\"family\"<\/span>: \"ideogram\"<\/span>, \"tier\"<\/span>: \"standard\"<\/span>, \"reason\"<\/span>: \"Prompt likely needs strong text handling.\"<\/span>}\n\nif<\/span> any(w in<\/span> prompt_lower for<\/span> w in<\/span> [\"photo\"<\/span>, \"realistic\"<\/span>, \"portrait\"<\/span>, \"cinematic\"<\/span>]):\n    return<\/span> {\"family\"<\/span>: \"flux\"<\/span>, \"tier\"<\/span>: \"premium\"<\/span>, \"reason\"<\/span>: \"Prompt is photorealistic, so Flux is a strong fit.\"<\/span>}\n\nif<\/span> any(w in<\/span> prompt_lower for<\/span> w in<\/span> [\"illustration\"<\/span>, \"sketchnote\"<\/span>, \"diagram\"<\/span>, \"vector\"<\/span>]):\n    return<\/span> {\"family\"<\/span>: \"recraft\"<\/span>, \"tier\"<\/span>: \"standard\"<\/span>, \"reason\"<\/span>: \"Prompt sounds illustration-heavy.\"<\/span>}\n\nreturn<\/span> {\"family\"<\/span>: \"nano-banana\"<\/span>, \"tier\"<\/span>: \"standard\"<\/span>, \"reason\"<\/span>: \"No specific requirement detected; using the default.\"<\/span>}<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
It works for obvious cases. But it breaks the moment prompts get ambiguous, and prompts are almost always a little ambiguous.<\/p>\n\n\n\n
\"keyword
The keyword router explains why it selected Ideogram before calling Cloudinary.<\/figcaption><\/figure>\n\n\n\n
The keyword router explains why it selected Ideogram before calling Cloudinary.<\/p>\n\n\n\n
Why Keyword Matching Isn’t Enough<\/h2>\n\n\n\n
Try this prompt: “A sketchnote of my lecture on photorealistic rendering techniques.”<\/p>\n\n\n\n
A keyword router sees “photorealistic” and picks Flux. But the output you actually want is an illustration. The word photorealistic describes the subject, not the style.<\/p>\n\n\n\n
A keyword router matches words. Your agent understands intent. It understands that the output should be a sketchnote, not a photorealistic rendering.<\/p>\n\n\n\n
Swapping in Claude<\/h2>\n\n\n\n
Replacing the keyword router with Claude is one function change:<\/p>\n\n\n
def choose_model_claude(prompt: str) -> dict:\nclient = anthropic.Anthropic()\nmessage = client.messages.create(\nmodel=\"claude-sonnet-4-6\"<\/span>,\nmax_tokens=256<\/span>,\nsystem=\"\"<\/span>\"You are a model router for an image generation pipeline.\nGiven a prompt, return ONLY a JSON object:\n{\"<\/span>family\": \"<\/span>\u2026\", \"<\/span>tier\": \"<\/span>\u2026\", \"<\/span>reason\": \"<\/span>One sentence.\"}\nAvailable families: flux, ideogram, recraft, gpt-image, nano-banana.\"<\/span>\"\"<\/span>,\nmessages=[{\"role\"<\/span>: \"user\"<\/span>, \"content\"<\/span>: f'Prompt: \"{prompt}\"'<\/span>}],\n)\nreturn<\/span> json.loads(message.content[0<\/span>].text.strip())<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
The keyword router makes a decision by matching keywords. Claude reasons about the intent of the request before choosing a model.<\/p>\n\n\n\n
\"diagram\"\/<\/figure>\n\n\n\n
Notice what changed. The agent isn’t generating the image, it isn’t replacing Cloudinary. It’s making a routing decision. Cloudinary remains the execution layer while the agent decides which model best fits the request. Because Cloudinary exposes multiple model families through the same API, the router only has to decide what<\/strong> to use, not how<\/strong> to call it.<\/p>\n\n\n\n
This example uses a small routing script to make that decision explicit, but the same idea applies to larger agent workflows. If you’re already building agents, model selection can become just another reasoning step before the API call. I wrote it as a standalone script because it’s easier to understand, easier to experiment with, and easier to adapt to your own projects.<\/p>\n\n\n\n
What I Actually Learned<\/h2>\n\n\n\n
The model choice matters more than I expected. The same prompt can produce very different results depending on which model you pick, and those differences aren’t subtle. Text rendering in particular is still surprisingly hard. Generating a beautiful image is relatively easy, but generating a beautiful image with readable text is a different problem entirely.<\/p>\n\n\n\n
What I found most interesting was that the routing decision itself was the interesting part, not the generation. Once you separate “which model should I use” from “call the API,” that first question becomes something an agent can reason about rather than something you have to answer in advance every time.<\/p>\n\n\n\n
Why Cloudinary?<\/h2>\n\n\n\n
I wasn’t looking for another image model. I was looking for a consistent interface to multiple image models. Without that, swapping models means learning new APIs, new authentication, and new response shapes.<\/p>\n\n\n\n
With Cloudinary’s Image Generation API, the router just returns a family name. Everything else stays the same.<\/p>\n\n\n\n
Generated images also land directly in Cloudinary as managed assets, immediately available for transformation and delivery without me needing to do any extra steps.<\/p>\n\n\n\n
Try It Yourself<\/h2>\n\n\n\n
If you’d like to experiment with this pattern, I’ve shared the complete routing script as a GitHub Gist.<\/p>\n\n\n\n
The script uses Cloudinary’s Image Generation API to select a model, generate the image, and save it as a managed asset.<\/p>\n\n\n\n
To get started:<\/p>\n\n\n\n