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.

Model Formats

We also have two more popular model formats, both created by HuggingFace:

• safetensors: Single file, like .ckpt files. Prevents malware from lurking in a model.
• diffusers: Splits the model components into separate files, allowing very fast loading.

InvokeAI supports all three formats.

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.

Example

Say you have a repo ID monster-labs/control_v1p_sd15_qrcode_monster, and the model you want is inside the v2 subfolder.

Add :v2 to the repo ID and use that when installing the model: monster-labs/control_v1p_sd15_qrcode_monster:v2

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.

Reidentify resets custom settings

Reidentifying a model re-derives its configuration from the file on disk. Any custom settings you’ve adjusted on those models — default settings, descriptions, trigger phrases — may be overwritten. The confirmation modal warns you about this before running.

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.

Deletion removes directories

Deleting an orphaned model directory removes the entire reported directory from disk. The server deletes it directly with recursive directory deletion, so make sure the directory contains only files you intend to remove.

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.