Anthropic SDK v1.15.0 Update: Messages API Adds Speed Parameter

Anthropic has released version v1.15.0 of its official SDK. This is a relatively small update, but a few API-level changes are worth developers' attention.

Core Change: Messages API Introduces the speed Parameter

The most notable update this time is that the Messages API now supports a speed parameter, along with a new usage.speed field in the response body. This means developers can directly control the model's output speed mode at the request level, without relying on extra configuration or workarounds.

According to the SDK documentation, some models require a beta header to enable the speed feature, which is something to pay special attention to during integration. The SDK already adapts to different model capabilities, and developers can use the between_tools field in thinking types to determine whether a model supports this capability.

This design approach follows Anthropic's usual practice for declaring model capabilities—exposing supported features in the API's capabilities description so clients can adapt dynamically rather than relying on hardcoded logic.

About the beta header: Anthropic's API has long used a beta header mechanism (in the form anthropic-beta: xxx-2024-xx-xx) to release features that aren't yet stable. The reason not all models directly support speed is that this capability requires adjusting scheduling strategies on the inference side, and only some newer model versions have it. When sending a request, the client must explicitly declare the corresponding beta identifier in the HTTP header for the server to parse the speed field; otherwise the parameter will be ignored or will trigger an error. Anthropic typically promotes beta capabilities to general availability once they stabilize, at which point the header declaration can be removed. Before using it, it's advisable to first check via the model capabilities interface whether the target model natively supports it.

About usage.speed and capabilities detection: The usage field in the Messages API has always been used to return token statistics for the current call (such as input_tokens and output_tokens). The newly added usage.speed echoes the speed mode actually adopted by the server, making it easier to distinguish calls at different speed tiers in logs or billing systems. As for the between_tools field in capabilities, it refers to whether the model supports interleaving thinking processes between multiple tool calls during the thinking (chain-of-thought) phase. Exposing such fine-grained capabilities in capabilities allows clients to dynamically decide at runtime whether to enable related parameters, avoiding call failures on different models caused by hardcoded logic.

Organization-Level Spend Limit: Read-Only spend limit

Another API-level change is that the Console organization's usage-tier spending cap is now returned as a read-only spend limit.

The practical significance of this change is that developers can read the current organization's spending limit information directly through the API, without logging into the Console to check manually. For teams that need cost monitoring and automated alerts, this saves considerable hassle. However, it's currently a read-only attribute—the limit cannot be modified through the API.

About usage-tier and spend limit: The usage-tier in the Console refers to the tier an organization is placed in based on cumulative spending, with different tiers corresponding to different rate limits and feature permissions. The spend limit is the spending cap set for an organization or workspace; once the threshold is reached, API calls are rejected to prevent unexpected bill overruns. Previously, these values could only be viewed in the Console UI, making it difficult to retrieve them programmatically. Now that they're returned read-only through the API, teams can periodically pull limits and current usage into their monitoring systems and set up alert rules for early warning. Note that read-only means limits cannot be adjusted through the API—configuration still needs to be done in the Console.

Engineering and Documentation Improvements

Beyond the developer-facing API changes, this release also includes several internal improvements:

CI acceleration: The breaking change detection process has been sped up. For SDK projects that release frequently, the time cost of CI directly affects iteration pace.

Documentation additions: Headers documentation for Managed Agents and telemetry endpoints has been improved, and the script for formatting code blocks in the docs has been simplified. Documentation about the speed parameter requiring a beta header has also been added to the SDK docs.

Test coverage: New test cases have been added for OpenTelemetry options and method default timeouts. Test coverage for timeout behavior is critical to SDK stability, especially in production scenarios with complex network environments.

About OpenTelemetry and default timeout tests: OpenTelemetry is a vendor-neutral observability standard covering traces, metrics, and logs. With SDK support for OpenTelemetry, developers can feed information such as API call latency, retries, and errors into their existing observability pipelines for unified analysis alongside business flows. Method default timeouts determine how long a single request waits before giving up when there's no response—too short a timeout can kill slow requests by mistake, while too long a timeout lets failed requests tie up connections. Adding test cases for these two behaviors essentially solidifies what were previously implicit defaults into contracts that can be regression-verified, reducing the risk of hidden breakage from future refactoring.

Practical Impact for Developers

If your project is already using the Anthropic Messages API, this upgrade is essentially smooth—the new parameters are all optional, and there are no breaking changes.

What's really worth trying is the flexibility that the speed parameter brings. In latency-sensitive scenarios (such as real-time conversation or streaming output), being able to adjust the speed mode at request granularity is far more practical than a global configuration. It's advisable to first confirm whether the target model requires a beta header, then decide whether to add the corresponding branch to your capabilities detection logic.

The read-only exposure of spending limits is more suited to teams already doing cost management, who can plug it into their existing monitoring pipelines.

Overall, v1.15.0 is a routine release focused on API capability expansion and engineering polish, with no aggressive changes—but for developers who use the Messages API heavily, the small tweaks all deliver real value.

One-line Summary

Anthropic SDK v1.15.0 adds a speed parameter and read-only spending limits, with no breaking changes.

Paragraph Summary

Anthropic's official SDK has released v1.15.0, a routine iteration overall with no breaking changes. The core API change is that the Messages API now supports a speed parameter and adds a usage.speed field in responses, letting developers control the model's output speed mode at request granularity; some models require a beta header to enable it, and the thinking types capabilities now include a between_tools field for dynamic adaptation. Another change is that the Console organization's usage-tier spending cap is exposed through the API as a read-only spend limit, making cost monitoring and alerting easier—though it cannot currently be modified via the API. On the engineering side, CI breaking change detection is faster, Managed Agents and telemetry endpoint docs have been improved, and new tests cover OpenTelemetry options and default timeout behavior. Overall, it's worth trying for latency-sensitive scenarios and teams already doing cost management.