Claude is a strong partner for writing and code, but ask it to make an image from the command line and you hit a wall. The Claude CLI has no built in image generation tool. The reflex is to open a separate image product, pay for one more subscription, and break your flow to do it. There is a better move. You almost certainly already have image generators one command away, inside tools you already run, and Claude can drive them for you. This piece shows how to turn Claude into an orchestrator that sends one image brief to two other models at once, then hands you both results to compare.
The pattern has a name worth borrowing: a council. One brief goes in. Two images come out, side by side. You keep the one that fits and discard the other. Claude never touches an image itself. It writes the brief, launches the generators, collects the files, and presents them. That is the whole idea, and it costs nothing beyond capacity you likely already pay for.
Why Claude needs a co-pilot for images
Every frontier lab made a different bet about what belongs in a command line agent. Claude leaned into reading, reasoning, editing files, and running shell commands. Image generation was not part of that surface. Meanwhile the OpenAI and Google command line tools both ship an image generation tool their agents can call directly. So the capability gap is not a quality gap. It is a packaging gap, and packaging gaps are the easiest kind to route around.
The naive fix is to pick one of the other two tools and use it directly. That works, but it throws away the most useful property of having more than one model available. Image models disagree, and they disagree in ways you cannot predict from the brief alone. One renders text on a sign cleanly while the other smears it. One nails the composition and misses the mood. One invents a sixth finger. When you can only see a single output, you have no idea whether the flaw is your brief or that model’s blind spot. When you see two, the answer is usually obvious in a second.
The council pattern
The council is three rules. First, keep the brief verbatim: both models get the exact same words so the comparison is fair. Second, run them in parallel, not one after the other, so you wait once rather than twice. Third, isolate each model’s output in its own folder so you always know which image came from which seat, even when a model picks its own filename.
Claude is the right conductor for this because the orchestration is exactly the kind of glue work it is good at. It takes your plain language brief, drops it into a small script unchanged, launches both generators at once, waits for them, finds whatever files landed on disk, and shows you the pair with a short read on which one is stronger. You make the final call. Claude does the fetching and the framing.
What you need
Three tools, all of which you may already have installed and authenticated.
| Seat | Role | What it needs |
|---|---|---|
| Claude | Orchestrator | The Claude CLI, no image tool required |
| OpenAI CLI | Image seat one | An authenticated OpenAI command line tool with its image generation tool |
| Gemini CLI | Image seat two | An authenticated Google Gemini command line tool with its image tool |
The word free deserves a caveat. Nothing here is a new bill. The council runs on generation capacity bundled into plans you probably already hold, so there is no extra image subscription to buy. Whether a given brief draws on included quota or metered usage depends on your own plan with each provider. The point is that you are reusing tools you have, not signing up for a fourth one.
The script
The council is a small shell script. It takes an output folder and a brief, launches both generators in parallel, each jailed to its own subfolder, then reports the file each one produced. This is a generic version you can drop into any project. Adjust the model names and the exact flags to match the versions of the CLIs you have, since those change over time.
#!/usr/bin/env bash
# image-council: send one brief to two image-capable CLIs in parallel
# and report the file each one produced.
set -u
# Model config: bump these as newer versions ship.
OPENAI_MODEL="gpt-5.5"
GEMINI_MODEL="gemini-3.5-flash"
OUTDIR="${1:?usage: image-council.sh <output-dir> \"<brief>\"}"
shift
BRIEF="$*"
[ -z "$BRIEF" ] && { echo "no brief given" >&2; exit 1; }
mkdir -p "$OUTDIR/openai" "$OUTDIR/gemini"
# Same words to both seats so the comparison stays fair.
TASK="Use your image generation tool to create ONE image for this brief and \
save it as a png in the current directory. Brief: ${BRIEF}"
# Launch both at once, each in its own folder.
( cd "$OUTDIR/openai" && codex exec -m "$OPENAI_MODEL" "$TASK" ) &
( cd "$OUTDIR/gemini" && gemini -m "$GEMINI_MODEL" -p "$TASK" ) &
wait
# Report whatever each seat actually wrote to disk.
for seat in openai gemini; do
img=$(find "$OUTDIR/$seat" -type f \( -iname '*.png' -o -iname '*.jpg' \) | head -1)
echo "$seat: ${img:-no image produced}"
doneTwo design choices are worth calling out. The model names live in a config block at the top, so when a newer image model ships you bump one line and never touch the logic. And each seat writes into its own subfolder, so attribution never depends on the model naming its file politely. Some CLIs render into a scratch directory rather than the working folder; if a seat looks empty, the fix is to copy the newest image out of that scratch location, which you can add as a few lines after the wait.
How Claude runs it
You do not run the script by hand. You ask Claude for an image, and it handles the mechanics. A clean flow looks like this.
You describe the image you want in plain language. Claude picks an output folder, writes your brief to a file unchanged so shell quoting never mangles it, and calls the script with a generous timeout, because two agentic image generations can take a few minutes. When the script returns, Claude reads both image files so it can actually see them, then presents the pair to you together, labeled by provider. It closes with a short comparison: which one followed the brief more faithfully, which handled any text, which has artifacts, and which it would pick and why. You decide.
Follow ups stay cheap. If you want the second image darker or the first one wider, Claude re-runs the script with the amended brief into a fresh versioned folder, so every round stays on disk and you can compare across iterations instead of overwriting your history.
Why two beats one
The council is not about doubling your odds of a usable image, though it does that. It is about turning an unknowable question into a visible one. With a single generator, every weak result forces the same guess: was that my brief or the model? You cannot tell, so you burn credits rewording a brief that was fine, or you accept a flaw that a different model would have avoided for free. Two outputs from the same words collapse that guess. If both models miss the same way, the brief needs work. If only one misses, you have your answer and your image in the same glance.
This is the same discipline that separates teams who compound with AI from teams who just spend on it. The winning move is rarely one more tool. It is getting more signal out of the tools you already have. That case runs through the whole argument for a standardized toolkit in the practical AI stack, and it is the exact question to ask before you buy anything, which is the subject of how to evaluate AI workflows before buying automation.
Making it a repeatable skill
Running a script by memory is fine once. To make the council a habit, wrap it so a single command triggers the whole flow: brief in, script launched, both images returned, comparison written. Most agent command line tools support some form of reusable command or skill for exactly this. The wrapper should keep three things stable. The brief passes through verbatim. The model names sit in one config block you can bump without reading the logic. And each run writes to its own folder so nothing clobbers a previous round.
Done once, this turns a capability Claude lacks into a capability you have on tap, at no new cost, with a built in second opinion every time.
Guardrails worth keeping
Keep briefs verbatim. The value of the council is a fair comparison. The moment you paraphrase the brief differently for each seat, you are comparing two experiments instead of two models, and the result tells you nothing.
Version every round. Write each generation to a new folder rather than overwriting. Cheap disk buys you a full history to compare against, and image work is iterative by nature.
Mind what goes into a brief. A brief is a prompt sent to two outside providers. Keep private, sensitive, or identifying material out of it, the same way you would with any external model. Describe the image, not your internal specifics.
Do not over-trust the pick. Claude’s one line recommendation is a starting read, not a verdict. You are looking at both images. Trust your eye over the summary when they disagree.
FAQ
Can Claude generate images by itself? Not from the command line. The Claude CLI has no built in image generation tool. It can, however, orchestrate other command line tools that do, which is what the council pattern relies on: Claude writes the brief and runs the generators, and the OpenAI and Gemini tools make the actual images.
Is this really free? There is no new subscription to buy. The council reuses image generation capacity that comes with tools you likely already run. Whether a specific image draws on included quota or metered usage depends on your own plan with each provider, so check your limits before running large batches.
Why use two image models instead of one? A single output leaves you guessing whether a weak result is your brief or that model’s blind spot. Two outputs from identical words make the answer visible. If both fail the same way, fix the brief. If only one fails, you already have your image.
Which models should I use? Use the current image capable models from whichever OpenAI and Google command line tools you have authenticated. Keep the exact model names in one config block at the top of the script so you can update them as new versions ship without rewriting anything.
What if one model produces nothing? Deliver the other image anyway and re-run only the seat that failed. Common causes are an expired login, a timeout on a complex brief, or a tool that rendered into a scratch directory instead of the working folder, in which case you copy the newest file out of that location.