seedream-v4 or bytedance-seed/seedream-4: which Sume id to store

Store the canonical org/slug id, for example bytedance-seed/seedream-4, and let the legacy bare alias seedream-v4 stay only in old code. Sume's image docs say bare Image Router ids are accepted as aliases for their org/slug equivalents, so both work today. Only the canonical id appears in GET /v1/images/models, so only it diffs cleanly when a model is added or retired.

The two Seedream aliases are the ones that do not look like their canonical ids. seedream-v4 is bytedance-seed/seedream-4, and seedream-4-5-edit is bytedance-seed/seedream-4.5.

Aliases that do not match their canonical id

A normalizer for a config file or database

Run every stored id through a normalizer once, then write the result back. Unknown ids come back unchanged on purpose, so an id Sume no longer lists is caught by the catalog check, not hidden by the mapper.

ALIASES = {
    "seedream-v4": "bytedance-seed/seedream-4",
    "seedream-4-5-edit": "bytedance-seed/seedream-4.5",
    "seedream-5-lite": "bytedance-seed/seedream-5-lite",
    "flux-2-pro": "black-forest-labs/flux.2-pro",
    "flux-2-flex": "black-forest-labs/flux.2-flex",
    "higgsfield-soul": "higgsfield/soul",
    "gpt-image-2.5": "openai/gpt-image-2.5",
    "gpt-image-2.5-sunburst": "openai/gpt-image-2.5-sunburst",
    "gpt-image-2": "openai/gpt-image-2",
    "nano-banana-2": "google/nano-banana-2",
}

def canonical(model_id):
    return ALIASES.get(model_id, model_id)

if __name__ == "__main__":
    for old in ("seedream-v4", "seedream-4-5-edit", "gpt-image-1"):
        print(old, "->", canonical(old))

Why this matters for a shutdown

During a migration you diff your pinned ids against the live catalog. An alias in the config looks like a missing model. Normalize first, then compare, as in the catalog diff post. Seedream 4.5 also forces n to 1 on Sume, so a batch caller that sent n: 4 to another model needs a loop.