anthropics/anthropic-sdk-typescript: one package, three release lines, and a browser switch

Three packages, one repository, three different tag formats

The most surprising thing in this repository is that the version numbering is not one sequence. Three release lines publish from it: sdk-v0.129.0, vertex-sdk-v0.20.0 and google-cloud-sdk-v0.0.15, and the last push and the latest push are within seconds of each other, which means all three are cut together. Each has its own version line and its own starting point, with google-cloud-sdk still at 0.0.15 while the main SDK is at 0.129.0. The monorepo layout explains why: a pnpm-workspace.yaml, a packages directory, a build-all script, and separate TypeScript configurations for the build, the Deno target and the distribution source, including tsc-multi.json for a multi-target build. So this is one codebase compiled and published three ways, which is the right design if the three clients share a surface, and a maintenance decision that costs real effort on every change. The practical consequence for you is a version constraint. Depending on @anthropic-ai/sdk with a caret range against 0.x semantics will behave differently from depending on a 1.x package, and a project that pins across two of these clients has to track two independent numbers. Read the tag you are pinning, not the repository's general version.

An install, a client, and one call

The whole getting-started path is short enough to reproduce. Install with npm install @anthropic-ai/sdk, construct a client with the API key from the environment, and call messages.create with a max_tokens, a message list and a model:

const message = await client.messages.create({
  max_tokens: 1024,
  messages: [{ role: 'user', content: 'Hello, Claude' }],
  model: 'claude-opus-5-5',
});

Note what the example does not do. There is no retry configuration, no timeout, no client wrapper, no pagination helper, no event stream. The API key is passed as apiKey and the comment says that is the default and can be omitted, which is a small design statement: the SDK reads the environment variable if you do not pass it. The request shape is flat and typed, which is what a generated client should look like, and the response is an object with a content array that you log. Everything the getting-started example omits is somewhere else in the repository: the examples directory contains streaming, raw streaming, streaming deltas handled manually, thinking streams, fallbacks, cancellation, count-tokens, middleware, MCP, batch results, structured outputs in five flavours, and a set of managed-agents examples covering worker dispatch, sandbox workers, tool-call observation and self-hosted workers. That list is the real feature surface, and it is considerably wider than the three-line quickstart suggests. Read the examples directory as the documentation index, because the README does not describe any of it.

Browser use is off unless you name the danger yourself

The runtime list is where this SDK is more opinionated than most. Supported are TypeScript 5.0 and later, Node.js 20 LTS or later, Deno from 1.28.0, Bun from 1.0, Cloudflare Workers, the Vercel Edge Runtime, Nitro from 2.6, and Jest 28 or later provided you use the node environment. Then the restrictions. Browser use is disabled by default, and the stated reason is to avoid exposing secret API credentials, with a link to key-handling guidance; you enable it by explicitly setting dangerouslyAllowBrowser to true. Jest with jsdom is not supported. React Native is not supported. That is one coherent position rather than three separate omissions. An API key in a browser bundle is a key that anyone can extract from your page, so refusing to run there by default is the correct default, and naming the escape hatch after what it actually is is honest naming. The consequence is architectural, though, and it is the part worth planning for. If your application has a client half that calls the model directly, this SDK will not help you; you need a server component that holds the key and proxies requests, and the browser half talks to that instead. The SDK supports the server half, so the work is a server you were going to write anyway.

Two dependencies, one optional peer, and a type-focused toolchain

The dependency surface is unusually small and that is worth reading closely. Two runtime dependencies: standardwebhooks, which is for verifying webhook signatures, and json-schema-to-ts, which is for turning a JSON schema into TypeScript types at build time. One optional peer dependency, zod at 3.25 or later or 4, marked optional in peerDependenciesMeta, which is how you get schema-validated request and response types without forcing a validation library on projects that do not want one. Everything else is development tooling: nock for HTTP interception in tests, fast-check with vitest for property-based testing, arethetypeswrong for checking that the published types resolve correctly in a consumer's setup, valibot used to compare against zod for schema conversion, iconv-lite, and the TypeScript ESLint pair pinned to an exact version. The arethetypeswrong dependency is the interesting one, because it means the maintainers check that the type definitions they ship actually work when consumed, which is a class of bug that most SDKs discover only through user reports. Tests run on vitest with a .mts config, and there is a separate ecosystem-tests script that runs its own CLI, which is how you check the package against real runtime environments rather than mocks.

The publish path deliberately fails on a normal npm publish

There is a detail in the scripts that tells you how seriously this repository treats its release process. The prepublishOnly script echoes a message telling you to run the build and then publish from the dist directory, and then exits 1, which means an accidental pnpm publish fails on purpose rather than shipping whatever happens to be in the working tree. The publishConfig sets the package to public access and names dist as the directory, so the published artefact is a build output rather than the source tree. The prepare script is also conditional: it checks whether the install is a git install, and only then builds and swaps files, so installing straight from a git URL gives you a working package while installing from the registry does not rebuild anything. Release management runs through release-please, with a release-please-config.json and a manifest, and there is a CHANGELOG.md, a MIGRATION.md and a SECURITY.md in the root. The presence of MIGRATION.md alongside a 0.x version line is the clearest signal of how fast this surface changes, and it is where you should look before a major upgrade rather than after one.

What this repository is for, and what it is not

The scope is stated in one sentence: access to the Claude API from server-side TypeScript or JavaScript applications. It is a generated-style client, not a framework, and there is no agent runtime, no tool-calling loop and no orchestration in here. The examples directory includes agents and mcp files, which is worth pausing on, because the presence of an agents example next to a thin HTTP client invites the assumption that the SDK runs agents. It does not; those examples are request shapes against an API surface that has agent features. The distinction matters for anyone arriving from a framework, and it is the single most common misreading this repository invites. Two other boundaries. The documentation lives off-repository at platform.claude.com, and the repository carries api.md, helpers.md, CLAUDE.md and a stats file, which suggests generated and internal content alongside the source. And the compatibility promise is bounded by what the API accepts, not by the SDK, so an API change reaches you as a change in generated types. The right way to treat this package is as a thin, well-typed, frequently regenerated edge, and to keep whatever logic you own on your side of it rather than in the request path.

Editorial conclusion

Adopt this SDK if you are calling the Claude API from server-side TypeScript and want the official surface, because the install is one package, the two runtime dependencies are narrow, and zod is an optional peer rather than a forced one. Do not adopt it expecting a client that works everywhere, since browser use is disabled unless you set dangerouslyAllowBrowser to true, jsdom is unsupported under Jest, and React Native is excluded. Verify two things first. Pin the version you test against, because the repository publishes three release lines at once, sdk, vertex-sdk and google-cloud-sdk, and the tags read sdk-v0.129.0 rather than v0.129.0, so a naive version constraint will not match. And note the API key is sent from your process by default, which is exactly the exposure that the browser default is protecting; anything client-side needs a proxy of your own. If the numbers matter to you, the repository ships an examples directory with a count-tokens example and a cancellation example that both talk to the API before you commit to a design.

Frequently asked questions

Official sources

1. anthropics/anthropic-sdk-typescript on GitHub
2. License: MIT
3. Project website
4. README
5. Releases