Claude is a strong writer of image prompts and a poor renderer of pixels. It has no diffusion model of its own, so every image workflow that starts in a Claude chat or in Claude Code ends somewhere else: an MCP server, a small script, or a hosted endpoint that holds the API keys. The part people get wrong is the order of operations. They write a long prompt first, then go shopping for a model, and end up rewriting the prompt for every provider they try. Doing it the other way round, picking the model class first and then writing a brief that survives a swap, is what turns a one-off render into a workflow. If you are working inside the terminal, the Claude Code integration path is the shortest version of this setup.

This guide covers the two decisions that actually matter: which model to route the job to, and how to write an image brief you can reuse across models, weeks, and batches without rewriting it each time. The same two decisions apply whether you call the renderer from a chat, a local script, or a workflow you expose as an API.

Claude does not render, it routes

Anthropic’s models read images well and write about them well, but they do not generate them. What Claude does contribute is the part most people are worse at than they think: turning a vague request into a structured brief with a subject, a lens, a light source, a palette, and a negative list. Once that brief exists, the render is a routing decision, and routing is cheap to change.

That separation is why “which image model is best” is the wrong first question. The better question is which class of job you are doing, because the current generation of image models has split into fairly clean specialisms rather than one general winner. Photoreal scenes, text-in-image, and in-place editing now pull toward three different engines.

Choose the model before you write the brief

Pick the class of job, then the model, then write the brief for that model’s strengths. Four options cover most of what comes through a Claude workflow, and the FLUX 1.1 Pro model page covers the photoreal end of that list in more depth.

Job	Model to route to	Why	Typical cost per image
Photoreal scenes, people, product shots	FLUX 1.1 Pro	Holds anatomy and lighting at high resolution	$0.04
Fast iteration, cheap drafts	FLUX Krea or FLUX Dev	Good enough to judge composition before you spend	$0.003 to $0.025
Editing an existing image, character consistency	Nano Banana 2	Instruction editing without a full re-render	$0.03 to $0.14
Vector, logos, clean text in the image	Recraft V4	Native SVG output and reliable typography	$0.04 to $0.08

Editing is the case people underestimate. If the workflow is “render once, then change fourteen small things”, an instruction editing model saves more time than any prompt tuning will, and the Nano Banana 2 API guide covers the request shape for that pattern.

Text inside the image is the other fork worth deciding early. Diffusion models still mangle long strings, so if the deliverable has a headline, a price, or a logo lockup baked in, route it to a model with vector output rather than fixing spelling in six retries. The Recraft V4 examples show the difference on typography-heavy work.

Write an image brief that survives a model swap

A reusable brief is a structured object, not a paragraph. Ask Claude to keep it as JSON or YAML in the repo, and the same file can feed any model with only the renderer-specific fields changing. This is the same discipline that makes a prompt library useful instead of a pile of one-off strings. A brief that travels well has seven fields:

• subject: who or what, with the two or three details that must not drift
• setting: place, time of day, weather
• light: source, direction, quality, for example “single hard key from camera left, deep falloff”
• lens: focal length and framing, for example “85mm, chest up, shallow depth”
• palette: three to five colours, named
• style: the register, for example “editorial photography” or “painterly concept art”
• avoid: the negative list, kept short and specific

Only the last two usually need model-specific tuning. FLUX responds to natural sentences and handles long descriptive strings; Recraft prefers shorter design-language instructions; editing models want an instruction rather than a description, phrased as “change the background to X, keep the subject untouched”. Keeping those variants as separate fields in one file is what makes the swap a config change rather than a rewrite, the same way a REST pipeline swaps a step without touching its callers.

Three ways to wire it up

In our own timing, the wiring is not the slow part. Across three separate setups, getting image generation working inside Claude Code took under ten minutes each time, while arriving at a brief that held up across two different models took closer to an afternoon. Budget your attention accordingly.

The first route is an MCP server. Claude calls a generate tool the same way it calls any other tool, the image lands on disk, and the conversation keeps its context. This suits exploratory work where you want to look at a frame and immediately ask for a change. It is the weakest option for volume, because every render is a turn in a chat, and a programmatic generation platform will handle a hundred renders better than a chat loop will.

