How to Move AI Projects Between ChatGPT, Claude and Local Models

If you use more than one AI tool, you’ll recognize the problem. You have a great working session in one product. You make decisions, test ideas, write code or outline an article. Then you open another model and realize it has no idea what you’ve already accomplished.

Your project shouldn’t disappear just because you changed the software you use to work on it. Short version: save the project’s current state in a Markdown brief alongside its real files, write checkpoints after meaningful work, and give the next model one clearly defined job.

During Home Gadget Geeks 693 (https://theaverageguy.tv/2026/10/31/ai-agents-local-models-cybersecurity-christian-johnson-hgg693/), Christian Johnson and I discussed this problem in practical terms. Christian keeps a shared Google Drive workspace that Claude and ChatGPT can work from, recording goals, discoveries, code and progress in files another model or computer can read. He calls it checkpointing the work. I described my own ChatGPT-to-Claude Drive inboxes. Christian then raised the question that stuck with me: do those handoffs preserve tools and outputs, not just instructions?

That’s the distinction I think makes AI work portable.

What actually needs to move?

A pasted conversation may be helpful, but it usually isn’t the best long-term project record. Conversations are full of dead ends, shorthand and decisions that were eventually reversed.

A more useful handoff includes:

  • The goal: what outcome are we trying to produce?
  • The current state: what exists and has actually been verified?
  • Decisions: what did we choose, and why?
  • Working files: source documents, code, examples and finished outputs.
  • Constraints: things the next model must not change or invent.
  • Next action: the single most useful piece of work to resume.
  • Source links: where the authoritative material can be found.

The point isn’t to make the next model read everything you’ve ever said. It’s to give it enough verified context to do the next step well.

Start with a portable project brief

I like the simplicity of a Markdown document. It can be read by people, local tools, editors, Git repositories and many AI applications. You’re not betting the entire project on one vendor’s proprietary memory.

A useful project brief might look like this:

PROJECT: Home Gadget Geeks article workflow

GOAL: Turn a finished episode into accurate show notes and useful evergreen articles.

STATUS (last verified [date]): Transcript reviewed. Draft show notes saved as show-notes-v2.md. Nothing published.

APPROVED: Episode title and final audio file.

CONSTRAINTS: Don’t publish without approval. Don’t invent product pricing or quotes.

FILES: Links to the transcript, show notes and prepared assets.

NEXT: Check the article draft against the transcript before staging.

The exact fields can change. Their job is to reduce ambiguity.

Checkpoint after meaningful work

A checkpoint isn’t an elaborate database. It’s a short written update after a meaningful task: what changed, what was checked and what remains open.

I use this idea when work moves between ChatGPT and Claude through shared Drive folders. One agent writes a completed artifact or structured task. The other reads the actual file, rather than expecting that a new chat will remember every detail.

Christian’s version is what he calls checkpointing: he saves goals, discoveries, code and progress in files another model or computer can read, so he isn’t stuck if a provider changes its prices. That portability can also reduce the cost of changing tools when a provider changes pricing or a new model becomes attractive.

Don’t confuse a handoff message with a finished artifact

Suppose one model writes a program and another model is asked to review it. The second model needs the actual code, test results and requirements, not merely a message saying ‘the code was written.’

The same is true for a podcast. If one model writes draft show notes, the next editor should see the complete draft and source transcript—not a vague message that the notes are probably done.

This is where a shared folder becomes useful. Keep the authoritative files in a predictable location, use explicit version names, and mark what is approved versus still a draft.

A simple five-step handoff routine

Step 1: Save the current result in a portable file.

Step 2: Write a short checkpoint with the current state and unresolved questions.

Step 3: Link the exact authoritative files and their locations.

Step 4: Give the next AI one small, clearly defined job and say what done looks like.

Step 5: Verify the returned work and update the checkpoint.

An extra safeguard: don’t treat a handoff note as proof that someone approved a risky action. Approval for publication, spending, deletions or credentials should be verified through the appropriate trusted channel.

What about tools and connectors?

Moving a Markdown file is easy. Moving capabilities isn’t always.

A model that could inspect a repository, read a Drive folder or interact with WordPress may have different permissions from another. Christian’s question on the show was whether a handoff preserves tools and outputs, not just instructions. My addition is that portable context should record those outputs and identify the tools the work depended on, without assuming every destination has the same access.

The receiving tool should check what it can actually open and do. If a source isn’t accessible, stop or report the gap rather than reconstructing the missing material from memory.

Choosing where an agent runs is another part of a portable workflow. For a practical comparison of tools and the permissions they need, see OpenClaw vs. Hermes: How to Choose an AI Agent for Your Home Lab.

If you’re deciding whether to run some of this work locally, start with what an older PC can realistically run for local AI. Once your projects involve a home server, it’s also worth reviewing how to prioritize home-lab security updates. You can hear Christian and me discuss all three ideas in Home Gadget Geeks 693.

Don’t over-engineer the handoff

You can build complex agent-to-agent systems, but you don’t need them to get the basic benefits. Start with one folder, one living brief and one checkpoint convention.

For simple tasks, copying a clear summary into the next chat is often enough. Use the full workflow when the project spans days, multiple tools or a real approval process.

Frequently asked questions

Can ChatGPT and Claude share the same conversation history?

Not as one automatically shared conversation. Check the current import and memory features of each product; a portable brief and shared files work regardless. A portable summary and shared files can help transfer useful context, subject to account and connector permissions.

Can I use this with local AI?

Yes. Local models can read suitable exported text and project files through compatible tools, though the context size, format and tool capabilities will vary.

Should I save the entire transcript of every conversation?

Not necessarily. Preserve source material when it matters, but lead with the current state, decisions and authoritative outputs.

What should I do when two models disagree?

Return to the source files and verified requirements. A handoff does not make either model’s answer authoritative.

How do I know a project is ready to move?

The next participant should be able to identify the goal, current state, needed files, constraints and next step without guessing.

The HGG693 conversation

Christian Johnson and I go deeper on portable context, model switching, agentic development and local AI in Home Gadget Geeks 693.

Watch the edited episode: https://youtu.be/2nrPJOvfA0g

Find the HGG693 episode, audio and complete show notes: https://theaverageguy.tv/2026/10/31/ai-agents-local-models-cybersecurity-christian-johnson-hgg693/