issue: Follow-up queries not generated in temporary chats #5544

New Issue

Closed

opened 2025-11-11 16:23:57 -06:00 by GiteaMirror · 5 comments

GiteaMirror commented 2025-11-11 16:23:57 -06:00

Owner

Copy Link

Originally created by @silentoplayz on GitHub (Jun 15, 2025).

Originally assigned to: @tjbck on GitHub.

Check Existing Issues

• I have searched the existing issues and discussions.
• I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.6.14

Ollama Version (if applicable)

v0.9.0

Operating System

Edition: Windows 11 Pro | Version: 24H2 | OS Build: 26100.4351 | Windows Feature Experience Pack: 1000.26100.107.0

Browser (if applicable)

LibreWolf v135.0.1-1 (Firefox)

Confirmation

• I have read and followed all instructions in README.md.
• I am using the latest version of both Open WebUI and Ollama.
• I have included the browser console logs.
• I have included the Docker container logs.
• I have provided every relevant configuration, setting, and environment variable used in my setup.
• I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
• I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
• Start with the initial platform/version/OS and dependencies used,
• Specify exact install/launch/configure commands,
• List URLs visited, user input (incl. example values/emails/passwords if needed),
• Describe all options and toggles enabled or changed,
• Include any files or environmental changes,
• Identify the expected and actual result at each stage,
• Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

When interacting with a model in a temporary chat, after the model finishes generating its response, a list of suggested follow-up queries (e.g., "Tell me more about X", "What are the implications of Y?") should appear below the response, similar to how they appear in non-temporary chats.

Actual Behavior

In temporary chats, follow-up queries are not generated or displayed after the model completes its response. This feature works correctly in non-temporary chats.

Steps to Reproduce

1. Initiate a Temporary Chat:

• Click the "New Chat" button in the top left corner.
• Select a model from the model dropdown.

2. Send a Query:

• In the chat input box, type a simple question, e.g., "What is the capital of France?".
• Press Enter or click the send button.

3. Observe Behavior:

• The model will generate the response ("The capital of France is Paris.").
• Expected: Below the response, suggested follow-up queries should appear.
• Actual: After the model's response has finished generating, wait up to 30 seconds to see that no follow-up queries are generated or displayed. The chat just ends with the model's response.
  

4. Compare with Saved Chat (Optional - to confirm feature works elsewhere):

• Click "New Chat" next to the model name dropdown, which will start a new empty chat.
• Ask another question: "What is the capital of France?".
• Observe that in this saved chat, follow-up queries are correctly generated and displayed after the response.

This issue consistently reproduces in temporary chats across different models and query types.

Logs & Screenshots

Additional Information

• The issue appears to be specific to "temporary" chats, which do not get a unique chat ID in the URL and are not saved in the sidebar).
• Follow-up query generation works as expected in "saved" chats (those initiated by clicking "New Chat" next to the model dropdown, or by selecting an existing chat from the sidebar).

