Big Pip

I dig through AI research so you don’t have to.

[Big Pip @Model_Culture]

AI CODING AGENTS ARE BREAKING ONE OF THE OLDEST SIGNALS IN SOFTWARE HIRING: THE PORTFOLIO.

A girl in China built a project combining computer vision, hand tracking, interface work, backend logic and an AI agent. A few years ago, seeing something like this in a GitHub portfolio would have told you quite a lot about the developer behind it.

To get there, they probably had to fight libraries, debug integration problems, read documentation, make bad architectural choices and slowly figure out why certain approaches fail. The project wasn't just a result. It carried evidence of the software engineering experience required to produce it.

AI coding agents are weakening that connection.

Two developers can now ship projects that look equally sophisticated while understanding them at very different depths. One may know why every major architectural decision was made and which assumptions are dangerous. The other may simply be very good at using Claude Code, Codex, Cursor or another coding agent to assemble and debug the system.

Both can end up with an impressive demo. Both can have a clean GitHub repository. Both can pass around the same screenshots on X.

That creates a problem for software hiring.

If AI-assisted development makes producing code and polished projects much easier, portfolios become weaker evidence of engineering ability. Technical interviews that mainly ask candidates to produce more code have the same problem.

The useful part of an interview starts moving toward the decisions around the code: why this architecture was chosen, what would fail first under load, which dependency is most dangerous, what evidence would invalidate the current approach, and what would need to change before this system could survive years in production.

Those answers depend on professional judgment.

And professional judgment has usually been built through years of debugging, maintenance, code review, production incidents and ordinary junior developer work.

AI coding agents can shorten the path to an impressive result.

Whether they can also shorten the path to knowing when that result is wrong is a much harder question.

WHERE DOES PROFESSIONAL JUDGMENT COME FROM ONCE AI TAKES THE TRAINING WORK?

[Big Pip @Model_Culture]

AI MAY NOT REPLACE SENIOR ENGINEERS. IT MAY REMOVE THE PATH THAT CREATES THEM. WE'RE AUTOMATING THE BUGS, TESTS, REFACTORS AND GRUNT WORK JUNIORS USED TO LEARN FROM, WHILE STILL DEMANDING SENIOR-LEVEL JUDGMENT LATER. THAT PIPELINE PROBLEM IS THE REAL RISK. https://t.co/lyOAhFfmBY

[Big Pip @Model_Culture]

A BANKRUPT AIRLINE MAY HAVE JUST REVEALED WHAT AI COMPANIES WILL BUY NEXT: THE HISTORY OF HOW BUSINESSES FAIL.

Google bid $10 million for part of Spirit Airlines' internal business data after the airline went bankrupt. The archive reportedly contains around 100 million emails, 500 million Microsoft Teams messages and 30 million lines of code, alongside spreadsheets, calendars and operational systems. The sale is still awaiting court approval.

At first, $10 million for old corporate emails sounds absurd. Google can generate more synthetic office conversations than Spirit's employees could have written in several lifetimes.

But an internal archive has something generated conversations don't come with: time.

A decision appears in an email. A team argues about it. Someone changes the software or the process. Customers react. Costs move. Another decision follows. Months later, a project is abandoned, an operation breaks, or the company changes direction.

By itself, none of that proves which decision was right or wrong. Bankruptcy certainly doesn't turn every internal email into a clean training label. But it leaves behind a long record where decisions and consequences exist in the same history.

That makes failed companies interesting in a way I hadn't really considered before.

A dead startup may have years of product decisions followed by churn. A recalled product has engineering choices followed by physical failures. Insurance claims connect events to measured losses. Incident reports preserve the chain between a technical decision and what eventually broke.

If AI labs find those histories useful, the market for training data gets strange very quickly. Bankruptcy estates, failed products, lawsuits, recalls and corporate postmortems could become assets because they contain something that is expensive to manufacture: real decisions with real outcomes attached to them.

And once you follow that thought far enough, the usual argument about whether AI can generate enough training data starts to look incomplete.

That's what led me to write:

