Bring Your Own SDXL Models in Local Waifu 1.7.2

Local Waifu 1.7.2 is about making the local image side feel like it belongs to you.

Until now, the built-in image models gave you a clear starting point. That is still the right path when you want a setup that has already been tested together. But people who know exactly which SDXL checkpoint they want should not have to keep a second image app open just to use it.

This release adds a local library for your own SDXL checkpoints and LoRAs. It also fixes the kind of problems that make an image feature feel unreliable: a model setting that quietly does nothing, an import that is no longer where the app expects it, or a Photo Director image arriving after you have already selected a different companion.

The result is more freedom, with the guardrails left in place.

Your checkpoint lives in a local library

You can now import a full SDXL .safetensors checkpoint from Settings > Models > Image Models. Local Waifu copies it into a private local library, adds it to the Image Models list, and gives it its own quality-steps profile.

That copy matters. The app does not hold a fragile reference to whatever folder you originally picked. You can move the original download, clean up your Downloads folder, or keep your model collection arranged your own way. The imported model has its own managed local place to live.

Nothing in that flow uploads the model. A checkpoint can be a very personal part of an image workflow, especially when it was trained for a particular art direction. Version 1.7.2 treats it as a file on your machine, not as something that needs to be sent to a service before you can use it.

There is an important limit here: the feature is for full SDXL checkpoints. The .safetensors extension is only a container. It does not prove that a file is the right kind of model. Local Waifu checks the architecture during import and rejects checkpoints that are not SDXL instead of letting them reach a render that was never going to work.

That may sound strict. It is better than accepting every file and leaving you to discover the mismatch after waiting through a failed generation.

If you are choosing between local image approaches, our guide to offline image generation explains the wider difference between a model running on your machine and a cloud image request.

LoRAs are now tied to the model they shape

A LoRA changes the behavior of a base model without replacing it. One might influence illustration style. Another can push toward a lighting language, a character detail, or a visual mood. They are powerful because they are small compared with a full checkpoint. They are also easy to misuse when an app lets everything pile up without showing what belongs together.

In 1.7.2, LoRAs are attached to the specific SDXL model you are using. Import an SDXL LoRA, enable it for that model, and set its weight from 0 to 1.5. You can have up to three active at once.

The compatibility check is deliberate. A LoRA that cannot be verified as SDXL-compatible can still enter the library, but it cannot be switched on until the app can confirm it belongs with the selected model. That gives you room to keep your own files while avoiding a misleading “active” state for something the renderer should not use.

The Image Models screen also says plainly that LoRAs apply to SDXL models. You should not need to remember a hidden rule from a release note just to understand why a control is unavailable.

There is no promise that three LoRAs will always make an image better. Often one is enough. The useful part is being able to see what is active, set the weight deliberately, and remove a combination when it is not giving you the result you wanted.

Photo Director now protects the companion you selected

Photo Director is a different job from general image generation. It has to preserve the chosen companion’s identity, not simply make an attractive image from a prompt.

That is why the feature now uses only the tested local identity path: a ready FLUX.2 klein 4B model and the companion’s saved portrait. It does not try to stretch every imported checkpoint into an identity renderer. A model can be great for landscapes or a specific illustration style and still be the wrong tool for preserving a companion’s face.

The release also handles a frustrating race that is easy to miss until it happens. Imagine starting a Photo Director render, changing to another companion, then receiving the first result late. Before this fix, a late result could be displayed under the newly selected companion. In 1.7.2 that outdated result is discarded.

The same protection applies when you swap or replace a portrait. Local Waifu now refreshes the identity details based on the portrait content itself. Replacing a file with another image that happens to have the same size or timestamp no longer risks carrying an old appearance description forward.

That is a small detail from the outside. In practice, it is the difference between a tool that remembers which person you asked for and one that makes you double-check every generated image.

The Image Models screen says what is happening

The setting that controls an image model can fail in quiet ways. A large import may take time. A downloaded model might be damaged. A model can be active, loading, unavailable, or blocked because it is the model currently in use.

Version 1.7.2 makes those states more explicit. Imports get a progress panel. Model cards have clearer loading and retry states. Deleting the active model is disabled with an explanation instead of becoming a confusing failure. The LoRA controls are accessible, translated into every supported language, and validate the weight field rather than accepting an unusable value.

There are fixes behind those messages too. On Mac, the LoRA controls and backend previously used different argument names, which meant a toggle or weight could be silently ignored. That contract now matches. A damaged or newer local-library record no longer blocks a built-in image model from being selected. On Windows, deletion holds the right render and download locks, so an imported file cannot vanish halfway through an operation.

Your imported models also appear in Telegram through /imgmodel, using the same selection safeguards as the desktop picker. The important point is not the command name. It is that the model library is one library, rather than one list in the app and another list somewhere else.

This release keeps the built-in path intact

You do not need to import anything to benefit from 1.7.2. The built-in models remain the simplest way to start, and the app still gives clear guidance when Photo Director needs its tested local model or a saved portrait.

Custom SDXL support is there for the people who already have a preferred checkpoint and know why they want it. Everyone else can keep using the model path that is already set up for them.

That balance matters. More model choice should not mean more ways for the app to quietly make the wrong choice for you.

If you want the full release history, it is kept in the Local Waifu changelog. For the broader picture of what stays on your computer, see what running locally actually means.

FAQ

Which files can I import in Local Waifu 1.7.2?

Import full SDXL .safetensors checkpoints and SDXL LoRAs from the Image Models settings. The app checks checkpoint architecture before import, so a random .safetensors file is not treated as proof that it will run as an SDXL model.

Are imported checkpoints uploaded anywhere?

No. Local Waifu copies the import into its own local library and renders from that local copy. It does not upload the checkpoint as part of the import flow.

How many LoRAs can I use at once?

Up to three compatible SDXL LoRAs can be active for one model. Each weight is adjustable from 0 to 1.5.

Can I use a custom SDXL model with Photo Director?

No. Photo Director keeps its tested identity path: the ready FLUX.2 klein 4B model and the selected companion’s saved portrait. This is how the feature avoids attaching a late or unsupported render to the wrong companion.

Questions people ask

Back to news