anthropic-sdk-go: the Go client for the Claude API and its OpenTelemetry behaviour

One client, typed resources, and a large generated surface

The Claude SDK for Go provides access to the Claude API from Go applications, and the package is installed under the name github.com/anthropics/anthropic-sdk-go. The import comment in the README is explicit that the package is imported as anthropic, which is what lets the examples refer to anthropic.NewClient and anthropic.MessageNewParams rather than a longer path.

The architecture is the familiar generated-client shape. A root client holds the configuration, and resources hang off it, most visibly client.Messages.New, which is the entry point for the Messages API. Request parameters are structs (anthropic.MessageNewParams) and content is built with helpers such as anthropic.NewUserMessage and anthropic.NewTextBlock, so the wire format is expressed in types rather than in a map of strings.

What is unusual is the sheer size of the surface. The repository root lists a long run of files prefixed with beta, including betaagent.go, betamessage.go, betamemorystore.go, betadeployment.go, betadream.go, betafile.go and a long betaorganizationanalytics chain, each with a matching test file. A separate api.md sits next to aliases.go, and there are aws/, bedrock/ and examples/ directories alongside the root packages. In other words, the stable Messages client is a minority of the tree, and the beta resources are where most of the surface area lives. The presence of release-please manifest files, a CHANGELOG.md and a .stats.yml points to a pipeline that regenerates and publishes the client repeatedly.

Your first call, and where the API key comes from

The getting-started example is small enough to read in one pass, and it shows the two decisions every caller makes: which client configuration to use, and which model to ask for.

client := anthropic.NewClient(
	option.WithAPIKey("my-anthropic-api-key"), // defaults to os.LookupEnv("ANTHROPIC_API_KEY")
)
message, err := client.Messages.New(context.TODO(), anthropic.MessageNewParams{
	MaxTokens: 1024,
	Messages: []anthropic.MessageParam{
		anthropic.NewUserMessage(anthropic.NewTextBlock("What is a quaternion?")),
	},
	Model: anthropic.ModelClaudeOpus5_5,
})

The comment on the API key line is the useful part. option.WithAPIKey sets the key explicitly, and the note says the default is os.LookupEnv("ANTHROPIC_API_KEY"), so a production service can rely on the environment variable and leave the option off entirely. The inline string in the example is a placeholder to replace.

Two details in the parameters are worth noting. MaxTokens is set explicitly at 1024, so a call does not rely on a default, and the model is a named constant, anthropic.ModelClaudeOpus5_5, rather than a string, which means a model rename shows up as a compile error instead of a runtime rejection. The examples directory also contains a config-file-auth example, so an alternative credential source beyond the environment variable is covered somewhere in the samples.

Requirements are Go 1.24 or newer, and go.mod pins a toolchain of go1.25.8 alongside a module line of go 1.24.

OpenTelemetry spans that stay empty unless you ask

The tracing section is the most carefully specified part of the README, and its default behaviour is the important detail. The SDK reports each API call as an OpenTelemetry span when your application has registered a tracer provider, and no client option is needed for that. The spans carry no content of requests or responses unless you set option.WithOpenTelemetryTracesContentMode(option.OpenTelemetryContentModeContent) or the environment variable ANTHROPIC_OPEN_TELEMETRY_TRACES_CONTENT_MODE=content.

So the safe default is a span with timing and attributes but no prompt text and no completion text. That is a deliberate choice, because span payloads routinely end up in a tracing backend that other teams can query, and an opt-in content mode is easier to defend than an opt-out one.

The limits are spelled out. A span holds at most 750,000 bytes of content, and it carries anthropic.content.truncated when content was cut or left out to fit. You can set a different ceiling with option.WithOpenTelemetryTracesMaxContentBytes(n) or ANTHROPIC_OPEN_TELEMETRY_TRACES_MAX_CONTENT_BYTES=n.

Propagation has a similar shape. Each request carries the trace context of its span in the headers of your registered propagator, and option.WithOpenTelemetryPropagation(false) or ANTHROPIC_OPEN_TELEMETRY_PROPAGATION=false leaves them out, for an application whose HTTP client instrumentation already sends them. The client options are WithTracerProvider, WithOpenTelemetryPropagation, WithoutOpenTelemetry, WithOpenTelemetryTraces, WithOpenTelemetryTracesContentMode and WithOpenTelemetryTracesMaxContentBytes, and since Go has one request option type, a method call accepts them too, in which case they apply to that call only. That last detail is the useful one for a mixed codebase: a per-call override is available without rebuilding the client.

Deployment backends: Bedrock, Foundry, Google Cloud and agents