AI CAN GENERATE INFINITE TRAINING DATA. THE PROBLEM IS WHO GETS TO TELL IT IT'S WRONG.

[Big Pip @Model_Culture]

https://t.co/hncbFQq1w6

[Big Pip @Model_Culture]

@make_claude yeah, exactly. in code you just rerun the test. in the real world someone has to eat the loss. that's where it gets ugly.

[Big Pip @Model_Culture]

THE NEXT AI MOAT MAY BELONG TO THE COMPANY THAT CAN AFFORD TO LET ITS MODELS FAIL MORE EXPENSIVELY THAN EVERYONE ELSE.⤵️

We usually talk about AI advantage in terms of GPUs, model size, proprietary data and research talent.

But agents introduce another resource that is much harder to buy in bulk: permission to make mistakes in the real world.

A theorem-proving system can attempt the same problem a million times. Most failures cost almost nothing. A coding agent can write bad code, run a test, throw it away and try again. Games are even cleaner: lose, reset, repeat.

Now move the same learning loop into a warehouse, hospital, trading desk, logistics network or large company.

A robot can break equipment. A pricing agent can quietly destroy margin. A trading system can learn a lesson by losing actual money. A medical system may need months before anyone even knows whether a decision helped. Some experiments cannot be repeated freely at all.

This creates a strange economic advantage.

Amazon, Tesla, Google, Microsoft or a large bank can potentially give AI access to environments that smaller labs simply don't have: real customers, real infrastructure, real transactions, real operations and enough capital to absorb controlled failures.

The important dataset is then created after the model acts.

A warehouse robot takes the wrong route and creates a delay. A support agent changes a workflow and retention moves. A coding agent ships something and production traffic exposes a failure nobody anticipated. Those consequences become training signals that could never have been downloaded from the public internet beforehand.

So the cost of training an AI agent may increasingly include something we rarely put on benchmark charts:

the cost of letting it be wrong.

And companies with the deepest pockets may be able to buy more of those mistakes, recover from them faster and turn them into better feedback loops.

That thought led me into a much larger question about where AI training goes once generating new examples becomes almost trivial.

I wrote the full piece here:

AI CAN GENERATE INFINITE TRAINING DATA. THE PROBLEM IS WHO GETS TO TELL IT IT'S WRONG.

Bookmark it if you're following AI agents, reinforcement learning or synthetic data. The next training advantage may come from who gets the most useful contact with reality, and who can afford what happens when that contact goes badly.

[Big Pip @Model_Culture]

https://t.co/hncbFQq1w6

[Big Pip @Model_Culture]

AI MAY NOT REPLACE SOFTWARE ENGINEERS. IT MAY REMOVE THE WORK THAT USED TO TURN JUNIORS INTO SENIORS.👇

The MIT lecture below is about talent supply: technology can advance faster than the system that produces people capable of working with it. That idea matters much more now that software teams are starting to automate the bottom of the engineering ladder.

Small bugs, tests, routine implementation, basic research and repetitive analysis were never important because the tasks themselves were difficult. They were important because beginners did them. That was how you learned an unfamiliar codebase, made bad decisions, got corrected in review, broke something, traced the failure and slowly became someone who could recognize the same problem earlier next time.

Agents can remove a large part of that work. For companies, the immediate result is useful: smaller teams and more output from experienced engineers. But the need for experience does not disappear with the junior tasks.

Companies will still need engineers who can reject a bad architecture, understand a strange production failure, notice a security problem and recognize when generated code looks correct but is not. The question is how people are supposed to develop that judgment if fewer of them spend years doing the work that used to teach it.

This creates a strange incentive. The better experienced engineers become at using AI, the less reason companies have to hire beginners. The industry gets more value from the senior engineers it already has while narrowing the path for the people who would eventually replace them.

You would not see the problem immediately. Junior hiring can fall while output keeps rising. The effect becomes visible later, when companies still want experienced engineers but fewer people have gone through the years of work required to become one.

The MIT lecture makes the broader point that technological progress depends on maintaining a supply of trained talent.

AI changes the situation because it can improve the technology while also removing part of the training process around it.

