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

@ai-sdk/zai releases 3.0.38 patch, only synchronizing three upstream dependency packages.
The Z.ai provider adapter package @ai-sdk/zai in the AI SDK ecosystem has released patch version 3.0.38, automatically committed by GitHub Actions with a verified signature. The only change: synchronously upgrading three underlying dependencies—@ai-sdk/provider 4.0.32, @ai-sdk/openai-compatible 3.0.76, and @ai-sdk/provider-utils 5.0.66. The article notes that the Z.ai adapter is built on openai-compatible, and its behavioral ceiling is determined by upstream provider and provider-utils, so downstream must follow upstream iterations. For direct users, this is a smoothly upgradeable patch release with no breaking API changes; it's recommended to verify the lockfile, confirm version alignment, and run provider integration tests. The release notes do not disclose specific code changes.

The Z.ai provider package in the AI SDK ecosystem has received a patch release. @ai-sdk/zai@3.0.38 was automatically published by GitHub Actions, with a single core change: synchronously upgrading three underlying dependency packages.
What Changed in This Update
According to the release notes, 3.0.38 is a Patch Changes release, committed by the github-actions bot on October 22 at 18:58 with a GitHub-verified signature. The specific updates are:
@ai-sdk/provider@4.0.32@ai-sdk/openai-compatible@3.0.76@ai-sdk/provider-utils@5.0.66
These three packages respectively handle the AI SDK's provider abstraction layer, OpenAI compatibility layer, and provider utility functions. Their version upgrades propagate down to the Z.ai adapter, making this a typical dependency-sync release.
The AI SDK monorepo uses a layered package design: @ai-sdk/provider defines the unified interfaces that provider adapters must implement (such as LanguageModelV1, EmbeddingModelV1, and other types), @ai-sdk/provider-utils provides shared utility functions and streaming response parsing helpers used across adapters, and @ai-sdk/openai-compatible wraps OpenAI's Chat Completions / Embeddings protocol into reusable factories, so that any service compatible with the OpenAI interface can be integrated with minimal configuration. The three packages form a strict dependency chain: adapters depend on openai-compatible, which in turn depends on provider and provider-utils. Therefore, any type or behavior adjustment in an upstream package requires downstream adapters to follow up in their version declarations—which is why this patch only changes dependency version numbers.
What Dependency Sync Means
@ai-sdk/zai is not a standalone SDK but a provider adapter layer built on top of @ai-sdk/openai-compatible. Its behavioral ceiling is largely determined by the upstream provider and provider-utils. When upstream releases utility function fixes or type adjustments, downstream adapters need to follow the upgrade, otherwise runtime behavior inconsistencies can occur.
Looking at the version numbers, provider-utils has reached 5.0.66 and openai-compatible has reached 3.0.76. This kind of high-frequency minor version iteration is quite common in the AI SDK monorepo, often corresponding to type definition tweaks, edge case fixes, or internal refactoring.
In semantic versioning (SemVer), major version changes represent incompatible API changes, minor versions represent backward-compatible new features, and patch numbers represent only backward-compatible bug fixes. The high-frequency patch releases in the AI SDK ecosystem typically correspond to type definition tweaks, edge case fixes, or internal refactoring rather than user-facing interface changes. However, it's worth noting that SemVer's "compatibility" promise only constrains public APIs; if a downstream adapter relies on upstream non-public exports or specific implementation details, patch upgrades can still cause compilation or runtime differences. This is also why the article recommends running integration tests after upgrading and verifying the lockfile—the lockfile clearly records each package version actually resolved, avoiding unexpected combinations caused by transitive dependencies being hoisted or deduplicated.
Practical Impact on Users
For projects that directly depend on @ai-sdk/zai, this is a patch release that can be smoothly upgraded without breaking changes to public APIs. Recommended steps:
- Check the lockfile to confirm whether the three upstream dependencies have been updated together;
- If the project also directly references
@ai-sdk/provider-utils, confirm version alignment; - After upgrading, run the existing provider integration tests, with emphasis on streaming responses and tool calling paths.
It should be noted that the release notes do not disclose the specific code changes, only the dependency version numbers. For production environments, if the current version is running stably, there's no need to rush to follow up; if you're investigating behavioral differences at the provider layer, this synchronized upgrade is worth including in your comparison scope.
Observations on Version Strategy
The Z.ai adapter follows the overall semantic versioning cadence of the AI SDK: patch number increments correspond to dependency refreshes and internal fixes, while minor version numbers correspond to new capability integration. This strategy allows downstream to confidently auto-upgrade by patch number, but it also means that individual patch releases carry low information density—real functional changes often only become visible at minor versions. For long-term maintained projects, watching the upstream provider-utils changelog is more valuable than tracking every adapter patch.
Information in this article comes from the GitHub Releases page; dependency version numbers and release times are subject to the release notes.
One-line Summary
@ai-sdk/zai releases 3.0.38 patch version, only synchronizing three upstream dependency packages.
Paragraph Summary
The Z.ai provider adapter package @ai-sdk/zai in the AI SDK ecosystem has released patch version 3.0.38, automatically committed by GitHub Actions with a verified signature. The only change: synchronously upgrading three underlying dependencies—@ai-sdk/provider 4.0.32, @ai-sdk/openai-compatible 3.0.76, and @ai-sdk/provider-utils 5.0.66. The article notes that the Z.ai adapter is built on openai-compatible, and its behavioral ceiling is determined by upstream provider and provider-utils, so downstream must follow upstream iterations. For direct users, this is a smoothly upgradeable patch release with no breaking API changes; it's recommended to verify the lockfile, confirm version alignment, and run provider integration tests. The release notes do not disclose specific code changes.
Related articles

Free Unlimited Claude Code Solution: Agnes AI + CC Switch Setup Guide
No paid subscription needed — pair the free AI platform Agnes AI with the open-source tool CC Switch to provide a backend for Claude Code, enabling unlimited free calls to text, image, and video models. This guide covers the full setup, test results, and usage boundaries.

A Complete Zero-Cost Guide to Getting Started with Claude Code for Beginners in China
A beginner's guide to Claude Code for users in China: two installation methods (command line and IDE plugin), full configuration steps for replacing the official API with the free domestic LongCat model, and a hands-on demo of building a small tool with natural language, plus tips.

When the NSA Gets Involved: The AI Supply Chain Crisis Behind Open-Source CVEs and API Key Hijacking
Multiple open-source projects disclosed severe CVEs in one day, PHP flaws alarmed the FBI, and Railway and OpenCode were breached with API keys stolen. This article breaks down the vulnerability window, AI-accelerated exploitation, and the AI supply chain crisis behind the API key black market, with a developer defense checklist.