Don’t Marry the Model

We switched an organization from ChatGPT to Claude in less than a week.

There was no transformation program. No long migration plan. No AI steering committee.

Just a renewal deadline, a short proposal, and enough confidence that we could go back if it did not work.

That last part mattered more than I expected.

The Switch Started With Timing

There was no formal policy. People used different AI tools, but most of the organization was using ChatGPT.

I had been thinking for a while that Anthropic aligned better with the organization’s values than OpenAI. Then a team member asked what I thought about an OpenAI boycott.

The timing was awkward but useful. There were less than two weeks left before the annual team plan renewed.

So the question became practical fast: do we renew ChatGPT because everyone is used to it, or do we take the moment seriously and try something else?

I wrote a short proposal for switching to Claude.

Leadership understood the reasoning. There was no veto. But there was hesitation, which made sense. ChatGPT was working. People had built habits around it. Some people had chat histories they relied on. Switching felt risky because the tool had quietly become part of their workflow.

That is the first thing I learned: AI tools become infrastructure before anyone calls them infrastructure.

Reversibility Changed the Conversation

The strongest argument was not that Claude was better forever.

It was that the decision was reversible.

If the switch did not work, we could go back. The cost of trying was lower than the cost of locking into another annual cycle without testing the alternative.

This changed the emotional shape of the decision.

People did not have to agree that Claude was the perfect tool. They only had to agree that trying it was safe enough. That is a much easier conversation.

I think this matters for AI tools in general. The market is moving too fast to treat any model, provider, or interface as permanent. The right question is not only “Which tool is best?”

The better question is: How painful would it be to switch next month?

If the answer is “very painful,” the tool has more power over the system than it should.

The Tool Is Not Just the Model

It is tempting to talk about this as a model switch: OpenAI to Anthropic, ChatGPT to Claude, one provider to another.

But that is too narrow.

Most AI products are not just models. They are wrappers, workspaces, chat histories, file stores, project systems, automations, browser extensions, connectors, permissions, and habits.

Even if a tool lets you change model providers, you can still be stuck inside the wrapper software.

A coding assistant might let you choose Claude, GPT, Gemini, or a local model. That sounds flexible. But if all the project context, instructions, workflows, and task history live inside that assistant, the wrapper becomes the lock-in.

A chatbot might support multiple models. But if the chat history, uploaded files, custom instructions, and team knowledge stay trapped inside the product, the model choice is only one small part of the system.

A no-code AI platform might advertise provider flexibility. But if the data, deployment, secrets, and automation logic live inside its proprietary environment, switching the model does not make the system portable.

This is the subtle trap: model choice can create the feeling of openness while the surrounding infrastructure creates the actual lock-in.

Chat History Was the Hidden Dependency

The part I underestimated was chat history.

For some people, ChatGPT was not just a place to ask questions. It was where context lived. Previous conversations contained examples, drafts, decisions, prompts, explanations, and half-formed work.

I did not warn people clearly enough that switching tools could mean losing access to that history.

That was a miss.

It revealed something important: when people use AI every day, the chat log becomes a messy knowledge base. Not a good one. Not a designed one. But a real one.

And because it is useful, people start depending on it.

This creates a bad pattern:

• useful context gets created inside a vendor product
• the product becomes the easiest place to continue the work
• leaving the product means leaving the context behind
• the longer this continues, the harder switching becomes

That is not just a UX problem. It is a systems problem.

If the most important context lives inside the tool, the tool owns the workflow.

Don’t Marry the Model

I do not think the lesson is “never commit to tools.” That would be silly. Good tools are worth learning deeply.

The lesson is to avoid confusing tool depth with tool dependency.

You want to get good enough with a tool that it compounds. You do not want to build so much invisible dependency around it that switching becomes a major migration project.

That means separating the durable parts from the replaceable parts.

Durable parts:

• project files
• source code
• notes
• decisions
• documentation
• prompts that actually work
• system instructions
• data exports
• deployment configuration
• credentials and access policies

Replaceable parts:

• model provider
• chat interface
• coding assistant
• automation wrapper
• hosting layer, when possible
• search or retrieval tool
• current “best” AI product

The model should be a component, not the foundation.

The same goes for the wrapper around the model.

What I Would Do Differently

If I did the switch again, I would make the context migration explicit.

Not complicated. Just explicit.

Before switching, I would tell people:

• important chat history may not come with you
• copy out reusable prompts, examples, and decisions
• save project-specific context somewhere outside the chat tool
• build a local-first or self-hosted memory system your AI can connect to

I would also separate the tool recommendation from the system principle.

The recommendation might be: use Claude now.

The principle is: keep the organization able to switch later.

Those are different things.

One is a current preference. The other is a long-term capability.

Build for Optionality

The deeper lesson is not about Claude or ChatGPT.

It is about optionality.

AI is moving too quickly for brittle systems. A model that feels clearly ahead today may be average in six months. A tool that feels magical today may become expensive, constrained, or strategically wrong later.

The way to handle this is not to avoid choosing. You still need to choose. Work needs tools.

But the system around the tool should stay untangled.

For me, that means a few practical defaults:

• keep important writing and documentation in files I control
• keep project context close to the project repo
• keep system instructions readable outside any one AI app
• prefer tools that can export data cleanly
• treat AI providers as swappable services where possible

This is not always convenient. Sometimes the integrated product is better. Sometimes the wrapper saves a lot of time. Sometimes lock-in is worth it for a while.

But it should be a conscious trade-off, not something that happens accidentally because the default chat box was convenient.

The Switch Created Momentum

One unexpected benefit of switching tools was that it made AI visible again.

People had to try something slightly unfamiliar. That created friction, but it also created attention.

Some people who were initially worried about losing ChatGPT came back a week later saying they liked Claude more. It made people re-evaluate how they were using AI instead of continuing on autopilot.

Tool changes can do that. They can create momentum if the stakes are low enough and the path back is clear enough.

The mistake is turning every tool choice into a permanent identity.

The Real System

An AI model is not a spouse. It is not a religion. It is not a home.

It is a capability layer.

Use the best one you can access. Learn it properly. Let it improve the work.

But do not let the model, provider, or wrapper become the place where all important context gets trapped.

The real system is the one that remains when a better option appears.

If switching tools feels impossible, the tool is no longer just a tool.

It has become the system.