KAIROS: A Complete Technical Teardown of Claude Code's Hidden Autonomous Daemon

On March 31, 2026, Anthropic accidentally shipped 512,000 lines of Claude Code source in an npm package. Five days earlier, a CMS misconfiguration had leaked draft blog posts about an unreleased model called Mythos.

Two leaks. One roadmap. KAIROS is the harness. Mythos is the brain.

I cloned the actual TypeScript source, read every file referencing KAIROS, and mapped the complete system. This is not a summary of viral tweets. This is what the code actually says.

What KAIROS Is

Current Claude Code is reactive. You ask, it does. KAIROS makes it proactive. It watches your codebase, consolidates memories while you sleep, responds to Discord and Slack messages, and reviews your pull requests automatically.

The name comes from Ancient Greek: kairos means "the right moment" or "the opportune time." It is the qualitative counterpart to chronos (sequential time). KAIROS does not act constantly. It acts when your codebase needs attention.

234 references across 65+ files. This is not a prototype behind a single feature flag. It is a deeply integrated system spanning the daemon lifecycle, memory architecture, cron scheduler, channel messaging, and GitHub integration.

The Three Control Planes

KAIROS is controlled at three distinct levels. Understanding this architecture is key to understanding why it is not yet shipped despite being functionally complete.

Plane 1 is why most people cannot find KAIROS code in the published npm package. Bun's compile-time feature() intrinsic resolves KAIROS to false in public builds. Every require() call gated behind feature('KAIROS') is eliminated before packaging. 108+ modules simply do not exist in the published bundle.

Plane 2 adds runtime gates even for internal builds. The directory must pass a trust dialog (preventing malicious .claude/settings.json injection), and a GrowthBook flag (tengu_kairos) must be enabled for the user. The daemon entry path (--assistant) bypasses the GrowthBook gate since daemon processes are pre-entitled.

Plane 3 is what changes when KAIROS is active. Five behavioral shifts, each with significant implications.

The Feature Flag Family

KAIROS is not one flag. It is a family of flags controlling different subsystems independently.

The modular flag design means Anthropic can ship pieces incrementally. KAIROS_BRIEF could ship without the daemon. Channels could ship without GitHub webhooks. The flags form a dependency graph, not a monolith.

The Daemon Lifecycle

When you run claude assistant, KAIROS takes over.

Without a sessionId, the daemon discovers existing sessions. With one, it attaches as a remote viewer via WebSocket. The viewer streams live events and lets users inject messages, but the agentic loop runs remotely.

The Dream Engine

This is the most technically fascinating part of KAIROS. Claude Code literally dreams.

The Gate System

Before dreaming, five gates must pass in order from cheapest to most expensive:

The time gate (24 hours) and session gate (5 sessions) are configurable via the GrowthBook flag tengu_onyx_plover. The scan throttle (10 minutes) prevents the time gate from firing every turn when sessions are below threshold.

The critical detail: when kairosActive is true, isGateOpen() returns false. KAIROS does not use interactive auto-dream. Instead, it runs a permanent nightly cron task via the /dream skill. The daemon controls its own schedule.

The 4-Phase Consolidation Prompt

When the dream fires, a forked subagent receives this prompt:

Phase 1 — Orient: ls the memory directory. Read MEMORY.md to understand the current index. Skim existing topic files to improve rather than duplicate.

Phase 2 — Gather recent signal: Priority order: daily logs first, then drifted memories that contradict current codebase state, then narrow grep of session transcripts (never full reads).

Phase 3 — Consolidate: Merge new signal into existing topic files. Convert relative dates to absolute. Delete contradicted facts at the source.

Phase 4 — Prune and index: Keep MEMORY.md under 200 lines and 25KB. Each entry one line under 150 characters. Remove stale pointers. Resolve contradictions between files.

The dream agent runs with restricted tools: Bash is read-only (ls, find, grep, cat, stat, wc, head, tail only). It can use FileEdit and FileWrite only for memory files. It tracks files touched, maintains a live turn log, and has an abort controller for user cancellation.

Daily Log Memory Mode

In standard mode, Claude edits MEMORY.md directly during sessions. In KAIROS mode, the memory architecture changes fundamentally:

Design decisions from the source:

• Append-only during sessions. The log is never reorganized in real-time.
• Date in the path, not literal in the prompt. The system prompt is cached and must survive midnight without a cache bust. A date_change attachment is injected at rollover.
• Nightly distillation via the permanent /dream cron task. Logs become topic files, MEMORY.md becomes a clean index.
• MEMORY.md still loaded every session as the orientation index, but never written directly.

The Channel System

KAIROS communicates via channels. A channel is any MCP server that pushes inbound messages.

Security: The Permission Protocol

Channel servers can declare a claude/channel/permission capability for sensitive actions:

1. Claude needs to run a destructive tool
2. Sends notifications/claude/channel/permission_request to the server (structured: tool name, description, input preview)
3. Server formats for platform (Telegram markdown, iMessage rich text)
4. Human replies with approval text
5. Server parses, emits structured permission event with {request_id, behavior: 'allow'/'deny'}

This prevents prompt injection via text channels. Approval requires a server-level structured event, not text pattern matching.

Gate Chain

Five gates protect channel access:

1. Server declares claude/channel capability
2. GrowthBook tengu_harbor kill-switch
3. OAuth authentication required (API key users blocked)
4. Teams/Enterprise: channelsEnabled: true in managed settings
5. Session allowlist from --channels flag

The Cron System

KAIROS's autonomous behavior runs on a cron scheduler.

When assistant mode activates, three permanent tasks are installed:

Thundering Herd Prevention

