Why I built a deeper changelog site

Anthropic ships Claude Code fast and doesn't tell anyone what's in it. Features land with no announcement, no entry in the changelog, sometimes no documentation at all, and when notes do turn up they turn up late. Most of the "changelogs" I see going around are Anthropic's own release notes copied out with commentary bolted on top, which tells you nothing you couldn't have read yourself in ten seconds.

The one I keep coming back to is --sdk-url. In v1.0.77, back in August 2025, Claude Code quietly picked up a persistent WebSocket transport as an alternative to the usual stdin/stdout pipe. You get claude --sdk-url=wss://..., bearer token auth over ws:// or wss://, automatic reconnection with exponential backoff up to five attempts, a thousand message buffer while it's disconnected, and request replay when it comes back so nothing gets lost. That's real behaviour you'd want to know about before building on it, and it's a year old now with nothing written down about it anywhere. It's on here though, because undocumented doesn't mean it isn't shipped.

What this site is

It reads Claude Code the way you'd read any other npm package. Pull the bundle, diff it against the last release, work out what actually changed, write it up. There are 465 versions on here going back to v0.2.100, and a busy release will run 300 or 400 entries.

This is the third attempt

The first version was a pipeline on a Windows box that produced markdown files and nothing else. Then I put it on GitHub Pages, which was an improvement, except the entire navigation was two links, Recent and Archive, with no database, no search and no way to send someone to one specific entry. It's still up while I retire it. This one is a Laravel app with a real database behind it, built on 10 August 2026, and it's the first version that can do anything more interesting than render a flat page.

How it works

A cron job checks npm's latest and next tags every five minutes. If nothing has changed that costs me one npm query and no model time at all. When something has changed:

the tarball gets pulled, prettified, and diffed against the previous release at the syntax tree level instead of as lines of text

the diff gets split into units and grouped by the flag names, identifiers and string literals they share

model agents work through those groups and write findings, and every finding has to cite the strings it came from

those citations get checked back against the source, duplicates get dropped, and what's left gets composed into entries and merged

everything gets scored twice, once for whether a daily user would care and once for whether someone watching where the product is going would care

Usually the page is live about half an hour after the release lands.

I'm not going to pretend it's complete. Run the same group through twice and you'll get anywhere from 57 to 136 turns of work out of it, and the second run reproduces maybe 4 or 5 of the first run's 9 findings while turning up 3 to 5 it missed entirely. So treat everything here as a floor. I don't rebuild old changelogs to catch what a second pass would have found, because that costs real money.

What it costs

This comes out of my Max subscription instead of per-call billing, so the numbers below are what the model time would price at if I were paying for it directly.

The sweep is about 95% of it. v2.1.232 came to $101.95, v2.1.227 to $92.90, v2.1.234 to $78.51, v2.1.229 to $36.32. A version bump with nothing in it, v2.1.231, cost $1.43. Four other stages spend money and record none of it, so the real figure sits a bit above all of those.

I spent a chunk of August bringing that down. Smaller lookup budgets, shorter lived caching, a minimum density per group so I stop paying full price for groups with almost nothing in them, and a deeper second pass only where it's actually worth running. v2.1.235 was the first release through the new setup and its sweep came to $22.12, $11.63 for the broad pass and $10.49 for the deep one. That's a single release though, so don't read it as an average yet.

What sent me looking in the first place: the number of API calls an agent makes correlates 0.854 with what it costs me, and -0.072 with how many findings it produces. The extra turns were buying re-reading, not coverage.

The prompts

There's a second thing running alongside all this that captures Claude Code's own system prompts, one per version, and none of it talks to Anthropic. A published version gets downloaded from npm and run inside a locked down sandbox, throwaway filesystem over the home directory, environment wiped, none of my own configuration anywhere near it, pointed at a fake API on loopback with a fake key. The client builds its whole request, system prompt, every tool schema, every injected reminder, and that request gets written to disk before it would have left the machine.

That's 115 versions so far, v2.1.0 through v2.1.235, with word level diffs between them. I keep two arms separate because they genuinely differ, the Agent SDK in print mode has 24 tools and interactive Claude Code has 27, and they sit about 13 KB apart. They're separate because this project once published the SDK's prompt as though it were Claude Code's. All of it is at /prompts.

Where it's going

Feature flags are already live. Any entry that names a tengu_* gate carries what that gate is really doing, sorted into six states, and that covers the case you can't see from outside, where the code default is off but it's switched on in practice. What I want next is a page per flag with its whole history on it, and flag state feeding into how things get scored.

I'd also like a page for every identifier, so every env var, CLI flag and gate has somewhere listing every release that touched it. Right now they only surface as chips on entries, checked against the shipped bundle before publishing. And I want the documentation ledger wired into entries, so an entry can tell you whether Anthropic ever documented the thing it describes.

Reader feedback calibrating the scores is on the list too, though I'll be upfront that there's no design for it yet and there's an obvious problem with it. Anyone can vote and anything open can be gamed. I've thought about putting votes behind a login, but realistically nobody is going to make an account just to tell me an entry is wrong, so it stays open until that actually becomes a problem. Whenever the calibration does get built, feedback would only ever nudge it. It isn't going to set a score by itself.

If you read this with an agent

There's /llms.txt if you want the whole site as one document, every changelog has a markdown version at /v/{version}.md, and the captured prompts have raw text routes too. If you're pointing a coding agent at documentation instead of reading it yourself, start there.

The Discord bot

The bot posts releases into any server that invites it. Seven kinds of announcement in all: a build sitting on npm that isn't downloadable yet, the run starting, the changelog going live with highlights and deep links, npm's stable tag moving, Anthropic finally posting their own notes, Anthropic editing their docs, and service incidents. Each one can be switched off on its own and pointed at its own channel.

Setup runs about a minute. Invite it, run /changelog set-channel, run /changelog test. It asks for three permissions, View Channel, Send Messages and Embed Links, and no privileged intent, so it can't read your messages or see your member list. Announcements queue up so a restart doesn't lose them, and if it loses permission somewhere it unsubscribes itself instead of hammering the same error forever. The bot page has the full command list.

One person runs all of this. If something on here looks wrong, or you just want to argue about it, Discord is the quickest way to get me, and X works too.