@ai-sdk/zai 3.0.36 Patch Release: Dependency Chain Upgraded in Sync

The Z.ai adapter package in the AI SDK ecosystem has released a new patch version. @ai-sdk/zai@3.0.36 introduces no new features itself; the changes are concentrated on synchronizing the dependency chain. For developers using the Vercel AI SDK to connect to Z.ai models, the value of this release lies in maintaining dependency consistency and passing through potential upstream fixes.

Patch Contents: Three Core Dependencies Upgraded in Sync

According to the release record on GitHub, this version contains only a set of patch changes, centered on updating three upstream packages: @ai-sdk/provider upgraded to 4.0.31, @ai-sdk/provider-utils upgraded to 5.0.64, and @ai-sdk/openai-compatible upgraded to 3.0.74. The release was completed automatically by github-actions, and the commit carries a GitHub verified signature, indicating the standard automated release process was followed.

Such "dependency-only" patches are common in the SDK ecosystem. They don't change the API surface, but they pass down fixes, type adjustments, and compatibility changes from the upstream provider and utility layers. If your project pins an older provider version, the actual runtime behavior after upgrading to 3.0.36 may be affected by changes in the upstream packages—so it's worth running your integration tests after upgrading.

A note on what patch version means under Semantic Versioning (SemVer): given a version number MAJOR.MINOR.PATCH, incrementing only the PATCH position indicates backward-compatible bug fixes—no new features, no changes to the public API surface, and no breakage for existing callers. This is the basis for the article's emphasis on "no API changes." However, in the npm ecosystem, a package's patch version may indirectly change behavior because its own dependencies are bumped. The "semantic promise" therefore mainly covers the package's own interface and does not guarantee the entire dependency tree is frozen. Understanding this helps assess risk: dependency-chain upgrade patches typically carry risk from upstream behavior drift, not from code changes in the package itself.

A note on GitHub Actions automated releases and signature verification: GitHub Actions is the platform's built-in CI/CD service. The release process is generally driven by tools like changesets, which generate the version number and changelog, after which the workflow triggers npm publish and tags the release. The "Verified" badge on a Git commit indicates the commit carries a GPG/SSH or GitHub-generated signature, confirming the commit came from the expected identity and the content has not been tampered with. For supply chain security, these two together show the release path is automated and auditable, reducing the risk of manual error and credential leakage.

What the Dependency Chain Structure Tells Us

From the dependencies updated here, we can see the layered design of the Z.ai adapter: provider provides the unified model interface abstraction, provider-utils carries common utilities such as request construction and streaming parsing, and openai-compatible indicates that Z.ai's integration reuses the OpenAI-compatible protocol layer. This structure means that when protocol-level corrections appear in the OpenAI-compatible layer, the Z.ai adapter benefits automatically through dependency upgrades without needing its own code changes.

For developers, this is also a reminder: when troubleshooting Z.ai adapter issues, besides looking at the @ai-sdk/zai code itself, pay attention to behavior changes in these three upstream packages. In particular, version jumps in provider-utils are often related to details like streaming responses and error handling.

A note on the layered architecture of the Vercel AI SDK: the ai core package provides unified APIs like generateText and streamText, @ai-sdk/provider defines model interface specifications such as LanguageModelV1 (the specification version), @ai-sdk/provider-utils provides request construction, streaming parsing, and error mapping utilities shared by all adapters, and @ai-sdk/openai-compatible is a generic adapter base for any service compatible with the OpenAI Chat Completions protocol. The Z.ai adapter is built on openai-compatible, meaning it mainly customizes baseURL, authentication headers, and a few parameter differences, while reusing the OpenAI specification for the protocol body. The benefit of this design is low maintenance cost; the trade-off is that when the OpenAI-compatible layer adjusts protocol details (such as tool call delta concatenation or the usage field), downstream adapters passively inherit these changes through dependency upgrades.

A note on the OpenAI-compatible protocol: it means the server implements the same request body, response structure, and SSE streaming chunk format as OpenAI's /v1/chat/completions and similar endpoints, so existing OpenAI SDKs can call it by simply swapping baseURL and API key. Many domestic model services (including Z.ai) offer compatible endpoints to lower migration costs. Note that the degree of "compatibility" varies—for example, support for extension fields like tools, response_format, and reasoning may not be complete, so check the specific service's compatibility documentation when troubleshooting.

Upgrade Recommendations

There's nothing special about the upgrade method; just follow your usual dependency management. Bump @ai-sdk/zai to 3.0.36 in package.json, or run the corresponding package manager update command, refreshing the lockfile along with the three upstream dependencies. If your project also directly depends on @ai-sdk/provider or @ai-sdk/provider-utils, make sure the versions align to 4.0.31 and 5.0.64, to avoid type mismatches caused by multiple versions of the same package coexisting.

In CI environments, it's recommended to keep a full type check and build. Patch versions are low risk, but problems with dependency upgrades often surface at the type level rather than at runtime—catching them early is more cost-effective than discovering them after deployment.

A note on lockfiles and "multiple versions of the same package coexisting": package-lock.json, pnpm-lock.yaml, and yarn.lock record the fully resolved dependency tree and exact versions, and are key to ensuring consistency between CI and local installs. After the lockfile is refreshed, if your project both directly depends on @ai-sdk/provider and depends on it indirectly through @ai-sdk/zai, the package manager may hoist to a single version satisfying all ranges; if the two ranges don't intersect, two copies will coexist. In that case, same-named types in TypeScript come from different paths, producing hard-to-diagnose errors like "Type X is not assignable to type X." Ways to avoid this include: explicitly aligning direct dependency versions, unifying versions in a monorepo using overrides/resolutions, or checking for duplicate instances with npm ls @ai-sdk/provider.

Credibility of the Release Information

This release comes from the automated process of the official GitHub repository, the commit has a verified signature, and the release tag and changelog are complete in structure. Some dynamically loaded content on the release notes page (tag filters, asset lists) showed loading errors during RSS scraping, but this is a page rendering issue and does not affect the completeness of the version content itself. For teams concerned about supply chain security, signature verification and an automated release process are themselves signals that can be factored into trust decisions.

One-line Summary

@ai-sdk/zai 3.0.36 is a pure patch version that only upgrades three upstream dependencies in sync.

Paragraph Summary

@ai-sdk/zai has released patch version 3.0.36 with no new features; the changes are concentrated on dependency chain synchronization: @ai-sdk/provider up to 4.0.31, @ai-sdk/provider-utils up to 5.0.64, and @ai-sdk/openai-compatible up to 3.0.74, released automatically by GitHub Actions with verified signatures. The article notes that such dependency-only updates don't change the API surface but do pass down fixes and type adjustments from the upstream provider and utility layers, potentially affecting actual runtime behavior. The dependency structure shows the Z.ai adapter reuses the OpenAI-compatible protocol layer, so upstream protocol fixes are inherited automatically. When upgrading, refresh the lockfile and confirm that directly depended-on provider package versions are aligned to avoid type mismatches from multiple versions coexisting; keeping type checks and builds in CI is recommended to surface issues early.