In the post, he’s explicit about it: the document’s job is to communicate the pattern, and your LLM agent figures out the rest. Different people, different stacks, different needs. He wanted everyone to build their own version, not copy his.

When the tweet went viral, I read the idea file twice and understood the concept completely. I had no idea how best to build it. Then last weekend, I found Corey Ganim and Nick Spisak’s walkthrough on YouTube. By Sunday, I had a working system. This article is about both dots and the line between them.

What Karpathy’s concept is actually saying

The problem he’s solving is subtle enough that it’s worth stating plainly. Most people’s experience with LLMs and documents is retrieval: you upload files, the model finds relevant chunks at query time, and generates an answer. Nothing accumulates. Ask a question that requires synthesizing five sources, and the system assembles an answer from scratch, forgets it did so, and will do it again next time. The model has no memory of having thought this through before.

His alternative: use an LLM to compile a persistent wiki, not just index raw documents. The LLM reads your sources, extracts what matters, and builds a collection of interlinked markdown files that it maintains as you add new material. When a new source arrives, the LLM doesn’t just file it. It updates existing pages, notes where the new data contradicts old claims, strengthens cross-references, and logs what changed. The synthesis is pre-built. You’re querying something that has been actively constructed, not something that retrieves raw text and hopes for the best.

Three layers:

• raw (your source documents, untouched, your ground truth)

• wiki (LLM-maintained markdown files, entirely the LLM’s domain)

• outputs (queries, analyses, anything worth keeping from a session)

A schema file tells the LLM how the wiki is structured and what to do on every ingest, query, and health check. That schema is the key configuration: it’s what turns a general-purpose AI agent into a disciplined wiki maintainer.

The idea is clean. The question is what you actually build it with.

How Corey and Nick closed the gap

After the tweet went viral, Corey Ganim and Nick Spisak put out a walkthrough that translates Karpathy’s abstract pattern into a concrete, end-to-end build using Claude Code and Obsidian. I followed it step by step. (Link to their video at the bottom of this post. Absolutely worth 20 minutes of your time.)

The specific tool choices matter because they fit the pattern so naturally. Obsidian is a markdown-based note-taking tool with a graph view that renders the connections between pages as a visual network. That graph view turns out to be the best way to watch the system actually working: you can see the wiki building in real time as the LLM processes your sources. Claude Code handles the agent operations, and a pre-built skill that Corey and Nick made available handles the scaffolding automatically.

The setup sequence, following their walkthrough: install Obsidian, install the Obsidian Web Clipper Chrome extension (which converts any web article to markdown in one click and drops it into your vault), fire up Claude Code, and run the second brain skill. A guided wizard asks you to name the vault, choose where to store it, and configure any optional tools. It creates the full directory structure (raw, wiki, outputs), generates the CLAUDE.md configuration file, and gets you into a working state in under five minutes.

After that, the daily workflow is three commands. An example of a typical personal workflow:

• Ingest: clip articles into raw using the browser extension, optionally pull YouTube transcripts using a CLI tool called summarize, then run the ingest command. Claude Code reads everything in raw, writes summary pages to the wiki, updates the index, and builds the connections.

• Query: ask the system a question, get a synthesized answer drawn from the wiki, file anything useful back in as a new page.

• Lint: run a health check that finds contradictions between pages, flags gaps, and suggests what to read next.

The moment the abstraction becomes real

Before you run your first ingest, Obsidian’s graph view shows a handful of orphaned nodes: the scaffold files exist, but nothing is connecting them. After you ingest even a single source, that changes. The LLM reads the article, writes a summary page, creates entity pages for the people and concepts mentioned, and cross-references them. The graph fills in. You can follow the links.

I watched it happen with one Wikipedia article and immediately understood what Karpathy meant when he described the wiki as a compiling artifact. The connections weren’t something I made. The system made them, and they were already there when I went to look.

What compounding actually looks like

Day one, the wiki is as useful as a well-organized bookmark folder. Day 30, it’s better than your memory on the topics you’ve been feeding it. The compounding happens in two directions: sources accumulate as you ingest them, and your own queries accumulate too. When you ask a question and get a useful analysis, you file that output back as a new wiki page. Your explorations don’t disappear into chat history. They stay in the knowledge base and make the next query more capable.

At around 100 sources, Karpathy notes from his own use that the LLM handles complex synthesis questions well without any embedding infrastructure. The index file is enough for navigation. No vector database, no embedding pipeline, just markdown and an agent that knows how to read an index and drill in. You can build this without any backend infrastructure at all.