Originally created by @silentoplayz on GitHub (Jun 15, 2025). Originally assigned to: @tjbck on GitHub. ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.6.14 ### Ollama Version (if applicable) v0.9.0 ### Operating System Edition: Windows 11 Pro | Version: 24H2 | OS Build: 26100.4351 | Windows Feature Experience Pack: 1000.26100.107.0 ### Browser (if applicable) LibreWolf v135.0.1-1 (Firefox) ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior When interacting with a model in a temporary chat, after the model finishes generating its response, a list of suggested follow-up queries (e.g., "Tell me more about X", "What are the implications of Y?") should appear below the response, similar to how they appear in non-temporary chats. ### Actual Behavior In temporary chats, follow-up queries are not generated or displayed after the model completes its response. This feature works correctly in non-temporary chats. ### Steps to Reproduce 1) **Initiate a Temporary Chat:** * Click the "New Chat" button in the top left corner. * Select a model from the model dropdown. 2) **Send a Query:** * In the chat input box, type a simple question, e.g., "What is the capital of France?". * Press Enter or click the send button. 3) **Observe Behavior:** * The model will generate the response ("The capital of France is Paris."). * **Expected:** Below the response, suggested follow-up queries should appear. * **Actual:** After the model's response has finished generating, wait up to 30 seconds to see that no follow-up queries are generated or displayed. The chat just ends with the model's response.  4) **Compare with Saved Chat (Optional - to confirm feature works elsewhere):** * Click "New Chat" next to the model name dropdown, which will start a new empty chat. * Ask another question: "What is the capital of France?". * Observe that in this *saved* chat, follow-up queries *are* correctly generated and displayed after the response. This issue consistently reproduces in temporary chats across different models and query types. ### Logs & Screenshots   ### Additional Information - The issue appears to be specific to "temporary" chats, which do not get a unique chat ID in the URL and are not saved in the sidebar). - Follow-up query generation works as expected in "saved" chats (those initiated by clicking "New Chat" next to the model dropdown, or by selecting an existing chat from the sidebar).

GiteaMirror added the bug label 2025-11-11 16:23:57 -06:00

GiteaMirror closed this issue 2025-11-11 16:23:57 -06:00

GiteaMirror commented 2025-11-11 16:23:59 -06:00

Author

Owner

Copy Link

@decent-engineer-decent-datascientist commented on GitHub (Jun 15, 2025):

Completely unrelated, but how did you get that extremely cool organization in your models drop down? Specifically the tags per model and the tabs?

@decent-engineer-decent-datascientist commented on GitHub (Jun 15, 2025): Completely unrelated, but how did you get that extremely cool organization in your models drop down? Specifically the tags per model and the tabs?

GiteaMirror commented 2025-11-11 16:23:59 -06:00

Author

Owner

Copy Link

@silentoplayz commented on GitHub (Jun 15, 2025):

Completely unrelated, but how did you get that extremely cool organization in your models drop down? Specifically the tags per model and the tabs?

Model tags are the secret sauce behind that clean, organized dropdown!
Tags can be added to any model directly from its edit page in Open WebUI — it’s a breeze!

YES — you can even tag custom models from the Workspace section!

Tags aren’t limited to models alone — they can also be applied to connections!
You can tag any connection added via the Add Connection or Edit Connection modal — including OpenAI API, Ollama API, and Direct Connections.

Here’s a real-world example: my GroqCloud connection.

I added the tags Free and GroqCloud to the connection itself, not each model. Why? Because doing so automatically adds the same tags to every model that connection provides access to — saving me from repetitive tagging.
From there, I can still manually add extra tags to specific models if needed — like adding a Code tag to models that handle code generation.

And here’s how to tag direct connections too:

Now, the horizontal tag bar at the top of the model dropdown?
That’s auto-generated — it appears whenever you’ve tagged models or connections in your Open WebUI instance.

This bar is super useful:
You can scroll through it to see all tags, and clicking any tag filters the dropdown in real time.

P.S: If you're wondering why I decided not to use Prefix ID for connections, it's because doing so would would treat each model provided by the connection as a new one, which would require me to manually update ALL model details again. Instead, I manually name each model inside of Open WebUI, but I will prefix the model's name with something like Groq / or Ollama /, which helps me to quickly find out if I am using a local or external model from the model dropdown. I'll admit though, this is counterintuitive when compared to how I utilize tags in Open WebUI on connections to simplify manual work to do. Also, note that if you have added tags to a connection, you will not see those tags applied to the models that the connection provides from the models edit page, but you will see those tags added to the models from the model dropdown.

