Nate Herk breaks down practical insights from the leaked Claude Code source code
Nate Herk walks through eight actionable takeaways from the leaked Claude Code source code.
Summary
Nate Herk covers the leak of Claude Code's source code — roughly 2,000 files and over half a million lines of TypeScript — which became publicly accessible after Anthropic published an NPM package containing a source map pointing to readable source files on their servers. A security researcher discovered it, and the full codebase was mirrored on GitHub within hours. Herk emphasises he is not showing the actual code, given Anthropic's copyright and DMCA activity, but instead draws out eight practical insights about how to use Claude Code more effectively. The central argument is that most users treat Claude Code like a chatbot when it is actually a full agent runtime with a tool system, memory system, permission engine, multi-agent coordinator, and MCP client/server — and that understanding the architecture unlocks dramatically more value from the tool.
Key Takeaways
FULL TRANSCRIPT
What the leak was and how it happened
Nate Herk: Claude Code's source code just got leaked to the internet — 2,000 files, over half a million lines of production code, the actual codebase behind Claude Code. Here's what happened. Anthropic published an NPM package that included a source map file pointing to readable TypeScript source on their servers. A security researcher found it, followed the breadcrumbs, and the full source was mirrored publicly on GitHub within hours. It went super viral.
So I went through everything that people found, I went through the codebase, and I pulled out every practical insight that will actually change how you use Claude Code. I'm talking hidden commands that most people have no idea exist, how context and tokens actually work under the hood, and what the architecture reveals about features most users never touch. I broke it down into eight key insights, and each one builds on the previous one. The first few will change how you think about the tool, but the last one ties everything together into a system — and that's where the real leverage is. By the end of this, you'll know how to use Claude Code like a top 1% user.
I do have to start with a quick disclaimer. I'm not going to show any of the actual source code, and I'd encourage you to be careful if you go downloading it yourself. Even though this leaked through a public NPM package, Anthropic still owns the copyright and they've shown they're willing to send DMCA takedown notices. So everything I'm covering is just based on takeaways of how you can use the tool better.
Just to give you a taste of what's in this codebase — you know those little messages you see while Claude Code is thinking? That's a file with 187 spinner verbs in it. You've got normal ones like "computing" or "generating," but then you've also got funny ones like "boondoggling," "discombobulating," "frobnicating," "moonwalking," things like that. Someone at Anthropic got paid to write 187 of these. That's the energy I want from the people building my tools. But anyway, that's just a quick appetizer. Let's get into the stuff that actually matters.
Insight 1: Claude Code is a full agent runtime, not a chatbot
Nate Herk: Starting with number one — it's not what you think it is. The first thing this leak reveals is that Claude Code is not what most people think it is. Most people think it's basically just Claude but in your terminal, like a chatbot with access to your local files. That's completely wrong.
What the source code shows is that Claude Code is a full agent runtime. It's a proper application built with Bun, TypeScript, and React. It has a tool system, a command system, a memory system, a permission engine, a task manager, a multi-agent coordinator, and an MCP client and server — all wired together under one execution pipeline. The flow goes: your input hits a CLI parser, it goes to something called the query engine, calls the LLM API, runs a tool execution loop, and then renders results back in your terminal.
Why does this matter to you? Because if you're using Claude Code like a chatbot — meaning you're just typing questions and hoping for good answers — you're using maybe 10% of what it can actually do. The rest of the value is in the systems built around the model. And that's what the rest of this is about.
Insight 2: The slash command system most users ignore
Nate Herk: The second piece is the command system that you're ignoring. Here's something most people don't realise: the source code reveals there are roughly 85 slash commands in Claude Code. Most users know maybe five of them. You probably type `/help` and that's about it, or maybe `/context`. But power users — the ones getting ten times more value out of Claude Code — are using commands like shortcuts.
Here are the ones that matter most.
`/init` sets up your project context. It generates a `claude.md` file that acts as Claude Code's operating manual for your repository. We'll talk more about why this file is so important in a moment.
`/plan` puts Claude Code into planning mode. Instead of immediately executing, it maps out the full approach first and then asks you before it starts touching files. This is huge when you're working on something complex and you don't want it to just start editing things everywhere. You'll also save tokens in the long run doing this.
`/compact` is a big one for saving money. When your conversation gets long, context gets expensive. `/compact` compresses your conversation history so you can keep the important stuff but drop the noise. If you're burning through tokens, this is one of the fastest fixes. You can also run `/compact` with a prompt — so if you want to compact a project but keep all the important information about a specific integration, you can specify that when you run the compaction.
`/review` and `/security review` are built-in code review workflows. Instead of asking Claude Code to "look at my code," you use these commands and it runs a structured review. The fact that these exist as dedicated commands tells you something — review isn't an afterthought in this product, it's a first-class workflow.
`/context` manages what files Claude Code is actually paying attention to. This matters because every file in context costs you tokens. This command gives you visibility so you can clean things up.
`/cost` shows you what you've actually spent. Most people have no idea how much a session is costing them until they look at the bill. Run `/cost`.
`/resume` and `/summary` let you pick up where you left off between sessions without having to re-explain everything.
And that's only the tip of the iceberg. The point is: better prompts are one lever, but knowing these commands is a completely separate lever that most people aren't even touching.
Insight 3: The memory system and the claude.md file
Nate Herk: Number three is the memory system, and it is way more important than you think. The source code reveals that Claude Code has a full memory system, and the centre of it is a file called `claude.md`. Most people either ignore this file or dump a bunch of random notes into it — and that's a huge mistake, because `claude.md` is not documentation. It's operating context.
Think of it like this. If Claude Code is an employee, then `claude.md` is their onboarding document. It tells them: here's how we do things, here's what matters, here's what we never do, and here's how this project is structured. The best users keep the `claude.md` file short, opinionated, and operational. Things like: "We use TypeScript strict mode. Always." "Tests go in test folders next to the source file." "Never modify the database schema without running migrations." "Use PNPM, not npm." Decision rules, constraints, conventions — not a novel about your project's history.
The source also reveals that there are multiple layers to this: user-level memory, extracted memories, and even team memory synchronisation. What that tells us is that Claude Code has persistent memory mechanisms across project, user, and session contexts. And `claude.md` is one of the highest-leverage inputs shaping how it behaves in future sessions.
If you get nothing else from this, go update your `claude.md` file today — whether that's on the global level or the project level. Remember, these get injected every single session, before every single chat.
Insight 4: Permissions are why Claude Code feels slow
Nate Herk: Number four — permissions are why Claude Code might feel slow. If you've used Claude Code, you've hit this. You ask it to do something and it keeps asking: "Allow me to do this? Can I run this? Can I edit this?" And it's really annoying. Most people think the fix is better prompting. It's not. The fix is permissions.
The source code shows a deep permission system with multiple modes: a default mode where it asks you about everything, a plan mode, and then things like bypass permissions or auto modes where it can just execute. But here's the real gem — you can set wildcard permissions. Things like "allow all git commands" or "allow all file edits in my src folder." So instead of Claude Code asking you fifteen times whether it can run `git status` or edit a file or run a test, you set the rule once and it just works.
In your `settings.local.json` or `settings.json`, you can set global, user-level, or project-level permissions for things you always want to allow, always want to deny, or always want it to ask about. This lets you go from babysitting every action to actually letting it operate like an agent while you step away.
Insight 5: Claude Code is built for multi-agent work
Nate Herk: Number five — it is built for multi-agent work. This one surprised me. The source code reveals a full coordinator subsystem, agent tools, team tools, and a task system designed for background and parallel work.
What does this mean in plain English? The architecture is clearly built to support decomposition — splitting work across multiple agents that can run in parallel. Think one agent exploring your codebase, another implementing changes, and another validating tests. There are even concepts in the source for background tasks — work that continues while you're focused on something else.
How much of this is fully user-facing today versus still rolling out is harder to say from the source alone, but the architecture makes the intent clear: Claude Code is designed to handle complex multi-step work by breaking it apart, not by cramming it all into one thread.
The practical takeaway is about how you structure your requests. Instead of one massive prompt like "refactor this entire module, update the tests, and fix the documentation," break that up. Let Claude Code decompose the work. Think about it the same way I talk about workflows versus agents in something like n8n or just in general — the best results come from breaking complex work into clear sequential steps, or in this case parallel steps, rather than hoping one giant general instruction to one giant general agent gets everything right.
Insight 6: MCP, plugins, and skills as the real extension layer
Nate Herk: Number six is about MCP plugins and skills being the real extension layer. Here's what the source code confirms: MCP isn't just supported by Claude Code — it's baked into the architecture. Claude Code is both an MCP client and an MCP server. It can connect to external tools through MCP, and other systems can connect to it.
But it goes beyond MCP. The source also reveals a skills and plugin layer, meaning power users can build repeatable workflows, custom capabilities, and domain-specific extensions that compound over time. It's not just about connecting to one tool — it's about building an ecosystem around Claude Code that makes it smarter for your specific work.
This is where Claude Code stops being just a coding tool and starts being an integration layer. You can connect it to databases, APIs, internal tools, documentation systems — anything with an MCP server — and then layer skills and plugins on top for the stuff you do repeatedly. The more systems you connect it to, the more useful it becomes. The power isn't the tool itself — it's what you connect to it and the workflows you start to automate and build with it.
Insight 7: Features that don't exist yet for regular users
Nate Herk: Number seven — there are features we don't even have access to yet. This one's super interesting. The codebase includes checks for something called `user type`, and one of the values is `ant`, meaning Anthropic. What this tells us is that certain capabilities are gated behind internal feature flags. The source references things like voice mode, a system called Chyros, a daemon mode, and a coordinator mode — all behind flags that suggest they're either internal, experimental, or being rolled out gradually.
I want to be honest here: we can't say for sure how different the internal experience actually is. Some of these could be early prototypes. Some might be close to shipping publicly. The source alone doesn't tell us that. But what it does confirm is that Claude Code is heavily feature-flagged, meaning different users may already be getting meaningfully different experiences depending on their environment, their build, or their rollout group.
The practical takeaway is to pay attention to Claude Code updates. Capabilities that are flagged or limited today are likely on the roadmap. And when they land, the people who already understand the architecture will be ready to use them immediately. Think about how many features and tools Claude Code has been shipping lately — it's because they've all been already built and tested internally. I've heard that computer use has been around for a long time, but they just released those functions once they were ready.
Insight 8: How to put it all together and use Claude Code like a top 1% user
Nate Herk: Number eight — how to actually use this to save money and get better results. Let me tie all of this together with what I think matters most: the habits that separate top 1% users from everyone else.
The single biggest insight from this entire source code is this: top users don't just write better prompts — they design a better operating environment for their Claude Code.
Here's what that looks like in practice.
First, treat `claude.md` like a force multiplier. Keep it short, keep it opinionated, update it regularly, and route to other files. This single file shapes every interaction you have with Claude Code.
Second, learn the command system. You don't need all 85 commands, but `/plan`, `/compact`, `/context`, `/review`, `/cost`, and `/resume` — these will change your daily workflow immediately.
Third, configure permissions for your recurring workflows. Stop babysitting every action. Set wildcard rules for the stuff you do every day.
Fourth, think in terms of decomposition, not monolithic prompts. Break complex work into a search phase, a plan phase, an execute phase, and a verify phase. Let Claude Code use its architecture the way it was actually designed to. Otherwise it's like trying to shoot an American football through a basketball hoop — that's not what it was designed to do.
Fifth, manage your context like it's money, because it literally is. Use `/compact` when conversations get long. Use `/context` to control what's loaded. Use `/summary` and `/resume` to carry work across sessions without losing important details. Every unnecessary file in context is tokens you're paying for. Context management isn't just a nice-to-have — it's an actual discipline, something you need to build a habit around.
Sixth, connect things to it. Whether that's MCP servers, CLIs, plugins, or skills — the more tools Claude Code can access, the more valuable it actually becomes.
Seventh, treat it like infrastructure, not an app. The source reveals a massive configuration surface: model routing, sub-agent model overrides, shell behaviour, privacy controls, and even the ability to route through different cloud backends like AWS Bedrock or Google Vertex. Most people never touch these settings, but if you're using Claude Code seriously, there's real leverage in tuning the environment to fit your workflow.
That's what was hiding inside Claude Code's source code.