@ai-sdk/baseten@2.1.0
Minor Changes
-
11f00aa: Make the native performance client opt-in for embeddings.
@basetenlabs/performance-clientis no longer a dependency. It is a NAPI addon — 16 platform binary packages, ~5-16 MB installed — that could not load in edge runtimes and whose platform binaries bundlers could not resolve, and it was imported at module top level, so every consumer paid for it even though only embeddings use it.Embeddings now go over plain HTTP to the deployment's OpenAI-compatible endpoint, which is what Baseten Embeddings Inference serves with no additional settings. To keep the native client's client-side batching and request hedging, install it yourself and pass the constructor:
import { createBaseten } from "@ai-sdk/baseten"; import { PerformanceClient } from "@basetenlabs/performance-client"; const baseten = createBaseten({ modelURL, performanceClient: PerformanceClient, });
The default path now supports things the previous implementation silently dropped:
abortSignal, per-callheaders, thedimensionsanduserprovider options, and the provider'sfetchoption —createBaseten({ fetch })previously had no effect on embeddings. Response headers and warnings are now real rather than empty.usage.tokensnow comes fromprompt_tokensrather thantotal_tokens, matching theEmbeddingModelV4contract ("we only have input tokens for embeddings") and the other providers. The values are normally identical for embeddings.One behaviour change to be aware of: each request now sends at most 128 values.
embedManysplits and parallelises above that, so only a directdoEmbedcall with more than 128 values is affected — it throwsTooManyEmbeddingValuesForCallError. The opt-in native path is unchanged and still receives everything in one call.Separately, report token usage for streamed chat completions. The provider never set
includeUsage, sostream_options.include_usagewas omitted from requests and OpenAI-compatible servers returned no usage at all for streams —streamTextreportedinputTokens/outputTokens/totalTokensasundefinedwhilegenerateTexton the same model reported them correctly. This affected both the Model APIs and dedicated-deployment paths.Also parse the error envelope dedicated deployments return. Baseten sends two different shapes: the Model APIs send
erroras a bare string ({"error":"please check the model you provided"}), while a dedicated deployment passes through its server's OpenAI-shaped{"error":{"message":…,"code":…,"param":…,"type":…}}object. The schema only accepted the string, so the object failed to parse and the message degraded to the HTTP reason phrase — a realThe model \x` does not exist.surfaced asNot Found, or as the empty string over HTTP/2, which has no reason phrase. The schema now accepts both. This affects embeddings especially, since they require amodelURL` and so always talk to a dedicated deployment.
Patch Changes
- Updated dependencies [160ccdb]
- @ai-sdk/provider-utils@5.0.20
- @ai-sdk/openai-compatible@3.0.22