Disallow to change the model in existing conversation

[wtlyu]

Is it possible to change the model? I'm facing some failure cases on that
@danny-avila

[danny-avila]

Can you describe the issue more? I would like to allow model switching in existing conversation. If this creates an issue, we could have it have the same effect as clicking 'new chat'

[wtlyu]

I'm understand how you can switch model in existing conversation. The big issue is the conversationId, messageId and parentMessageId are all in different scope

[wtlyu]

How can we say the conversationId of all in one conversation? and the chatgpt will not keep memory of the previous talk

[danny-avila]

the way it currently works is it resets all of those parameters, and treats any further input from user as a new conversation, it does not continue the conversation. Even though the previous conversation is in view, the only way to go back to the 'previous' conversation state is to click on the convo again

[wtlyu]

another big issue is the messageId and parentMessageId chain is break. the behavior of standard and bing version gpt is not the same ,such as:

1. chatgpt will accept our conversationId, it's a UUID, but bing version is not, it will always generated by server, a long string. and Sydney look same as chatgpt.
2. chatgpt allow a nonsense parentMessageId to be used, but in bingai, new conversation will be created.

[wtlyu]

So literally , you are creating a totally new conversation, just combine them and show together

[danny-avila]

So literally , you are creating a totally new conversation, just combine them and show together

Yes, they are in just in view together, but they are separate conversations

[wtlyu]

I dislike this design and it make everything toooo complete to handle. I prefer to use something like a conversationGroup. which contains several conversation to render together.

[danny-avila]

A conversation group sounds more complicated to me. The view is only rendered together during the same session that the user switches the model, it's only temporary. When the user revisits a convo, only one model is ever present in the conversation. This seemed like the most simple solution to me, and I'd rather not over-engineer this functionality when they can be delegated to new convos

[wtlyu]

For now, this will break the messageTree. because messageId and parentMessageId chain are break.

And the resubmit is also confused on which model should be used. and what is the correct conversationId (maybe use the previous one?)

[danny-avila]

If that's the case, I think the simplest solution would be to just render a new message view on model switch, that would be the equivalent to clicking new chat, what do you think?

[wtlyu]

We should also review all frontend, check if the model variable is used correctly. (use convo.model or submit.model. mostly, use convo.model is the correct one.)

Another easy solution is disable the model switch within conversation. Canbe changed only in new chat view.

[wtlyu]

now changing model will create new conversation