Findings:

Ashley had already removed some of the models, and the old threads lost their model references. When she opens the thread, it automatically selects another available model, which has a legacy of bad UX.

There is another issue created to address that (searching for it...)

@louis-jan @imtuyethan I dont understand the issue, can you guys explain a bit more clearly?

is this an edge case where:

1. Old thread
2. Model used for that thread is deleted (along with model.json)
3. User sends more messages in old thread
4. Thread autoselects some other model
5. New model has corrupted settings? How?

Should be able to extract chat template from gguf, not good ux

@louis-jan @imtuyethan I dont understand the issue, can you guys explain a bit more clearly?

is this an edge case where:

1. Old thread
2. Model used for that thread is deleted (along with model.json)
3. User sends more messages in old thread
4. Thread autoselects some other model
5. New model has corrupted settings? How?

Hi @0xSage @tikikun. This is an outdated issue, it should link to the updated one. This is the case where the model is deleted and the app selects another available model to continue the conversation. However, that is an old behavior that we will update soon.

@imtuyethan please help link the new issue.

There are two issues related to this:

1. For this one: https://discord.com/channels/1107178041848909847/1281512188762128467/1281537450111406080, it's because I deleted model A, threads defaulted to model B & the settings were not updated, so threads used model B but settings from model A, causing the weird responses (wrong prompt template, etc.,...). This should be fixed via feat: Pick new model in thread if original model is unavailable #3385.

2. bug: Dropping GGUF metadata when creating model.yaml for Model Downloaded via URL #3558

dupe of #3385