Felix Arntz

feat(provider): add support for provider references and uploading files as supported per provider (#13816) ## Background The AI SDK supports passing media files inline or via URL, but has no way to upload files directly to a provider or reference previously uploaded files across providers. Some providers return internal file IDs (not URLs) from their upload APIs, and switching providers mid-conversation requires a way to map the same logical file to different provider-specific identifiers. ## Summary Introduces `uploadFile` as a top-level function and `ProviderReference` (`Record<string, string>`) as the provider-independent way to reference uploaded files. - **New spec types**: `SharedV4ProviderReference` (provider package), `FilesV4` interface with `uploadFile` method, `UploadFileResult`; `mediaType` and `filename`** are top-level parameters as they're widely supported and used - **New top-level API**: `uploadFile({ files, data, mediaType?, filename?, providerOptions? })` in the `ai` package, with auto-detection of media type from file bytes when not provided - **Provider implementations**: `files()` interface on Anthropic, Google, OpenAI, and xAI providers, each implementing `FilesV4.uploadFile` - Other providers don't support uploading files, or they only support uploading files for batch inference (`*.jsonl`), which we don't support anyway. - **Provider reference support in messages**: `LanguageModelV4FilePart.data` now accepts `SharedV4ProviderReference` in addition to `DataContent`; providers that support file references (Anthropic, Google, OpenAI, xAI) resolve them via `resolveProviderReference`; all other providers throw `UnsupportedFunctionalityError` - **Spec cleanup**: `file-id` and `image-file-id` tool result output types replaced with `file-reference` and `image-file-reference` using `SharedV4ProviderReference` instead of `string | Record<string, string>` - **Uploading from URL is not supported** — no provider supports this, and auto-downloading is questionable; callers should fetch first - **`reasoning-file` was not touched** — it is model-generated as part of reasoning output, so provider references are not applicable - **Docs included** — Docs about `uploadFile` and `ProviderReference`, and a new architecture guide are included ### Design decisions - `ProviderReference` is a plain `Record<string, string>` rather than a wrapper class, keeping it simple to create and merge - The `isLikelyText` heuristic for media type detection and the `documentMediaTypeSignatures` are kept internal (not exported) — they work well enough for `uploadFile` but are not general-purpose utilities - `resolveProviderReference` (provider-utils) does the lookup by provider name and throws with a clear error listing available providers when the reference doesn't contain an entry for the current provider ### Open questions 1. Should we include a `type` property in `ProviderReference` to distinguish different kinds of provider references (e.g. file vs skill, see #12855)? 2. Should `mediaType` and `filename` be top-level fields in the `uploadFile` result object? - They're currently top-level request parameters, but in the response they're in `providerMetadata`. 3. `mergeProviderReferences` is currently inlined in an example (`multi-provider.ts`) — should we offer this as a utility, or leave it for later? 4. `file-id` and `image-file-id` were removed in `toModelOutput` return value — should we deprecate them instead and/or offer auto-migration via codemod? 5. Out of scope: supporting providers that allow uploading files solely for batch inference (e.g. Cohere, Groq, Mistral), which we don't support at a provider level yet anyway - probably leave for later? ## Manual Verification Upload file examples were added for all 4 supported providers (Anthropic, Google, OpenAI, xAI), each with image, PDF, and text variants. ## 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 Reuse the new `ProviderReference` approach for #12855. ## Related Issues Fixes #12995

chore(provider/google): remove useless GenerativeAI affix from types and classes for consistency (#14566) ## Background The `google` provider package used `GoogleGenerativeAI` as the prefix for all classes and interfaces (e.g. `GoogleGenerativeAILanguageModel`, `GoogleGenerativeAIProvider`). This is redundant since the entire package is for the Google Generative AI API, and inconsistent with other providers which use short prefixes (`OpenAI*`, `Anthropic*`). And really, this is the Google provider, especially because `google-vertex` is a separate provider anyway. Since we are in v7 stage, I think it's a good idea to clean up that odd naming. ## Summary - Renamed all `GoogleGenerativeAI*` classes, types, interfaces, and functions to `Google*` (e.g. `GoogleGenerativeAILanguageModel` -> `GoogleLanguageModel`, `createGoogleGenerativeAI` -> `createGoogle`) - Renamed all `google-generative-ai-*` source files to `google-*` - Added deprecated backward-compatible aliases in `index.ts` for all previously public names (`GoogleGenerativeAIProvider`, `GoogleGenerativeAIProviderSettings`, `GoogleGenerativeAIProviderMetadata`, `GoogleGenerativeAIVideoModelId`, `createGoogleGenerativeAI`) - Updated `google-vertex` to use new names from `@ai-sdk/google/internal` - Updated documentation and examples to use the new names - Fully backward compatible via deprecated aliases ## Manual Verification N/A - Refactoring only. ## 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)

feat(provider): add new top-level `reasoning` parameter to spec and support it in `generateText` and `streamText` (#13553) ## Background Reasoning/thinking configuration has historically been handled entirely via `providerOptions`, requiring provider-specific knowledge from callers and making it impossible to write portable reasoning code. ## Summary Adds a top-level `reasoning` parameter to `generateText` and `streamText` (and the underlying `LanguageModelV4` call options spec), as proposed in #12516. The parameter accepts a flat enum — `'provider-default' | 'none' | 'minimal' | 'low' | 'medium' | 'high' | 'xhigh'` — aligned with the OpenAI/OpenRouter convention. For the v4 spec, `'provider-default'` is omitted as that can be resolved at the `generateText` and `streamText` level by simply omitting the value. Existing `providerOptions` for each provider remain supported, both to help with a smooth transition path and to continue to support cases where a specific `providerOptions` behavior may be more granular than what the new top-level `reasoning` parameter allows. If reasoning-related keys are present in `providerOptions`, they take full precedence and the top-level `reasoning` parameter is ignored, so existing code continues to work without changes. Two helper functions are added to `provider-utils` to make provider-side mapping straightforward: - `mapReasoningToProviderEffort` — maps the enum to a provider's native effort string, emitting a compatibility warning if coercion is needed. - `mapReasoningToProviderBudget` — maps the enum to a token budget by multiplying the model's max output tokens by a percentage, clamped between a min and max budget. ### Provider migration status - [x] OpenAI — effort-based - [x] Anthropic — mixed (effort-based for newer models) - [x] Google — mixed (effort-based for newer models) - [x] Amazon Bedrock — mixed - [ ] xAI — effort-based - [ ] Groq — effort-based - [ ] DeepSeek — budget-based - [ ] Fireworks — effort-based - [ ] OpenAI Compatible — effort-based - [ ] Open Responses — effort-based - [ ] Perplexity — no reasoning support - [ ] Alibaba — no reasoning support - [ ] Azure — no reasoning support - [ ] Mistral — no reasoning support - [ ] Cohere — no reasoning support ## Manual Verification I ran all the relevant updated examples for each migrated provider, verifying they still work as before. ## 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 providers (potentially via this PR, or in a follow up PR) - Consider deprecating use of certain `providerOptions` values that provide no benefit over the new top-level `reasoning` parameter ## Related Issues Fixes #12516

feat(provider): add `reasoning-file` support (#13352) ## Background See #13321 ## Summary * Adds new type `reasoning-file` for files that are part of reasoning rather than actual content * Part of `provider` v4 spec * Relevant generate result, content part, stream result, and stream parts in `ai` are expanded accordingly * **bug fix:** simply by introducing `reasoning-file` (and thus breaking it apart from `file`), we fix the bug where reasoning files would before be included in top-level `files` (e.g. in `GenerateTextResult` or `StepResult`), which would lead to a duplicate entry in many scenarios * updates `google` language model to use `reasoning-file` instead of `file` with provider metadata where applicable * updates relevant `google` examples which were previously based on the provider options workaround FYI: https://github.com/vercel/ai/pull/13352/changes/9c1c48df9615ee3613800f23ae9e5cb77c0dc142 shows a glimpse of what supporting this in future 3P code could look like. ## Manual Verification Run the examples modified here. Specifically, run `examples/ai-functions/src/generate-text/google/image-thinking-multi-step.ts` against this branch and against `main`: With `main`, you'll see that `files` will include the same image twice (once as part of reasoning, once as the actual output) - this is the bug this PR effectively fixes. ## 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 N/A ## Related Issues Fixes #13321

feat(ai): add support for uploading provider skills using the provider references abstraction (#12880) ## Background #12995 introduced a new concept of provider references for managing uploaded assets to a provider in a container that supports multi-provider references. In #12995, this was implemented for uploading files (e.g. large media) to a provider for referencing it in inference calls. This PR uses that same approach for uploading skills to a provider with programmatic tool calling. This is currently supported by Anthropic and OpenAI. ## Summary - Introduces a new `SkillsV4` specification in `@ai-sdk/provider` for uploading remote skills across providers - Adds new core function `uploadSkill` in the `ai` package - Implements `SkillsV4` for both `@ai-sdk/openai` and `@ai-sdk/anthropic`, including provider-specific API handling - Includes comprehensive unit tests for all new code and example scripts demonstrating basic CRUD and skill-referenced inference for both providers ## Manual Verification Run the new examples included in the PR. ## Checklist - [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 N/A ## Related Issues Fixes #12855 Related: #12995 --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

fix(ai): fix missing support for image thought signatures (e.g. for Gemini image models) (#13064) ## Summary This fixes a few problems: * Image thought signatures were not supported by `ai` at all when streaming, including in UI / `useChat` transformations. * Image thought signatures were therefore also not being processed when received in a Gemini API response. * When using Gemini to produce multimodal output (e.g. text and images together), the order of output parts was not respected - images were always displayed after all text, even when in the original response they were in between text paragraphs. ## Manual Verification Use the new UI example `google-gemini-images` in `examples/ai-e2e-next` to verify. Try a prompt like: ``` Write a 3 verse kids poem about a dog meeting an owl, accompanied by illustrations ``` Without this PR, you will see all images appear after all text, even though this is not the correct order per the streaming chunks. With this PR, that's fixed. Similarly, without this PR you will not be able to send any follow up messages - they will error because of the missing image thought signatures. With this PR, it works. ## Related Issues Fixes #12988 Fixes #11461 Fixes #10595

chore: remove obsolete model IDs for Anthropic, Google, OpenAI, xAI (#12923) ## Background Follow up to: - #12807 - #12808 - #12809 - #12810 These issues were opened with type "New provider", so models listed in "New models" in this context does not mean these are new models, but rather that they are _all_ models that the provider API supports. This PR removes any models that were not in this list but still in our codebase. ## Summary - Removes obsolete model IDs across the four providers, being conservative to err on the side of keeping one if it _might_ still work: - e.g. aliases (model version that lacks the date suffix of a model that's still supported, model version of a supported model that appends "-latest") - model IDs that are deemed obsolete here but may be present on other providers (e.g. Gateway, Amazon Bedrock, Google Vertex) remain untouched there - Replaces usage in our examples with suitable newer replacement models - Replaces usage in documentation code snippets and removes mentions in documentation model lists or model tables ## 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: --> - [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)

feat(ai): break `CallSettings` apart into `LanguageModelCallOptions` and `RequestOptions` (#14417) ## Background `CallSettings` bundled two unrelated concerns: model-facing generation controls (e.g. `temperature`, `seed`) and request-facing transport controls (e.g. `maxRetries`, `headers`, `timeout`). This made the API harder to understand and the internal preparation helper (`prepareCallSettings`) was misleadingly named since it only validated model-facing fields. ## Summary Splits `CallSettings` into two focused types: - **`ModelCallOptions`** — model-facing generation controls: `maxOutputTokens`, `temperature`, `topP`, `topK`, `presencePenalty`, `frequencyPenalty`, `stopSequences`, `seed`, `reasoning` - **`RequestOptions<TOOLS>`** — request/transport controls: `maxRetries`, `abortSignal`, `headers`, `timeout` This naming also aligns with our newer naming convention pattern of `*Options` (and `*CallOptions` for model call options specifically). `prepareCallSettings` is renamed to `prepareModelCallOptions` to reflect that it only validates model-facing fields. Public surfaces updated to use the split types: `generateText`, `streamText`, `ToolLoopAgentSettings`, `streamUI` (rsc), and `getBaseTelemetryAttributes` (otel). Deprecated object-generation APIs (`generateObject`, `streamObject`, `streamUI`) explicitly omit `timeout` to preserve their current behavior. `CallSettings` and `prepareCallSettings` remain as deprecated aliases for back compat. They will be removed in a future major version. ## Manual Verification Type-level only change — no runtime behavior changes. ## 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 Remove `CallSettings` and `prepareCallSettings` deprecated aliases in a future major version. ## Related Issues Fixes #13777

feat: migrate providers to support new top-level `reasoning` parameter (#13648) ## Background The new top-level `reasoning` parameter was added to the AI SDK spec and core in #13553. Providers need to be migrated to translate this parameter into their native reasoning/thinking configuration. ## Summary Migrates 7 providers to support the new top-level `reasoning` parameter: - **deepseek**: Maps `reasoning` to existing thinking support (already had infrastructure, just needed wiring) - **groq**: Maps `reasoning` to `reasoning_effort` in provider options - **xai**: Maps `reasoning` to `reasoning_effort` for both chat and responses models - **openai-compatible**: Maps `reasoning` to `reasoning_effort` in provider options - **open-responses**: Maps `reasoning` to `reasoning.effort` in the responses format - **alibaba**: Maps `reasoning` to `enable_thinking` + `thinking_budget` via token budget calculation - **cohere**: Maps `reasoning` to `thinking.type` + `thinking.token_budget` via token budget calculation - **fireworks**: Uses **openai-compatible** Together with #13649, this completes the work on #12516. ## Manual Verification Relevant examples were updated or added, then run for verification. ## Checklist - [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 N/A ## Related Issues See #12516.

feat(provider/google): support cancelling long-running Interactions API agents via AbortSignal, and process their intermittent stream (#15139) ## Background PR #15013 added Interactions API support but two background-mode gaps remained: aborting a call didn't stop the run on Google's side (kept billing), and `streamText` against an agent buffered everything until the run finished instead of actually streaming. ## Summary - Poll loop now fires `POST /interactions/{id}/cancel` on abort. - Agent `doStream` now opens `GET /interactions/{id}?stream=true` and reconnects with `last_event_id` on idle disconnects. - Existing `streamText` agent examples switched to `fullStream` with dimmed `reasoning-delta` output; new abort examples + shared SIGINT→AbortController helper. ## Manual Verification - `aif examples/ai-functions/src/stream-text/google/interactions-agent-single-turn.ts` — reasoning prints incrementally. - `aif examples/ai-functions/src/generate-text/google/interactions-agent-abort.ts` — server-reported status flips to `cancelled`. ## 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 - `webhook_config` — deferred until the AI SDK has a fire-and-forget primitive; polling alongside a webhook defeats the point. - `background: true` for model-id calls — API rejects every documented model today, it seems the API only supports this parameter in combination with `agent`.

chore(provider): align V4 model return types to have their own definitions across all model interfaces (#14250) ## Background Many V4 model interfaces in `provider` defined their return types inline inside the `doGenerate`/`doEmbed`/etc. method signatures. This made it cumbersome to reference those types by name elsewhere (requiring `Awaited<ReturnType<ModelV4['doMethod']>>`). It also made them inconsistent with `LanguageModelV4` and `EmbeddingModelV4`, which were already using their own distinct type definitions for their return types. ## Summary Each V4 model interface now has its return type extracted into a dedicated file (e.g. `image-model-v4-result.ts`, `speech-model-v4-result.ts`) and exported by name. This applies to all V4 interfaces: `LanguageModelV4`, `EmbeddingModelV4`, `ImageModelV4`, `VideoModelV4`, `SpeechModelV4`, `TranscriptionModelV4`, `RerankingModelV4`, `FilesV4`, and `SkillsV4`. The `ai` package is updated to use these named types instead of the verbose `Awaited<ReturnType<...>>` pattern. ## Manual Verification N/A — pure type-level refactoring with no runtime behavior changes. ## Checklist - [ ] 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 N/A ## Related Issues N/A

feat(provider): align tool result output content file part types with top-level message file part types (#14921) ## Background In #14733, we unified the different ways to pass file content for top-level `type: 'file'` parts. However, for tool result output content parts, the AI SDK has been still using various independent shapes like `file-*`, and `image-*`, the latter of which were already deprecated in #14411. We should align files being returned as tool result output to work similar to how files are being passed in top-level messages. ## Summary This PR introduces a single canonical `file` content-part variant for tool-result outputs that mirrors the top-level `FilePart`: `{ type: 'file', mediaType, filename?, data: { type: 'data' | 'url' | 'reference' | 'text', ... } }`. - **`provider` (v4 spec)**: `LanguageModelV4ToolResultOutput.value` now carries a single tagged `file` variant. Spec break — atomic update across spec + provider adapters. - **`provider-utils`**: top-level `ToolResultOutput` content array gets the new `file` variant added; every legacy `file-*` and `image-*` variant stays in place and is annotated `@deprecated` with a message pointing at `file`, for back compat. - **`ai` (`mapToolResultOutput`)**: the conversion seam normalizes every legacy case into the new `type: 'file'` shape and emits exactly one `DeprecationWarning` per legacy item. - **`mcp`**: client emits the new shape directly. - **Examples + docs**: every `toModelOutput`-emitting example and the tool-calling guide use the canonical shape. Top-level `ToolResultOutput` is fully backward compatible (legacy variants still accepted; the seam normalizes them with a deprecation warning). The v4 spec change is a breaking change for direct `LanguageModelV4` consumers. ## Manual Verification Examples using `toModelOutput` can be run to verify the changes. ## 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 Eventually remove the deprecated legacy `file-*`/`image-*`/`*-id` content-part variants from `ToolResultOutput` and remove the auto-migration as part of it. ## Related Issues Technically a follow-up to #14010.

feat(provider/google): add support for managed agents in the Interactions API (#15448) ## Background Google just announced support for "Managed Agents" — customizable agents that execute in a sandbox environment, using the Interactions API. They support optional preloaded sources (inline files, repositories, GCS) and configurable network egress. This PR adds support for the new features. A new base agent ID that can be used with these features is `'antigravity-preview-05-2026'`. The PR also corrects two implementation details that were stale once managed agents entered the picture: `background: true` was unconditionally injected for any agent call although managed agents reject it, and the `agent` factory shape used a strict literal union that couldn't accommodate user-defined agent names. ## Summary - Added `'antigravity-preview-05-2026'` to the `GoogleInteractionsAgentName` union (the default managed-agent preset). - New `{ managedAgent: string }` factory shape on `google.interactions(...)` for user-defined agents, keeping the existing `{ agent }` shape strictly typed against known presets. - New `providerOptions.google.environment` option (`'remote'` | `env_id` string | `{ type: 'remote', sources?, network? }`) covering `inline`, `repository`, and `gcs` sources plus `allowlist`/`disabled` network policies. The SDK warns and drops the field on model-id calls. - `background: true` is now opt-in via `providerOptions.google.background` instead of being auto-injected. `doStream` routes through background polling only when the flag is set; otherwise it sends `stream: true` directly. Existing deep-research examples were updated to set the flag explicitly. - New examples have been added, with existing examples being updated for the changes to the `background` parameter. - Google provider docs updated with a new "Managed Agents" subsection and the new `background`/`environment` provider options; the stale "agent calls run with `background: true` on the wire" claim was corrected. - Updated all Interactions API examples and code snippets in documentation that pass `providerOptions` to use the `GoogleLanguageModelInteractionsOptions`, which had been previously missing for all Interactions API code examples ## Manual Verification Run the new examples this PR adds. ## 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 - Consider exposing `/v1beta/agents` CRUD as a first-class resource on the provider. This is currently not reasonable given the AI SDK philosophies, where at least 3 providers should support such an approach. - Consider adding support for downloading environment snapshots via `files/environment-{id}:download`. Not clear whether it's a good idea either, since it does not fit into current AI SDK paradigms.

feat(ai): refresh `customProvider` and `createProviderRegistry` to support file and skill upload abstractions (#14284) ## Background `customProvider` and `createProviderRegistry` had gaps in provider capability coverage: `customProvider` had no way to attach a provider's `files` or `skills` interfaces, `createProviderRegistry` was missing `videoModel` support entirely, and neither exposed `files`/`skills` access through the registry abstraction. This made it impossible to use file and skill upload APIs consistently through these provider management utilities. ## Summary - **`customProvider`**: Added `files` and `skills` options. - **`createProviderRegistry`**: Added `videoModel(providerId:modelId)`, `files(providerId)`, and `skills(providerId)` methods. - Updated provider management docs with examples for all new APIs. - Added 6 new `ai-functions` examples. - Simplified the `ai-e2e-next` upload-file route to use `createProviderRegistry` instead of a hand-rolled provider map. Fully backward compatible. ## Manual Verification Run the new examples. ## 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 N/A ## Related Issues N/A

chore(provider/xai): update provider to use v4 types (#13417) ## Background As part of the ongoing migration from V3 to V4 provider specification types, the `xai` package still referenced V3 types from `provider`. ## Summary Similar to e.g. #13375, this updates the xAI provider to use the V4 spec types. ## Manual Verification N/A ## Checklist - [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 N/A ## Related Issues N/A

chore(anthropic): remove unnecessary messages affix from Anthropic symbols and files (#14712) ## Background The Anthropic provider had a redundant `messages` affix in several internal symbol and file names (e.g. `AnthropicMessagesLanguageModel`, `AnthropicMessagesModelId`, `anthropic-messages-language-model.ts`). While the Anthropic API uses `/messages` as its root, there is no other variant, so including it in the name is not helpful. ## Summary - Rename files, types, and classes accordingly - Maintain back compat for package-level exports by re-exporting as deprecated aliases under the old name ## Manual Verification N/A ## Checklist - [ ] 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)

fix(provider/google): correctly mark reasoning files as such and fix related multi-turn errors (#13262) ## Background When using Gemini thinking models with image output, the Google API returns `thought: true` on non-text parts (e.g. `inlineData` images). The SDK correctly maps `thought: true` on text parts to `type: 'reasoning'`, but silently strips the flag from file parts. This causes problems in multi-turn exchanges: the thought-image gets sent back as a regular image, causing API errors because they're interpreted as regular images but lack thought signatures (which per Google API are only present on the non-reasoning images). ## Summary Since we can't introduce a new part type without a spec change, this preserves the `thought` flag on file parts via `providerMetadata`/`providerOptions`. - Add `thought: z.boolean().nullish()` to the `inlineData` member in the provider-specific response schema - In both `doGenerate` and `doStream`, propagate `thought: true` into `providerMetadata` on file parts (alongside `thoughtSignature`) - In `convertToGoogleGenerativeAIMessages`, read `thought` from `providerMetadata` and send it back to the API on file parts Function examples for `generate-text` and `stream-text` demonstrating multi-step image generation with thinking are added, as well as an E2E example that allows interactive multi-turn with reasoning output that includes the images. ## Manual Verification Test with the new examples to verify; for the E2E example making two turns would result in an error without the `packages` fixes from this PR. ## Checklist - [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 A provider-agnostic mechanism to distinguish thought content from output content regardless of part type (as discussed in #12516) would be the ideal long-term solution, removing the need for provider-specific `providerMetadata` checks. However, this will require a spec change and therefore is only an option for v7 - we should explore that further. ## Related Issues Fixes #11461

chore: fix unused vars not being flagged by our lint tooling (#14329) ## Summary we have a ton of unused variables in our codebase. For some reason, the lint rules to flag these were disabled. This PR fixes only the violations flagged by `oxlint` - it's already a bunch. We can open another PR for the TypeScript flagged problems. `oxlint` finds many false positives in tests, and since this is less important for tests anyway, we can just disable the rule for test files. To reduce the scope, we still ignore those errors in `examples/` for now - also because some of the unused variables in `examples` are intentionally there. ## Checklist - [ ] 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)

fix(provider): fix v4 spec to not use shared v3 types (#13482) ## Background The v4 language model spec types were incorrectly importing and using shared v3 types (`SharedV3ProviderOptions`, `SharedV3ProviderMetadata`, `SharedV3Headers`, `SharedV3Warning`) instead of their v4 equivalents. This meant the v4 spec was not self-contained and depended on v3 shared types. Initially pointed out by @lgrammel in https://github.com/vercel/ai/pull/13352#discussion_r2939793776. ## Summary Updated all v4 language model spec files to import from `shared/v4` instead of `shared/v3`, using the correct `SharedV4*` types throughout.

fix(provider/anthropic): fix remaining errors with Anthropic `code_execution` tool dynamic calls from latest `web_fetch` or `web_search` (#15566) ## Background When Anthropic's `web_fetch` or `web_search` tools internally trigger code execution, the API emits `code_execution` tool calls even though the user did not register that tool. The fix from #12668 marked such calls as `dynamic: true` to bypass validation, but several code paths in the Anthropic language model still emitted unmarked calls, causing errors. The newer `code_execution_20250825` tool variant also surfaces calls under sub-names (`bash_code_execution`, `text_editor_code_execution`) that need the same treatment. ## Summary - Mark `code_execution` tool calls as `dynamic` in all remaining emission sites for the 20250825 tool variant (non-streaming `bash_code_execution`/`text_editor_code_execution` branch, streaming first-delta and end paths, and streaming `tool-call` finalization). - Normalize the streaming delta path to use the unified `code_execution` provider tool name and consistently backfill input with `"type": "programmatic-tool-call"` so downstream consumers see a consistent shape. - Only set `firstDelta: true` when no input has been buffered yet, avoiding double-prefixing. This was not surfacing in a real bug so far, but it was clearly also an oversight (per `firstDelta: true` only ever being okay if there was no input yet on that same chunk). ## Manual Verification Run the existing examples: - `examples/ai-functions/src/stream-text/anthropic/web-fetch-20260209-pdf.ts` - `examples/ai-functions/src/stream-text/anthropic/web-fetch-20260209-pdf.ts` Without this PR, they will somewhere in the stream include the error about an incompatible tool being found, most times when executing them. With this PR, this error is gone from both. ## Checklist - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [ ] 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)