Misc. bug: WebUI incorrectly displays local model names

[jfslee]

Name and Version

version: 6821 (a2e0088)

Operating systems

Windows

Which llama.cpp modules do you know to be affected?

llama-server

Command line

llama-server --offline -m <some-model.gguf>

Problem description & steps to reproduce

Starting from b6821, the webUI no longer correctly shows the model used to generate a response when running a model offline from a local GGUF file. The last release that this worked correctly was b6818.

Steps to reproduce:

1. Run llama-server using a local GGUF file.
   llama-server --offline -m .\gemma-3-4b-it-Q6_K.gguf
2. Launch the webUI. In the settings page, ensure that the checkbox for 'Show model information' under the 'General' tab is checked.
3. Start a conversation.
4. Close the server and restart it using a different local GGUF file.
   llama-server --offline -m .\Qwen3-4B-Instruct-2507-Q6_K.gguf
5. Launch the webUI and either continue the previous conversation, regenerate the most recent response or start a new conversation.

Expected behavior:
The webUI should show the first message as generated by gemma-3-4b-it-Q6_K.gguf and the second message generated by Qwen3-4B-Instruct-2507-Q6_K.gguf.

However, since b6821, all responses are instead shown as being generated by whichever local model is loaded.

First Bad Commit

Seems to have been introduced by commit 9b9201f

Relevant log output

[ServeurpersoCom]

Problem description & steps to reproduce

Starting from b6821, the webUI no longer correctly shows the model used to generate a response when running a model offline from a local GGUF file. The last release that this worked correctly was b6818.

Steps to reproduce:

1. Run llama-server using a local GGUF file.
   `llama-server --offline -m .\gemma-3-4b-it-Q6_K.gguf`

2. Launch the webUI. In the settings page, ensure that the checkbox for 'Show model information' under the 'General' tab is checked.

3. Start a conversation.

4. Close the server and restart it using a different local GGUF file.
   `llama-server --offline -m .\Qwen3-4B-Instruct-2507-Q6_K.gguf`

5. Launch the webUI and either continue the previous conversation, regenerate the most recent response or start a new conversation.

Thanks for reporting! I’ll take a look at this right away.

[ServeurpersoCom]

But note that’s actually expected before I improve it :
The WebUI doesn’t poll /props, so if you restart llama-server with a different local model, you’ll need to refresh (F5) to reload the backend info.

And to close the issue : I’ll refresh /props, update its cache, and trigger the UI refresh as soon as the first chunk arrives, even in legacy mode. I had improved this before, but I didn’t reapply it during the recent small refactor.

[ServeurpersoCom]

It affects both code paths, legacy and with ModelSelector enabled, so the improvement will be useful in both cases :)
https://github.com/user-attachments/assets/8d4484aa-2c56-4324-ba1d-ceb911960c6e

[ServeurpersoCom]

I’ve improved the WebUI behavior : when switching backends, the interface now refreshes automatically on the first chunk received from the model, keeping it properly in sync without requiring a manual refresh.

We could technically add polling for the legacy mode to detect backend changes automatically, but that wouldn’t be very clean, and it’s not part of the OAI-Compat API design anyway.

EDIT : Actually, I fixed the wrong thing : the issue still remains with the conversation view, where message model info isn’t refreshed properly.

[ServeurpersoCom]

The final fix is done, now that the /props refresh is unified, the legacy mode (without the model selector) behaves correctly.
The message history now properly reflects the backend model used.

I've recorded a video that specifically targets this issue:

CmdLineSwap-RaspberryPi5.mp4

And another one to show there’s no regression when the model selector is enabled,
also demonstrating the multimodal function updates:

NonReg-FullSetup.mp4