A project → LoRAs.
If you have trained a LoRA — or found one you like — paste its identifier and bind it to a character.
Every shot that character appears in will use it.
### Identifiers, not uploads
The weights stay where they are. Hosting them would mean becoming a model host, which is a different
product with a different compliance surface. What is stored here is the identifier your provider
already understands:
- Replicate —
owner/model:versionhash - Hugging Face —
org/repo, optionally with a filename - Civitai — the numeric model version id, not the model id
- Self-hosted — whatever path your own endpoint expects
### The trigger word is the part everyone forgets
Most LoRAs do nothing unless their trigger appears in the prompt. Set it here and it is injected at
the front of every prompt that uses the LoRA — trigger words carry most of their weight from early in
the prompt, and one you typed yourself is not duplicated.
A LoRA saved without a trigger carries a permanent warning rather than being rejected. Some do not
need one; most do.
### Why "never used yet" is stated
An identifier a provider cannot resolve usually does not error. It falls back to the base model and
returns a perfectly good image that simply is not your character, with nothing anywhere to explain
it. So:
- Last accepted means a generation completed with the LoRA attached — not that the weights were
definitely loaded.
- A LoRA that has never successfully run says so.
- The last failure is recorded and shown.
The only real proof is looking at the output. The screen says that too.
### Limits
Three LoRAs on Creator, 25 on Pro, 100 on Studio, unlimited on Enterprise. At most three apply to one
shot — stacking more produces mush, and most providers reject the request in a way that reads as "the
LoRA did nothing". Any beyond three are dropped and named.