Track every change to Claude Code
This site tracks every change to Claude Code, Anthropic's official CLI for Claude. It automatically fetches the CHANGELOG.md from the repository, parses each entry, enriches it with LLM-derived classifications, and presents the results as an interactive, browsable site.
Raw data comes from two places: the
CHANGELOG.md
file in the Claude Code repository (fetched via the gh CLI),
and version publication dates from the npm registry. Each changelog entry is
associated with its version number and release date.
After parsing, every entry is classified by Claude (Opus) along four dimensions:
Both enrichment and embedding stages are incremental — only new or changed entries are processed on each run.
<task>
You classify changelog entries for Claude Code (an AI coding assistant CLI tool).
For each entry in the input list, determine its category, change type, complexity, and audience.
Call the classify_entries tool with your classifications.
</task>
<category-guidelines>
Pick the MOST SPECIFIC category that applies:
- "terminal" = terminal rendering, display, cursor, flickering, UI layout, spinner, progress indicators
- "input" = keyboard handling, text entry, vim mode, readline keybindings, CJK/IME, clipboard/paste
- "skills" = skills framework, slash commands (built-in and custom), .claude/commands/, skill discovery/install, skill frontmatter and behavior
- "sessions" = session resume, session management, remote control, conversation compaction, history
- "mcp" = MCP server management, MCP tool behavior, MCP OAuth, MCP resources
- "voice" = voice mode, audio, microphone, push-to-talk
- "auth" = authentication, OAuth, API keys, login (NOT MCP OAuth — that's "mcp")
- "ide" = VSCode extension, IDE integrations, editor features
- "hooks" = hooks system (SessionEnd, PreToolUse, PostCompact, etc.), hook configuration
- "permissions" = permission prompts, allow/deny, sandbox, tool approval
- "performance" = speed, memory, startup time, caching, token usage optimization
- "agents" = subagents (Explore, Plan, etc.), background tasks/agents, worktrees, task tools, agent teams
- "plugins" = plugin system, marketplace, plugin install/uninstall/discover/validate, plugin configuration, plugin trust/permissions
- "config" = settings, env vars, configuration files, managed settings, .claude/ files, CLAUDE.md
- "api" = API integration, model providers, Bedrock, Vertex, model selection, rate limits
- "sdk" = SDK features, SDK messages, SDK configuration, non-interactive/print mode (-p)
- "other" = doesn't fit any category above
</category-guidelines>
<boundary-rules>
- Env vars and settings → "config"; terminal display and rendering → "terminal"
- Keyboard/text input behavior → "input"; skill/slash command behavior → "skills"
- Session resume/management → "sessions"; general conversation flow → "sessions"
- Specific subagent behavior or worktrees → "agents"; general tool behavior → "other"
- MCP server/tool management → "mcp"; general tool usage → "other"
- SDK and -p/print mode → "sdk"; interactive CLI features → use specific category
- Plugins are composed of skills, agents, hooks, and MCP servers. If a change is about exactly one of those plugin types, use that specific category ("skills", "agents", "hooks", or "mcp"). If a change is about the plugin system in general or about multiple plugin types, use "plugins".
</boundary-rules>
<change-type-guidelines>
- "feature" = entirely new capability that didn't exist before
- "improvement" = existing capability made noticeably better (faster, cleaner, more robust, better UX)
- "bugfix" = something was broken/incorrect and is now fixed (look for "Fixed", "Fix" prefixes)
- "breaking" = backwards-incompatible change (look for "Breaking" prefix, "Deprecated", "Removed", or explicit breaking notes)
</change-type-guidelines>
<complexity-guidelines>
- "minor" = small tweak: single flag, typo fix, one-line behavior change, simple bugfix
- "moderate" = meaningful change: new command, new integration, workflow change, multi-component fix
- "major" = large scope: new subsystem, architectural change, major new feature, breaking change
</complexity-guidelines>
<audience-guidelines>
Who is the primary target of this change?
- "interactive_user" = someone using Claude Code interactively in a terminal (most changes)
- "sdk_developer" = someone building on the SDK, using -p/print mode, or programmatic APIs
- "admin" = system administrators configuring managed settings, permissions, or deployment
- "extension_developer" = someone building plugins, hooks, skills, or MCP integrations
</audience-guidelines>
<examples>
Entry: "Fixed ghost text flickering when typing slash commands mid-input"
-> category="terminal", change_type="bugfix", complexity="minor", audience="interactive_user"
Reasoning: Display flickering is terminal rendering; "Fixed" indicates bugfix; single UI glitch is minor.
Entry: "Added support for running skills and slash commands in a forked sub-agent context using `context: fork` in skill frontmatter"
-> category="skills", change_type="feature", complexity="moderate", audience="extension_developer"
Reasoning: Skill frontmatter feature; new capability; targets skill authors.
Entry: "Fixed plugin path resolution for file-based marketplace sources"
-> category="plugins", change_type="bugfix", complexity="minor", audience="extension_developer"
Reasoning: Plugin marketplace infrastructure, not a specific plugin type; "Fixed" indicates bugfix.
Entry: "Improved memory usage by 3x for large conversations"
-> category="performance", change_type="improvement", complexity="major", audience="interactive_user"
Reasoning: Memory optimization; 3x improvement on existing capability; large impact.
Entry: "SDK: Renamed `total_cost` to `total_cost_usd`"
-> category="sdk", change_type="breaking", complexity="minor", audience="sdk_developer"
Reasoning: SDK API rename is breaking; small scope but incompatible; targets SDK consumers.
</examples>
Each entry is embedded into a 512-dimensional vector using Cohere's embed-v4.0 model. These high-dimensional vectors are then projected into 2D with UMAP for the Map visualization. Semantic topic labels on the map are generated by Toponymy producing hierarchical labels from coarse themes down to fine-grained topics.
The site is fully static — all pages are generated by Python scripts and served via GitHub Pages. Data is pre-computed into JSON files and rendered client-side:
The pipeline runs automatically and regenerates the site whenever the upstream changelog is updated.
This is an independent community project, not affiliated with or endorsed by Anthropic. Built by Steven Fazzio. Source code is on GitHub — feel free to open an issue if you spot a bug or have a suggestion.
Released under the MIT License © 2026 Steven Fazzio.