mudler/LocalAI · info

Note: Found %zu LoRAs in negative prompt (may not be support

Error message

Note: Found %zu LoRAs in negative prompt (may not be supported)\n

What it means

Informational note from the prompt setter: the negative prompt contained <lora:...> tags that were parsed and stripped. The parsed negative-prompt LoRAs are only logged, not merged into params->loras (only the positive prompt's LoRAs are applied), matching upstream behavior where LoRAs in negative prompts are typically ignored.

Source

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

    lora_vec.clear();
    lora_strings.clear();

    // Parse LoRAs from prompt
    std::string prompt_str = prompt ? prompt : "";
    std::string negative_prompt_str = negative_prompt ? negative_prompt : "";

    // Get lora_dir from ctx_params if available, otherwise use stored path
    const char* lora_dir_to_use = lora_dir_path.empty() ? nullptr : lora_dir_path.c_str();

    auto [loras, cleaned_prompt] = parse_loras_from_prompt(prompt_str, lora_dir_to_use);
    lora_vec = loras;
    cleaned_prompt_storage = cleaned_prompt;

    // Also check negative prompt for LoRAs (though this is less common)
    auto [neg_loras, cleaned_negative] = parse_loras_from_prompt(negative_prompt_str, lora_dir_to_use);
    // Merge negative prompt LoRAs (though typically not used)
    if (!neg_loras.empty()) {
        fprintf(stderr, "Note: Found %zu LoRAs in negative prompt (may not be supported)\n", neg_loras.size());
    }
    cleaned_negative_prompt_storage = cleaned_negative;

    // Set the cleaned prompts
    params->prompt = cleaned_prompt_storage.c_str();
    params->negative_prompt = cleaned_negative_prompt_storage.c_str();

    // Set LoRAs in params
    params->loras = lora_vec.empty() ? nullptr : lora_vec.data();
    params->lora_count = static_cast<uint32_t>(lora_vec.size());

    fprintf(stderr, "Set prompts with %zu LoRAs. Original prompt: %s\n", lora_vec.size(), prompt ? prompt : "(null)");
    fprintf(stderr, "Cleaned prompt: %s\n", cleaned_prompt_storage.c_str());

    // Debug: Verify LoRAs are set correctly
    if (params->loras && params->lora_count > 0) {
        fprintf(stderr, "DEBUG: LoRAs set in params structure:\n");
        for (uint32_t i = 0; i < params->lora_count; i++) {

View on GitHub (pinned to 44413a9d06)

Solutions

  1. Move needed LoRA tags into the positive prompt — negative-prompt LoRAs are not applied
  2. Or remove them from the negative prompt to silence the note and keep prompts clean
  3. If counteracting a style, lower the LoRA multiplier in the positive prompt instead

Example fix

// before
prompt: "a cat"
negative_prompt: "bad hands <lora:sketchy:0.6>"  // logged, not applied

// after
prompt: "a cat"
negative_prompt: "bad hands"
Defensive patterns

Strategy: validation

Validate before calling

// Go caller: reject LoRA tags in negative prompts explicitly
if loraTag.MatchString(req.NegativePrompt) {
    return fmt.Errorf("negative prompt cannot contain <lora:...> tags; they are not applied")
}

Prevention

When it happens

Trigger: Sending a request whose negative prompt includes LoRA tags, e.g. negative_prompt='blurry <lora:bad_hands:0.5>'; parse_loras_from_prompt runs on both prompts, and any hits in the negative side produce this note.

Common situations: Prompts imported from UIs that allow LoRAs in negative prompts; users expecting negative-prompt LoRAs to counteract styles, which this backend does not apply.

Related errors


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