mudler/LocalAI · warning

LoRA directory not set, cannot parse LoRAs from prompt\n

Error message

LoRA directory not set, cannot parse LoRAs from prompt\n

What it means

Warning from parse_loras_from_prompt(): the prompt contains <lora:...> tags but no LoRA directory was configured (lora_dir empty at load time), so the tags cannot be resolved to files. The function returns an empty LoRA list; the tags are still stripped from the cleaned prompt and generation proceeds without LoRA effects.

Source

Thrown at backend/go/stablediffusion-ggml/cpp/gosd.cpp:179

static bool is_absolute_path(const std::string& p) {
#ifdef _WIN32
    // Windows: C:/path or C:\path
    return p.size() > 1 && std::isalpha(static_cast<unsigned char>(p[0])) && p[1] == ':';
#else
    // Unix: /path
    return !p.empty() && p[0] == '/';
#endif
}

// Parse LoRAs from prompt string (e.g., "<lora:name:1.0>" or "<lora:name>")
// Returns a vector of LoRA info and the cleaned prompt with LoRA tags removed
// Matches upstream implementation more closely
static std::pair<std::vector<sd_lora_t>, std::string> parse_loras_from_prompt(const std::string& prompt, const char* lora_dir) {
    std::vector<sd_lora_t> loras;
    std::string cleaned_prompt = prompt;

    if (!lora_dir || strlen(lora_dir) == 0) {
        fprintf(stderr, "LoRA directory not set, cannot parse LoRAs from prompt\n");
        return {loras, cleaned_prompt};
    }

    // Discover LoRA files for name-based lookup
    std::map<std::string, std::string> discovered_lora_map = discover_lora_files(lora_dir);

    // Map to accumulate multipliers for the same LoRA (matches upstream)
    std::map<std::string, float> lora_map;
    std::map<std::string, float> high_noise_lora_map;

    static const std::regex re(R"(<lora:([^:>]+):([^>]+)>)");
    static const std::vector<std::string> valid_ext = {".pt", ".safetensors", ".gguf"};
    std::smatch m;

    std::string tmp = prompt;

    fprintf(stderr, "Parsing LoRAs from prompt: %s\n", prompt.c_str());

View on GitHub (pinned to 44413a9d06)

Solutions

1. Set the lora_dir option at model load to a directory containing the LoRA files
2. Or remove the <lora:...> tags from the prompt if LoRAs are not intended
3. Watch for the companion load-time warning to catch the missing lora_dir early

Example fix

// before: loaded without lora_dir
prompt = "a cat <lora:pixar:0.8>"; // tag silently ignored

// after: configure the directory at load time
loadModel("...,lora_dir=/models/loras");

// Go caller: reject LoRA tags when no directory is configured
var loraTag = regexp.MustCompile(`<lora:[^>]*>`)
if opts.LoraDir == "" && loraTag.MatchString(req.Prompt) {
    return fmt.Errorf("prompt contains <lora:...> tags but no lora_dir is configured")
}

When it happens

Trigger: Generating with a prompt like 'a cat <lora:style:0.8>' while the backend was loaded without a lora_dir option (which also triggers the load-time warning 'LoRA model directory not set').

Common situations: Prompts copy-pasted from CivitAI/shared UIs that embed <lora:...> tags, used against a backend instance configured without a LoRA directory.

Related errors

• LoRA directory does not exist or is not a directory: %s\n
• Invalid LoRA multiplier '%s', skipping\n
• WARNING: LoRA file not found: %s\n
• Invalid lora_apply_mode: %s, using default\n
• WARNING: LoRA model directory not set. LoRAs in prompts will

AI-assisted analysis of mudler/LocalAI@44413a9d06 (2026-08-15). Data as JSON: /api/errors/ca9fa736085cbbd6. Report an issue: GitHub.