Custom Model Training

Custom Model Training

Ideogram lets you train a custom model on your own reference images, then generate new images that stay consistent with those references via a custom_model_uri passed to generate_image. This is the skill that closes the loop other skills in this toolkit start: brand-identity-sheet locks a brand system into one image; character-model-sheet locks a character into one multi-panel turnaround. Once that reference exists, this skill turns it (plus any other reference images) into a model that generates on-brand or on-character assets indefinitely, instead of re-describing the same look in every future prompt and hoping it stays consistent.

Always run the pipeline — create the dataset, upload the images, kick off training, poll until it's ready, and generate a proof image with the trained model — rather than stopping after train_model and telling the user to check back later. The prompt-only version of this skill would just be a description of the Ideogram API; the value is in actually running it, watching training through to completion, and coming back with a generated image that demonstrates the model works.

Before you start: read the honest facts

Read references/dataset-requirements.md before running the pipeline. It splits what's actually confirmed about these tools (from direct inspection of their schemas) from what's genuinely unknown (minimum image count, training duration, the exact "ready" status value). Don't invent numbers for the unknowns — tell the user what's confirmed and what you're finding out by trying it, per the standing rule against stating third-party API behavior as fact without a verified source.

Workflow

1. Resolve the input

Ask for (or confirm) a local folder of reference images if the user hasn't pointed to one already. This version of the skill only supports a folder of existing images — if the user wants to train on images generated earlier in this session, save those to a folder first, then proceed the same way.

If the folder is empty, missing, or the path doesn't resolve, stop and ask for a valid path. Don't create a dataset from nothing — an empty or near-empty dataset produces a model that's not meaningfully trained on anything, and there's no way to walk that back after train_model has started.

2. Create the dataset

Call mcp__ideogram__create_dataset with a descriptive name (the brand or character name plus something like "-training-set" reads well in list_datasets later). Keep the returned dataset_id — every subsequent call needs it.

3. Upload the reference images

Call mcp__ideogram__upload_dataset_assets with the dataset_id and the list of filenames. It returns one curl_command per file. Run each one sequentially via Bash — not in parallel, and not batched. The tool's own description warns that each upload URL is single-use and short-lived, so firing them concurrently (or waiting too long between generating and running one) risks a URL going stale before it's used.

If a curl_command fails, don't retry it as-is — a failed or stale single-use URL is dead. Surface the real error to the user, and if the upload genuinely needs retrying, call upload_dataset_assets again for that file to get a fresh URL.

4. Start training

Call mcp__ideogram__train_model with dataset_id and a model_name. This kicks off an asynchronous job — the call returns before training finishes, so treat its response as "training started," not "training done."

5. Poll until the model is ready

Call mcp__ideogram__get_model with the returned model identifier, on a reasonable interval (a minute or so between checks is a sane starting point — training duration isn't documented anywhere, so there's no known target to time against). Since the exact status field/enum isn't confirmed ahead of time, read whatever fields the response actually contains each time rather than assuming a specific value like "status": "ready" in advance — note what the field is actually called and what values it takes once you see them, since that's genuinely useful information to report back.

If polling goes on for an unreasonably long time, or the response settles into a state that looks like failure rather than "still training," don't keep silently polling — tell the user what you're seeing and ask whether to keep waiting.

6. Generate with the trained model

Once get_model indicates the model is ready, pull the custom_model_uri from its response and call mcp__ideogram__generate_image with custom_model_uri set, using a prompt that exercises what the model should now do consistently (e.g. the brand's wordmark on a new application, or the character in a new pose). This is the actual proof that training worked — a "training complete" status alone doesn't confirm the model generates anything useful.

7. Save what you made

Following the toolkit's "No Context Lost" habit: save the dataset name, dataset_id, model_name, custom_model_uri, the final generation prompt, and the resulting image to the project's branding folder (wherever brand-identity-sheet or character-model-sheet already save their output for this project — match that location). A custom_model_uri that only exists in the conversation is one the user has to rediscover by calling list_models later; save it now.

Reference files

• references/dataset-requirements.md — confirmed vs. unverified facts about create_dataset, upload_dataset_assets, train_model, and get_model. Read this before running the pipeline, not after something goes wrong.