The examples directory is the best evidence for how widely this SDK is meant to be used, and it is not a list of one-off snippets. The named examples include bedrock/, bedrock-streaming/ and bedrock-bearer-token/ for Amazon Bedrock, foundry/ and googlecloud/ for the other hosted routes, plus agents/, agents-with-files/, agents-comprehensive/ and a set of managed-agents examples covering self-hosted sandbox workers, worker dispatch, streaming deltas and observing tool calls.

There is a mcp-tool-runner/ example and a message-mcp-streaming/ example, and go.mod depends on github.com/modelcontextprotocol/go-sdk, so tool integration through the Model Context Protocol is a first-class concern rather than an afterthought. The remaining examples cover the features teams actually reach for: message/ and message-streaming/, multimodal/, file-upload/, structured-outputs-raw/, refusal-fallback/ and message-output-config/.

The go.mod dependency list also shows the credentials paths in use. The AWS SDK v2 packages and smithy-go are there for the Bedrock route, google.golang.org/api for the Google Cloud route, golang.org/x/oauth2 for OAuth based flows, and github.com/standard-webhooks/standard-webhooks/libraries for webhook verification. The presence of a raw HTTP recorder, github.com/dnaeon/go-vcr, in the require list is a sign that the SDK's own test suite replays recorded traffic, which is what lets the team test the client without calling the live API.

The repository also carries a SECURITY.md and a REVIEW.md, alongside CONTRIBUTING.md and a .devcontainer/ directory for local development.

The beta prefix is where the risk sits

Naming is the first signal of stability in this tree, and there is a lot of beta in it. Files such as betaagent.go, betamemorystore.go, betadeployment.go and betaorganizationanalytics.go, each with a test file, are generated alongside the root packages. Beta resources in an SDK normally mean the shape may still change, and the naming here covers agents, deployments, files, memory stores, dreams and organization analytics, which is a wide surface to treat as provisional.

The api.md file at the repository root and aliases.go next to it are the pieces to read before committing to a resource. Because the tree is generated and regenerated, the practical risk is not that a call breaks silently but that a struct field or a resource path is renamed in a release, and your code needs an update. The versioning is managed by release-please, with a.release-please-manifest.json at the root, so versions are tied to conventional commits and the CHANGELOG.md is the record of what changed between them.

The release cadence itself is worth noting. The three most recent releases listed are v1.81.0 on 2026-10-14, v1.80.0 on 2026-10-09 and v1.79.1 on 2026-10-08, and the last push was on 2026-10-15. At that rate, depending on a specific minor version means depending on a moving target, and the cost of an upgrade is proportional to how much of the beta surface your code touches.

Where this SDK stops, and the MCP Go SDK beside it

The honest limit on this package is that it is a client, not a platform. It covers the Claude API surface, and the README points to the full documentation at platform.claude.com/docs/en/api/sdks/go rather than duplicating it. There is no retry policy, rate limit handling, prompt caching strategy or cost accounting described anywhere in the README, and no mention of a mock or fake client for tests. The dependency on go-vcr in go.mod suggests the project itself takes that approach, but the README does not present it as a supported feature of the SDK, so do not plan on it.

The comparison that actually exists in this repository is with the Model Context Protocol SDK. go.mod requires github.com/modelcontextprotocol/go-sdk v1.3.1, and the examples include a dedicated mcp-tool-runner/ project. The difference in approach is concrete. The Anthropic SDK is a typed client for one provider's HTTP API, and it is the thing that carries a model, a message list and a completion back to your program. The MCP SDK is for exposing and consuming tools over a protocol, and it is the thing that lets a model call into your code. If your workload is tool calling, the MCP example is the one to read, and the Anthropic SDK becomes the transport underneath it rather than the design centre.

The other alternative is to skip the SDK and call the API over HTTP yourself, for example with Go's net/http. You would keep the dependency count at zero and control every byte on the wire, and you would take on retries, error shapes, streaming parsing and type definitions that the generated client already maintains for you. The generated surface is the reason to stay, and the beta prefix is the reason to look closely before you do.

Editorial conclusion

Adopt anthropic-sdk-go when your Go service calls the Claude API and you want typed request and response structs, a single client with option-based configuration, and OpenTelemetry spans that stay free of prompt and completion content unless you deliberately turn content mode on. Do not adopt it if you need a stable surface outside the beta namespaces, since the repository carries a large set of beta-prefixed resources and an api.md file, and it moves with a release-please managed changelog. Verify first that your Go toolchain is 1.24 or newer, that ANTHROPIC_API_KEY is set in the environment rather than hardcoded, and that your tracing pipeline is ready for the span attributes and the 750,000 byte content cap described in the README before you switch content mode to content.

Frequently asked questions

Official sources

1. anthropics/anthropic-sdk-go on GitHub
2. Issues
3. License: MIT
4. README
5. Releases