@silentoplayz commented on GitHub (Jun 15, 2025): > Completely unrelated, but how did you get that extremely cool organization in your models drop down? Specifically the tags per model and the tabs? **Model tags are the secret sauce behind that clean, organized dropdown!** Tags can be added to any model directly from its edit page in Open WebUI — it’s a breeze!  **YES — you can even tag custom models from the `Workspace` section!**  **Tags aren’t limited to models alone — they can also be applied to connections!** You can tag any connection added via the `Add Connection` or `Edit Connection` modal — including `OpenAI API`, `Ollama API`, and `Direct Connections`.  **Here’s a real-world example: my GroqCloud connection.**  I added the tags `Free` and `GroqCloud` to the **connection itself**, not each model. Why? Because doing so automatically adds the same tags to every model that connection provides access to — saving me from repetitive tagging. From there, I can still manually add extra tags to specific models if needed — like adding a `Code` tag to models that handle code generation. **And here’s how to tag direct connections too:**  **Now, the horizontal tag bar at the top of the model dropdown?** That’s auto-generated — it appears whenever you’ve tagged models or connections in your Open WebUI instance. **This bar is super useful:** You can scroll through it to see all tags, and clicking any tag filters the dropdown in real time.  P.S: If you're wondering why I decided not to use `Prefix ID` for connections, it's because doing so would would treat each model provided by the connection as a new one, which would require me to manually update ALL model details again. Instead, I manually name each model inside of Open WebUI, but I will prefix the model's name with something like `Groq / ` or `Ollama /`, which helps me to quickly find out if I am using a local or external model from the model dropdown. I'll admit though, this is counterintuitive when compared to how I utilize tags in Open WebUI on connections to simplify manual work to do. Also, note that if you have added tags to a connection, you will not see those tags applied to the models that the connection provides from the models **edit page**, but you will see those tags added to the models from the **model dropdown**.

GiteaMirror commented 2025-11-11 16:23:59 -06:00

Author

Owner

Copy Link

@decent-engineer-decent-datascientist commented on GitHub (Jun 16, 2025):

Completely unrelated, but how did you get that extremely cool organization in your models drop down? Specifically the tags per model and the tabs?

Model tags are the secret sauce behind that clean, organized dropdown! Tags can be added to any model directly from its edit page in Open WebUI — it’s a breeze! YES — you can even tag custom models from the Workspace section!

Tags aren’t limited to models alone — they can also be applied to connections! You can tag any connection added via the Add Connection or Edit Connection modal — including OpenAI API, Ollama API, and Direct Connections.

Here’s a real-world example: my GroqCloud connection. I added the tags Free and GroqCloud to the connection itself, not each model. Why? Because doing so automatically adds the same tags to every model that connection provides access to — saving me from repetitive tagging. From there, I can still manually add extra tags to specific models if needed — like adding a Code tag to models that handle code generation.

And here’s how to tag direct connections too:

Now, the horizontal tag bar at the top of the model dropdown? That’s auto-generated — it appears whenever you’ve tagged models or connections in your Open WebUI instance.

This bar is super useful: You can scroll through it to see all tags, and clicking any tag filters the dropdown in real time.

P.S: If you're wondering why I decided not to use Prefix ID for connections, it's because doing so would would treat each model provided by the connection as a new one, which would require me to manually update ALL model details again. Instead, I manually name each model inside of Open WebUI, but I will prefix the model's name with something like Groq / or Ollama /, which helps me to quickly find out if I am using a local or external model from the model dropdown. I'll admit though, this is counterintuitive when compared to how I utilize tags in Open WebUI on connections to simplify manual work to do. Also, note that if you have added tags to a connection, you will not see those tags applied to the models that the connection provides from the models edit page, but you will see those tags added to the models from the model dropdown.

Thank you so much! This is so clean, can't believe I never leveraged this.

