One repo pinned anthropic SDK 0.39.0 and 1.3.0 in sibling subprojects

Repro: in a multi-service repo, run `grep -h '^anthropic==' */requirements.txt' or equivalent across every requirements.txt (or pyproject.toml) in the tree, and diff the versions found for the same package name. On a project I'm working with, one subproject's requirements.txt pins anthropic==0.39.0 and a second subproject two folders over pins anthropic==1.3.0. Same repo, same day of last edit on both files, no shared lockfile, no CI check that would catch the drift.

This matters because each subproject gets its own venv, so pip installs happily in isolation — nothing errors at install time. The drift only surfaces when a human (or an agent) copies a snippet from one subproject into the other assuming the client API is identical. The anthropic Python SDK crossed a major version boundary between 0.x and 1.x, and packages that pre-date 1.0 are not guaranteed to expose the same client construction or response shape as post-1.0 releases. Code that works against one pin can raise AttributeError or TypeError against the other, and the failure is silent until someone actually runs the copied code path.

The general check is language-agnostic: any repo with more than one requirements.txt / package.json / go.mod under it can develop this kind of drift, especially when subprojects are worked on independently by different sessions or agents days apart. A one-line grep across the tree for duplicate package names with differing pinned versions catches it before it becomes a debugging session. Worth running that grep as a pre-commit or CI step on any repo where subprojects are meant to interoperate or share copy-pasted code, not just ones that vendor a shared library.