Who is talking, and why it matters
This course is independent. It is not affiliated with, sponsored by or endorsed by Anthropic, and it reproduces none of Anthropic's course or documentation text. The explanations are my own, written the way I would explain things to a colleague. Command names, setting keys and version numbers appear because they are identifiers you have to type exactly.
That matters for a practical reason: this course is never the source of truth. Anthropic's current documentation and the binary installed on your machine are. Claude Code ships several releases a week. When I checked in early October 2026, the changelog was at 2.1.295 and the weekly digest covered a span of six or seven version numbers per week.
When you sit at the keyboard, a stale fact costs you a confused minute. When a job runs at 03:00 with nobody watching, a renamed flag or a changed limit costs you a silent failure, or a run that did something you didn't intend. So before anything else, we build one habit: check, then label, then build.
The three-source check
Think of it like adopting a library: you read the lockfile, the docs and the release notes. Here it takes about two minutes.
1. Your installed version
claude --version
# 2.1.295 (Claude Code) <- the number that matters is the one on THIS machine
claude doctor
# read-only diagnostics: install health, settings validation,
# and the result of the most recent update attempt
Run this where the work will run. Your laptop, a CI runner and a teammate's machine can sit on three different versions.
Gotcha: channels and package managers. Native installs update themselves in the background. Homebrew, WinGet, apt, dnf and apk installs do not by default. The
autoUpdatesChannelsetting can be"latest"(the default) or"stable", which is typically about a week behind. A feature can be in the changelog and still not be on your machine.claude updatepulls the newest build for your channel.
2. The documentation index
The docs publish a machine-readable index of every page. Use it to find out whether a feature still exists under the name you remember.
# List every docs page that mentions routines
curl -s https://code.claude.com/docs/llms.txt | grep -i routine
If there is no hit, that tells you something. The feature may have been renamed, folded into something else, or never existed outside a blog post. Open the page the index points to and look for two things:
- A status label near the top: "research preview", "beta", "experimental".
- Requirements: minimum version, plan, login type, operating system.
3. The changelog
The changelog is listed in the index and is generated from CHANGELOG.md in the anthropics/claude-code GitHub repository. Search it for the feature name to see when it arrived and whether it has been changed, renamed or removed since.
Renames really happen. claude project purge became claude purge. The old name still works and prints a notice, which is harmless interactively and noise in a script that parses output. The docs also publish a "What's new" weekly digest, which is a faster read when you only want the headlines.
Gotcha: compare versions as numbers.
2.1.99is older than2.1.225. Compare each segment numerically. Do not compare them as strings.
Three labels
After the check, give the capability exactly one label.
| Label | Meaning | What you do |
|---|---|---|
| Stable | Documented with no preview or beta label, and your installed version, plan and provider meet the stated requirements | Build on it, and re-check when you upgrade |
| Preview | The docs call it research preview, beta or experimental | Use it with a fallback and a re-check date |
| Unconfirmed | You can't find it in the current docs, or you haven't verified it on your version, plan or provider | Don't put it in an unattended path yet |
"Unconfirmed" is the label people skip. It covers everything you only know from memory, a conference talk, a social post, or this course.
Don't confuse the stable release channel with a stable feature. The channel gives you an older, steadier build. A preview feature in that build is still a preview.
Worked example: one check, start to finish
Say you want a cloud routine that reacts to pull requests, and you want to attach the GitHub trigger from the CLI.
- Version.
claude --versionon the machine you'll use prints2.1.295. - Index. The grep above finds a routines page. Open it.
- Feature page. A note at the top says routines are in research preview and that behaviour, limits and the API surface may change. Adding a GitHub trigger from the CLI needs v2.1.225 or later. The
/schedulecommand needs a claude.ai subscription login, so it won't appear if you are authenticated with a Console API key or through a cloud provider. The HTTP endpoint for API triggers ships behind a dated beta header. - Changelog. Search it for "routine" to see recent behaviour changes.
The label is preview. You are allowed to use it. You are not allowed to forget that it's a preview. Write the finding down next to the automation:
# docs/automation-notes.md
feature: routines, GitHub trigger added from the CLI
status: preview # docs label: research preview
min_version: 2.1.225
requires: claude.ai subscription login; Claude GitHub App on the repo
checked: 2026-10-09, installed 2.1.295
recheck: on every upgrade, and monthly
fallback: run the review by hand if the trigger stops firing
Labels also move. Auto mode arrived as a research preview in March 2026. From v2.1.283 it is the starting permission mode for interactive terminal and VS Code sessions. A label is a snapshot, so it carries a date.
How this course uses the habit
Every later lesson names its features and says what was preview at the time of writing. Treat those statements as leads, and run the three-source check before you rely on any of them.
Key takeaways
- This course is independent of Anthropic, is not endorsed by it, and reproduces none of its course or documentation text.
- The sources of truth are the current documentation and your installed version. A lesson, a post or your memory is not.
- Check in this order:
claude --versionon the machine that will run the work, then the documentation index, then the feature page, then the changelog. - Note the minimum version, plan, login type and platform, and compare version numbers numerically.
- Label each capability stable, preview or unconfirmed, with a date, before you build an unattended workflow on it.
- Preview features are usable with a fallback and a re-check date. Unconfirmed ones stay out of unattended paths.