Gregor Martynus

feat: Realtime API support for browser<->provider websocket connection (#13893) ## Background Part of https://github.com/vercel/ai/issues/13897 Support for Realtime API has been requested for a long time. We want to support different architectures 1. Websocket connection from browser directly to provider 2. Websocket connection from browser through user's server to provider 3. Websocket connection from browser through gateway to provider 4. Websocket connection from browser through user's server and gateway to provider This pull requests implements the first, see [Architecture](#architecture) below ## Summary Alternative implementation of the Realtime API support proposed in #13889, with a reworked developer-facing API: - **`openai.experimental_realtime('gpt-realtime')`** works in both server and browser (no separate `@ai-sdk/openai/realtime` import needed) - **`openai.experimental_realtime.getToken()`** static method for server-side ephemeral token creation - **`experimental_useRealtime`** hook returns `messages: UIMessage[]` (aligned with `useChat` format) instead of `transcript` - **`inputAudioTranscription`** session config enables rendered user messages for transcribed microphone input - **`addToolOutput(callId, result)`** for client-side tools that need manual result submission - **`onToolCall`** callback for auto-executed client-side tools - Framework-agnostic helper type: `Experimental_RealtimeSetupResponse` Provider implementations included: **OpenAI**, **Google**, and **xAI**. ElevenLabs support is split into a stacked follow-up: **#15747**. <a name="architecture"></a> ## Architecture ```mermaid sequenceDiagram participant Browser participant Server participant Provider as AI Provider<br/>(OpenAI / xAI / Gemini / ...) Browser->>Server: POST /api/setup Server->>Provider: Request token (with tool definitions) Provider-->>Server: Short-lived auth token Server-->>Browser: { token } Browser->>Provider: Open WebSocket (using token) Provider-->>Browser: Audio/text chunks (streaming) Provider-->>Browser: Tool call request Browser->>Server: App-specific tool request (optional) Server-->>Browser: App-specific tool result Browser->>Provider: Send tool result via WebSocket Provider-->>Browser: Continue streaming ``` ### Alternatives considered #### Generic RPC route for server-side tools One option was for the SDK to expose a generic server-side tool execution flow: the realtime session would receive a tool call, POST `{ name, inputs, callId }` to an `execute-tools` route, execute a matching server-side tool, and send the result back to the provider automatically. We decided against that for the initial implementation. A generic RPC route is convenient, but it creates a security-sensitive application boundary: the app must authenticate the user, bind the request to a realtime session, allowlist tool names, validate call IDs, rate limit access, and authorize each tool invocation. If the SDK provides the generic route shape, it is easy to copy into production without those controls. Instead, the SDK keeps tool execution client-driven through `onToolCall` and `addToolOutput`. Server-backed tools should call app-specific API endpoints from `onToolCall` (for example `/api/weather`), where the application can apply its normal auth, validation, authorization, and rate limiting rules. Documentation should cover secure server-backed tool calling patterns, but the SDK should not own the generic remote tool RPC abstraction yet. ## Manual verification The realtime voice example added in this PR lives at `examples/ai-e2e-next/app/realtime/page.tsx` (UI) and `examples/ai-e2e-next/app/api/realtime/[...path]/route.ts` (server-side token endpoint). 1. Add the provider API key(s) for whichever provider(s) you want to test to `examples/ai-e2e-next/.env.local`: ```bash OPENAI_API_KEY=... # OpenAI realtime (gpt-realtime) GOOGLE_GENERATIVE_AI_API_KEY=... # Google realtime (gemini-3.1-flash-live-preview) XAI_API_KEY=... # xAI realtime (grok-voice-latest) ``` 2. Start the example: ```bash cd examples/ai-e2e-next pnpm dev ``` 3. Open http://localhost:3000/realtime, pick a provider + voice, and click **Connect**. Use the microphone or type a message. Ask "what's the weather in Paris?" or "roll a dice" to exercise client-side tool calling (`onToolCall`). ## Checklist - [x] Tests have been added / updated (for bug fixes / features) - [x] Documentation has been added / updated (for bug fixes / features) - [x] A _patch_ changeset for relevant packages has been added (for bug fixes / features - run `pnpm changeset` in the project root) - [ ] I have reviewed this pull request (self-review) - [ ] Security Audit - esp. securing remote tool calling - [ ] Update internal Architecture / how it works docs ### Future Work 1. **ElevenLabs** provider support — stacked follow-up in #15747 2. Websocket connection from browser through user's server to provider 3. Websocket connection from browser through gateway to provider 4. Websocket connection from browser through user's server and gateway to provider ## Related issues - #3176 - #3907 - #4082 - #5007 - #9559 - #12381 - #13706 - #13889 Co-authored-by: Cursor <cursoragent@cursor.com>

feat(video): externalize polling control and webhook support for generateVideo (#12515) - Adds optional `doStart`/`doStatus` methods to the experimental `VideoModelV4` spec, enabling a two-phase async model where the SDK core orchestrates polling or webhook-based completion instead of each provider implementing its own polling loop. - Adds `poll` and `webhook` parameters to `experimental_generateVideo` for user-controlled polling intervals/timeouts and webhook-based completion. - Adds optional `handleWebhookOption` to `VideoModelV4` so a provider can signal native webhook support. The SDK only invokes the user's webhook factory when the model implements it; otherwise it falls back to polling. - Replaces `doGenerate` with `doStart`/`doStatus` in the first-party models implementing `VideoModelV4` (FAL, Alibaba, KlingAI, Replicate, xAI, Google, and Google Vertex). The gateway video model remains a `doGenerate` passthrough. - Makes `doGenerate` optional on `VideoModelV4`. Third-party providers implementing only `doGenerate` continue to work unchanged, and the SDK falls back to it when no async flow is selected. - Constrains operation handles to `JSONValue`, making the provider-owned task reference serializable and suitable for future persistence and gateway support. Towards https://github.com/vercel/ai/issues/12381. ## Architecture ``` User calls: generateVideo({ model, prompt, poll?, webhook? }) ↓ Core function: Chooses flow based on model capabilities and user options ↓ ┌───────────┴───────────────┐ │ │ [Legacy / fallback] [Start/Status flow] │ (poll or webhook provided, │ or doGenerate missing) │ │ model.doGenerate(options) model.doStart(options) ↓ ↓ Provider owns polling returns { operation } ↓ ┌───────────┴────────────┐ │ │ [native webhook] [polling] │ │ await notification SDK core loop │ │ model.doStatus(op) model.doStatus(op) └───────────┬────────────┘ ↓ return result ``` The SDK core owns the polling lifecycle. Providers only implement single-shot `doStart` (submit) and `doStatus` (check once). The polling interval and timeout are controlled by the user. ## Review decisions - **`poll` and `webhook` are intentionally composable.** When a model supports native webhooks, `poll.timeoutMs` limits the webhook wait. When it does not, the same polling configuration controls the automatic fallback. This behavior is documented and covered by tests. ([discussion](https://github.com/vercel/ai/pull/12515#discussion_r2821429102)) - **The first iteration uses fixed polling intervals and timeouts.** Exponential backoff and `onAttempt` were removed to keep the API small; aligning polling with shared retry/backoff primitives can be revisited separately. ([discussion](https://github.com/vercel/ai/pull/12515#discussion_r2821435402)) - **Operation handles are JSON-serializable.** `operation` is typed as `JSONValue` instead of `unknown`, while remaining opaque to core. ([discussion](https://github.com/vercel/ai/pull/12515#discussion_r2843221880)) - **Shared cross-modality operation types are deferred.** The current types remain video-specific until another modality implements the same lifecycle, avoiding a premature provider-spec abstraction. ([discussion](https://github.com/vercel/ai/pull/12515#discussion_r2843151286)) - **Replicate's server-side `wait` remains provider-specific.** It affects how long Replicate holds the submission request open, while top-level `poll` controls the SDK's provider-neutral status lifecycle. It can be added through Replicate provider options independently if needed. ([discussion](https://github.com/vercel/ai/pull/12515#discussion_r2843203139)) ## Verification - [x] Tests added and updated - [x] Documentation added and updated - [x] Patch changeset added - [x] TypeScript, lint/format, and code consistency checks pass locally ## Future work - Expose async operations as a first-class API: start an operation, persist its handle, and resume or query it later. ([discussion](https://github.com/vercel/ai/pull/12515#discussion_r2843215786)) - Generalize operation types after another model modality implements the same lifecycle. - Add AI Gateway transport for the JSON-serializable start/status operation flow. - Explore a multi-notification webhook receiver if providers need intermediate status events rather than a single completion notification. ## Related issue https://github.com/vercel/ai/issues/12381 --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Co-authored-by: josh <144584931+dancer@users.noreply.github.com> Co-authored-by: vercel-ai-sdk[bot] <225926702+vercel-ai-sdk[bot]@users.noreply.github.com> Co-authored-by: mat lenhard <mclenhard@gmail.com> Co-authored-by: Rohan Taneja <47066511+R-Taneja@users.noreply.github.com> Co-authored-by: Felix Arntz <felix.arntz@vercel.com> Co-authored-by: Walter Korman <shaper@vercel.com> Co-authored-by: Nico Albanese <49612682+nicoalbanese@users.noreply.github.com> Co-authored-by: Cursor <cursoragent@cursor.com>

fix(providers): only send credentials to same-origin response-supplied URLs (#15989) ## Background Reported via the Anthropic CVD as **VULN-11567 (ANT-2026-FX163E39)**. Several provider clients follow a URL taken from the provider's API response — a polling/status URL or a final media URL (`polling_url`, `urls.get`, `result_url`, `result.sample`, `video.uri`) — and reuse the authenticated headers, or append `?key=<API_KEY>`, on that request. Because the host of the response-supplied URL is never validated, the long-lived API key is sent to whatever host the response names (a CDN in the benign case, or an attacker-chosen host if the provider is compromised or the response is tampered with), allowing credential exfiltration. A safe no-headers pattern already exists in `xai-image-model.ts`. ## Summary Adds an `isSameOrigin(url, baseUrl)` helper to `@ai-sdk/provider-utils` and gates every affected fetch so the provider credential is attached **only when the followed URL is same-origin with the provider's configured API origin**; a foreign origin gets the request without credentials. This single rule covers both cases correctly: - **Polling/status URLs** (need auth, normally same-origin) keep working. - **Media downloads** on a CDN (foreign origin) are fetched without the key. Google's video download legitimately needs the key, and its URI is same-origin, so it still works. ### Sites gated | Package | Site | Response field | | --- | --- | --- | | `@ai-sdk/black-forest-labs` | poll + image download | `polling_url`, `result.sample` | | `@ai-sdk/fireworks` | image download (workflows_async) | `result.sample` | | `@ai-sdk/replicate` | video poll | `urls.get` | | `@ai-sdk/gladia` | transcription poll | `result_url` | | `@ai-sdk/fal` | video status poll | `response_url` | | `@ai-sdk/google` | video download (`?key=`) | `video.uri` | (fal's transcription poll and Google's operation poll build their URL from a hardcoded/`baseURL`-anchored host, so they are not response-host-supplied and are left unchanged. `fal-image` and `replicate-image` already omit credentials on download.) ### Tests - Unit tests for `isSameOrigin` (same origin, foreign host, scheme/port mismatch, fail-closed on invalid input). - A foreign-origin regression test per provider asserting the credential header (or `?key=`) is **not** sent when the response names a different host. All suites pass in node and edge. ## Manual Verification <!-- TODO --> ## Checklist - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [ ] Documentation has been added / updated (for bug fixes / features) - [x] A _patch_ changeset for relevant packages has been added (for bug fixes / features - run `pnpm changeset` in the project root) - [x] I have reviewed this pull request (self-review) ## Future Work - Consider routing all response-supplied follow-up fetches through a small shared wrapper (origin-gated `getFromApi`) so new providers can't reintroduce this pattern, and so the rule is enforced in one place rather than per call site. ## Related Issues Linear: VULN-11567 (tracked under VULN-11626). --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

docs(examples): migrate deprecated streamText result helpers to standalone helpers (#15741) ## Background Follow-up to #14652, which deprecated the five `streamText` result methods that convert a result into other forms and added stateless standalone helpers in their place. That PR intentionally **deferred** migrating the existing `examples/`, `content/docs/`, and `content/cookbook/` usages to keep the API change reviewable: > Migrate remaining usages of the deprecated methods in `examples/` and `content/docs/` + `content/cookbook/` to the new standalone helpers. Intentionally deferred to a follow-up PR so the API change here stays reviewable. This PR is that follow-up. ## Summary Migrated every remaining usage of the deprecated result methods to the standalone helpers exported from `ai`. The result object's `.stream` is passed to the helper directly: | Deprecated (on `streamText` result) | Standalone replacement | | --- | --- | | `result.toUIMessageStream(opts)` | `toUIMessageStream({ stream: result.stream, ...opts })` | | `result.toUIMessageStreamResponse(opts)` | `createUIMessageStreamResponse({ stream: toUIMessageStream({ stream: result.stream, ...streamOpts }), ...responseInit })` | | `result.pipeUIMessageStreamToResponse(res, opts)` | `pipeUIMessageStreamToResponse({ response: res, stream: toUIMessageStream({ stream: result.stream, ...streamOpts }) })` | | `result.toTextStreamResponse(init)` | `createTextStreamResponse({ stream: toTextStream({ stream: result.stream }), ...init })` | | `result.pipeTextStreamToResponse(res, init)` | `pipeTextStreamToResponse({ response: res, stream: toTextStream({ stream: result.stream }), ...init })` | For `toUIMessageStreamResponse` / `pipeUIMessageStreamToResponse`, the options object is split: stream options (`originalMessages`, `generateMessageId`, `onFinish`, `messageMetadata`, `sendReasoning`, `sendSources`, `sendStart`, `sendFinish`, `onError`) go into `toUIMessageStream`, while response-init options (`headers`, `status`, `statusText`, `consumeSseStream`) stay on the responder helper. **Scope:** 149 files (80 examples, 37 docs, 32 cookbook). Notable cases: - **`agent.stream()` results** (`content/cookbook/01-next/77-track-agent-token-usage.mdx`) return a `StreamTextResult`, so their `toUIMessageStreamResponse` is the deprecated method and was migrated. Where the snippet used the `<AgentUIMessage>` generic to type the `messageMetadata` callback, the message generic moves to `toUIMessageStream<ToolSet, AgentUIMessage>`. - **`streamText` + `Output`** routes (e.g. `use-object`, `stream-object`) use `streamText`, so their `toTextStreamResponse` is deprecated and was migrated. `streamObject` results — whose `toTextStreamResponse`/`pipeTextStreamToResponse` are **not** deprecated — were left untouched (none were present in the migrated files). - **Chunk iteration** (`examples/ai-functions/.../anthropic-reasoning-ui-stream.ts`): the standalone `toUIMessageStream` returns a plain `ReadableStream` rather than the old `AsyncIterableStream`, so the `for await` was replaced with a reader loop. - **MDX `highlight` ranges**: expanding single-line imports / one-line returns shifted line numbers inside fenced code blocks; affected `highlight="..."` attributes were recomputed. - Minor correctness fix in `12-use-chat-an-error-occurred.mdx`: the migrated snippet's stale `getErrorMessage` option was corrected to `toUIMessageStream`'s actual `onError` option. ## Manual Verification - `oxfmt` + `oxlint` clean on all changed TS/TSX files. - `tsc --noEmit` on the affected example packages (`ai-functions`, `ai-e2e-next`, `express`, `hono`, `fastify`, `nest`, `node-http-server`, `angular`, `next`, `next-openai-pages`, `nuxt-openai`, `sveltekit-openai`) shows no migration-related type errors. (Pre-existing, unrelated errors in `ai-functions` azure/xai web-search example files are not touched by this PR.) - No production package code changed, so no changeset is required. ## Checklist - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [ ] Tests have been added / updated (for bug fixes / features) - [x] Documentation has been added / updated (for bug fixes / features) - [ ] A _patch_ changeset for relevant packages has been added (for bug fixes / features - run `pnpm changeset` in the project root) - [x] I have reviewed this pull request (self-review) <!-- No changeset and no tests: this PR only updates examples/ and content/ (docs + cookbook); no published package code changed. --> ## Future Work - Deduplicate workflow's `toUIMessageChunk` against the new `ai` helper (tracked in #14652). - Remove the five deprecated instance methods in the next major release (v8). ## Related Issues Follow-up to #14652. --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

fix(provider-utils,ai): harden download SSRF guard against hostname and redirect bypasses (#15980) ## Background The download URL validation guard (`validateDownloadUrl`) and the file download helpers (`downloadBlob`, `download`) had several bypasses when handling untrusted URLs. These were reported via the Anthropic coordinated vulnerability disclosure (Linear VULN-11554, VULN-11552, VULN-11560; tracked under VULN-11626). ## Summary Hardens the guard against three classes of bypass: - **Trailing-dot hostnames** — a fully-qualified name with a trailing dot (e.g. `localhost.`, `myhost.local.`) resolves identically to the bare name but skipped the localhost/`.local` blocklist. The hostname is now normalized (trailing dots stripped) before the checks. - **IPv6 with embedded IPv4** — the previous string-prefix logic missed addresses that carry an IPv4 target in their last 32 bits: IPv4-compatible (`::a.b.c.d`), IPv4-translated (`::ffff:0:a.b.c.d`), and NAT64 (`64:ff9b::/96` and the `64:ff9b:1::/48` local-use prefix). The address is now fully expanded into its 8 groups, the embedded IPv4 is decoded and run through the existing private-range checks, and unparseable addresses fail closed. - **Redirects validated too late** — redirects were only checked *after* `fetch` had already followed them, so the request to a redirect target had already been issued before the guard ran. **On the server**, both download helpers now follow redirects manually (`redirect: 'manual'`), re-validating each hop (resolved against the current URL) **before** requesting it, capped at 10 hops. ### Browser behavior The manual redirect handling is gated on a new `isBrowserRuntime()` helper. In a browser, `fetch(url, { redirect: 'manual' })` returns an unreadable opaque-redirect response, so per-hop validation is impossible and would break every legitimate redirected download. SSRF is also a server-side threat — browser fetch is constrained by CORS and cannot reach a server's internal network or cloud-metadata endpoints. So in the browser we fall back to `redirect: 'follow'` and let the platform follow redirects natively. The initial URL is still validated in both environments. ### Files - `packages/provider-utils/src/validate-download-url.ts` — trailing-dot normalization + IPv6 expansion/embedded-IPv4 detection - `packages/provider-utils/src/is-browser-runtime.ts` — new runtime helper (exported) - `packages/provider-utils/src/download-blob.ts`, `packages/ai/src/util/download/download.ts` — manual redirect following with per-hop validation on the server; native follow in the browser Regression tests added for all three bypasses, the browser fallback, and the runtime helper. A regression test asserts the unsafe redirect target is **never requested** on the server. ## Manual Verification <!-- TODO --> ## Checklist - [ ] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [ ] Documentation has been added / updated (for bug fixes / features) - [x] A _patch_ changeset for relevant packages has been added (for bug fixes / features - run `pnpm changeset` in the project root) - [x] I have reviewed this pull request (self-review) ## Future Work - **DNS-resolution bypass (VULN-11509)** is intentionally not addressed here. A correct fix requires resolving the hostname and pinning the connection to the validated IP (to defeat DNS rebinding), which is Node-only and either changes the public `validateDownloadUrl` signature to async or adds an undici dispatcher dependency. Recommended as a separate, ADR-backed follow-up. ## Related Issues Linear: VULN-11554, VULN-11552, VULN-11560 (tracked under VULN-11626). VULN-11509 deferred (see Future Work). --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: dnukumamras <mukund.sarma@vercel.com>

feat(ai): expose `toUIMessageChunkStream` helper (#14652) ## Background `DefaultStreamTextResult` carried five instance methods that convert a `streamText` result into other forms: - `toUIMessageStream` — inline stream-to-UI-message conversion logic, only reachable through the class method - `toUIMessageStreamResponse` and `pipeUIMessageStreamToResponse` — UI message response helpers tied to the result object - `toTextStreamResponse` and `pipeTextStreamToResponse` — text response helpers tied to the result object Two problems with this shape: 1. The `toUIMessageStream` transformation is trapped inside the class. It can't be composed over a `fullStream` captured outside of `streamText` (custom transports, tests, non-`streamText` producers that emit `TextStreamPart<TOOLS>`). 2. The five methods duplicate capability that now exists as top-level helpers, inflating the `StreamTextResult` surface and steering users toward method chaining instead of composition. ## Summary see before/after APIs in migration guide: https://github.com/vercel/ai/blob/ui-message-stream-helper/content/docs/08-migration-guides/23-migration-guide-7-0.mdx#streamtext-response-helpers-deprecated--use-stateless-helpers - Extract the per-part conversion into a standalone `toUIMessageChunk(part, options)` helper exported from `ai`. Operates on `TextStreamPart<TOOLS>`. - Add `toUIMessageChunkStream`, which maps `ReadableStream<TextStreamPart<TOOLS>>` to UI message chunks and includes response message ID injection plus `onFinish` handling, so it can replace `result.toUIMessageStream()` directly. - Add `toUIMessageChunkStreamResponse` for `fullStream -> Response` and `pipeTextStreamToUIMessageStreamResponse` for `fullStream -> Node ServerResponse` migrations. - Refactor `DefaultStreamTextResult`'s deprecated UI stream method, `createAgentUIStream`, and `DirectChatTransport` to delegate to the standalone helpers with full streams. - Add `@deprecated` JSDoc to all five instance methods on the `StreamTextResult` interface. The methods still work in v7 and will be removed in the next major. - Update the v6 -> v7 migration guide and changeset with before/after examples for each deprecated method. ## Scope notes This PR keeps each helper input shape explicit: - `toUIMessageChunkStream`, `toUIMessageChunkStreamResponse`, and `pipeTextStreamToUIMessageStreamResponse` accept `ReadableStream<TextStreamPart<TOOLS>>` from `result.fullStream`. - `createUIMessageStreamResponse` and `pipeUIMessageStreamToResponse` continue to accept already-converted UI message chunk streams. - `toUIMessageChunk` accepts `TextStreamPart<TOOLS>` only. Workflow dedup is deferred to a follow-up PR so this one stays focused. ## Manual Verification - `pnpm type-check` in `packages/ai` - `pnpm exec vitest --config vitest.node.config.js --run src/ui-message-stream/to-ui-message-chunk-stream-response.test.ts src/ui-message-stream/pipe-text-stream-to-ui-message-stream-response.test.ts` in `packages/ai` ## Checklist - [x] Tests have been added / updated (for bug fixes / features) - [x] Documentation has been added / updated (for bug fixes / features) - [x] A _patch_ changeset for relevant packages has been added (for bug fixes / features - run `pnpm changeset` in the project root) - [x] I have reviewed this pull request (self-review) ## Future Work - Migrate remaining usages of the deprecated methods in `examples/` and `content/docs/` + `content/cookbook/` to the new standalone helpers. Intentionally deferred to a follow-up PR so the API change here stays reviewable. Regression tests in `packages/ai/src/generate-text/stream-text.test.ts` and historical migration guides under `content/docs/08-migration-guides/` intentionally stay on the deprecated API. - Deduplicate workflow's `toUIMessageChunk` against the new `ai` helper. - Remove the five deprecated instance methods in the next major release (v8). --------- Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: Aayush Kapoor <83492835+aayush-kapoor@users.noreply.github.com>

feat: `response.stream` (#15653) ## Background In preparation of https://github.com/vercel/ai/pull/14652 Follow up to https://github.com/vercel/ai/commit/b095aef28f21c44377fcbe227264c3fa99c05a80 ## Summary - introduces `response.stream` as a replacement for `response.fullStream` - deprecates `response.fullStream` Note: I didn't update `streamObject` since it's deprecated and due to be removed anyway. ## Manual Verification Ran examples

fix(provider-utils): cancel response body on download rejection to prevent socket leak (#15968) ## Background When a download is rejected early, the `fetch` response body was left unconsumed and uncancelled. Under WHATWG Fetch / undici, an undisturbed body keeps the underlying TCP socket open instead of returning it to the connection pool. This happened on three paths: - `readResponseWithSizeLimit()` threw immediately when the `Content-Length` header exceeded `maxBytes`, before any reader was acquired. - The `!response.ok` early-throw paths in `download()` and `downloadBlob()`. - The redirect-validation path in `download()` and `downloadBlob()`, where a redirect resolving to a blocked URL (SSRF / open-redirect) threw before the body was consumed. An attacker-controlled origin can advertise a large `Content-Length` (or return an error status, or open-redirect to a blocked URL) **without sending a body**, accumulating open sockets on the victim until file-descriptor exhaustion (`EMFILE`) / connection-pool starvation causes a remote denial of service. This is reachable by any application that downloads user-supplied URLs (e.g. multimodal image/file inputs), even with SSRF mitigations in place. ## Summary - Added a `cancelResponseBody(response)` helper (`packages/provider-utils/src/cancel-response-body.ts`) that calls `response.body?.cancel()` and swallows cancel errors so the original rejection is preserved. Exported from `@ai-sdk/provider-utils`. Kept in its own module since it is a connection-cleanup concern reused independently of size-limiting. - Cancel the body before throwing on every early-rejection path: - Content-Length over limit in `readResponseWithSizeLimit()` - `!response.ok` in `download()` and `downloadBlob()` - blocked redirect target in `download()` and `downloadBlob()` - Added regression tests asserting the body is cancelled on the Content-Length, non-ok, and open-redirect paths, plus dedicated unit tests for `cancelResponseBody` itself. ## Manual Verification The original PoC requires a malicious HTTP server that advertises a 10 GiB `Content-Length` and never sends a body, plus OS-level `netstat` to observe leaked `ESTABLISHED` sockets — so it does not map to a runnable `examples/` script. Verified instead via unit tests that assert `ReadableStream.cancel()` is invoked on each early-rejection path (the cancel call is what releases the socket back to the pool): - `pnpm --filter @ai-sdk/provider-utils test:node` — all passing (613) - `pnpm --filter ai test:node` (download suite) — all passing (3090) - `pnpm check` — 0 warnings, 0 errors ## Checklist - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [ ] Documentation has been added / updated (for bug fixes / features) - [x] A _patch_ changeset for relevant packages has been added (for bug fixes / features - run `pnpm changeset` in the project root) - [x] I have reviewed this pull request (self-review) ## Related Issues VULN-10892 --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com> Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>

feat(provider/openai): support GPT-5.6 reasoning and prompt caching controls (#17028) ## Summary - add GPT-5.6 `max` reasoning effort support for Chat Completions - add Responses API `reasoningMode` and `reasoningContext` options, including the effective reasoning context in provider metadata - support GPT-5.6 implicit and explicit prompt cache options, 30-minute TTL, and explicit cache breakpoints for supported message content - report cache-write tokens for Chat Completions and Responses without double-counting uncached input tokens - document GPT-5.6 reasoning, prompt caching, cache-write usage, and original image detail behavior - add `generateText` and `streamText` examples for pro mode, persisted reasoning context, and explicit prompt caching Follow-up to #17021. ## Test plan - `pnpm test:node` in `packages/openai` — 19 files, 772 tests - `pnpm test:edge` in `packages/openai` — 19 files, 772 tests - `pnpm type-check` in `packages/openai` - `pnpm type-check:full` - `pnpm check` - `node tools/validate-properties-tables.mjs` Live GPT-5.6 examples were not run locally because no `OPENAI_API_KEY` was configured.

feat(openai): report Chat Completions stream mismatch (#16423) ## Background Issue #16408 reports that after migrating to AI SDK v7, `streamText` with tools can execute tool calls but the final assistant text does not appear when using `createOpenAI({ baseURL })` against a custom OpenAI-compatible endpoint. The reproduced mismatch is that `provider('gpt-4o-mini')` uses the OpenAI Responses API in v7, while the custom endpoint returns Chat Completions SSE chunks. Those chunks were previously parsed by the Responses stream parser, producing a generic validation error instead of telling the user that the wrong OpenAI API surface was selected. Using `provider.chat('gpt-4o-mini')` against the same mocked Chat Completions chunks preserves the tool call, executes the tool, and streams the final UI text. I also checked the related #12056 Azure-style chunks (`choices: []`, empty assistant content prelude, and trailing content filter chunk); the OpenAI Chat parser already streams the text delta for that shape. Credit to @itisvincent for #16408, @mac-110 for the raw Azure-compatible stream fixture in #12056, and @PaulyBearCoding for the related no-argument tool-call investigation in #10283. #10283 is a separate empty-tool-arguments issue and is not fixed here. ## Summary - Detect Chat Completions stream chunks that reach the OpenAI Responses stream parser and return a targeted `APICallError` explaining the API mismatch. - Document that `openai('model-id')` / `createOpenAI()('model-id')` uses the Responses API, including when `baseURL` is customized. - Document that Chat Completions-only custom endpoints should use `openai.chat('model-id')` or the OpenAI-compatible provider. - Add provider tests for custom `baseURL` routing, Azure-compatible Chat Completions stream chunks, and the new mismatch error. - Add a patch changeset for `@ai-sdk/openai`. ## Manual Verification Reproduced the reported setup locally with `streamText`, `createOpenAI({ baseURL, fetch })`, a tool call step, and a follow-up Chat Completions SSE text step. With `provider('gpt-4o-mini')`, the mocked Chat Completions stream is routed through the Responses parser and now reports a helpful mismatch error. Switching only the model to `provider.chat('gpt-4o-mini')` executes the tool and yields `text: "Created test."`, `finishReason: "stop"`, and a UI stream containing the final `text-delta`. Also confirmed that the Azure/content-filter stream fixture based on #12056 is realistic and is handled by the OpenAI Chat parser. The Responses parser mismatch detection covers Azure-style `choices: []` chunks. Automated focused test run: ```sh pnpm --filter @ai-sdk/openai exec vitest --config vitest.node.config.js --run src/openai-provider.test.ts src/chat/openai-chat-language-model.test.ts src/responses/openai-responses-language-model.test.ts -t "baseURL configuration|should stream text after Azure content filter chunks|should return helpful error when Chat Completions stream is received" pnpm --filter @ai-sdk/openai type-check ``` ## Checklist - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [x] Documentation has been added / updated (for bug fixes / features) - [x] A _patch_ changeset for relevant packages has been added (for bug fixes / features - run `pnpm changeset` in the project root) - [x] I have reviewed this pull request (self-review) ## Future Work The no-argument tool call behavior from #10283 should remain a separate fix path. ## Related Issues Closes #16408. Related to #12056 and #10283.

feat (provider/quiverai): new @ai-sdk/quiverai provider (v2.0.0) (#15461) ## Background Add a 1st-party `@ai-sdk/quiverai` provider for [QuiverAI](https://quiver.ai/) SVG image generation, ported from https://github.com/quiverai/ai-sdk-provider. This PR targets `main` (canary pre-release). It must be merged **after** https://github.com/vercel/ai/pull/15463 has shipped `@ai-sdk/quiverai@1.0.0` from `release-v6.0`. With #15463's `v1.0.0` recorded as the initial version in `.changeset/pre.json`, the major changeset on this branch will publish `@ai-sdk/quiverai@2.0.0` once canary mode exits. ## Summary - New `packages/quiverai` package (image model only) supporting `generate` and `vectorize` operations against Arrow models (`arrow-1`, `arrow-1.1`, `arrow-1.1-max`). - Workflow serialization, example in `examples/ai-functions/src/generate-image/quiverai/`, docs at `content/providers/01-ai-sdk-providers/180-quiverai.mdx`, major changeset. - `package.json` version pinned to `1.0.0` and `.changeset/pre.json` initialVersions seeded with `@ai-sdk/quiverai: 1.0.0` so canary publishes start at `2.0.0-canary.x` and avoid colliding with the `v1.0.0` line shipped from `release-v6.0`. ## Manual Verification Ran both examples added in this PR against the live QuiverAI API: - `examples/ai-functions/src/generate-image/quiverai/basic.ts` — text-to-SVG generation with `arrow-1.1`. - `examples/ai-functions/src/generate-image/quiverai/vectorize.ts` — vectorization of `examples/ai-functions/data/wtf-logo.png` with `arrow-1.1`. ## Checklist - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [x] Documentation has been added / updated (for bug fixes / features) - [x] A _patch_ changeset for relevant packages has been added (for bug fixes / features - run `pnpm changeset` in the project root) - [x] I have reviewed this pull request (self-review) ## Related Issues Closes https://github.com/vercel/ai/issues/15459 Depends on https://github.com/vercel/ai/pull/15463 (must merge first). --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Support toModelOutput in WorkflowAgent (#15917) ## Background `WorkflowAgent` did not honor tool `toModelOutput`, unlike core text generation. ## Summary - route WorkflowAgent tool results through model-output conversion - keep raw tool output for UI/results/callbacks - add next-workflow example + docs ## Manual Verification Tested examples/next-workflow end-to-end ## Checklist - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [x] Documentation has been added / updated (for bug fixes / features) - [x] A _patch_ changeset for relevant packages has been added (for bug fixes / features - run `pnpm changeset` in the project root) - [x] I have reviewed this pull request (self-review) --------- Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

fix(google): auto-inject skip_thought_signature_validator on Gemini 3 replays (#15560) ## Background Gemini 3 rejects replayed assistant `functionCall` parts without `thoughtSignature` with HTTP 400. This happens when app/client code persists or rebuilds messages and drops `providerOptions`. ## Summary - For Gemini 3 only (`/^gemini-3[.-]/`), inject Google's documented `skip_thought_signature_validator` sentinel when a replayed tool call has no signature. - Warn once per request with affected tool names. - Adapted to `main` V4 Google provider files and existing `google` / `googleVertex` / `vertex` namespace lookup. ## Manual Verification Live replay against `google('gemini-3-flash-preview')`: missing-signature replay changed from HTTP 400 to HTTP 200 with warning. ## Checklist - [ ] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [ ] Documentation has been added / updated (for bug fixes / features) - [x] A _patch_ changeset for relevant packages has been added (for bug fixes / features - run `pnpm changeset` in the project root) - [x] I have reviewed this pull request (self-review) ## Related Issues Closes #15550. Refs #10344, #11413, #14196, #15548, #13060. Co-authored-by: Cursor <cursoragent@cursor.com>

fix(openai): correlate rotated Responses API item ids (#18548) ## Background `@ai-sdk/openai` keyed active Responses API reasoning state and emitted stream-part IDs by each event's opaque `item_id`. A real request to GitHub Copilot's `/responses` endpoint with `gpt-5.3-codex` showed that Copilot sends `response.output_item.added`, but rotates the opaque ID on every subsequent reasoning and message event. `output_index` remains stable. That caused the reported `activeReasoningPart.summaryParts` crash. If the crash was bypassed, the same rotation produced the downstream `text part ... not found` error because text start, delta, and end used different IDs. The committed fixture is the complete 69-event SSE sequence captured from the real provider on 2026-08-06. Opaque identifiers, encrypted reasoning payloads, obfuscation padding, and the safety identifier were sanitized; event order, event types, output indexes, deltas, usage, and response structure were preserved. ## Summary - Retain `output_index` when parsing text-delta and reasoning-summary events. - Track the canonical message/reasoning item ID from `response.output_item.added` by `output_index`. - Use that canonical ID for reasoning/text deltas and end events, and avoid dereferencing absent reasoning state. - Add the sanitized live Copilot SSE capture as a regression fixture and assert that it emits no stream errors, preserves one ID per logical reasoning/text part, and returns the complete answer. - Add a public-API end-to-end example that serves the captured ID-rotation pattern over localhost SSE. - Add a patch changeset for `@ai-sdk/openai`. ## Contributor Credit Thanks to @A-S-Manoj for the upstream report and diagnosis; @drmgc and @EntropyParadigm for the Nanocoder reports; @daitmaamar4-png, @OverHash, and @jianminLee for independent downstream reports; and @mussaratshamsher for the related work in #18337. ## End-to-End Verification I first sent an authenticated request to the real GitHub Copilot Responses API using the credential created by `nanocoder copilot login`. Replaying that exact raw response through public `createOpenAI(...).responses(...)` and `streamText(...)` failed before this change with: ```text TypeError: Cannot read properties of undefined (reading 'summaryParts') ``` After rebuilding `@ai-sdk/openai`, replaying the same unsanitized raw response completed successfully. I also ran the checked-in localhost HTTP/SSE reproduction: ```sh cd examples/ai-functions pnpm tsx src/stream-text/openai/responses-reasoning-id-rotation.ts ``` It now prints: ```text Expected: reasoning summary followed by "ok". Thinking through the request.ok ``` This is the complete end-to-end example used for that verification: ```ts import { createServer } from 'node:http'; import { createOpenAI } from '@ai-sdk/openai'; import { streamText } from 'ai'; import { run } from '../../lib/run'; const modelId = 'gpt-5.3-codex'; const responseId = 'resp_copilot_repro'; const reasoningAddedId = 'rs_copilot_added'; const reasoningSummaryAddedId = 'rs_copilot_summary_added'; const reasoningSummaryDeltaId = 'rs_copilot_summary_delta'; const reasoningSummaryDoneId = 'rs_copilot_summary_done'; const reasoningDoneId = 'rs_copilot_done'; const messageAddedId = 'msg_copilot_added'; const messageDeltaId = 'msg_copilot_delta'; const messageDoneId = 'msg_copilot_done'; const response = { id: responseId, object: 'response', created_at: 1, status: 'in_progress', error: null, incomplete_details: null, input: [], instructions: null, max_output_tokens: null, model: modelId, output: [], parallel_tool_calls: true, previous_response_id: null, reasoning: { effort: 'low', summary: 'auto' }, store: true, temperature: null, text: { format: { type: 'text' } }, tool_choice: 'auto', tools: [], top_p: null, truncation: 'disabled', usage: null, user: null, metadata: {}, }; const reasoningItem = { id: reasoningDoneId, type: 'reasoning', summary: [{ type: 'summary_text', text: 'Thinking through the request.' }], }; const messageItem = { id: messageDoneId, type: 'message', status: 'completed', role: 'assistant', content: [{ type: 'output_text', text: 'ok', annotations: [] }], }; const events = [ { type: 'response.created', response }, // A live GitHub Copilot capture used a different opaque item id for every // reasoning and message event while keeping output_index stable. { type: 'response.output_item.added', output_index: 0, item: { id: reasoningAddedId, type: 'reasoning' }, }, { type: 'response.reasoning_summary_part.added', item_id: reasoningSummaryAddedId, output_index: 0, summary_index: 0, }, { type: 'response.reasoning_summary_text.delta', item_id: reasoningSummaryDeltaId, output_index: 0, summary_index: 0, delta: 'Thinking through the request.', }, { type: 'response.reasoning_summary_part.done', item_id: reasoningSummaryDoneId, output_index: 0, summary_index: 0, }, { type: 'response.output_item.done', output_index: 0, item: reasoningItem, }, { type: 'response.output_item.added', output_index: 1, item: { id: messageAddedId, type: 'message' }, }, { type: 'response.output_text.delta', item_id: messageDeltaId, output_index: 1, delta: 'ok', }, { type: 'response.output_item.done', output_index: 1, item: messageItem, }, { type: 'response.completed', response: { ...response, status: 'completed', output: [reasoningItem, messageItem], usage: { input_tokens: 5, input_tokens_details: { cached_tokens: 0 }, output_tokens: 8, output_tokens_details: { reasoning_tokens: 7 }, total_tokens: 13, }, }, }, ]; function toSse(value: unknown) { return `data: ${JSON.stringify(value)}\n\n`; } async function startMockCopilotServer() { const server = createServer((request, response) => { if (request.method !== 'POST' || request.url !== '/v1/responses') { response.writeHead(404).end(); return; } request.resume(); request.on('end', () => { response.writeHead(200, { 'content-type': 'text/event-stream', connection: 'close', }); for (const event of events) { response.write(toSse(event)); } response.end(); }); }); await new Promise<void>((resolve, reject) => { server.once('error', reject); server.listen(0, '127.0.0.1', () => { server.off('error', reject); resolve(); }); }); const address = server.address(); if (address == null || typeof address === 'string') { throw new Error('Mock Copilot server did not bind to a TCP port.'); } return { server, baseURL: `http://127.0.0.1:${address.port}/v1`, }; } run(async () => { const { server, baseURL } = await startMockCopilotServer(); try { const copilot = createOpenAI({ apiKey: 'test-key', baseURL, }); const result = streamText({ model: copilot.responses(modelId), prompt: 'Reply with exactly: ok', }); console.log('Expected: reasoning summary followed by "ok".'); for await (const part of result.stream) { if (part.type === 'reasoning-delta' || part.type === 'text-delta') { process.stdout.write(part.text); } } console.log(); } finally { await new Promise<void>((resolve, reject) => { server.close(error => { if (error != null) { reject(error); return; } resolve(); }); }); } }); ``` ## Checklist - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [x] Documentation has been added / updated (for bug fixes / features) - [x] A _patch_ changeset for relevant packages has been added (for bug fixes / features - run `pnpm changeset` in the project root) - [x] I have reviewed this pull request (self-review) ## Future Work #18337 proposes synthesizing `reasoning-start` when a provider truly omits `response.output_item.added`. The real Copilot trace includes that event with a different ID, so this PR keeps that separate behavior out of scope. It can be evaluated independently if a raw provider trace confirms the missing-event variant. ## Related Issues Fixes #18270 - https://github.com/Nano-Collective/nanocoder/issues/719 - https://github.com/Nano-Collective/nanocoder/issues/576 - https://github.com/anomalyco/opencode/issues/21346 - https://github.com/Soju06/codex-lb/issues/398 - https://github.com/cita-777/metapi/issues/269 - Related implementation: #18337

feat(ai): promote repairText option to stable (#18015) ## Background `experimental_repairText` was introduced for `generateObject` in #4937 and extended to `streamObject` in #7640. The option and its stable `RepairTextFunction` type have matured behind the experimental name. Following the graduation strategy in #16562, this promotes the option to a stable un-prefixed name while retaining the experimental name as a deprecated alias until v8. ## Summary - Add `repairText` to `generateObject` and `streamObject`. - Keep `experimental_repairText` as a deprecated alias. - Prefer `repairText` when both option names are provided. - Update existing repair tests to use the stable name and add focused deprecated-alias and precedence coverage for both functions. - Update the shipped API JSDoc and add an `ai` patch changeset. The public reference pages for `generateObject` and `streamObject` were intentionally deleted in #12707 when both functions were deprecated in favor of `generateText` and `streamText` with `Output`, so this PR does not restore those legacy documentation pages. Adding repair support to `generateText`/`Output` remains tracked separately in #10973. ## Testing - `pnpm check` - `pnpm type-check:full` - `pnpm --filter ai exec vitest --config vitest.node.config.js --run src/generate-object/generate-object.test.ts src/generate-object/stream-object.test.ts` - `pnpm --filter ai exec vitest --config vitest.edge.config.js --run src/generate-object/generate-object.test.ts src/generate-object/stream-object.test.ts` ## Related Issues Closes #18011. Part of #16562.

fix: reject empty OpenAI, Anthropic, and Replicate base URLs with a helpful error (#17158) ## Background Empty base URL configuration previously allowed provider creation and later produced opaque request-time URL parsing errors, including when OPENAI_BASE_URL was empty. ## Summary Added a shared validateBaseURL helper that throws InvalidArgumentError for empty or whitespace-only values and applied it during OpenAI, Anthropic, and Replicate provider creation without changing the semantics of withoutTrailingSlash or Google Vertex default URL construction. ## Testing Added utility tests for validation and URL normalization, provider regressions for explicit OpenAI, OPENAI_BASE_URL, Anthropic, and Replicate configurations, and Google Vertex xAI and MaaS coverage using the real shared URL utility for omitted and empty defaults. ## End-to-end Validation - `issue-17156-empty-base-url.ts` — ran `pnpm -C examples/ai-functions exec tsx src/reproduction/issue-17156-empty-base-url.ts`; all invalid configurations produced helpful factory-time AI SDK errors and the live OpenAI call returned the expected text. ## Related Issues Fixes #17156 Co-authored-by: gr2m <39992+gr2m@users.noreply.github.com>

feat(anthropic): opus 5 (#17904) Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

fix(provider/xai): send reasoning effort "none" for top-level `reasoning: 'none'` (#16893) ## Background The xAI API supports disabling reasoning on `grok-4.3` and newer reasoning models by sending `reasoning: { effort: "none" }` (Responses API) / `reasoning_effort: "none"` (Chat Completions API). When the parameter is omitted, xAI defaults to `effort: "low"`, so the model still reasons. The xAI provider explicitly mapped the top-level `reasoning: 'none'` call option to `undefined`, silently dropping it from the request — without even emitting a warning. Users who requested `reasoning: 'none'` still got (and paid for) reasoning tokens. The `providerOptions: { xai: { reasoningEffort: 'none' } }` escape hatch already forwarded `'none'` correctly, and the OpenAI provider passes top-level `'none'` straight through, so this was an inconsistency introduced in #13648, presumably before xAI supported `none`. Additionally, probing the live API revealed that `grok-4.20-reasoning` and `grok-4.20-non-reasoning` (including dated variants like `grok-4.20-0309-reasoning`) reject the reasoning effort parameter entirely — **any** value, not just `'none'` — with `400 invalid-argument: Model X does not support parameter reasoningEffort.` So the top-level `reasoning` option already caused request failures on those models before this PR. ## Summary - Map the top-level `reasoning: 'none'` option to effort `'none'` in both the Responses API model (`xai-responses-language-model.ts`) and the Chat Completions model (`xai-chat-language-model.ts`), instead of dropping it. - Omit the reasoning effort parameter and emit an `unsupported` warning when the top-level `reasoning` option is used with models that reject the parameter (`supports-reasoning-effort.ts`). Explicit `providerOptions.xai.reasoningEffort` is still passed through verbatim. - Updated the chat model test that locked in the old behavior, and added top-level `reasoning` coverage for the Responses API model (mapping, `'none'`, `providerOptions` precedence, and unsupported-model gating). - Added patch changesets for `@ai-sdk/xai`. ## Manual Verification Ran the following against the live xAI API (via `examples/ai-functions`), logging the request body with a custom `fetch`: ```ts import { createXai } from '@ai-sdk/xai'; import { generateText } from 'ai'; const xai = createXai({ fetch: async (url, init) => { console.dir(JSON.parse(init.body), { depth: Infinity }); return fetch(url, init); }, }); const result = await generateText({ model: xai('grok-4.3'), prompt: `How many "r"s are in the word "strawberry", and what is the square root of 144? Then, how much is the product of both of the resulting values? Think hard about it. Only respond with the resulting final number, nothing more.`, reasoning: 'none', }); console.log(result.finalStep.reasoning); console.log(result.text); ``` **Before the fix**: the request body contained no `reasoning` field, and `result.finalStep.reasoning` contained reasoning content (xAI defaults to `effort: "low"`). **After the fix**: the request body contains `reasoning: { effort: 'none' }` and the response contains no reasoning content. Also verified against the live API with `reasoning: 'none'` on models that reject the parameter: - `grok-4.3` → `reasoning: { effort: 'none' }` sent, no reasoning tokens, no warnings. - `grok-4.20-reasoning` → parameter omitted, request succeeds (would be a 400 otherwise), `unsupported` warning surfaced. - `grok-4.20-non-reasoning` → parameter omitted, request succeeds, `unsupported` warning surfaced. ## Checklist - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [ ] Documentation has been added / updated (for bug fixes / features) - [x] A _patch_ changeset for relevant packages has been added (for bug fixes / features - run `pnpm changeset` in the project root) - [x] I have reviewed this pull request (self-review) ## Related Issues Fixes #16892 --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

fix(provider-utils): limit JSON response handler reads (#16374) ## Background JSON response handlers read bodies without the shared size limit. ## Summary Use `readResponseWithSizeLimit` for JSON and status-code response handlers. ## Manual Verification New tests fail without the code changes ## Checklist <!-- Do not edit this list. Leave items unchecked that don't apply. If you need to track subtasks, create a new "## Tasks" section Please check if the PR fulfills the following requirements: --> - [ ] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [ ] Documentation has been added / updated (for bug fixes / features) - [x] A _patch_ changeset for relevant packages has been added (for bug fixes / features - run `pnpm changeset` in the project root) - [x] I have reviewed this pull request (self-review) ## Future Work None. ## Related Issues closes #15756 --------- Co-authored-by: Aayush Kapoor <aayushkapoor34@gmail.com>

fix(google-vertex): use embedContent for Gemini embeddings (#16238) ## Background `gemini-embedding-2` / `gemini-embedding-2-preview` are registered model ids, but the Vertex provider always calls the legacy `:predict` endpoint. Google dropped `:predict` for that family, so every call fails with `400 FAILED_PRECONDITION`. (`gemini-embedding-001` still supports `:predict`.) ## Summary - Route `gemini-embedding-2`/`-preview` to `:embedContent`. - Cap `maxEmbeddingsPerCall` at 1 for those models (`:embedContent` takes a single value). - Add a minimal `:embedContent` response schema. ## Manual Verification Added unit tests asserting the request hits `:embedContent` with the right body, parses embeddings/usage, and that `maxEmbeddingsPerCall === 1`. `pnpm vitest run src/google-vertex-embedding-model.test.ts` — 15 passed. ## Checklist - [x] All commits are signed - [x] Tests have been added / updated - [ ] Documentation has been added / updated - [x] A _patch_ changeset for relevant packages has been added - [x] I have reviewed this pull request (self-review) ## Related Issues Fixes #15853 Recreated from #15887 by @he-yufeng (co-authored), adding a changeset and signed commit so full CI runs. Co-authored-by: Yufeng He <he-yufeng@users.noreply.github.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>