DEV Community

Cover image for I Read the Leaked Claude Code Source — Here's What KAIROS Actually Does
Kevin
Kevin

Posted on

I Read the Leaked Claude Code Source — Here's What KAIROS Actually Does

I spent last weekend reading through the Claude Code source code that accidentally ended up inside a published npm package on March 31. You have probably heard the headline numbers: 1,900 TypeScript files, around 512,000 lines, 44 unreleased feature flags, first flagged by security researcher Chaofan Shou on March 31 and subsequently analyzed by VentureBeat and The Register.

One flag kept showing up over and over again: KAIROS. More than 150 references across the tree. That is not a casual experiment. That is an entire subsystem.

This post is the part of my notes I think is most interesting to other devs: what KAIROS actually is, what it would feel like to use, and the parts that should make us pause before celebrating.

I am not going to paste verbatim code from the leak. None of us should. The original repo was taken down, Anthropic has called this a packaging mistake, and the interesting material can be described without reproducing proprietary source. If you want the full catalog of flags with context, someone in the community put together a Claude Code leaked feature flags writeup that is the most complete one I have come across — I was cross-referencing it while writing this.

TL;DR

  • KAIROS turns Claude Code from a request-response CLI into a long-running daemon.
  • It introduces a subsystem called autoDream that runs during user idle time and consolidates the agent's internal observations.
  • It is gated behind an internal feature flag, disabled for all external users, no public timeline.
  • The interesting part is not the daemon. It is what autoDream is allowed to do to its own memory.

What Claude Code looks like today

If you use Claude Code right now, the mental model is simple. You open a shell, you run a command, the agent answers or edits files, and when the session ends, almost all of its working memory ends up in the garbage collector. The things that survive are boring: CLAUDE.md, project indexing, your git history.

Every other mainstream AI coding tool works the same way. Cursor, Copilot, Windsurf, Cline — all request-response. You lead, the model follows. The loop is human-initiated every single time.

That is the model KAIROS is designed to break.

KAIROS as a daemon

At the architecture level, the KAIROS code paths in the leak introduce two things that do not exist in today's shipping build:

  1. A background session that outlives any individual conversation. When you close a Claude Code window the process does not end. It keeps running, watching file changes, terminal output, and other signals from your dev environment.
  2. A persistent context store that the background session writes to. Instead of each invocation starting from a cold window, the agent accumulates observations over hours or days.

On its own, that is already a meaningful shift. "Persistent context" is the single thing every power user of Cursor/Copilot has been asking for. A tool that remembers what you were doing yesterday without you having to re-explain it is objectively useful.

But the more interesting code paths are not about keeping memory around. They are about what the agent is allowed to do to that memory while you are not looking.

autoDream: memory consolidation while you are idle

The subsystem is literally called autoDream in the source. That name is not an accident — it is a direct reference to the biological process by which short-term memories are consolidated into long-term ones during sleep. Anthropic is not hiding the metaphor.

Based on what I read, autoDream fires when KAIROS detects the developer is idle — no typing, no commands, no interactions with the agent for some window of time. Once it fires, it runs three distinct operations on the daemon's accumulated observations:

1. Merge. Facts collected across different sessions, files, and subprocesses get stitched into unified representations. The agent's scattered notes about what auth/session.ts does become a single coherent model.

2. Remove contradictions. When new observations invalidate old ones — think of a refactor that moves logic from A to B — autoDream drops the old entries. Stale knowledge gets pruned.

3. Promote tentative observations to absolute facts. This is the one I kept re-reading. The agent carries some information as provisional ("this function might handle authentication"). After enough supporting evidence accumulates, autoDream rewrites those entries as assertions ("this function handles authentication"). Hedging language gets erased from the agent's own memory.

None of this requires a human approval step. There is no "here is my consolidation diff, please review." The developer is idle, the daemon processes in the background, the internal model of your codebase is different when you come back.

Why this is a category change, not an upgrade

There is a clean analogy for what KAIROS represents: the transition from text editor to IDE.

Early text editors were passive. They displayed characters. You edited them. Modern IDEs are proactive — they analyze your code as you type, flag errors before compile time, propose refactors, manage dependencies. The tool went from reactive to agentic in the loosest sense.

Every AI coding tool today is still stuck at the "passive editor with fancy autocomplete" stage of that analogy. You ask, it answers, it forgets. KAIROS is the first design I have seen that tries to make the jump to the "proactive IDE" side. And it does it in a way that goes further than any IDE ever did — because an IDE's static analysis operates on syntax and types, while autoDream operates on semantics and intent.

If KAIROS ships in something resembling the form in the leak, it is not "Claude Code v2.2 with longer memory." It is the first AI coding tool that operates as a genuine background agent instead of an on-demand assistant. I think that distinction is going to matter a lot.

The parts I am not comfortable with

Reading the code, there are four things that I think every developer should be skeptical about before flipping this switch when it eventually ships.

Absolute facts are terrifying. The autonomous promotion of "might" to "is" is the most consequential operation in the whole system. If the consolidation walks a wrong assumption into the permanent record — especially in a large codebase where the developer cannot easily audit the internal state — every subsequent decision the agent makes is built on corrupted ground truth. I did not see an obvious mechanism in the code for detecting and rolling back a bad promotion.

Always-on monitoring is a privacy surface. A daemon that continuously watches file changes and terminal output is a process that needs a clear answer to "what is sent where." I did not find that answer in the leaked files. Local inference? Continuous API calls? Some hybrid with a local embedding model? Unclear.

Resource cost. An LLM running as a background process is not free, either on your laptop or on Anthropic's infra. Nothing in the code commits to a specific execution model, which means we genuinely do not know yet what this would do to your battery or your bill.

It might not ship. Feature flags live for years. Some of them get abandoned entirely. KAIROS being in the leaked source is not the same as KAIROS being a product Anthropic has committed to. Do not build your team's workflow around something no customer has ever touched.

What to do with this

If you care about where AI coding tools are going, KAIROS is one of the most interesting things to come out of a leak I can remember. It is a concrete artifact — not a blog post about "the future of agents," but actual code paths describing an architecture.

If you want the wider context: the Claude Code leak was the second Anthropic security incident in five days, after the CMS leak on March 26 — someone already did a clean reconstruction of what that first leak actually exposed. Both have been public for weeks now, both have been picked apart by different researchers at different depths, and the picture is still being assembled.

I am going to keep digging through the other 43 feature flags. If you have looked at a specific one and want to compare notes — what BUDDY does, how COORDINATOR schedules its sub-agents, the ULTRAPLAN remote planning session logic — drop a comment, I will probably have opinions.

Top comments (0)