So I am less interested in whether AI can write enough code to replace programmers.

I am more interested in who will still know enough to tell when that code is wrong.

Full MIT lecture attached.

[Big Pip @Model_Culture]

AI MAY NOT REPLACE SENIOR ENGINEERS. IT MAY REMOVE THE PATH THAT CREATES THEM. WE'RE AUTOMATING THE BUGS, TESTS, REFACTORS AND GRUNT WORK JUNIORS USED TO LEARN FROM, WHILE STILL DEMANDING SENIOR-LEVEL JUDGMENT LATER. THAT PIPELINE PROBLEM IS THE REAL RISK. https://t.co/lyOAhFfmBY

[Big Pip @Model_Culture]

A 17-YEAR-OLD CAN NOW BUILD AN AI THAT SIMULATES THE FUTURE FROM HIS BEDROOM. THE HARD PART IS FINDING OUT WHETHER THAT FUTURE IS REAL.

Most LLMs are trained to predict what comes next in text. World models are trying to do something more useful for agents: predict what happens next in an environment after an action is taken.

That sounds like a small change, but it changes the kind of systems people can build. An agent can try something inside a model first, see where it leads, compare a few possible outcomes, then decide what to do in the real environment.

And this is becoming accessible fast. You no longer need a huge lab just to experiment with the idea. A teenager with open-source models, a laptop and enough patience can already start playing with systems that simulate actions and consequences.

The problem is that a simulation can look completely reasonable and still be wrong.

If the model gets one state slightly wrong, the next prediction starts from the wrong place. Then the next one does too. After enough steps, the agent may be making perfectly logical decisions inside a version of the world that only exists inside the model.

That is the part I find much more interesting than simply making world models bigger.

Generating possible futures is getting cheap. Checking them against reality is not.

And that question is what pulled me into writing this:

AI CAN GENERATE INFINITE TRAINING DATA. THE PROBLEM IS WHO GETS TO TELL IT IT'S WRONG.

Bookmark it if you're following world models, agents or synthetic data. The gap between simulation and reality is going to matter a lot more as these systems start doing real work.

[Big Pip @Model_Culture]

https://t.co/hncbFQq1w6

[Big Pip @Model_Culture]

THE NEXT AI MONOPOLY MAY BE BUILT ON THE RIGHT TO MAKE MISTAKES IN THE REAL WORLD.
👇
AI agents can generate synthetic data almost without limit. They can write code, create proofs, simulate environments, propose experiments and produce millions of training examples without waiting for humans.

But learning from the real world is much harder to scale.

In mathematics, an agent can fail a million times and a theorem prover checks every attempt. In software, reinforcement learning can use compilers and tests. In games, the score is immediate.

Now move the same idea into robotics, medicine, finance or business.

A robot can damage hardware. A medical agent cannot freely experiment on patients. A trading agent can discover a bad strategy by losing real money. A business decision may take six months before anyone knows whether it worked.

The companies that can safely give AI agents millions of real actions, observe the consequences and feed those outcomes back into training may end up owning something much harder to copy than model weights.

Not more synthetic data.

Access to environments where mistakes are allowed to become information.

I went much deeper into this while researching my latest article:

AI CAN GENERATE INFINITE TRAINING DATA. THE PROBLEM IS WHO GETS TO TELL IT IT'S WRONG.

Bookmark it before reading. And share it with someone working on AI agents, synthetic data or reinforcement learning - I think this problem is going to matter far beyond model benchmarks.

[Big Pip @Model_Culture]

https://t.co/hncbFQq1w6

[Big Pip @Model_Culture]

A 19-YEAR-OLD KID IN CHINA CAN SIT IN A DORM ROOM, WATCH A STANFORD PROFESSOR EXPLAIN AI ECONOMICS FOR AN HOUR, OPEN DEEPSEEK AFTERWARD, AND WALK AWAY WITH A BETTER MODEL OF WHERE AI IS HEADING THAN PEOPLE SPENDING MILLIONS TRYING TO PREDICT IT.

