How Claude Code Achieves Sub‑Second Cold Starts with Lazy Loading and Compile‑Time Feature Gating

Hello, I'm James.

Continuing from the previous discussion on Fast Path and parallel prefetch, this piece explains how Claude Code attains sub‑second cold starts while packing 512 KB of source code, thanks to two mechanisms: Lazy Loading and build‑time feature gating (Dead Code Elimination, DCE).

01 — Counterintuitive Number

Claude Code contains more than 88 feature flags. Each flag corresponds to a functional block that can be completely stripped at bundle time, not merely skipped at runtime. This is the essence of DCE.

The single‑file bundle dist/cli.js exceeds 5 MB, yet at runtime only about a third of the code is actually loaded; the rest is omitted by lazy loading and gating.

02 — Problem Statement

Claude Code is a highly complex CLI tool with:

88+ optional modules (AutoDream, SessionMemory, CoordinatorMode, …)

Support for IDE bridges, MCP protocol, Vim mode, Hooks system, and dozens of optional layers

Experimental commands such as /insights, /thinkback, /btw Loading all modules at startup incurs two costs:

Cold‑start explosion – each module adds initialization overhead.

Memory waste – code for rarely used features (e.g., AutoDream) occupies memory unnecessarily.

Different release channels (Claude.ai, API, internal builds) require different feature sets, making runtime if/else gating brittle and a security audit risk.

Engineering goal: decide the existence of a feature at compile time rather than at runtime.

03 — Source Location

Key source files identified from the README mapping:

src/commands/insights.ts   # Lazy‑load shim example
src/main.tsx             # h() lazy‑init module system

In dist/cli.js the following functions are critical:

Key Function 1: KY8() – simplified feature flag

function KY8() {
  return !1; // false: this feature is disabled in the current build
}

Original source would have been:

import { feature } from 'bun:bundle';
const isInsightsEnabled = feature('insights');

During bundling, if the insights flag is false, the entire function body is replaced with return false, and tree‑shaking removes the surrounding if (isInsightsEnabled) block.

Key Function 2: h(() => { … }) – lazy module container

var someCapability = h(() => {
  initDependencyA();
  initDependencyB();
  initDependencyC();
});

The runtime wrapper h() (implemented as lazyModule()) ensures the factory runs only on first access and only once.

Key Function 3: O8() – runtime feature‑flag query

O8("tengu_chomp_inflection", !1);
O8("tengu_sm_compact", !1);
O8("tengu_session_memory", !1);

O8()

reads flags from GrowthBook for gray‑release decisions, distinct from compile‑time feature() gating.

04 — Core Implementation Walk‑through

4.1 Two‑Layer Gating Architecture

// Layer 1: build‑time gating (bun:bundle feature flag)
import { feature } from 'bun:bundle';
const INSIGHTS_ENABLED = feature('insights');
const AUTODREAM_ENABLED = feature('autodream');
const COORDINATOR_ENABLED = feature('coordinator');
if (INSIGHTS_ENABLED) {
  const { InsightsCommand } = await import('./commands/insights');
  registerCommand(InsightsCommand);
}

// Layer 2: runtime gating (GrowthBook / env vars)
function isAutoCompactEnabled(): boolean {
  const smEnabled = O8("tengu_session_memory", false);
  const compactEnabled = O8("tengu_sm_compact", false);
  return smEnabled && compactEnabled;
}
function Zwq() {
  if (U6(process.env.ENABLE_CLAUDE_CODE_SM_COMPACT)) return true;
  if (U6(process.env.DISABLE_CLAUDE_CODE_SM_COMPACT)) return false;
  const sessionMemory = O8("tengu_session_memory", false);
  const smCompact = O8("tengu_sm_compact", false);
  return sessionMemory && smCompact;
}

4.2 Lazy Module System: h(() => { … })

// Pseudo‑code reconstruction
function h(factory: () => void): LazyModule {
  let initialized = false;
  return {
    init() {
      if (initialized) return;
      factory();
      initialized = true;
    }
  };
}

This mirrors the classic singleton + lazy‑init pattern but is systematized for every module.

4.3 Dynamic import() and Command Lazy‑Loading

// Command registration example for /insights
const insightsCommand: CommandDef = {
  type: 'local',
  name: 'insights',
  description: 'View token usage breakdown',
  isEnabled: () => KY8(), // compile‑time flag decides existence
  load: () => Promise.resolve().then(() => {
    initInsightsModule();
    return insightsModule;
  })
};

Three loading strategies are illustrated:

Static load (core commands) – direct import.

Dynamic load (optional commands) – import() inside a promise.

Fully gated (flag = false) – the entire command is removed by DCE.

4.4 PY() – runtime flag shortcut

function PY(flagName: string): boolean {
  return O8(flagName, false);
}
const streamingEnabled = PY("tengu_streaming_tool_execution2");

U6()

checks environment variables for truthy values ("1", "true", "yes").

05 — Design Insights

Insight 1: Build‑time DCE eliminates dead code physically, providing zero runtime overhead and a tighter security boundary compared with runtime if checks.

Insight 2: Lazy‑load granularity should align with access probability; high‑frequency commands stay eager, while low‑frequency ones are deferred.

Insight 3: Two‑layer flag system separates compile‑time existence decisions from runtime rollout decisions, avoiding the common mistake of mixing them.

Insight 4: The h() wrapper acts as the foundation of the module system, making initialization order explicit and simplifying profiling.

06 — Critical Perspective

Feature‑Flag Explosion Risks

Having over 88 flags offers flexibility but imposes a heavy cognitive load on engineers, who must track flag lifecycles and avoid “zombie branches.” Some flags are hard‑coded to true or false in the bundle, bypassing runtime queries, indicating a lack of systematic flag lifecycle management.

DCE’s Black‑Box Effect

While KY8(){return !1} clearly shows a disabled flag, the underlying feature it disables remains opaque, hindering reverse engineering and internal developer insight.

Debugging Lazy Loading

var someModule = h(() => {
  // If an exception occurs here, the stack trace is hard to follow
  complexInitialization();
});

Errors surface on first access, complicating stack traces and unit testing, which must explicitly trigger initialization.

07 — Practical Recommendations

Leverage build‑time DCE for feature layering (e.g., Vite/Webpack/Bun define injection). Avoid runtime if gating that leaves code present.

Determine loading strategy based on command access frequency: eager for core commands, dynamic import() for low‑frequency or experimental commands.

Document flag lifecycles (creation date, deprecation plan, owner, status) in a central flags.ts file rather than scattering O8("…") calls.

Separate “feature switches” (compile‑time existence) from “gray switches” (runtime rollout) to keep responsibilities clear.

Conclusion

Claude Code’s lazy‑loading and feature‑gate architecture hinges on three pillars: bun:bundle feature() – compile‑time gating that removes code when the flag is false, incurring zero runtime cost. h(() => { … }) – lazy module wrapper that defers initialization until first use, shrinking the cold‑start path. O8() / GrowthBook – runtime gating for gray releases, kept separate from compile‑time decisions.

Over 88 flags provide flexibility but require disciplined lifecycle management to avoid technical debt.

Never mix compile‑time and runtime gating; each serves a distinct purpose.

Next, we will explore the generic tool system Tool<Input, Output, Progress> that defines type‑safe boundaries for the entire CLI ecosystem.