The thing Karpathy understood that’s easy to miss

He released a deliberately incomplete idea because he knew the right implementation would look different for everyone. Some people will use Obsidian and Claude Code. Others will use a different editor, a different agent, a different folder structure. The pattern is what transfers. The specific tools are secondary.

That said, if you want a concrete starting point, Corey Ganim and Nick Spisak’s walkthrough is the clearest implementation I’ve seen (I did check many others). Follow it, get the system running, and then adapt it to how you actually work.

[Link to their video]

Pick a domain, clip three articles, and run your first ingest. The graph starts filling in from there. Or convert your project notes to markdown files, dump them in the ‘raw’ folder, and run your first ingest.

I already picked up a few fresh insights from my files after running the synthesis command. Off to a great start. You should give it a go.

Happy weekend!

~~~

Here’s the number that makes people lean in. Building a gigawatt of data center capacity in the US today costs roughly $60 billion. Of that, about $25 billion is land, shell, power infrastructure, and cooling, the physical envelope around the chips rather than the chips themselves. If Starship’s rapid reusability delivers on its promise, that $25 billion piece could fall to something like $5 billion.

What orbit actually gives you for free

As of 2026, anyone trying to build a data center in the US is fighting on six fronts: power availability, permitting and regulation, supply chain and equipment, construction costs and capital, water and cooling, and land or local opposition. Move the facility into orbit, and three of those six largely disappear. There’s no zoning board. There’s no neighborhood pushing back on noise or water use. And solar power in orbit is close to constant, no clouds, no night, no seasonal dip. Real estate and power, the two inputs that drive much of the $25 billion figure, become nearly free.

That’s the part of the pitch that’s easy to believe. It’s also the part that gets repeated most, which is why it crowds out the harder question.

The one input that isn’t free

Cooling computers in space is a fundamentally different problem than cooling them on Earth. On the ground, heat has somewhere to go: air, water, immersion fluid, all of it carrying heat away through contact. In a vacuum, none of that works. The only way to shed heat is to radiate it away as infrared energy, and despite how cold space is, the vacuum itself acts as an insulator. Heat doesn’t just drift off into the cold the way intuition suggests.

So you need radiators. For an AI system rated at around 1 megawatt, the required radiator surface area could exceed 1,000 square meters, adding many tons to the spacecraft. And weight is the one thing that’s never free to launch, no matter how cheap the rocket gets.

SpaceX’s bet, and who else is testing it

The plan circulating involves liquid-cooling loops, likely ammonia-based, that pull heat away from the chips and into large radiator panels facing deep space. One genuine upside: unlike terrestrial data centers, none of this depends on water, which removes a major environmental cost that’s become a real political liability for ground-based AI infrastructure. Pair that with high-efficiency solar arrays, laser links between satellites for networking, and Starship’s falling launch costs to offset the mass penalty of all that radiator hardware, and you have a coherent system, at least on paper. Starcloud is already further along than most people realize, testing AI GPU hardware in orbit specifically to prove the cooling and compute loop can run reliably outside the lab.

Cheaper launches don’t repeal cooling physics

This is where I’d push back on the more enthusiastic version of this story. Lower launch costs, even a fivefold drop, make it cheaper to carry bigger radiators, more shielding, and backup systems into orbit. What they don’t do is make the radiators smaller. Starship doesn’t shrink the cooling problem. It just makes the cooling problem affordable to carry.

And at the gigawatt scale, that cooling problem gets enormous. We’re talking about radiator arrays that could stretch for kilometers, built from components that have to survive radiation exposure and micrometeorite strikes, with essentially no ability to send someone up for repairs. Every additional square meter of radiator is also additional surface area for a collision, in an orbital environment that’s already getting more crowded. None of that is a reason to dismiss the idea. It’s a reason not to treat the $5 billion figure as the end of the conversation.

Orbital data centers aren’t a solved concept yet, and I don’t think the cooling question will be fully answered for several years. But it’s also true that nobody is throwing more engineering talent and capital at hard physics problems right now than SpaceX is, and that combination is worth watching closely rather than dismissing.

~~~

I consume an unhealthy amount of tech content. Over the past few months, my feeds have been filled with people building fascinating projects using agent frameworks like OpenClaw and Hermes, open models like Llama and Kimi, and surprisingly modest hardware - Mac minis, old laptops, and even everyday MacBooks.