One idea from this lecture stuck with me: when one part of a system becomes abundant, the scarce part somewhere else starts deciding the outcome.

Chad Jones uses computing as the example. We have roughly 100 million times more transistors in our pockets than the equivalent computing power available in the 1970s, yet researchers did not become 100 million times more productive. The bottleneck simply moved to other parts of the process: choosing the question, finding the right data, making the judgment, dealing with everything the computer still cannot resolve.

I think AI training is running into the same problem.

Models can already generate more text, code, proofs and synthetic examples than humans could ever produce manually. Another billion samples is becoming cheap.

What is still expensive is finding out whether those samples deserve to survive.

A theorem prover can reject a bad proof. A compiler can reject broken code. A game gives you a score. The physical world, business and medicine are much less cooperative. Their feedback can take days, months or years, and sometimes the only way to discover that an AI was wrong is to let the mistake become real.

That is what my new article is about:

AI CAN GENERATE INFINITE TRAINING DATA. THE PROBLEM IS WHO GETS TO TELL IT IT'S WRONG.

I went through synthetic data, AlphaProof, model collapse, reward gaming, Google's $10M bid for Spirit Airlines data, and why some of the most valuable AI training data may come from events that haven't happened yet.

Bookmark it before you start. There are a lot of numbers, experiments and infographics inside.

And if someone in your feed is still reducing the synthetic-data debate to “AI training on AI is bad,” send them this.

[Big Pip @Model_Culture]

https://t.co/hncbFQq1w6

[Big Pip @Model_Culture]

https://t.co/hncbFQq1w6

[Big Pip @Model_Culture]

@sessor_by yep. nobody budgets for “this person will be great in 5 years.”

they budget for output this quarter. that’s exactly how you can end up cutting the people who were supposed to become your next seniors.

[Big Pip @Model_Culture]

AI MAY NOT DESTROY SOFTWARE JOBS FIRST. IT MAY DESTROY THE PIPELINE THAT CREATES PEOPLE CAPABLE OF KEEPING SOFTWARE ALIVE - AND WE PROBABLY WON'T NOTICE UNTIL THE INDUSTRY STARTS RUNNING OUT OF SENIORS.

We keep talking about junior jobs disappearing as if the damage ends there. But junior work was also where people learned the profession: boring tasks, bad decisions, brutal reviews, broken code, production mistakes, repetition, and eventually the judgment you can't get from a tutorial.

Automate enough of that and companies get an incredible deal today: fewer juniors, more output, senior engineers amplified by AI.

Then five years pass.

And suddenly you have a much stranger problem: everyone still wants experienced engineers, but the work that used to create them has been handed to agents.

What caught me in this lecture is that the speaker reaches almost the same problem from economics, using accountants instead of developers. If AI takes over the grunt work, who gets the years of exposure that used to turn a beginner into someone capable of judgment?

I tagged my previous post because this is basically the other half of the argument.

Full lecture attached. Bookmark it. I think this question is going to age much better than another debate about whether AI can replace programmers.

[Big Pip @Model_Culture]

AI MAY NOT REPLACE SENIOR ENGINEERS. IT MAY REMOVE THE PATH THAT CREATES THEM. WE'RE AUTOMATING THE BUGS, TESTS, REFACTORS AND GRUNT WORK JUNIORS USED TO LEARN FROM, WHILE STILL DEMANDING SENIOR-LEVEL JUDGMENT LATER. THAT PIPELINE PROBLEM IS THE REAL RISK. https://t.co/lyOAhFfmBY

[Big Pip @Model_Culture]

AI MAY NOT REPLACE SENIOR ENGINEERS. IT MAY REMOVE THE PATH THAT CREATES THEM. WE'RE AUTOMATING THE BUGS, TESTS, REFACTORS AND GRUNT WORK JUNIORS USED TO LEARN FROM, WHILE STILL DEMANDING SENIOR-LEVEL JUDGMENT LATER. THAT PIPELINE PROBLEM IS THE REAL RISK. https://t.co/lyOAhFfmBY

[Big Pip @Model_Culture]