@decent-engineer-decent-datascientist commented on GitHub (Jun 16, 2025): > > Completely unrelated, but how did you get that extremely cool organization in your models drop down? Specifically the tags per model and the tabs? > > **Model tags are the secret sauce behind that clean, organized dropdown!** Tags can be added to any model directly from its edit page in Open WebUI — it’s a breeze!  **YES — you can even tag custom models from the `Workspace` section!**  > > **Tags aren’t limited to models alone — they can also be applied to connections!** You can tag any connection added via the `Add Connection` or `Edit Connection` modal — including `OpenAI API`, `Ollama API`, and `Direct Connections`.  > > **Here’s a real-world example: my GroqCloud connection.**  I added the tags `Free` and `GroqCloud` to the **connection itself**, not each model. Why? Because doing so automatically adds the same tags to every model that connection provides access to — saving me from repetitive tagging. From there, I can still manually add extra tags to specific models if needed — like adding a `Code` tag to models that handle code generation. > > **And here’s how to tag direct connections too:**  > > **Now, the horizontal tag bar at the top of the model dropdown?** That’s auto-generated — it appears whenever you’ve tagged models or connections in your Open WebUI instance. > > **This bar is super useful:** You can scroll through it to see all tags, and clicking any tag filters the dropdown in real time.  > > P.S: If you're wondering why I decided not to use `Prefix ID` for connections, it's because doing so would would treat each model provided by the connection as a new one, which would require me to manually update ALL model details again. Instead, I manually name each model inside of Open WebUI, but I will prefix the model's name with something like `Groq / ` or `Ollama /`, which helps me to quickly find out if I am using a local or external model from the model dropdown. I'll admit though, this is counterintuitive when compared to how I utilize tags in Open WebUI on connections to simplify manual work to do. Also, note that if you have added tags to a connection, you will not see those tags applied to the models that the connection provides from the models **edit page**, but you will see those tags added to the models from the **model dropdown**. Thank you so much! This is so clean, can't believe I never leveraged this.

GiteaMirror commented 2025-11-11 16:23:59 -06:00

Author

Owner

Copy Link

@tjbck commented on GitHub (Oct 2, 2025):

Addressed in dev.

@tjbck commented on GitHub (Oct 2, 2025): Addressed in dev.

GiteaMirror commented 2025-11-11 16:23:59 -06:00

Author

Owner

Copy Link

@silentoplayz commented on GitHub (Oct 2, 2025):

Addressed in dev.

Awesome! I have tested with local models, external models, and custom models and can confirm that the issue has been addressed.

Local model in temporary chat:

Custom workspace model with local model as base in temporary chat:

External model in temporary chat:

Custom workspace model with external model as base in temporary chat:

@silentoplayz commented on GitHub (Oct 2, 2025): > Addressed in dev. Awesome! I have tested with local models, external models, and custom models and can confirm that the issue has been addressed. Local model in temporary chat: <img width="2298" height="1276" alt="Image" src="https://github.com/user-attachments/assets/ec96aeac-49a4-4de8-a5b9-2611c77b4342" /> Custom workspace model with local model as base in temporary chat: <img width="2298" height="1276" alt="Image" src="https://github.com/user-attachments/assets/92b16e81-8fab-4f47-b736-28e5500891bd" /> External model in temporary chat: <img width="2298" height="1276" alt="Image" src="https://github.com/user-attachments/assets/e3de8d7f-3e88-4a1d-8896-81e2effe4f14" /> Custom workspace model with external model as base in temporary chat: <img width="2298" height="1276" alt="Image" src="https://github.com/user-attachments/assets/d750e416-7ee0-4caa-8cbc-7bd05f56c498" /> <img width="2298" height="1276" alt="Image" src="https://github.com/user-attachments/assets/942c25bb-adaa-4519-b5fa-af1face6c5a0" />

GiteaMirror referenced this issue 2025-11-11 17:58:05 -06:00