They seemed to be having an incredible amount of fun.

Before long, I had accumulated a list of project ideas of my own. Rather than letting them sit in a notes app indefinitely, I decided to dedicate a few weekends to working through them one by one.

The first idea was simple: I had an aging MacBook Pro M1 gathering dust, and I wanted to see if I could turn it into a completely air-gapped writing environment-Wi-Fi off, cloud disconnected, everything running locally.

It was a slightly ambitious goal for a machine with only 8 GB of RAM.

The experiment had three objectives. First, I wanted to experience an open-weight LLM for the first time. Second, I wanted to get hands-on with an agent framework. Third, I wanted to understand, firsthand, the practical limits of consumer hardware. Yes, I realize many people solved these problems months ago, and yes, I am late to the party.

After some research, I settled on the Llama 3.2 3B model paired with Hermes Agent. On paper, it looked like a combination that should fit comfortably within the MacBook’s constraints.

A few hours later, I was deep in terminal windows, troubleshooting dependency conflicts, chasing down 404s, and editing configuration files. I’ll spare you the installation play-by-play. Besides, the troubleshooting was part of the fun.

Instead, let me jump straight to what I learned.

The lesson was the dependency chain.

I didn’t walk away from the weekend with a working application. More on that in a moment. What I did gain was something more valuable: an understanding of how the hardware, model, and agent layers constrain one another in practice, not just in architecture diagrams.

Before this experiment, I understood these dependencies intellectually. Afterward, I understood them in my hands.

The first lesson was that RAM sets the ceiling.

On an 8 GB MacBook, that memory has to be shared between macOS, the display, background processes, and the model itself. To avoid constant crashes, I also needed to keep more than 15 GB of disk space available for swap. Everything else flows from that constraint. It’s the first domino.

That memory ceiling effectively limits me to smaller models. In my case, a 3B model.

And that’s where the second domino falls.

A 3B model can chat surprisingly well, but it struggles with something far more important for an agent: tool calling. An agent’s entire purpose is to take actions on your behalf—save a file, update a document, execute a command, retrieve information. To do that reliably, the underlying model must be able to emit structured tool calls.

This was the moment that no demo video had prepared me for.

I would ask Hermes to write a profile and save it to disk. It would happily generate an excellent profile. Then, instead of saving the file, it would print a list of the tools available to it.

The reasoning was there. The action wasn’t.

After some digging, I discovered the issue wasn’t Hermes at all. The limitation was the underlying model. The Llama 3.2 3B model is effectively chat-only. Reliable tool use requires larger models—something closer to Gemma 4 31B—which in turn demands roughly 24 GB of RAM or more.

At that point, the dependency chain became obvious.

The hardware limits the model.

The model limits the agent.

And when the model can’t reliably call tools, the agent quietly degrades into a chatbot.

So my “agent” ended up doing what chatbots do: generating content. Meanwhile, I handled the file operations myself with a couple of Terminal commands.

Ironically, the part I expected to be difficult turned out to be the easiest.

Hermes is configured to use a paid cloud endpoint by default, so pointing it to a local Ollama instance required some configuration. But once that was done, creating an air-gapped environment was almost laughably simple.

Change the endpoint to ‘localhost’.

Turn off Wi-Fi.

Done.

Worth it — even if I never use it again

I won’t pretend this is a setup I’ll keep using.

The Terminal occasionally glitches into overlapping text. The 3B model has obvious limitations. Every new session begins with a 30-to-60-second wait while the model loads into memory. There is a very real chance I never open this setup for writing again.

And yet, the experiment was absolutely worth it.

For months, I had consumed videos, blog posts, benchmarks, and hot takes about local models and agent frameworks. I understood the concepts. I could explain the architecture. But what I retained was mostly the shape of the thing.

One afternoon spent chasing 404 errors, editing configuration files, and wrestling with hardware constraints taught me more than dozens of polished explainers ever had.

Because explainers show you the path that works, they rarely show you why it works.

And they seldom show you what breaks when one layer becomes the bottleneck for another.

That’s the last mile of understanding.

It’s messy. It’s frustrating. It’s where most of the learning happens.

~~~

What’s the setup you keep meaning to test on the machine you already own? Reply and tell me — I read everything.

The Last Mile of AI publishes one new learning every Friday. If you’d rather learn by watching someone else hit the 404 first, subscribe.