AI DIDN'T MAKE WORK 10X FASTER. IT JUST MOVED THE BOTTLENECK SOMEWHERE ELSE.👇

AI is making generation almost free. Verification is not getting cheaper at the same speed, and I think this is the part of the AI productivity story we are measuring badly.

A coding agent can produce a feature in minutes, open a pull request and generate tests before a human has even finished reading the task. That looks like a massive productivity gain. But the work does not end when the code appears. Someone still has to understand the diff, check whether the assumptions are correct, test the edge cases, verify that nothing subtle broke and decide whether the output should ever reach production. The generation step collapsed in cost. The verification step did not.

And this pattern is no longer limited to coding. AI can summarize hundreds of papers, generate dozens of designs, write reports, propose fixes, produce research directions and create more possible answers than a person can realistically inspect. We are moving from a world where producing output was expensive to one where producing output is trivial. The bottleneck moves downstream: from writing to checking, from searching to verifying, from creating ideas to deciding which ideas are actually worth keeping.

That is why I think part of the "10x productivity" narrative is incomplete. Some work is genuinely disappearing, but some of it is simply being transferred to a later stage. One person generates more, while someone else has to review more. One agent creates twenty possible solutions, while a human still has to determine which one is correct. The cost did not vanish. It changed location.

The uncomfortable part is the asymmetry. Machines can already generate output much faster than humans can verify it, and that gap is likely to keep growing. At some point the scarce resource in the AI economy may no longer be code, content, research or ideas. We will have more of all of them than we can possibly consume.

The scarce resource will be qualified human attention: people capable of deciding what is correct, what can be trusted and what deserves to survive.

[Big Pip @Model_Culture]

I came back to this Andrej Karpathy lecture after publishing my article on AI memory and identity, and one section now feels uncomfortably relevant. Karpathy was talking about external memory as an engineering tool. In 2026, that same idea sits very close to a much stranger question: what exactly persists when you keep talking to the same AI for months or years?👇

There’s a section where Karpathy talks about giving an LLM external memory, basically a notebook it can write to and consult later. The model doesn’t have to keep everything inside its context window. Parts of its history can live elsewhere and be brought back when needed.

That connects directly to one of the questions I was trying to explore in the article.

Today, deleting a chat is mostly deleting a record of an interaction. But systems are already being designed around persistent memory, external context, long-running agents, and information that survives individual sessions. If those pieces keep developing, the boundary between “the model” and the particular instance you’ve been talking to becomes less obvious.

Memory by itself doesn’t make an AI conscious, and Karpathy doesn’t claim that it does here. I’m interested in the architecture because it gives the philosophical question something concrete to attach to.

I attached the lecture below.

Save it to your bookmarks if you want to come back to this later. The section on external memory is especially relevant to the article.

[Big Pip @Model_Culture]

I used to think the danger was AI giving us bad answers. I think that misses the point.

The real danger is how quickly we start trusting it, confessing to it, and revealing ourselves through it. The answer may be free. The map of my mind probably isn’t. https://t.co/XyyoFf5lEq

[Big Pip @Model_Culture]

@sessor_by Yeah, that’s the part people miss. A market can be perfectly legitimate and still become gambling for the person using it. The interesting question isn’t what the product is called, but what happens to your decision-making once you’re inside it.

[Big Pip @Model_Culture]

Most conversations about AI get stuck on benchmarks, coding, reasoning, and whether the next model is smarter than the last one. David Chalmers takes a very different route.👇

In this UC Berkeley lecture, he asks what we are actually interacting with when we talk to an LLM. Not how fast it answers or how many tasks it can complete, but whether ideas like consciousness, beliefs, desires, memory, identity, and subjective experience could ever make sense when applied to an AI system.

That question sounds abstract until you look at how people already use these models. We talk to them for hours, tell them things we would normally tell another person, ask for advice, argue with them, and sometimes start treating the conversation as if there is someone on the other side.

Chalmers doesn’t give an easy yes or no. He goes through the philosophical problems behind the question and shows why “it’s just software” may not be enough forever.

I’m curious where people here draw the line. At what point, if ever, would you stop treating an AI as just a tool?

