Stop picking between ChatGPT and Claude. Own your context instead.

Claude and ChatGPT are the two all-rounders and they have rotated the lead for as long as I have been doing this. Gemini is genuinely better at some things, Grok at others. Betting the business on one of them being permanently ahead is a bet that has lost every month for two years.

What actually stops people switching is not the subscription. It is the feeling that the tool “knows them”. Every AI product has a memory feature now and every one of them is, quietly, a lock-in feature. The memory is inside their product, in their format, and it does not come with you.

The fix is to keep the memory yourself. Plain text files, in a folder, on your computer. Then every tool reads the same files and you are free to use whichever one is best this week.

Start with one folder and five files. Write them in Word, Google Docs or Notes and save them as plain text.

1. Who we are. The business, what it sells, who the customers are, who is on the team. Half a page.
2. How we write. Tone, words we use, words we never use, how we sign off. Include a real example of something you wrote and liked.
3. The rules. Everything that has ever annoyed you about an AI’s output, as a numbered list. “Always quote prices in AUD including GST.” “Never call a customer by their first name in a proposal.” “Ask before assuming.”
4. This project. One per project or client. What it is, what has been decided, what is out of scope, where the documents are.
5. Decisions and mistakes. A dated log. Every time you correct the AI on something that matters, add a line. This file is worth more than the other four combined after a month.

Then put the folder in front of the tool. As of today all three of the main products support this in the same way:

• Claude: create a Project, paste the rules into the project instructions, add the files to the project’s knowledge.
• ChatGPT: create a Project, same thing. Set it to project-only memory so it works from your files rather than from its guesses about you.
• Gemini: create a Gem, paste the rules into its instructions, add the files under Knowledge.

Every new chat in that project or Gem starts with your context loaded. The tool’s own memory becomes a convenience rather than something you depend on. When the files change, update the folder first, then re-upload. The folder is the source of truth, never the tool.

If a better model comes out next month, you create a project in the other product, attach the same folder, and you are working within the hour.

Everything the AI needs to know about me and my business is in markdown files on my Mac. Markdown is just text with a bit of formatting. You can open it in Notepad.

• One global file with who I am, how I work and the rules that apply to everything.
• A folder of rules by topic: code style, how I want to be spoken to, what to do when blocked.
• One file per project with the context for that project, which mostly points at the documents where the detail lives.
• One memory folder per project, with one file per thing worth remembering, and an index.

None of this is pasted into a chat. Every session, in every tool, reads the global file and the current project’s file automatically the moment it starts, before I have typed a word. It is not a feature I switch on. It is how the tools work when the files exist, and it is why a brand new session already knows the rules, the project and what went wrong last time.

I use Claude Code and Codex most days, and Gemini and Grok when they are the right tool. They all read the same files. Codex is literally told to go and read Claude’s files before it starts. This is the actual instruction:

## Claude Context Bridge
- Treat existing Claude context as shared project context, not as a separate system.
- When starting work in a repository, read Claude guidance when available:
  - ~/.claude/CLAUDE.md for global preferences.
  - CLAUDE.md in the repository for project rules.
  - The project's memory folder for what has already been decided.
- Prefer the most local project guidance over broad global guidance when they conflict.

Two competing tools, one set of files. Nothing to migrate. If a third tool is best next month, it gets the same instruction.

Not much, and that is the point. The files are short because they only hold what the tool cannot work out on its own.

Who I am. The top of my global file is half a page on the business, what it sells, who the clients are and how I work. Nothing clever.

Rules, most of them born of pain. Every one of these exists because something annoyed me enough to write it down:

- A QUESTION IS NOT A WORK ORDER. If my message is a question, the deliverable is your ANSWER. Do NOT write or edit code. Only build when I clearly instruct it.
- WHEN BLOCKED, STOP AND ASK. Do NOT silently fall back to an inferior alternative.
- NEVER give time estimates. Claude doesn't know how long things take for Claude.
- NEVER use em dashes anywhere. Use hyphens.
- ALL money values are in AUD unless I explicitly say otherwise.
- ALL of my businesses operate in Brisbane (UTC+10, no DST, ever).

A mistakes log. Dated, blunt, and read at the start of every session by every tool:

- 2026-04-14: Included guessed competitor data as verified facts in a proposal draft. Caught before sending. Root cause: filled gaps with assumptions instead of flagging them as unverified. NEVER present unverified information as fact.

Nobody “trained” anything. I wrote a paragraph, and every tool now reads it before starting work. One correction becomes a standing instruction.

A project file. Short, and it points at where the detail lives rather than repeating it:

Full project context, decisions and client notes: project-notes.md
Current build progress: progress.md
Follow docs/journey-review-plan.md before building new functionality.
Local port is 3006.

A memory index. One line per thing remembered, each pointing at its own small file. Readable by me, editable by me, deletable when it turns out to be wrong. That last part matters. A memory you cannot see is a memory you cannot fix.

The rules that earn their keep most are not about code at all. They are about the emails, proposals and reports that go out with my name on them. This is from my global file, and every tool reads it before it writes anything a client will see:

## Client-facing documents
- The reader IS the client. Speak to them, not about them. Never reference them in third person by first name ("the alert Kate flagged"). Use "you" or describe the thing directly.
- No internal language. Don't use "brain dump", "stakeholder", "discovery call" or "scope of work" in the deliverable. Just describe the thing.
- No restating what the client told us back to them as if it's new. They know what they said. Don't open with "You mentioned that you want X". Just propose X.
- No meeting-recap framing inside a proposal. Get to the substance.
- Tone test: read it back as if you're the client receiving it cold. If any sentence makes you cringe or sounds like AI marketing copy, rewrite it.

Because of that file, a proposal comes out addressed to the person reading it, in the words we would actually use, without me fixing the same five things every time. Same with email: there is a rule about formatting because an early email came out cramped and hard to read. Written down once, applied across every tool.

If you run a business, this is the file to write first. How you address people, what you never say, how a quote is laid out, what a good email from you looks like. It is worth more than any prompt trick, and it is the one that makes every AI you use sound like you.

This is the part that changes what the AI is for. The files do not just tell it who I am. They tell it how to reach my business, and the rules for doing so.

Everything I run sits behind one API I built, the SILA API, and the global file tells any model how to use it. Email across four accounts, with the right sender picked for the thread. The task list for every project. My training plan and ride history. A bot that watches a task inbox, turns each client email into a job and starts a session in the right project with a briefing. The rules for all of it live in the same file as the rules for how to talk to me:

## Email
- When asked to send, draft, search or read email, use the SILA API. Never fall back to a browser or another connector. If a call fails, report the exact error and stop.
- Resolve accounts at runtime, never hardcode them. Reply from whichever address the thread was addressed to.
- NEVER send plain-text-only email. Always pass proper HTML paragraphs so it renders full width like a normal message.
- Sending email is outward-facing. Confirm recipient, account and content with me first unless I have clearly told you to just send.

None of that is a feature of Claude or Codex. It is mine. Codex sends email through the same API under the same rules, and so would anything else that reads the file. Swap the model, nothing changes.

The non-technical version is the connectors inside each product: connect your Gmail, Drive and calendar wherever supported. You connect each tool separately, but the rules for how to use them stay in the same instructions file as everything else.

The other half of owning your context is the history. Every chat I have with any of these tools is saved as a plain text file on my Mac, in the folder for that project. Not inside the product. On my disk. I can open a conversation from six months ago, search across all of them, or hand an old one to a different tool and say “pick this up”.

That is what makes a new session per task cheap. Nothing is lost when a chat ends, because the chat is a file. The next session does not need the conversation, it needs the decisions, and those get written into the project’s notes as they happen.

The version anyone can do today. End every session that mattered with one prompt: “Summarise what we decided, what changed and what is still open, in plain text.” Paste the answer into the decisions file in your folder with the date on it. Thirty seconds, and the next session, in any tool, starts from there instead of from zero.

The automated version. The habit above can be automated, so every session writes its own summary into the right project folder on your computer without you asking. It takes a bit of setup. If it is something you would like help setting up, I would be more than happy to help. The habit works on its own until then.

Jake Van Clief, who has a large following for exactly this idea, published it in March 2026 as a paper: Interpretable Context Methodology: Folder Structure as Agentic Architecture. His line is that it has been sixty years and we still use folders and files, and he is right.

His version organises the files around five questions the AI needs answered, in order: where am I, where do I go, what do I do, what rules apply, and what am I working with. If you want a structure to copy, that is a good one. His workspaces are aimed at running whole pipelines through the folder, which is more than most businesses need. The principle underneath is the same: the context is in the files, and the files are yours.

This is what I reach for, as of September 2026, from my own use rather than any benchmark. It will change, which is the whole point of being mobile.

• Claude and ChatGPT are the all-rounders. Writing, reasoning, code, anything long. Whichever one is ahead this month gets the heavy work.
• Gemini for anything with video, and anything inside the Google world: Docs, Sheets, Drive, YouTube.
• Grok, and Grok Build in particular, when the other tools get overly cautious about a perfectly legitimate request. It also has the best read on what is happening right now: trends, what people are saying on X and Reddit, new product data.

If your context is in a folder, you can use all four without briefing each one from scratch.

The other thing I see constantly, especially with clients who have just started: every conversation has to contain everything. One enormous chat that has been running for three weeks, with the whole history of the business in it, because they are afraid the AI will forget.

It is the most expensive way to work and it gets worse results. Long conversations chew through usage limits, and the models genuinely perform worse when the important thing is buried in the middle of a huge history. That second part is not opinion, it is a documented weakness of the models, and Van Clief’s paper builds its whole method around avoiding it.

Think of it like briefing a new staff member. You hand them the handbook and the task. You do not read them your entire email history first.

One task, one session, small brief. The files are the handbook. If the files are good, the model only needs the task.

Could you switch tools tomorrow and give the new one your working preferences, project context and key decisions without rebuilding them from memory?

If yes, you own your context. If no, you are renting your own memory from whichever company happens to be ahead this month. Fix that first, then pick whatever model you like.