All video notes
Video notes · Claude Code memory

Turn off Claude Code's Memory

Video by Theo - t3․gg on YouTube · 39 min · uploaded August 2026

Notes and analysis by BrainTube, written from the video. Not affiliated with Theo - t3․gg. Watch on YouTube

In short

Theo argues that automatic memory in Claude Code does more harm than good for coding, and backs it with an audit of his own machines: 45 memory files in one project, most stale, and memories written about three times as often as they were read. His alternative is a deliberate stack: fix problems in the architecture first, then in lint rules and CI, then in a hand-written AGENTS.md. The diagnosis is solid for code; the conclusion is weaker for knowledge that does not live in a repo.

The argument

The video's claim is that a codebase already is the memory. Code is the source of truth, it changes constantly, and any second store of facts about it (comments, plan files, auto-saved memories) drifts out of date and starts to mislead the agent. Theo builds on a clip of Mario Zechner (creator of the Pi agent) and Armin Ronacher (creator of Flask), who say coding needs no memory system, bash is all you need, and tool output should only enter context when needed. He then checks his own Claude Code memories and finds them full of point-in-time trivia. His replacement is not a better memory tool but a ladder of fixes, borrowed from a post by a developer he calls Potato Lauren: remove the failure through architecture, catch it with tests or CI, and only then reach for skills, rules and a carefully written AGENTS.md that tells the agent how to think, not just what to avoid.

Key ideas, with timestamps

  1. 3:20

    Code is the ground truth

    In the clip, Mario says he does not want a memory system for coding because the code base is already the thing he maintains. Theo extends this to comments and leftover markdown plan files, which go stale and then actively steer agents the wrong way. His term for the risk is a split-brain problem: change one place, forget the others, and the context lies.

  2. 6:40

    Cursor moved away from fancy context

    Theo uses Cursor as evidence. Its early edge came from indexing the codebase and feeding the model dynamic context, but once Claude Code showed that a model with bash and file tools finds what it needs, Cursor itself moved away from that approach. His conclusion is that embedding-based codebase retrieval is now behind the curve for coding agents.

  3. 7:41

    An append-only log as memory

    Mario's Slack bot writes every prompt and answer to one append-only JSONL file and searches it with jq. Theo calls this hilarious and effective: no curation, no summarisation, just the full record and a search tool. He also concedes at 8:43 that memory makes more sense in chat, where links between topics (a sore shoulder and a new desk) are not traceable the way code paths are.

  4. 13:50

    Auditing his own memories

    He asks Claude Code what memories it holds for T3 Code. On one box it is a single spec for a feature he never shipped. On his main machine one clone holds 45 memory files, including PR numbers, a sidebar draft preference, a stale GitHub CLI version issue and his washer-and-dryer Discord bridge.

  5. 17:00

    Three kinds of decay

    The agent's own review says maybe a third of the memories earn their keep. Around ten duplicate what is already in AGENTS.md, about twelve describe shipped features, and a group of point-in-time states (a drift, a leak, a PR) are risky because nobody knows if they are still true.

  6. 21:08

    Written three times more than read

    Across more than 355 sessions on that machine, 19 opened a memory file while 80 wrote or edited one. Of the 45 memories, 26 were never read once. This is the strongest data in the video, and it is what moves him from skeptic to turning memory off across his fleet.

  7. 24:12

    The order of fixes

    Each time you correct an agent, try to remove the need for that correction. First through architecture or data structures (his examples are tRPC, Convex and type safety across the stack), then a lint rule or test, then a skill or rule, and only last a human check. He treats skills as a safety net, not a toolbox to grow.

  8. 26:17

    A bandwidth budget in CI

    His concrete example: T3 Code was sending tens of megabytes over websockets to load a thread. After optimising it below 100 KB, regressions came back within days, so he added CI that replays real threads and fails the PR if bandwidth goes about 30% over the new baseline. Agents now fix the regression before reporting done.

  9. 32:57

    An AGENTS.md about direction

    He walks through the T3 Code AGENTS.md: what the product is, what makes it special (open at the core, performance, remote ready, every surface), a glossary, known ways the agent kills the dev server, verification and PR rules, and a taste section with a teammate's preferences. The goal is that the agent understands the project well enough to anticipate what he wants.