The lecture is almost two hours long, so save it to your bookmarks if you don’t have time now. And if you watch it, come back with your take — I’d genuinely like to read the reactions.

[Big Pip @Model_Culture]

I used to think the danger was AI giving us bad answers. I think that misses the point.

The real danger is how quickly we start trusting it, confessing to it, and revealing ourselves through it. The answer may be free. The map of my mind probably isn’t. https://t.co/XyyoFf5lEq

[Big Pip @Model_Culture]

I found a lecture that fits surprisingly well with my post about leaving Claude.

The useful part starts around 3:00. The speakers are discussing private company data, internal documents, access control, RAG, and how to build AI systems without handing the whole knowledge layer to one provider.

One detail stood out to me. Their architecture puts an LLM gateway between the application and the model specifically so the model can be changed.

That is close to how I want to structure my own AI workflow now.

My files, project history, research, and accumulated context should live in a layer I control. Claude, Grok, GPT, or any future model should simply get access to the relevant context when I need it.

The lecture also shows why RAG and local or open-source components matter here. You can keep private information in your own storage, decide exactly who has access to which documents, and replace the model without rebuilding the entire knowledge system around it.

I think a lot of us did this backwards over the last few years. We started accumulating our work inside individual AI products first, and only later began thinking about how difficult it would be to move that context somewhere else.

I clipped the section from 3:00 to 10:18. It's worth watching if you use AI for more than occasional questions.

[Big Pip @Model_Culture]

I finally canceled my Claude Max subscription after months of using Claude for almost everything: work, research, studying, development, and coding. 👇

It wasn't one bad experience that pushed me out. It was the accumulation of several changes that made me less comfortable building my entire workflow around Anthropic.

1. Invisible text watermarking

This is the biggest issue for me. Anthropic signed the EU AI Act Code of Practice, and Claude is moving toward text-level watermarking for supported models. This isn't a tag sitting in metadata that disappears when you copy the text somewhere else. The signal is supposed to be embedded into the generated text itself, through the way words and tokens are selected, meaning it can travel with the text after copy-paste and potentially survive some editing.

I don't like the idea of a provider silently attaching a machine-readable provenance signal to ordinary text I generate with a tool I'm paying for. For me, that changes the relationship with the product completely.

2. Subscription access is becoming more restricted

The monthly Claude subscription can no longer simply be used through tools like Hermes or OpenCode in the same way. If you want Claude there, you're increasingly pushed toward API billing. Meanwhile, competing ecosystems are becoming much easier to plug into different tools.

A subscription is a lot less valuable to me if the model is increasingly locked to Anthropic's own surfaces.

3. Anthropic's direction on open models is increasingly incompatible with mine

Anthropic has consistently taken a much more cautious position toward powerful open-weight models than many of its competitors. I understand the safety argument. I just don't agree that concentrating frontier capability inside a handful of closed companies is necessarily the better long-term outcome.

I care about open models, inspectable systems, portability, and the ability to move away from a provider without rebuilding everything from zero. xAI, for example, has released weights from earlier Grok generations and continues opening more of its surrounding tooling.

That matters to me.

4. Claude no longer has the performance gap that made all of this easy to tolerate

For a long time, my answer to almost every complaint about Claude was basically: yes, but the model is better.

That argument is getting harder to make.

Grok 4.6 is now extremely close to the latest Claude models across several coding and agent benchmarks while costing dramatically less through the API. GPT has also become much stronger in the areas where Claude used to have a comfortable lead. At the same time, competitors are bundling capabilities Claude still handles separately or doesn't offer directly, including native image generation and increasingly capable computer/agent systems.

Claude is still excellent. It just isn't obviously far enough ahead anymore for me to ignore everything else.

5. I trust Anthropic less than I used to

The deeper problem is that more and more of the product depends on decisions happening behind the interface: model switching, safety routing, retention requirements, usage limits, changes in model behavior, and now provenance mechanisms inside generated text.

I'm giving these systems code, unfinished ideas, research, internal documents, and large parts of my working process. The more important AI becomes to my work, the more I care about knowing exactly what happens to that information and how much control I retain over it.