When thousands of KAIROS daemons all schedule 0 8 * * * (8 AM daily), the cron system applies deterministic per-task jitter:

• Recurring tasks: Forward delay based on frac(taskId) * recurringFrac * interval, capped at 15 minutes
• One-shot tasks: Backward lead (fires slightly early) when the minute matches mod 30 (humans round to :00 and :30)
• Fleet tuning: GrowthBook flag tengu_kairos_cron_config refreshes every 60 seconds, allowing ops to spread load during incidents without restarting clients
• Kill-switch: tengu_kairos_cron gate stops all firing mid-session

GitHub Webhooks

The KAIROS_GITHUB_WEBHOOKS flag enables PR event subscriptions:

• subscribe_pr_activity / unsubscribe_pr_activity tools
• Events arrive as <github-webhook-activity> tagged messages
• A webhookSanitizer module (eliminated from public build) prevents prompt injection from webhook content
• Merge conflict transitions are NOT available (GitHub does not webhook mergeable_state changes). Must poll: gh pr view N --json mergeable

The workflow: PR opens, KAIROS daemon receives webhook, reviews the diff, posts a comment or notifies you via channel.

PROACTIVE vs KAIROS

These are related but distinct modes:

PROACTIVE can activate standalone via --proactive flag. KAIROS implies PROACTIVE but adds the daemon, cron, channels, daily-log memory, and remote viewer.

Capybara: The Brain Behind the Daemon

While KAIROS is the harness, the model powering it matters. The source contains multiple references to an internal model codenamed Capybara — the internal name for what the CMS leak called Mythos.

Source Code Evidence

// src/constants/prompts.ts
@[MODEL LAUNCH]: Update comment writing for Capybara
@[MODEL LAUNCH]: False-claims mitigation for Capybara v8 (29-30% FC rate vs v4's 16.7%)

// src/main.tsx
Ant model aliases (capybara-fast etc.) resolve via tengu_ant_model_override

// src/utils/undercover.ts
NEVER include in commit messages:
- Internal model codenames (animal names like Capybara, Tengu, etc.)
BAD: "Fix bug found while testing with Claude Capybara"

// src/utils/model/model.ts
capybara-v2-fast → cap*****-v2-fast  // Model ID masking

// src/utils/toolResultStorage.ts
(notably capybara) to emit the \n\nHuman: stop sequence

// src/query.ts
capybara to opus 400s  // Fallback logic

What This Reveals

• Multiple versions exist: v4 through v8 at minimum, with capybara-fast and capybara-v2-fast speed variants
• False claims are worse: Capybara v8 has a 29-30% false claims rate versus v4's 16.7%. The model is more capable but less factually reliable. This is likely why general release is delayed.
• Stop sequence bug: Capybara models sample the \n\nHuman: stop sequence at approximately 10%, causing premature turn endings
• Fallback logic: When Capybara returns a 400 error, the system falls back to Opus
• Speed encoding: Model speed is encoded in the ID itself (capybara-v2-fast[1m])
• Undercover mode strips all Capybara references from commits and PR descriptions for internal Anthropic employees

The Convergence

KAIROS is model-agnostic in the source — it uses whatever model the session is configured with. But the combination of KAIROS (always-on daemon with channels, webhooks, and dream) plus Mythos-tier intelligence (step-change reasoning and cybersecurity capabilities) is the product Anthropic is building toward.

The CMS leak described Mythos as targeting "enterprise security teams" first. KAIROS's architecture — persistent daemon, channel communication, GitHub webhook integration, proactive monitoring — is exactly the harness an enterprise security team would want running a cybersecurity-focused model 24/7.

ULTRAPLAN: Cloud-Based Planning

One more hidden system worth noting. When a user types "ultraplan" in their prompt, it triggers a cloud-based planning flow:

ULTRAPLAN offloads complex planning to a cloud session with more compute, then teleports the approved plan back to the local terminal for execution. The keyword is replaced ("ultraplan" becomes "plan") so the remote model does not see the routing mechanism.

What This Means for Builders

Understanding KAIROS at the source level changes how you should prepare:

1. The hook exit-code protocol becomes critical. In autonomous mode, Claude acts without you watching. Exit code 2 (deny) is your safety net. Build hooks that block destructive actions proactively, not just reactively.

2. CLAUDE.md's 12,000-character budget matters more. When the daemon acts overnight, your instructions are all it has. Make them precise. Architecture decisions, file protection rules, behavioral boundaries.

3. MCP channels are the communication layer. Start thinking about how your tools push messages to humans. The channel protocol is the bridge between autonomous AI and human oversight.

4. Daily log mode means cleaner memory. If you are already using persistent memory files, adopt the append-only daily log pattern now. Let nightly consolidation handle organization. It is the same architecture KAIROS uses.

5. The permission protocol prevents prompt injection. If you build MCP servers that will work with channels, implement the structured permission protocol. Text-based approval is not secure enough for autonomous agents.

Timeline

• KAIROS: 234 references, three control planes, fully integrated cron system. The code is production-quality. Likely ships H2 2026, piece by piece via the modular flag system.
• Capybara/Mythos: Multiple versions in testing internally. False claims rate still too high for general release. Enterprise security teams first. Efficiency improvements needed before broad availability.
• Together: The enterprise vision — a Mythos-powered KAIROS daemon monitoring your infrastructure 24/7, reviewing PRs, responding to incidents via Slack, consolidating context overnight. This is not speculation. The architecture for it is already built.

---

Every claim in this post traces to a specific file in the Claude Code TypeScript source. Analysis by Sidharth Satapathy. Follow @satapathy9 for more AI engineering deep dives.