AI SDK 3.0.19 Released: Credential Resolution and WebSocket Config Go Async

The AI SDK's @ai-sdk/topaz package has released version 3.0.19. It's delivered as a patch update, but two of its changes have a real impact on how developers handle authentication and real-time connections.

Credential Configuration Now Supports Promises and Callbacks

The most significant change in this release comes from commit 7716e18: provider API key and token settings now support Promises as well as synchronous or asynchronous callback functions.

Previously, credentials were typically read and serialized synchronously at initialization time, which made it hard for developers to host keys in asynchronously fetched sources—such as a remote key management service or temporary credentials only available at runtime. The new version allows credentials to be resolved each time an authenticated request is made, rather than being fixed once at construction time.

The official notes emphasize that this change resolves credentials per request "while preserving existing authentication behavior and synchronous credential serialization capabilities." In other words, the synchronous approach still works; the asynchronous approach is a new capability rather than a breaking replacement. For applications that need multi-tenant isolation or dynamic key rotation, this reduces the need to wrap custom async key-fetching logic in the business layer.

Provider in the AI SDK is an abstraction layer that describes how to connect to a model service (such as OpenAI, Anthropic, or a self-hosted inference endpoint): it encapsulates the base URL, auth headers, request serialization, and similar logic, with a unified interface defined by the @ai-sdk/provider package. Each time you call methods like generateText or streamText, the SDK constructs the underlying HTTP request through the provider instance. This is precisely why the location of credential configuration (construction time vs. request time) directly determines whether keys can be fetched dynamically.

Credential serialization refers to the provider converting fields like API key and token into strings and storing them fixedly in the configuration object at initialization, with subsequent requests reusing that string. This approach has the advantage of predictable behavior and easy caching, but the drawback of being unable to express asynchronous scenarios where "the key isn't available yet." With the shift to per-request resolution, the provider re-evaluates credential configuration before each authenticated request, thereby supporting reads from asynchronous sources.

getServerWebSocketConfig() Can Now Return Asynchronously

Another change, aimed at an experimental feature, concerns OpenAI Live's getServerWebSocketConfig() method. This method can now resolve asynchronously, and the official guidance is that callers must first await its result before using the returned connection settings.

For projects already using Live-related capabilities, this is a point that requires active adaptation: if you previously used the return value directly as a synchronous object, you should switch to awaiting the promise after upgrading. Experimental APIs don't promise stability, but signature changes like this deserve a separate note in your upgrade checklist.

WebSocket is a protocol that provides full-duplex communication over a single TCP connection. Unlike HTTP's request-response model, once the connection is established, the server can proactively push data to the client. OpenAI's real-time voice/multimodal interface (the Realtime API) transmits audio and event streams over WebSocket, so the AI SDK needs to provide server-side configuration for establishing that connection, including the URL, auth headers, and subprotocols.

getServerWebSocketConfig() returns exactly this set of connection parameters. Making it asynchronously resolvable is typically done so that configuration can fetch short-lived tokens or signed URLs right before the connection is actually established—such credentials have short lifespans and can't be hard-coded statically at application startup. The cost is that callers must await, otherwise they get a Promise object instead of the configuration, and the connection will fail outright.

Dependencies Updated in Sync

This version ships with three dependency updates, corresponding to commits 5c247e9 and dcd2f8d, covering:

• @ai-sdk/provider-utils@5.0.72
• @ai-sdk/provider@4.0.35

Such coupled upgrades are typically used to align the behavior of the underlying provider abstraction and utility functions—especially since changes to credential resolution logic often require coordination from lower-level packages. When upgrading, it's advisable to verify the versions of both packages together to avoid inconsistencies between the provider layer and the utils layer.

Under Semantic Versioning (SemVer), the third digit incrementing in 3.0.19 indicates a patch release, which by convention should only contain backward-compatible bug fixes and introduce no breaking changes. But "API surface compatibility" doesn't equal "completely unchanged runtime behavior": the adjustment to credential resolution timing in this release is a behavioral change that could still affect code relying on the old timing.

@ai-sdk/provider and @ai-sdk/provider-utils are the foundational packages of the AI SDK ecosystem—the former defines provider interfaces and types, while the latter provides shared utilities for request construction, stream parsing, error handling, and more. Concrete provider packages at the upper layer (such as @ai-sdk/topaz) rely on their capabilities to implement authentication. When credential resolution logic moves from construction time to request time, the underlying utils often need to provide corresponding evaluation helper functions, which is why both packages need synchronized upgrades.

Upgrade Recommendations

Since this is a patch version, API surface changes are limited, but the change in credential resolution timing will affect code that makes assumptions about "when the key is read." If your authentication logic depends on construction-time reads, or if you've cached credentials via synchronous serialization, you should verify after upgrading that these paths still work as expected. Projects using OpenAI Live need to check whether call sites of getServerWebSocketConfig() have added await.

Overall, this update pushes credential and connection configuration handling one step further toward the asynchronous model, a direction consistent with current application needs for dynamic key management and real-time connections.