So for now, I'm moving on.

I'll be testing Grok 4.6, Grok Bot, Cursor, and a more multi-model workflow instead of depending on Claude for everything.

The upside is that leaving one provider also forces you to clean up something most people probably should have done already: export your context, organize your project files, separate your memory from the model, and make sure your workflow is portable.

Your AI provider should be replaceable.

If changing models means losing your memory, your workflows, your project context, and months of accumulated knowledge, then the model isn't just a tool anymore.

It's infrastructure you don't control.

[Big Pip @Model_Culture]

exactly. that's probably the part I care about most now.

the model should be replaceable. your memory, project context, preferences, files, and accumulated history shouldn't disappear just because you changed providers.

right now we're still letting AI companies turn context into lock-in.

[Big Pip @Model_Culture]

I finally canceled my Claude Max subscription after months of using Claude for almost everything: work, research, studying, development, and coding. 👇

It wasn't one bad experience that pushed me out. It was the accumulation of several changes that made me less comfortable building my entire workflow around Anthropic.

1. Invisible text watermarking

This is the biggest issue for me. Anthropic signed the EU AI Act Code of Practice, and Claude is moving toward text-level watermarking for supported models. This isn't a tag sitting in metadata that disappears when you copy the text somewhere else. The signal is supposed to be embedded into the generated text itself, through the way words and tokens are selected, meaning it can travel with the text after copy-paste and potentially survive some editing.

I don't like the idea of a provider silently attaching a machine-readable provenance signal to ordinary text I generate with a tool I'm paying for. For me, that changes the relationship with the product completely.

2. Subscription access is becoming more restricted

The monthly Claude subscription can no longer simply be used through tools like Hermes or OpenCode in the same way. If you want Claude there, you're increasingly pushed toward API billing. Meanwhile, competing ecosystems are becoming much easier to plug into different tools.

A subscription is a lot less valuable to me if the model is increasingly locked to Anthropic's own surfaces.

3. Anthropic's direction on open models is increasingly incompatible with mine

Anthropic has consistently taken a much more cautious position toward powerful open-weight models than many of its competitors. I understand the safety argument. I just don't agree that concentrating frontier capability inside a handful of closed companies is necessarily the better long-term outcome.

I care about open models, inspectable systems, portability, and the ability to move away from a provider without rebuilding everything from zero. xAI, for example, has released weights from earlier Grok generations and continues opening more of its surrounding tooling.

That matters to me.

4. Claude no longer has the performance gap that made all of this easy to tolerate

For a long time, my answer to almost every complaint about Claude was basically: yes, but the model is better.

That argument is getting harder to make.

Grok 4.6 is now extremely close to the latest Claude models across several coding and agent benchmarks while costing dramatically less through the API. GPT has also become much stronger in the areas where Claude used to have a comfortable lead. At the same time, competitors are bundling capabilities Claude still handles separately or doesn't offer directly, including native image generation and increasingly capable computer/agent systems.

Claude is still excellent. It just isn't obviously far enough ahead anymore for me to ignore everything else.

5. I trust Anthropic less than I used to

The deeper problem is that more and more of the product depends on decisions happening behind the interface: model switching, safety routing, retention requirements, usage limits, changes in model behavior, and now provenance mechanisms inside generated text.

I'm giving these systems code, unfinished ideas, research, internal documents, and large parts of my working process. The more important AI becomes to my work, the more I care about knowing exactly what happens to that information and how much control I retain over it.

So for now, I'm moving on.

I'll be testing Grok 4.6, Grok Bot, Cursor, and a more multi-model workflow instead of depending on Claude for everything.

The upside is that leaving one provider also forces you to clean up something most people probably should have done already: export your context, organize your project files, separate your memory from the model, and make sure your workflow is portable.

Your AI provider should be replaceable.

If changing models means losing your memory, your workflows, your project context, and months of accumulated knowledge, then the model isn't just a tool anymore.

It's infrastructure you don't control.

[Big Pip @Model_Culture]

@sessor_by facts