alt Hacker News> Not because I can't see a use-case for them, but because I have 0 trust in them
> […]
> Put another way, LLM companies are trying to climb the ladder to be a platform, I have zero interest in that, I was a "dumb pipe", I want a commodity, I want a provider, not a platform.
That is my sentiment precisely, and a big reason why I’ve started moving away from Claude Code in the past few weeks when I realised how much of my workflow was becoming tied to their specific tools.
Claude Code’s "Memory" feature was the tipping point for me, with the model committing feedbacks and learnings to some local, provider-specific path, that won’t persist in the git repo itself.
That’s fine for user preferences, not for workflows, rules, etc.
And the latest ToS changes about not being allowed to even use another CLI made up my mind. At work we were experimenting with an autonomous debug agent using the Claude Code cli programmatically in ephemeral VMs. Now it just returns an error saying we can’t use subscriptions with third-party software… when there is no third-party software involved?
Anyway, so long Claude.
Replies
Think another way, these product features are easy to build in other harnesses too. And as the open source models and the other models which are much lower cost are getting better, there will be a time when it will be justified to have a harness that can work with many models and optimize your cost and efficiency.
> Claude Code’s "Memory" feature was the tipping point for me, with the model committing feedbacks and learnings to some local, provider-specific path, that won’t persist in the git repo itself.
It's a bit annoying, but as long as it's local and human (or LLM) readable, you can use your favourite agent to rework this stuff for itself.
I use opencode with claude models through a GitHub subscription. I've also used claude through Amazon Bedrock.
Both give you optionality because they support N models.
They can’t allow third party software because the third parties save the outputs of Claude responses and distill them into new models to compete with Claude.
> Claude Code’s "Memory" feature was the tipping point for me
My standing orders are the default MEMORY.md must be a stub directing Claude to another MEMORY.md file in the local folder, project, etc.
All memories remain with their respective projects over syncs, moves, devices, etc. The stub must state all this clearly, and nothing else.
This has worked very well.
If you give the model/memory a name, that name can be persistent and independent over "backend" model swaps.