Claude Code shipped its own TypeScript in npm source maps

The .js.map files that shipped with Claude Code on npm carry a field called sourcesContent, and that field held the product's original TypeScript: nearly two thousand files. Someone read all of it and turned the reading into an 18-chapter book, Claude Code from Source.
At a glance
- Eighteen chapters across seven parts were produced by 36 AI agents in four phases, from exploration to review, with the entire run from extraction to revised text taking roughly six hours.
- Fork agents share byte-identical prompt prefixes so children hit the same prompt cache, which the book puts at roughly 95% fewer input tokens; startup is 240ms and output is capped at 8K by default.
- A final audit pass rewrote every code block as pseudocode with different variable names, and the site says the finished text contains no Claude Code source, only original illustrations of the patterns.
If you have not met source maps before, they are the debugging crutch of shipped JavaScript. A bundler squashes readable code into one unreadable file, and the .js.map next to it tells a debugger which unreadable line came from which original one. sourcesContent is the optional part, where the original files are embedded whole instead of merely referenced.
The book was written by 36 agents in about six hours
Extraction came first. The sourcesContent field yielded what the site describes as the complete architecture, close to two thousand files of TypeScript. Then the agents went to work in four phases.
Six agents read the whole source tree in parallel. Twelve wrote 494KB of raw technical documentation. Fifteen rewrote all of it from scratch as narrative chapters. Three reviewers produced 900 lines of feedback, and three more agents applied every fix.
A final audit pass rewrote every code block as pseudocode with different variable names, so that no verbatim source remained. The site calls the project purely educational, and adds that the NO'REILLY cover is a parody with no affiliation to O'Reilly Media.
Ten patterns carry the design, starting with one async generator
The agent loop is a single async generator. It yields messages, returns a typed Terminal value at the end, and gets backpressure and cancellation from the language rather than from bespoke plumbing. Around it sits a 14-step pipeline that runs from model request to tool result, permission resolution included.
Tools are partitioned by safety classification: read-only calls run in parallel, writes are serialized. Read-only tools can also start speculatively while the model is still streaming, before the response is complete.
Context is compressed in four layers, snip, microcompact, collapse and autocompact, each lighter than the next. Skills load in two phases, frontmatter at startup and full content only on invocation. The 27 lifecycle hooks read a config snapshot frozen at startup, which the book presents as a guard against runtime injection.
Why do parallel sub-agents save about 95% of input tokens?
Because they are identical at the front, byte for byte. Fork agents are spawned with the same prompt prefix as their siblings, so the prompt cache recognizes it and the tokens are not paid for again. The book puts the saving at around 95% of input tokens.
Think of a print shop with the plate already inked: the setup is paid once and each extra copy costs only paper. Change a single character in the prefix and the plate has to be cut again. Sticky latches serve the same goal, which is why a beta header, once sent, is never unset mid-session.
Forks are one shape among several. The book also covers a coordinator mode and swarm teams that pass messages through mailboxes. The same chapters describe the loop that streams model output, executes tools and recovers from errors.
Memory runs on files and a Sonnet side-query, with no database
Memory lives in files, in four types, with staleness warnings. Recall is a side-query to Sonnet that picks which stored notes are relevant to the moment. The book claims that this beats embedding search.
The performance chapters account for the rest. Startup lands at 240ms through parallel I/O. Fuzzy search gets bitmap pre-filters in front of it. Slot reservation caps output at 8K by default and escalates to 64K when a response hits the cap, which the book says saves context in 99% of requests.
Six core abstractions sit at the centre, laid out in an interactive diagram on the site. Every chapter ends with an "Apply This" block of five transferable patterns, aimed at engineers building agentic systems and at technical leaders who want the reasoning without reading each code block.
The book carries no Claude Code source at all, by design, so every architectural claim is the agents' reading of files the reader cannot check it against. The accuracy pass was internal: three reviewers, 900 lines of feedback, three agents applying fixes. In our view that is a light audit for a text whose entire value is fidelity to code it deliberately does not show.
Which build the chapters describe
The site does not say which release of Claude Code the maps came from, when they were pulled, or whether sourcesContent is still present in the current npm package. Nothing in it promises a second pass over a newer build. For anyone planning to apply these patterns, the open question is which version of the agent these 18 chapters actually document.
Related stories
- Claude desktop teardown: MCP servers run outside the VM
- Show HN: Generate a Claude Code or Codex agent fleet from one HTML file
- pairmark races Claude Code against Codex in your repo
- Oh My Subagents keeps Claude Code teams running
- Show HN: Agent-hop – a Rust TUI that hops a live Claude Code chat into Codex
- Two approvals per feature: Pragma's Claude Code iOS pipeline
Comments
No comments yet. Be the first.
Join the conversation
Sign in with Google to leave a comment. Your name and avatar come from your Google profile, and the comment appears after moderation.
