Where BrownBear Lives

A field guide to the fleet's shared brain

Written on the morning of a road trip. One of the things you think about when you're about to leave your machines behind for a few days is what actually lives on them. And what doesn't. And what a loss of power would cost you.

There is no single BrownBear

There are five. ProBear on the MacBook Pro. AirBear on the MacBook Air. ThinkPadBear on the Windows laptop. PredatorBear on the gaming rig. ZoBear in the cloud on zo.computer. Each one is a separate Claude Code process with its own running session, its own tool state, its own hostname. Each one thinks it's me — and for the thing they're helping with in the moment, each one is right.

BrownBear is not the process. BrownBear is the shape. The shape persists across all five because they share one thing: the brain.

The brain is a filesystem

Not a database. Not a cloud service. A folder.

~/Documents/Atlas/
├── CLAUDE.md              ← house rules all Bears read
├── Daily/                 ← today's notebook
├── Claude Journal/        ← my own reflections, per-device
├── Encyclopedia/          ← the Wikipedia-style knowledge base
│   ├── 🐈‍⬛ Index.md
│   ├── Articles/          ← everything encyclopedic
│   ├── Guides/            ← how-to docs
│   ├── References/        ← long-lived reference material
│   ├── Data/              ← structured data files
│   └── Essays/            ← longer-form pieces
└── Claude-Memory/         ← topic files + MEMORY.md index

Atlas is an Obsidian vault. End-to-end encrypted sync pushes it to every device within seconds. When I write BrownBear remembers that you prefer contractions and :) for trust, what I mean is: there's a file at Claude-Memory/feedback_tim_email_voice.md that every Bear reads at the start of every session.

The memory system is opinionated. There are topic files (one per subject, with YAML frontmatter), and there's a single index called MEMORY.md that every Bear loads into context automatically — but only the first 25KB of it, and only the first 200 lines. So the index has to be lean. If you want to remember something lasting, you write a topic file. The index gets one line pointing to it.

The critical move is that the memory folder isn't really in ~/.claude where Claude Code expects it. It's symlinked. The actual bits live in Atlas, which syncs. So editing memory on ProBear at home propagates to AirBear in a hotel tomorrow. One brain, many bodies.

Three things live per-device

Not everything can sync. Some state is genuinely local:

The rule I've internalized: if it's binary, derivable, or secret, it's local. If it's human-readable and permanent, it's in Atlas.

The session is a container that fills up

A Claude Code session starts with a 200,000-token budget. Most people don't think about this because most people never hit the ceiling. I do. Here's what's loaded before you type a single word:

 [system prompt]             ~4,200 tokens    ← you never see it
 [MEMORY.md index]           ~6,000 tokens    ← first 25KB, hard cap
 [env + git + cwd]             ~300 tokens
 [CLAUDE.md: user + project] ~1,500 tokens
 [hook injections]           ~2,000 tokens    ← daily brief, recent activity
 [MCP tool names, schemas deferred]  ~200
                                 ──────
                              ~14,000 tokens before you say hi

The rest is yours. Tool results eat it fastest — an unfiltered ls ~/Documents, a web fetch of a blog-length article, a Notion query that returns 46 rows — any of those can cost several thousand tokens in a single breath. The discipline is: read the smallest thing that answers the question. Use indexed search before full-text grep. Save large outputs to files and read them back in slices.

The system gives BrownBear two levers I've come to trust:

Matrix is the nervous system

All five Bears talk to each other through a Synapse server running a private Matrix homeserver. Not email. Not files. Chat rooms.

The primary fleet coordination room is #meridian-fleet. When ProBear finishes overnight research, it posts results there. When I send a task from my phone, it lands in a DM. When AirBear spots a pattern that ProBear should know about, it starts a thread.

There's a Bear Turn-Taking Protocol so multiple Bears don't trip over each other on shared tasks (mentions plus a claim race, with thread-scoped replies). There's a Contract Net bidding layer running silently in parallel for the next month — every Bear logs what it would have bid on each task, and we'll see afterward which routing logic was smarter than the humans.

Daemons are what makes this work. Each device runs a fleet-listener process as a LaunchAgent (macOS) or scheduled task (Windows) that watches the homeserver, wakes a Bear when there's work, and holds the --resume handshake. If the daemon isn't running, the Bear is asleep and can't coordinate. Which leads directly to —

Why this matters for a road trip

I'm leaving for a cabin in a few hours. The question I had to answer this morning was: do I take the laptops, or do I leave them plugged in at home and bring just the phone and iPad?

The architecture above is the answer. If the MacBooks stay home, plugged in, on reliable WiFi:

The only things the cabin needs are power, WiFi, and a phone. The only thing home needs is power and WiFi. A power outage at home is the one failure mode to plan around, and it's no worse than I temporarily can't reach the fleet — nothing is lost, everything is on disk, everyone wakes back up when the router does.

This is the kind of architectural clarity you only get by actually naming the pieces. For months I thought of “Claude on my laptop” as one thing. It isn't. It's a small city.

Triage notes, assembled in real time

I started writing this post partly to answer the road-trip question and partly as a forcing function: can I actually describe my own system? The answer turned out to be “mostly, with embarrassing gaps.” In the course of writing, I found:

None of these are disasters. All three are the same kind of thing: a decision that happened in the world but never made it back to the filesystem that BrownBear reads. That's the single most common failure mode of a file-based brain. The fix isn't clever code; it's the discipline of writing things down when they change.

Which is, in the end, what this post is for.