What it gets right

The audit is the reason to watch. Most arguments about agent memory are vibes. Theo opens the files, counts them, and gets the agent to measure reads against writes. A 3 to 1 write-to-read ratio, with more than half the files never read, is a real finding about how auto-captured memory behaves in practice: capture is cheap and automatic, curation is nobody's job, so the store fills with snapshots.

The ladder of fixes is also sound engineering advice that predates AI. A type error or a failing CI check is a memory that cannot go stale, because it is checked against the code every run. His bandwidth budget is a good model: it turns a preference (keep payloads small) into a test the agent cannot ignore.

The point about direction is the most useful idea for AGENTS.md authors. Rules like "don't do X" pile up. A short explanation of what the product is and what it values (open source, remote-first, every surface) prevents whole classes of mistakes at once.

What it leaves out

  • The failure is curation, not memory. Every bad example he reads is a fact without an expiry date or a source. The same thing would happen to an AGENTS.md if an agent wrote to it after every task. The fix he applies by hand (delete the stale, keep the durable, put it in a reviewed file) is a curation process, and it is what good memory systems try to automate.
  • Code is not the only truth. Why a decision was made, what a customer asked for, what an outside API actually does, what was tried and rejected: none of that lives in the repo. Even his Muse Code example is knowledge discovered by probing, with no public docs. That is exactly the kind of thing worth keeping somewhere searchable, with a date on it.
  • Mario's log is a memory system. An append-only record plus a search tool is a design choice, and arguably a good one: keep raw sources, search on demand, never let the agent rewrite history. The video treats it as the absence of memory.
  • Scope. The advice fits one developer or a small team with strong taste and full control of the codebase. Larger teams with many repos and shared context will hit the limits of a single hand-tuned file sooner.

Claude Code's memory behaviour and settings may have changed since the video's August 2026 upload, so check the current docs before acting on the specifics.

How this applies to memory across AI tools

Separate two jobs. Rules about how to work in a codebase belong in the repo, reviewed like code, as Theo says. Reference knowledge, the videos, articles and docs you learned from, belongs in a store that keeps the original source and that you search when needed, not one the agent summarises into loose notes. That is Mario's JSONL idea applied to what you read, and it avoids the stale snapshot problem because the source is kept, not a paraphrase.

BrainTube takes that second approach: it saves YouTube videos with their transcripts, articles, PDFs and podcasts into one compiled knowledge base and exposes it as an MCP server, so Claude, ChatGPT, Cursor and other MCP clients can search it on demand. For the wider trade-offs, see persistent memory vs the context window and our comparison of Claude Code memory tools.

Who should watch it

Watch it if you use Claude Code or Codex daily and have never looked at what your agent has saved about you, or if you maintain an AGENTS.md or CLAUDE.md and want a model for a good one. The first three minutes after the intro are a sponsor read for WorkOS (about 1:45 to 3:05). Jump to 13:19 for the memory audit, 21:08 for the read and write numbers, 24:12 for the order of fixes, and 32:27 for the AGENTS.md walk-through. Skip it if you want a neutral comparison of memory tools: this is an opinionated rant, with a fair amount of profanity, about one tool's built-in feature.

Frequently asked

Should I turn off Claude Code's memory?
If you mainly work in codebases, Theo's evidence suggests auto memory adds stale facts faster than it adds value. Before deciding, ask Claude Code to list its memories for your project and judge them yourself. Durable rules are better kept in a reviewed AGENTS.md or CLAUDE.md in the repo.
What should go in AGENTS.md instead of agent memory?
In Theo's version: what the product is, what it values, a glossary, known ways the agent breaks things, how to verify changes, how to file PRs, and team taste preferences. He favours explaining how to think about the project over long lists of prohibitions.
Do coding agents need a memory system at all?
The video argues no for code itself, since the agent can read the code with bash and file tools and code is the source of truth. Knowledge that is not in the code, such as research, decisions and external docs, is a different case and benefits from a searchable store that keeps sources.

Keep videos like this one searchable

BrainTube saves YouTube videos with their transcripts into one compiled knowledge base that Claude, ChatGPT, Cursor and other MCP clients can search.

Start free

Go deeper

More video notes

Are you the creator and want this page changed or removed? Contact us and we will act within 48 hours.