Description
Is there an existing issue for this?
- I have searched the existing issues
Contact Details
Xiaden#6585
What should this feature add?
Add support for additional editable metadata fields in the model configuration system and surface them in the UI for both viewing and filtering.
These fields would help with attribution, version tracking, and surfacing model compatibility within the app:
class ModelConfigBase(ABC, BaseModel):
published_date: Optional[str] = Field(
default=None,
description="Date the model was published or released (freeform text)"
)
used_with: Optional[List[str]] = Field(
default_factory=list,
description="List of other models (e.g., LoRAs, VAEs) this model pairs well with"
)
attribution: Optional[str] = Field(
default="",
description="Comma-separated list of credits, creator names, links, or acknowledgments"
)
How these would work:
published_date
Used to display and sort models based on their release timeline, independent of when they were installed locally.
Stored as a string to allow for informal or incomplete date entry.
used_with
Used for:
Cross-model compatibility tracking
UI enhancements like surfacing related models at the top of dropdowns with icons
Filter/search features to group known-compatible items
Could be represented as pills or tags in the model card UI.
attribution
Displayed on the model card (bottom)
Each entry clickable (URLs open in new tab, names/emails copyable)
Long lists expandable into a scrollable panel by clicking a "... More" breadcrumb
Editable in a structured text input with comma-separation
Additionally, I'd reccomend surfacing an edit metadata button next to each selected model in the TXT to IMG and IMG to IMG tabs.
Alternatives
I currently manage this metadata manually in an Obsidian vault.
While the description field could technically hold this data, it’s already carrying load for prompt behavior notes, stylistic expectations, and config guidance. Overloading it further makes everything harder to parse—both by users and by code.
I also considered editing an existing DB datetime field, but those are immutable and expect strict formatting. A freeform string is much more user-friendly for informal workflows.
Additional Content
These metadata fields could also:
Be imported/exported as .json alongside the model file, which gives checkpoint makers a solid reason to start turning towards invoke.
Drive prompt template behavior (thinking about a template includeing used with metadata, or used with potentially pointing at a template)
Inform auto-stacking logic for compatible LoRAs or embeds
Act as filter tags in advanced search or smart folders
You can thank GPT for this request being much more readable than the last.