[GH-ISSUE #20946] feat: Create a model popularity endpoint #106334

New Issue

GiteaMirror · 2026-05-18T04:38:04-05:00

GiteaMirror commented

2026-05-18 04:38:04 -05:00

Originally created by @ambrustorok on GitHub (Jan 26, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/20946

Check Existing Issues

I have searched for all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.

Verify Feature Scope

I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.

Problem Description

Currently, there is no structured way to measure or expose the popularity of custom models in OpenWebUI. While users can create custom models and admins can make them public (at least in our setup), there is no visibility into which public models are actively being used or trending.

This makes it difficult to:

Surface popular community models
Rank or recommend public models
Understand real usage patterns (including temporary chats)
Analyze model usage over time (e.g. last 7 or 30 days)

Desired Solution you'd like

Introduce a model popularity system based on usage events and expose it via two new API endpoints.

1. Popular Models Endpoint

Add an endpoint to return the top N most popular public models, with support for time-based filtering:

GET /api/v1/models/popular?limit=10&window=7d

Response should include:

Model ID and name
Base model ID
Aggregated usage metrics:
- Total chats created
- Temporary chats created
- Total messages
- Unique users
A computed popularity score
Relevant metadata (tags, description)

2. Model Popularity Tracking

Track model usage via explicit usage events:

POST /api/v1/models/{model_id}/usage

This endpoint would be called when:

A new chat is created
A temporary chat is created
A message is sent using the model

Events should include timestamps to allow time-based aggregation.

Additionally, expose per-model popularity data:

GET /api/v1/models/{model_id}/popularity?window=30d

Key Requirements

Temporary chats should contribute to popularity
Popularity must be time-based (e.g. last 24h / 7d / 30d)
Separation between public models and non-public models (filter by group maybe??)
Design should support future ranking strategies so the models page could have a "hot" section (e.g. trending, decay); although this is something that that host could do

Alternatives Considered

No response

Additional Context

No response

Originally created by @ambrustorok on GitHub (Jan 26, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/20946 ### Check Existing Issues - [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request. ### Verify Feature Scope - [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions. ### Problem Description Currently, there is no structured way to measure or expose the popularity of custom models in OpenWebUI. While users can create custom models and admins can make them public (at least in our setup), there is no visibility into which public models are actively being used or trending. This makes it difficult to: - Surface popular community models - Rank or recommend public models - Understand real usage patterns (including temporary chats) - Analyze model usage over time (e.g. last 7 or 30 days) ### Desired Solution you'd like Introduce a model popularity system based on **usage events** and expose it via two new API endpoints. ### 1. Popular Models Endpoint Add an endpoint to return the top N most popular **public models**, with support for time-based filtering: ``` GET /api/v1/models/popular?limit=10&window=7d ``` Response should include: - Model ID and name - Base model ID - Aggregated usage metrics: - Total chats created - Temporary chats created - Total messages - Unique users - A computed popularity score - Relevant metadata (tags, description) --- ### 2. Model Popularity Tracking Track model usage via explicit usage events: ``` POST /api/v1/models/{model_id}/usage ``` This endpoint would be called when: - A new chat is created - A temporary chat is created - A message is sent using the model Events should include timestamps to allow time-based aggregation. Additionally, expose per-model popularity data: ``` GET /api/v1/models/{model_id}/popularity?window=30d ``` --- ### Key Requirements - Temporary chats should contribute to popularity - Popularity must be time-based (e.g. last 24h / 7d / 30d) - Separation between public models and non-public models (filter by group maybe??) - Design should support future ranking strategies so the models page could have a "hot" section (e.g. trending, decay); although this is something that that host could do ### Alternatives Considered _No response_ ### Additional Context _No response_

GiteaMirror closed this issue

2026-05-18 04:38:04 -05:00

GiteaMirror commented

2026-05-18 04:38:05 -05:00

@Classic298 commented on GitHub (Jan 26, 2026):

Verify Feature Scope

I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.

Definitely does not fit this definition, moving to Ideas section for further (and needed) discussion with the community whether there are many more users who want this and especially how this should be implemented

@Classic298 commented on GitHub (Jan 26, 2026): > Verify Feature Scope > > I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions. Definitely does not fit this definition, moving to Ideas section for further (and needed) discussion with the community whether there are many more users who want this and especially how this should be implemented

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#106334