The second route is a script. Claude writes a small CLI that reads the brief file, posts to the provider, and writes the result to a folder with a predictable name. This is the right shape once you know the model and the brief are settled, and it scales into batch generation over a list of inputs without any further work.

The third route is a hosted endpoint. The graph lives outside your repo, the keys live with it, and Claude calls one URL regardless of which model is behind it. The advantage shows up when you change models: the workflow changes on the server and every caller, including Claude Code, keeps working unchanged. This is the usual end state for anything that ships on a schedule, and node-based image pipelines are built for exactly that swap.

Keeping a series consistent

Consistency comes from fixing things, not from asking nicely. Fix the seed, fix the brief file, and fix the reference image, then change one field at a time. Fast draft models earn their place here: run twenty cheap variations from a lower-cost FLUX variant to find the composition, then re-render the winner once at full quality with the same seed and brief.

For character or product consistency across weeks, keep an anchor image in the repo next to the brief and pass it as a reference on every subsequent render. An instruction editing model plus a fixed anchor will hold a face or a package design far better than a text prompt repeated from memory, and it means week three matches week one without anyone reconstructing what was asked for in week one.

A working sequence

The order below is what the two decisions above look like in practice, and a prompt generator is a reasonable way to draft the first version of the brief before you start editing fields.

1. Say what the deliverable is and how many of them you need.
2. Pick the model class: photoreal, draft, edit, or vector.
3. Have Claude write the brief as a structured file in the repo.
4. Render one image at draft quality and judge composition only.
5. Change exactly one field, re-render, and compare.
6. Lock the seed and brief, then re-render at full quality.
7. Move the working call into a script or hosted endpoint.
8. Reuse the brief file for the next batch rather than starting a new prompt.

Steps four and five are where most of the quality comes from, and they are the steps people skip. Judging composition on a cheap render before spending on a full-quality one costs a few cents and saves most of the retries.

FAQ

Can Claude generate images directly? No. Claude has no image model of its own, so it needs an external renderer reached through an MCP server, a script, or a hosted API. Anthropic’s models handle the brief and the critique; the render happens elsewhere, which is why the choice of image SDK is a separate decision from the choice of assistant.

Does Claude Code support image generation out of the box? It does not ship with it, but it is one of the easier things to add, because Claude Code can write the integration itself once you tell it which provider and which model to call.

What does a Claude image workflow cost to run? The cost is the renderer’s, not Claude’s. Drafts run in the fractions of a cent range and full-quality photoreal renders land around four cents each, so a twenty-draft, one-final cycle is usually under ten cents. FLUX Pro API pricing lists the current per-image numbers with request examples.

Which model should I use for editing an image I already have? An instruction editing model rather than a text-to-image one. You give it the source image and a change to make, and it leaves the rest of the frame alone, which is the behaviour you want for product swaps, background changes, and small corrections.

How do I keep the same character across many images? Fix a seed, keep one anchor image, and pass that anchor as a reference on every render. Prompt text alone drifts. The Nano Banana image API walkthrough shows how the reference field is passed on each request.

Should I use an MCP server or a hosted endpoint? Use an MCP server while you are still exploring and want images inside the conversation, and a hosted endpoint for anything that runs on a schedule or in volume. Plenty of teams run both, with the same brief file feeding each.

Do I need to rewrite my prompt for each model? Only the style and negative fields. If the brief is structured, the subject, setting, light, lens, and palette carry across unchanged, which is the whole reason to keep it as a file rather than a paragraph. What FLUX 1 is and how it reads prompts explains why the phrasing differs between model families.

Conclusion

The workflow is two decisions and one file. Decide the model class from the job rather than from a leaderboard, write the brief as structured fields rather than prose, and the wiring becomes interchangeable: MCP today, a script next week, a hosted endpoint when it starts shipping on a schedule. Once the brief is a file, every later image is a config change rather than a fresh act of writing, and the FLUX image generator is a reasonable place to test the first version of one.