Every "getting started" guide, including ours, shows the unpinned install — pip install anthropic, npm install @anthropic-ai/sdk — because for a first experiment, latest is what you want. In a production repository the calculus flips: an install that resolves to "whatever was published this morning" means your build output depends on the calendar. The fix is two-layered: a version constraint in your manifest saying what you accept, and a lockfile recording exactly what you got.
What the official SDKs themselves suggest
It's telling that several of Anthropic's own SDK READMEs demonstrate pinned installs rather than bare ones:
| Language | Package | README install example |
|---|---|---|
| Python | anthropic (PyPI) | pip install anthropic (add your own pin + lockfile) |
| TypeScript | @anthropic-ai/sdk (npm) | npm install @anthropic-ai/sdk (package-lock.json records the exact version) |
| Java | com.anthropic:anthropic-java | README pins version 2.48.0 |
| Go | github.com/anthropics/anthropic-sdk-go | go get -u 'github.com/anthropics/anthropic-sdk-go@v1.56.0' |
| Ruby | anthropic (gem) | gem "anthropic", "~> 1.55.0" |
| PHP | anthropic-ai/sdk (Composer) | composer require "anthropic-ai/sdk:^0.36.0" |
| C# | Anthropic (NuGet) | dotnet add package Anthropic |
Two of those rows deserve a second look. Ruby's ~> 1.55.0 is a pessimistic constraint: it accepts patch releases (1.55.1) but not minor bumps — a reasonable default posture. PHP's ^0.36.0 is a pre-1.0 version, and under semantic-versioning conventions pre-1.0 minor releases are allowed to break things; treat a 0.x SDK as needing an exact pin and eyes on every release note.
Semantic versioning, decoded for this decision
Semantic versioning (semver) encodes intent in three numbers: major.minor.patch. Patch releases fix bugs; minor releases add features compatibly (new API parameters and endpoints arriving in the SDK, typically); major releases may break your code. A pragmatic policy for Claude SDKs: allow patch updates automatically, take minor updates on a short review cycle (they're often how you get access to newly shipped API features), and schedule major updates as small projects — that last case has its own article. Whatever range you allow in the manifest, commit the lockfile; it's what makes CI, your teammate's laptop, and production bit-for-bit identical, and it's what your container builds should install from.
Automating updates with Dependabot
Pinning without automation just means falling behind deliberately. Dependabot, GitHub's built-in dependency-update service (Renovate is the popular alternative and works on GitLab too), inverts the workflow: instead of a human remembering to check for releases, the bot opens a pull request when a new SDK version ships, with the version diff and release notes attached. Configure it per ecosystem (pip, npm, gomod, bundler, composer, nuget), on a weekly schedule, and let your normal CI decide the PR's fate.
That last clause is the load-bearing one. An auto-update PR is only as safe as the tests that gate it — which is why the mocked test layers from the pytest article and the Jest article matter beyond correctness: they're what lets you merge a Tuesday-morning SDK patch bump with confidence and no token spend. Teams that also run a small live integration suite on a schedule get a second net: if an SDK update interacts badly with the real API, the nightly run catches it while the change is still one PR deep.
anthropic==X.Y.Z does not pin model behavior — the model string in your requests does that, and per Anthropic's models documentation every current Claude model ID is a pinned snapshot. The two upgrade cycles are independent: track SDK releases on GitHub and model lifecycle on platform.claude.com. See tracking SDK changelogs.Where to go next
When an update PR carries a major version, switch to the migration checklist. For the full list of official SDKs and their repositories, see which languages have official SDKs.