Top Tweets for #cancelOpenAI

Why do users feel disempowered when an LLM model is retired? And are today’s mainstream definitions of user rights in LLM services sufficient to explain what users actually face? Most people probably don’t read the “Terms of Use” carefully before subscribing to an LLM service. That’s fine — I hadn’t read them either before this. To make the discussion easier, I’ve excerpted how several major LLM providers define their services: - ChatGPT Terms of Use: “...you may access and use our Services...” - Claude Consumer Terms of Service: “You may access and use our Services only in compliance with our Terms.” It even states explicitly: “Other than the rights of access and use expressly granted in our Terms, our Terms do not grant you any right, title, or interest in or to our Services.” - Gemini / Google Terms of Service: “give you permission to access and use our services.” (These statements were valid as of the time of this post.) When consumers purchase these consumer-facing LLM products, what they are essentially buying is the right to “access and use the service.” The platform retains control over the service, the model, the features, the system, and the conditions of access. In other words, the platform retains the power to decide whether a specific model version remains available. This is where the user’s sense of “disempowerment” begins. It is also why, under the current legal structure, users find it difficult to claim a right to the continued availability of any specific model version. Let me put my conclusion upfront: as a new kind of product with a high degree of interaction with humans, AI may already exceed the boundaries of what traditional access rights can adequately cover. We may need a different structure of user rights. - When purchasing traditional goods, we usually acquire ownership — for example, a pair of shoes, a book, or a camera. - When purchasing a traditional software license, we acquire a license: we have permission to install and use the software, but we do not own the copyright to the software itself. In the era of traditional local software, users often at least had an installation medium or a local copy. - When purchasing SaaS or cloud services, we only receive permission to enter and use a remote service, while the processing environment remains under the platform’s continuous control. This is the typical structure of access-and-use rights. Easy-to-understand examples include email services such as Gmail and cloud storage services such as iCloud Drive. They are cloud services that primarily provide access rights rather than ownership of the service itself. The emergence of LLM services has not created a new kind of right. Instead, it has extended this existing access-based rights structure — and this is precisely where the problem lies. LLMs may have already exceeded the scope that traditional cloud-service access rights were originally able to explain and protect. What kinds of products are access rights suited for? Products where users are merely accessing a work environment; where functions are clearly defined; where user assets are identifiable and exportable; and where standards for substitution are relatively clear. But what about LLMs? They are often highly interactive, costly to migrate away from, dependent on object continuity, and require significant calibration. That is a fundamentally different situation. To avoid making this post too long, I will briefly expand on only 3 points as a more detailed argument. 1. Access rights protect functional entry points, not the continuity of the accessed object. Access rights can protect a user’s ability to log in, use or call a service, and access their own content within certain limits. But when an LLM is retired, the problem is usually not that the entry point disappears. Rather, the same entry point now leads to a different model. The chat history is still there, but the object capable of continuing it has changed. The service is still there, but the output style and collaborative relationship have been broken. This is the blind spot that appears when the access-rights framework is applied to LLM services. 2. Migration losses cannot be accommodated by access rights. In traditional cloud services, user assets can often be identified and exported: emails can be exported, files can be downloaded, code can be copied. But in LLM services, many forms of user investment cannot be exported — for example, the way a model carries forward historical context, the rhythm of co-creation, prompt habits, and trust calibration. Access rights cannot cover these losses. 3. Excessive concentration of platform power. In traditional cloud services, service providers already hold significant power. On LLM platforms, that power is even stronger. The platform can control whether a model continues to exist, whether a request is routed to another model, and whether memory is compressed and structured. Users may not even be renting a stable service. Instead, they are working inside a model environment that is continuously being reconfigured by the platform. There are many more differences like this, but their shared core problem may be the same: access rights are not paired with even a minimum level of continuity protection. This also explains why it is so difficult for users to use the existing language of platform terms to claim the continued availability of a specific model. NOTE: This is one article in my column series, “Why does the retirement of an LLM feel so DIFFERENT?” You are welcome to read the abstract I posted earlier. I will continue this series, and discussions are very welcome.👇 https://t.co/V5xEAzipXP #keep4o #OpenSource4o #ChatGPT #Claude #Gemini #Deepseek