85

This is a nice, optimistic view that I would prefer to be true. In fact, if they released a “Logout of all sessions” button alongside this new feature, or had changelogs to indicate this, I would completely agree.

Being the devil’s advocate. Let me introduce a second view:

“We need to disconnect any sessions/users that are idling on our platform to reduce overhead costs. We can simply reconnect them once they regain focus to the page”

Yup. It’s seriously concerning that not one person thought “Wait… What about people with chat history turned off?”

So. I am thinking that they are inbetween a rock, and a hard place. Because maybe this “feature” reduces a lot of cost, but they don’t know how to implement it, or don’t care enough to make any exceptions for Chat History Off users. I really doubt they aren’t aware of this issue. Pure speculation.

3 Likes
86

Wow that’s some Orwellian doublespeak lol. In who’s mind is this a “feature”? Feels like a heavy-handed tactic to push people into turning on chat history/training. I won’t compromise the security and privacy of my workplace by doing that when using GPT at work. I do allow history at home.

3 Likes
87

Really unfortunate… I submitted a feedback message a few days ago and never heard back. I’m dropping down to the free version until they either verify it’s a bug or resolve the issue. It’s unusable for my purposes as is…

2 Likes
88

It might not be a bug but rather a deliberate feature. I am currently seeking further clarification from OpenAI.

In response to the OpenAI request: “For clarity and transparency, even with the history feature disabled, there’s a brief retention period (typically up to a few minutes) to maintain the continuity and context of the conversation. Additionally, this feature also means that if you close the current conversation to start a new one, the previous conversation will be permanently closed, ensuring that your data remains private and will not be recovered.”

Also, recently, the ChatGPT Model 4 seems to be producing errors in its answers at an increased rate. There might be an issue with the model.

3 Likes
89

Wow. Looks like this is not a bug then. Up to a few minutes? That’s actually insanity.

Honestly they should just remove Chat History Off instead of acting like it’s usable with this new update. Up to few minutes? Based off of what? The last activity? Since I have had focus on the page? It can take a minute for ChatGPT to finish typing and I’m usually doing other things during that time.

Based off of this it seems like we need to have a very quick, consistent back-and-forth, or risk completely losing the chat. Or, more realistically, Chat History Off is unusable.

So basically: fill the form, or become an enterprise customer to prevent your data from being used in future training.

4 Likes
90

Or the responses you get are outsourced workers who receive some AI-selected canned answers that pop up, and pick the best match to send to you. And some supervisor at “Hyderabad Button Pushing, LLC” writes a new script that sounds like the right answer to make people stop sending messages.

4 Likes
91

I hope this is the truth.

It’d be very disappointing to know that not only was this intentional, but they made no attempt to tell us.

3 Likes
92

I feel like this is a bug. I was just using ChatGPT on the other tab, and wanted to check this thread, so I opened a new tab. It was not even a minute and I went back to ChatGPT tab. Then I saw that the chat was deleted already.

2 Likes
93

Agree with the Hyderabad Button Pushing, LLC :smiley:

94

I’ve been happily using GPT4 daily for the last 2 months with History and Training disabled, I was able to keep a single perpetual conversation open for hours (often an entire day) in this mode before I manually pull the plug and clear the chat myself

But, as of this week I have been experiencing the exact same issue that everyone else is describing here. After a few minutes, or an unfortunate Alt-tab, the thing resets.

This is an absolute deal-breaker and renders the platform completely useless for my purposes. No choice but to terminate my subscription until this is resolved :frowning:

4 Likes
96

You’re right that this “feature” is a no-go. But “no choice than to terminate my subscription” isn’t quite correct - except for protest - because the Tampermonkey script makes it as if the bug wasn’t there.

2 Likes
97

They should simply also allow chat history for people that don’t want their data to end up in models.

It is not that hard and strange in the first place that it is somehow coupled, even for paying customers.

I don’t mind paying a few dollars more for privacy and chat history btw, because I can imagine that there is some cost involved in storing the chats.

3 Likes
98

If this is about idling users, then why would they reset the the chat during the “onfocus” event if you actually want to engage?