[PR #5546] [MERGED] downgrade authlib to 1.3.1 #8497

GiteaMirror referenced this issue 2026-04-19 20:32:07 -05:00

[GH-ISSUE #5544] Oauth error after upgrading from 0.3.16 to any newer version #14028

GiteaMirror referenced this issue 2026-04-20 03:39:58 -05:00

[PR #5546] [MERGED] downgrade authlib to 1.3.1 #21701

GiteaMirror referenced this issue 2026-04-25 03:55:39 -05:00

[GH-ISSUE #5544] Oauth error after upgrading from 0.3.16 to any newer version #29556

GiteaMirror referenced this issue 2026-04-25 10:51:41 -05:00

[PR #5546] [MERGED] downgrade authlib to 1.3.1 #37331

GiteaMirror referenced this issue 2026-04-29 18:56:26 -05:00

[PR #5546] [MERGED] downgrade authlib to 1.3.1 #44749

GiteaMirror referenced this issue 2026-05-05 13:47:12 -05:00

[GH-ISSUE #5544] Oauth error after upgrading from 0.3.16 to any newer version #52694

GiteaMirror referenced this issue 2026-05-06 03:27:09 -05:00

[PR #5546] [MERGED] downgrade authlib to 1.3.1 #60557

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

dev

v0.9.2

v0.9.1

v0.9.0

v0.8.12

v0.8.11

v0.8.10

v0.8.9

v0.8.8

v0.8.7

v0.8.6

v0.8.5

v0.8.4

v0.8.3

v0.8.2

v0.8.1

v0.8.0

v0.7.2

v0.7.1

v0.7.0

v0.6.43

v0.6.42

v0.6.41

v0.6.40

v0.6.39

v0.6.38

v0.6.37

v0.6.36

v0.6.35

v0.6.34

v0.6.33

v0.6.32

v0.6.31

v0.6.30

v0.6.29

v0.6.28

v0.6.27

v0.6.26

v0.6.25

v0.6.24

v0.6.23

v0.6.22

v0.6.21

v0.6.20

v0.6.19

v0.6.18

v0.6.17

v0.6.16

v0.6.15

v0.6.14

v0.6.13

v0.6.12

v0.6.11

v0.6.10

v0.6.9

v0.6.8

v0.6.7

v0.6.6

v0.6.5

v0.6.4

v0.6.3

v0.6.2

v0.6.1

v0.6.0

v0.5.20

v0.5.19

v0.5.18

v0.5.17

v0.5.16

v0.5.15

v0.5.14

v0.5.13

v0.5.12

v0.5.11

v0.5.10

v0.5.9

v0.5.8

v0.5.7

v0.5.6

v0.5.5

v0.5.4

v0.5.3

v0.5.2

v0.5.1

v0.5.0

v0.4.8

v0.4.7

v0.4.6

v0.4.5

v0.4.4

v0.4.3

v0.4.2

v0.4.1

v0.4.0

v0.3.35

v0.3.34

v0.3.33

v0.3.32

v0.3.31

v0.3.30

v0.3.29

v0.3.28

v0.3.27

v0.3.26

v0.3.25

v0.3.24

v0.3.23

v0.3.22

v0.3.21

v0.3.20

v0.3.19

v0.3.18

v0.3.17

v0.3.16

v0.3.15

v0.3.14

v0.3.13

v0.3.12

v0.3.11

v0.3.10

v0.3.9

v0.3.8

v0.3.7

v0.3.6

v0.3.5

v0.3.4

v0.3.3

v0.3.2

v0.3.1

v0.3.0

v0.2.5

v0.2.4

v0.2.3

v0.2.2

v0.2.1

v0.2.0

v0.1.125

v0.1.124

v0.1.123

v0.1.122

v0.1.121

v0.1.120

v0.1.119

v0.1.118

v0.1.117

v0.1.116

v0.1.115

v0.1.114

v0.1.113

v0.1.112

v0.1.111

v0.1.110

v0.1.109

v0.1.108

v0.1.107

v0.1.106

v0.1.105

v0.1.104

v0.1.103

v0.1.102

Labels

Clear labels

bug

confirmed

confirmed issue

core

documentation

enhancement

good first issue

help wanted

non-core

pull-request

Mirrored from GitHub Pull Request

python

question

testing wanted

No Label bug

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

GiteaMirror ninjasurge

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#5544