Managing media generation models

Models are the “secret sauce” that drive image and video generation. This page provides a brief introduction to these models and describes how you can manage them using InvokeAI.

Types of Models

There are literally thousands of models available, each specialized for a different task. These include:

Type	Description
Text-to-Image	Given a text prompt, generate a still image.
Image-to-Image	Given a starting image and a text prompt, generate a new image.
Image Editing	Use a text prompt to modify an image or combine several images according to instructions.
Video Generation	Generate a video from a text prompt (text-to-video), a starting image (image-to-video) or another video (video-to-video). These modes can be combined in multiple ways.
Concept	Small add-on models that modify a larger image or video generation model to achieve special effects, such as adding a particular style, theme or character. The most common of these are LoRA models.
ControlNet	Models that provide spatial guidance to an image generation model while it works, helping to precisely control where elements of the image appear. A typical example is a pose model that transfers the pose of a stick figure onto a photorealistic subject.

In addition to models directly involved in image and video manipulation, InvokeAI supports several support models:

Type	Description
Image Segmenters	Identify and isolate individual objects in an image, which is often the first step in precisely editing it.
Vision Models	Describe what they “see” in an image. Used to classify, cluster and tag images, and to turn an image into a text prompt that can be reused.
Large Language Models	Generate text from text. InvokeAI uses them for prompt enhancement, which expands a simple prompt into one that achieves better results.

Local vs External Models

A model can be installed locally, in which case it executes on your own hardware (CPU and graphics card), or it can be hosted externally. In the latter case InvokeAI will send your request out to the hosted image or video generation service and return the result. To use an external model you will typically need to subscribe to the hosting service.

Locally-hosted models, also known as “open-weights” models, produce excellent quality images and videos with decent performance. They cost nothing to run beyond the initial hardware investment and the electricity it uses. However, some of the more advanced models may strain or exceed local hardware resources; some are 50-100 GB in size. In this case using an externally-hosted model may be your best choice.

Model Licensing

Note that 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. The Model Families table below summarizes each family’s license, and each model’s page has a License section with the details.

---

Model Manager

The InvokeAI Model Manager is the central location for managing both local and external models. For those just getting started with InvokeAI, it provides a series of recommended starter models that are organized into a series of bundles.

To access the model manager, go to the InvokeAI icon at the upper left of the screen, pull down its menu, and select “Model Manager.” It has two sections: a list of installed models on the left (initially empty), and a panel on the right that allows you to search and install bundles, individual starter models, and other locally-installable and external models.

If it isn’t selected already, click ”+ Add Models” to display the list of starter models and bundles.

Local Bundles

We suggest that you start by installing a bundle. You will see a series of chips across the top of the panel, each one corresponding to a different family (or “base”) of generation model. Clicking on the chip will show you all the starter models in that group. To install all the recommended models for that family, click “Install bundle.” You may also cherry-pick individual models within the bundle.

Some models are quite large and may take a while to download. During download and installation, a status bar will appear at the bottom of the right panel. Click on this bar in order to see the progress of individual models.

External Models

To add an externally-hosted model, select the “API Keys” section of the Model Manager’s right panel. This will display a list of model providers. Where prompted, enter the API key for access to the provider using your subscription. See your provider’s account page for information on how to generate these keys. Once a valid API key has been provided, the list of models hosted by that service will appear as selections in the Image Generation panel.

Gated Downloads

The API Keys section is also used to provide keys for services that require authentication to download certain models, such as those covered by restrictive licenses. If you try to install a model hosted by HuggingFace or Civitai and you get a permission denied error, you will need to enter an API key for your account on the service. You may also need to accept the license terms for the model in question on the host’s download page.

Installing Models by Hand

There is a search box at the top of the ”+ Add Models” section that has multiple uses. You can:

• Type a search term to find starter models that you can install immediately.
• Paste in the download URL of a model you wish to install from Civitai, HuggingFace, or another download site.
• Paste in the HuggingFace repository ID of a model you wish to install.
• If you’ve already downloaded the model and it is living on the InvokeAI backend filesystem, type in or cut and paste the path to the folder containing the model you wish to install.

If you type in a URL or HuggingFace repository ID, a Pull button will appear. Pressing it will initiate the download and install. If you type in a file path, the button will change to Scan. Pressing it will scan the indicated folder and list the installable models. Click the model(s) you wish to install.

Editing a Model

Once a model is installed, it will appear in the left-hand panel. The panel has controls that let you search and sort the models in various ways, including by model type and architecture.

Most models have default parameters that you can customize, for example step count, image dimensions and CFG. When you click on a model, an edit panel appears to the right where you can edit the model’s default parameters, change its name, add descriptive notes, and even choose a preview image for the model. For models that take prompt trigger terms, such as some LoRAs, you can add the terms so that they appear as shortcuts in the Image generation prompt box.

Deleting a Model

Right click on the model in the left panel and choose “Delete model”. It will be removed from the list of models InvokeAI knows about. If the model was downloaded and installed by the Model Manager, its weights will be deleted from your file system. If, on the other hand, you downloaded the model by hand and then imported it into InvokeAI, the weights will be left alone.

---

Model formats and families

Model Formats and Families explains the formats models come in, the components that make up a model, and the model families InvokeAI supports, with their licenses and links to each family’s page.

---

Advanced Topics

This section covers several model installation issues that you may encounter along the way.

HuggingFace repos that contain multiple models

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

How models are identified

InvokeAI identifies a model from the file itself, and falls back to its name only where the contents are the same:

• Standalone 16-channel VAEs. FLUX.1 and SD3 use the same VAE network with different settings. A diffusers vae/ folder is identified by its config.json, so FLUX.1-dev’s folder is filed as FLUX.1 and SD3.5’s as SD3. A single file such as sd3_vae.safetensors is identified by its name, folder or download source; if none of them names a model family, it is filed as FLUX.1. If a VAE lands under the wrong base, change Base in the model’s Edit view. A vae/ folder installed before this detection existed can be fixed with Re-identify model.
• FLUX.2 Klein 9B vs. Klein 9B Base. The two are identical in structure, so the file or repo name decides, and they ship different default step counts (4 against 28). Names that say “distilled” are read as Klein 9B even when they also contain “base”. If you installed Winnougan/Klein9b-Distilled-Base-INT8-Convrot by repo ID before this was fixed, it was filed as Klein 9B Base; remove and reinstall it.

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.
• Select the bulk action you wish to execute. These actions appear as buttons at the top of the list when one or more models are selected.
  • Delete — removes every selected model in a single confirmation step. Partial failures (e.g. permission issues) are reported per-model in the result toast.
  • Re-identify — 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.

Re-identify 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. Click the ”…” menu at the top right of the installed model list, and pick “Clean up orphaned models…”
3. If there are orphaned models, a dialogue box appears that lists them and offers to remove their database entries.

Orphaned models are automatically excluded from selection dropdowns (main model, LoRA, VAE, etc.), so you cannot accidentally pick one for generation.

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.