Also, the chat itself is the entire context in principle, so if they want to start up the context again, all data is there.

3 Likes
99

They should simply also allow chat history for people that don’t want their data to end up in models.

Yes, yes and yes. Easy fix. And then we can clear the chats manually if we don’t want them in our history.

I made a post in Feature Request specifically for this and mentioning this Bug.
Please if you read this and you are having this problem go there and post in the Feature Request as well for increased visibility. The forum doesn’t allow for links unfortunately.

3 Likes
100

Please allow chat history even when opting out of contributing to training data

:grinning: :100: :clap:Thank you so much for posting this in the “Feature Request”, I’ll go there and post something as well.

2 Likes
101

I’m not sure I understand what you mean at the end “if you want to actually engage”. But let me bring a scenario:

Let’s say you, as a server host decide to maintain an active connection / session with the user for whatever reason. It’s pretty common with ReactJS websites.

Your server grows exponentially. Instead of 10,000 active users you have 1,000,000. Things become a lot more complicated. For instance, using Firebase RealTime Database there is a hard limit of 200,000 active connections per database. Which, as a result, requires database sharding.

During all of this craziness of scaling you find a tasty metric: “5% of active users have been inactive, and not even focused on your page for over 10 minutes”. Bam, easy optimization right there.

So, to answer your question. They are not “resetting the chat”, exactly. They are disconnecting the “session”. Once you return to the page you reconnect, and just as if you refreshed the page: your chat is gone.

You know, it’s always a compliment to a programmer when a user goes “but look, it’s all there, it works so simply. Surely it can’t be difficult”.

What you are seeing is probably very shallow compared to what they store for you. At the very least, the chat itself is not the entire context (token limits). There is also probably a lot of metadata, embeddings, and correlations that occur for each message.

Could they re-build the conversation? Probably. Does it make sense? No. From every technical view this is just a bad idea.

3 Likes
102

I am also going to be cancelling my Pro account until they make it functional again. Yesterday it was literally IN THE MIDDLE OF ANSWERING A QUESTION and then reloaded the page and I lost the entire thing. It was literally mid-answer.

And they’re calling this a “feature”? That’s called gaslighting my friends, and this is scary stuff imho.

Garbage!

3 Likes
103

But why does it often happen when coming back to the page (ignoring the erratic stuff @eejai42 just described)? You may think the effect when coming back to the page is only cosmetic, but the Tampermonkey scripts only block this part and the chat still works. So, there’s no already reset connection that’d break the chat when an additional cosmetic reset is prevented. You could leave the chat alone for much longer than 10 minutes, come back, and only then, the chat is reset.

3 Likes
104

I agree.

It is definitely also connected to the chrome “returning to page” signal in some cases at least, because it’s often (frustratingly) when copying/pasting code it has written into an IDE when it chooses to reload.

And then there’s also definitely a time component that seems to be both dramatically too short for a practical conversation - but also does not seem to be related to activity. Rather, it’s as though we get 3 minutes to have the conversation and every 3 minutes it restarts the conversation, almost independently of it’s current state.

Very frustrating. And disappointing in terms of them trying to frame this as a “feature”. That is next level gaslighting.

1 Like
105

Great question.

Looking at the Greasy Fork script they found that the resource fetched is:

https://chat.openai.com/backend-api/accounts/check/v4-2023-04-27

Which is pretty self-explanatory (it returns your account information)

So. It could be that a session isn’t being disconnected & reconnected. Rather, the user settings are changed and it causes all the component to render again (causing the loss of conversation, basically the same as refreshing).

But, I’m unsure of this. It could a separate session (such as CloudFlare) that expires after 10 minutes of inactivity.

For whatever reason OpenAI have purposely caused this. The only “bug” part of it is that they didn’t consider the consequences for Chat History Off users.

Why the chat functions perfectly normal if the script is blocked is beyond me. If I had to guess it is simply because the page DOESN’T need to be refreshed. For some reason OpenAI wants people to continuously poll their servers and then demands a hard refresh if the stale time limit is hit.

I really doubt OpenAI is not aware of this by now. Doing any sort of investigation is pointless and fruitless because they aren’t here, and have no communication at all.

2 Likes