Models

Checkpoint and Diffusers Models

The model checkpoint files (*.ckpt) are the Stable Diffusion “secret sauce”. They are the product of training the AI on millions of captioned images gathered from multiple sources.

Originally there was only a single Stable Diffusion weights file, which many people named model.ckpt.

Today, there are thousands of models, fine tuned to excel at specific styles, genres, or themes.

Starter Models

When you first start InvokeAI, you’ll see a popup prompting you to install some starter models from the Model Manager. Click the Starter Models tab to see the list.

You’ll find a collection of popular and high-quality models available for easy download.

Some models carry license terms that limit their use in commercial applications or on public servers. It’s your responsibility to adhere to the license terms.

Other Models

There are a few ways to install other models:

• URL or Local Path: Provide the path to a model on your computer, or a direct link to the model. Some sites require you to use an API token to download models, which you can set up in the config file. You can also paste a HuggingFace Repo ID here directly — it is detected and routed to the HuggingFace installer automatically.
• HuggingFace: Paste a HF Repo ID to install it. If there are multiple models in the repo, you’ll get a list to choose from. Repo IDs look like this: XpucT/Deliberate. There is a copy button on each repo to copy the ID.
• Scan Folder: Scan a local folder for models. You can install all of the detected models in one click.

Diffusers models in HF repo subfolders

HuggingFace repos can be structured in any way. Some model authors include multiple models within the same folder.

In this situation, you may need to provide some additional information to identify the model you want, by adding :subfolder_name to the repo ID.

Ideogram 4

Ideogram 4 is an open-weight text-to-image model with a distinctive structured JSON prompt: instead of a single sentence, the model is trained to read an overall scene description plus a list of regions, each with a bounding box and its own text. Invoke assembles this JSON for you.

Installing Ideogram 4

The weights are gated on HuggingFace under a non-commercial license. Open the model page, accept the terms, and make sure your HuggingFace token is set up in the config file before installing. Two builds are available:

• ideogram-ai/ideogram-4-nf4 — nf4 quantized, CUDA only, fits in 24 GB VRAM. Recommended for NVIDIA GPUs.
• ideogram-ai/ideogram-4-fp8 — fp8 quantized, runs on any device, with higher memory use.

Paste either repo ID into the Model Manager’s HuggingFace / URL field to install.

Prompting Ideogram 4

When an Ideogram 4 model is selected, Invoke builds the structured JSON prompt automatically:

• The positive prompt becomes the overall scene description.
• Each enabled Regional Guidance layer on the Canvas contributes one element: its drawn box becomes the region’s bounding box and its prompt becomes that region’s description. Draw a box where you want something and describe it there.
• To drive the model directly, paste a raw JSON object into the prompt box — anything starting with { is passed through unchanged.

The exact JSON that was encoded is stored in the image metadata as Structured Caption, and can be recalled straight back into the prompt box from the metadata viewer.

Generation settings

• Sampler Preset — the primary quality/speed control. Quality (48 steps), Default (20 steps), and Turbo (12 steps) each bundle a step count, a guidance schedule, and the schedule shift.
• Advanced overrides (all optional, leave on Auto to use the preset’s values): Steps, Guidance Scale, Schedule Shift (mu), and a Color Palette that biases the generated colors.

Editing model metadata

Every model has an editable Source URL field alongside its name and description. Use it to record where a model came from — for example a Civitai or HuggingFace page — independent of how it was originally installed. The URL is editable from the model’s Edit view and appears as a clickable link in the model header once set. Models without a URL simply hide the field.

This is purely metadata: the URL has no effect on loading and is not used to refresh or reinstall the model. It is mainly useful for going back to the model’s documentation, license, or example prompts later.

Bulk actions in the Model Manager

The Model Manager supports multi-selection for batch operations.

• Select multiple models by clicking with Ctrl (Windows / Linux) or Cmd (macOS) held, or by using the checkboxes on each row. A sticky header at the top shows the current selection count and is always visible while you scroll.

• Open the Actions dropdown for the selection. The available actions are:

• Delete Models — removes every selected model in a single confirmation step. Partial failures (e.g. permission issues) are reported per-model in the result toast.

  • Reidentify Models — re-probes every selected model, updating fields that depend on the file contents (type, base, format, variant, etc.). This is the bulk version of the per-model reidentify action.

Both actions handle partial failures: if some models succeed and others fail, the toast lists succeeded and failed counts and the list view updates immediately for the ones that worked.

Finding orphaned models

If a model file is deleted or moved outside the Model Manager, its database entry sticks around. To find these orphaned entries:

1. Open the Model Manager.
2. Open the type filter dropdown and pick Missing Files.
3. The list now shows only models whose files are no longer present on disk. Each one also displays a Missing Files badge in its row.

Orphaned models are automatically excluded from selection dropdowns (main model, LoRA, VAE, etc.), so you cannot accidentally pick one for generation. Use the bulk delete action to clean them out in one step.

Synchronizing orphaned model directories

The Missing Files filter finds database records whose files are gone. InvokeAI also has a separate sync workflow for the opposite situation: model directories that still exist on disk but are not referenced in the database.

This can happen after a failed import, a manual database edit, or deleting a model record while leaving files behind. The sync workflow scans the models directory for top-level folders containing model files with common model extensions, including .safetensors, .ckpt, .pt, .pth, .bin, .onnx, and .gguf.

To review these directories:

1. In multi-user mode, sign in as an administrator. In single-user mode, the Model Manager controls are available by default.
2. Open the Model Manager.
3. Click Sync Models to scan for orphaned model directories.
4. Review each reported relative directory path, contained model files, and total size before deleting anything.

Only administrators can use this workflow in multi-user mode. The underlying API is /api/v2/models/sync/orphaned; API results also include the absolute path for each reported directory.

Exporting and Importing Model Settings

Each installed model has an Export Settings and Import Settings action in the Model Manager. Use these to back up a model’s configuration, move it to another install, or share a curated setup with someone else.

What gets exported

The exported .json file captures the configuration you have set on the model, not the model weights themselves:

• default_settings — steps, CFG / guidance, scheduler, dimensions, FP8 storage toggle, VAE precision, etc.
• trigger_phrases — for LoRAs and similar.
• cpu_only — for encoder-type models.
• name, description, source_url — the model’s identifying metadata.
• cover_image — the model’s thumbnail, embedded as a base64 data URL.

Fields you have not set are omitted from the file. The format is forward and backward compatible: older clients ignore newer fields, and a file produced by a newer version still imports cleanly into an older one (it just skips the fields it does not understand).

Importing

Importing applies the JSON to the currently selected model:

• default_settings, trigger_phrases, cpu_only, name, description, and source_url are applied via the normal model update path. Any field that the target model type does not support (e.g. cpu_only on a model that has no such setting) is listed in a “skipped” toast — everything else still applies.
• cover_image is uploaded and set as the model’s thumbnail.

Imports are validated before they run. The file is rejected if source_url is not an http(s):// URL or if cover_image is not a valid image data URL — so a malformed or hand-edited file cannot quietly poison a model’s configuration.

Typical workflows

• Back up a model you’ve spent time tuning so you can restore its settings after a reinstall, or roll back after experimenting.
• Copy settings between two installs of the same model — e.g. between a desktop and a workstation.
• Share a curated setup (name, description, thumbnail, default steps / CFG / scheduler, trigger phrases) for a model you have configured well.