One source image, three Ideogram 4.5 edits in parallel (Python)

When you want three different changes to one image, do not chain them. Send the same source URL as the first input_references entry in three separate POST /v1/images calls, run them at the same time, and compare the results. Each output differs from the original in one way, and no output carries the changes of the other two.

Chaining is right when step two needs step one (add a product, then add its shadow). Branching is right when the changes are alternatives: three headlines, three seasons, three colorways. Ideogram's launch post (read 2026-10-05) says 4.5 makes multi-turn editing possible. Branching avoids needing it.

Why separate keys

Each branch is its own paid operation. The Jobs and results docs say to reuse an Idempotency-Key only for the same operation and payload. So give each branch a key that includes its name, and reuse that key only if you retry that exact branch.

How to compare the branches

Put the three results side by side and check the same four things on each: the changed text, the parts that should be unchanged, the edges around the changed area, and the overall look against the source. The branch that changes only the text and nothing else wins.

For a more careful check, subtract the source from each result and look at where the pixels differ. A stored post on this site shows that check in Pillow; the principle is that the difference image should be bright only where you meant to change something.

Make the batch restartable

The script prints results but does not save them. In a real run, write each branch name and result URL to a file as it arrives, so a crash does not lose paid work. Because each branch has a fixed Idempotency-Key, rerunning the whole script after a crash resubmits the same operations, and Sume returns the original jobs for keys it has seen instead of billing again. The docs say to use the same key only for the same operation and payload, and the script follows that: the prompt for a branch name never changes.

If you want to add a fourth branch later, give it a new name and therefore a new key. Do not edit the prompt for an existing branch name; bump a version in the key instead (for example storefront-summer-v2).

The script

It uses a thread pool, because requests blocks. A 200 returns the URL; a 202 returns the job's status_url to poll.

import os, requests
from concurrent.futures import ThreadPoolExecutor

H = {"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"}
SRC = "https://example.com/storefront.jpg"
BRANCHES = {
    "summer": "Change the sign text to SUMMER SALE. Keep everything else identical.",
    "autumn": "Change the sign text to AUTUMN SALE. Keep everything else identical.",
    "winter": "Change the sign text to WINTER SALE. Keep everything else identical.",
}

def run(item):
    name, prompt = item
    body = {"model": "ideogram/ideogram-v4.5", "quality": "low", "prompt": prompt,
            "input_references": [{"type": "image_url", "image_url": {"url": SRC}}]}
    h = {**H, "Idempotency-Key": f"storefront-{name}-001"}
    r = requests.post("https://api.sume.com/v1/images", headers=h, json=body, timeout=60)
    r.raise_for_status()
    if r.status_code == 202:
        return name, "202 " + r.json()["data"]["status_url"]
    return name, r.json()["data"][0]["url"]

with ThreadPoolExecutor(max_workers=3) as pool:
    for name, out in pool.map(run, BRANCHES.items()):
        print(name, out)

Limits to respect

Parallel calls count against your plan's concurrency. The errors page lists 429 rate_limited and 429 queue_full: back off when you see them, and read retry-after if present. For three branches this is unlikely, but a batch of three hundred is not. Keep max_workers small, and stop the batch on 402 insufficient_credits.

Cost is three edits, billed per completed image. Draft at quality: low, then re-run the winner at a higher tier from the same source.

Parallel branches suit a decision you cannot make by reading: which wording, which season, which color. They do not suit a chain where each step needs the last result, since the branches never see each other. If your three variants share one fixed instruction and differ only in one phrase, build the prompts from a template so the shared part cannot drift. Keep the scope of this advice in view. It rests on the Sume docs and the vendor pages named in the sources, read on 2026-10-05, and on nothing measured by Sume. Where a behavior depends on your own images, such as how a model redraws a certain typeface, run a small pilot at the low quality tier and judge the result yourself before you plan a batch. Write down the prompt, the model id and the quality tier you used, so the run can be repeated. When the catalog or the docs change, re-read them; the live catalog is the contract, and a post is only a snapshot of it.