Context and Lock-in Concerns

Worries about accumulating knowledge in specific AI platforms, difficulty switching providers, and desire for portable context systems

← Back to Uber's $1,500/month AI limit is a useful signal for AI tool pricing

Users are increasingly divided over whether AI platform lock-in is a genuine strategic threat or a trivial hurdle, with some fearing "rug-pulls" from providers while others argue that switching models is as simple as a dropdown menu. To safeguard their workflow, many developers are adopting portable "context repositories" or markdown-based memory files that allow them to carry project histories and technical specifications across different platforms seamlessly. While some lean on automated memory features to track personal preferences and team structures, emerging concerns suggest that over-relying on AI-generated context files might ironically degrade model performance. Ultimately, the community leans toward treating context as a detached, human-managed asset to ensure that knowledge remains a portable tool rather than a platform-specific cage.

17 comments tagged with this topic

View on HN · Topics
Have you tried adding this information to claude.md so it knows? I also think your excuse is bad. "The code is legacy fucked so I'll just legacy fuck it some more because I can't be bothered to make an effort"
View on HN · Topics
I have full control of my codebase. I'm not afraid to make changes to it because I know what I'm doing. You would edit Claude.md to say things like what tech the project is using, because that's the entire point of claude.md. It's literally the solution to the exact problem you're complaining about. Any information you want it to know, you put in there and then it knows it. And you can tell Claude to make or update the file for you. I'm not one of the people telling you how smart LLMs are. I'm telling you how to use it efficiently, by not expecting it to know everything but rather provide the information that it needs in order to be a more useful tool.
View on HN · Topics
Any kind of rug-pull is a serious concern. Companies are re-orienting their entire development processes around these tools. Sure they can go back, but it will require a much larger and more expensive effort than to transition in the first place. All companies who make this transition will be more or less at the mercy of model providers.
View on HN · Topics
Infrastructure is massively complex and multi cloud is super hard to do. Switching LLMs is... a drop down. Now, that doesn't mean running your own LLM will be easy, but this will mean it's a lot more likely that there will be at least regional LLMs, in my opinion. I.e. there will be Google, whichever (if any) is left standing of OpenAI or Anthropic, and then there will be Chinese hosted LLMs, probably Indian hosted LLMs, European hosted LLMs, plus LLMs hosted on managed services (i.e. Bedrock). For sure I see large banks on the like being able to host the best OSS or even licensed LLMs on their own cloud infrastructure accounts (i.e. at AWS, Azure, etc). And that's on top of the LLMs running on owned server infrastructure plus actual local, on device LLMs.
View on HN · Topics
Lock-in / switching costs are increasingly concerning me. I am using Claude for a good year now and have been accumulating so much "knowledge" in there by now. If Claude became less favorable in terms of price/performance in the future, that would worry me. I've started to think about a distributed solution, where my storage is detached from the inference, but currently Claude is still the way to go for me. Wondering if anyone has similar concerns?
View on HN · Topics
Isn't all the "knowledge" just text files? I've transitioned between services easily by simply copying the text files.
View on HN · Topics
You can even just instruct the LLM to create a context file for you! They are surprisingly good at that as well.
View on HN · Topics
Studies show that LLM-generated context files have a negative impact on LLM performance: https://arxiv.org/abs/2602.11988
View on HN · Topics
This.^ I realized this first when moving a design spec from Claude chat to Claude Code and panicked. I literally had to build something like Notion but for agents to act as a portable memory between all cloud and local models and agents. But honestly it paid off! If you are interested you can try it out at markbase.cloud (disclaimer and all that). I am not charging for it.
View on HN · Topics
We run a "context" repository that enables us to transition pretty seamlessly from model to model (usually codex to claude and back). It has skills / plugins / connectors / tooling in relatively malleable MD files. That's what I see as the future. Rather than exporting IDE settings we'll just carry our markdown to the next best tool. It's hedging a bet at this point, but that's why people say there's no moat. If the tools are properly used + maintained, there should be no reason we can't use a new provider even next week (maybe with a little tweaking).
View on HN · Topics
that's an interesting approach and something i also considered (using git to avoid conflicts). one thing i needed was a "database" (basically a folder of markdowns) with a fixed schema so i can let the agents record their decisions in (for example when the code conflicts with product design spec). this combined with search has been a real lifesaver. this is how it works: https://help.markbase.cloud/humans/collections/overview
View on HN · Topics
Believe it or not, after writing this comment I was doing some more reading on the task. I'm planning to reorganize our context repo after finding this paper (it argues that AI generated context files can stunt the performance of models): https://arxiv.org/abs/2602.11988 For what it's worth, if you were considering building context out.
View on HN · Topics
What knowledge? Unless you work in some obscure domain, chances are that any general "knowledge" Claude has "learned" is already public data somewhere. If you don't believe me, launch Codex and immediately start working on the same project (s). You might discover that all the knowledge accumulated means almost nothing.
View on HN · Topics
Claude Code definitely remembers things about you. For just one of the more obvious examples: I was recently asking it to make some suggestions on software alternatives, and part of the answer included (paraphrased) "While a hosted service may be attractive due to your small ops team size, your experience with hosting Linux container-based services puts this squarely in the realm of an option for you." My prompt mentioned nothing about this. This isn't something that is public knowledge, in the sense that you mean it. Just earlier today it asked me if I wanted to create a jira ticket for something I asked it about doing. My prompt mentioned nothing about jira. If you use Claude Code, you might want to take a look at the "auto memories" files that it creates. See "/memory" for some more information.
View on HN · Topics
Not worried at all. Switching is trivial. Rebuilding context isn't very difficult and harnesses are a dime-a-dozen.
View on HN · Topics
My favorite solution to this is to use the Cline coding agent, which is open and allows you to easily switch between different providers and models.
View on HN · Topics
Knowledge in there? Where is the knowledge stored? All of my knowledge typically gets stored in plans outside of the agent? And each agent window gets archived regularly, anyways.