ai 7.0.127 → 7.0.129

package/docs/03-ai-sdk-core/16-mcp-tools.mdx

@@ -203,6 +203,11 @@ authorization and reads the stored tokens again.
 The SDK also provides this context when invalidating stored tokens that lack an
 authorization server pin. Other invalidations can omit the context.
 
+If an authorization-code exchange returns `invalid_grant`, the SDK propagates
+the error without invalidating stored credentials or retrying the rejected code.
+A rejected authorization code does not indicate that existing access or refresh
+tokens are invalid.
+
 ### OAuth Authorization Server Validation
 
 When using MCP OAuth in server-side applications, the MCP server can advertise
@@ -314,6 +319,45 @@ invalid tool arguments, are surfaced immediately without retrying. Successful
 MCP tool responses with `isError: true` are also returned to the model without
 retrying.
 
+`maxRetries` applies to `tools/call` requests, not to client initialization.
+The following example identifies potentially transient HTTP initialization
+failures using the exported `MCPClientError` type guard:
+
+```typescript
+import { createMCPClient, MCPClientError } from '@ai-sdk/mcp';
+
+try {
+  await createMCPClient({
+    transport: {
+      type: 'http',
+      url: 'https://your-server.com/mcp',
+    },
+  });
+} catch (error) {
+  if (
+    !MCPClientError.isInstance(error) ||
+    error.code != null ||
+    error.statusCode == null ||
+    !(
+      error.statusCode === 408 ||
+      error.statusCode === 409 ||
+      error.statusCode === 429 ||
+      error.statusCode >= 500
+    )
+  ) {
+    throw error;
+  }
+
+  // Retry according to your application's backoff policy.
+}
+```
+
+This example only considers HTTP statuses. A missing `statusCode` does not
+establish that a failure is transient: configuration errors, protocol errors,
+and cancelled requests can also lack an HTTP status. Network and timeout
+retries require a separate application policy. OAuth errors such as
+`UnauthorizedError` and `MCPClientOAuthError` are rethrown by this example.
+
 <Note type="warning">
   Only enable retries for MCP tools where retrying is safe. Retrying
   non-idempotent tools, such as tools that send emails or create records, can

package/docs/03-ai-sdk-core/17-runtime-and-tool-context.mdx

@@ -16,14 +16,14 @@ should affect execution.
 
 ## Context Types
 
-| Concept                           | Where you define it                                                | Where you read it                                                                               | Use it for                                                    |
-| --------------------------------- | ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------- |
-| `runtimeContext`                  | `generateText`, `streamText`, or `ToolLoopAgent` calls             | `prepareStep`, lifecycle callbacks, step results, and telemetry                                 | Shared generation or agent state                              |
-| `toolsContext`                    | `generateText`, `streamText`, or `ToolLoopAgent` calls             | `prepareStep`, approval callbacks, tool context resolution, and tool description functions      | A map of per-tool context values keyed by tool name           |
-| tool `context`                    | Each tool's `toolsContext` entry, validated by its `contextSchema` | Tool description functions, tool `execute`, `needsApproval`, and tool input lifecycle callbacks | Values needed by one tool                                     |
-| `toolContext`                     | Derived from one tool's context                                    | Tool approval callbacks and tool execution events                                               | The event/callback name for one tool's context                |
-| `telemetry.includeRuntimeContext` | The generation or agent call                                       | Telemetry filtering                                                                             | Top-level `runtimeContext` properties to include in telemetry |
-| `telemetry.includeToolsContext`   | The generation or agent call                                       | Telemetry filtering                                                                             | Top-level tool context properties to include in telemetry     |
+| Concept                           | Where you define it                                                             | Where you read it                                                                               | Use it for                                                    |
+| --------------------------------- | ------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------- |
+| `runtimeContext`                  | `generateText` or `streamText` calls; `ToolLoopAgent` settings or `prepareCall` | `prepareStep`, lifecycle callbacks, step results, and telemetry                                 | Shared generation or agent state                              |
+| `toolsContext`                    | `generateText` or `streamText` calls; `ToolLoopAgent` settings or `prepareCall` | `prepareStep`, approval callbacks, tool context resolution, and tool description functions      | A map of per-tool context values keyed by tool name           |
+| tool `context`                    | Each tool's `toolsContext` entry, validated by its `contextSchema`              | Tool description functions, tool `execute`, `needsApproval`, and tool input lifecycle callbacks | Values needed by one tool                                     |
+| `toolContext`                     | Derived from one tool's context                                                 | Tool approval callbacks and tool execution events                                               | The event/callback name for one tool's context                |
+| `telemetry.includeRuntimeContext` | The generation call or `ToolLoopAgent` settings                                 | Telemetry filtering                                                                             | Top-level `runtimeContext` properties to include in telemetry |
+| `telemetry.includeToolsContext`   | The generation call or `ToolLoopAgent` settings                                 | Telemetry filtering                                                                             | Top-level tool context properties to include in telemetry     |
 
 In agents, `runtimeContext` is the agent's shared runtime state. It flows
 through the loop and can be read or updated in `prepareStep` between model
@@ -31,7 +31,7 @@ calls. Tool-specific data stays in `toolsContext`, where each tool receives only
 its own validated `context`.
 
 ```txt
-generateText / streamText / ToolLoopAgent
+generateText / streamText / ToolLoopAgent settings
   -> runtimeContext
        -> prepareStep, lifecycle callbacks, step results
        -> telemetry, filtered by telemetry.includeRuntimeContext
@@ -123,6 +123,10 @@ Treat tool context as immutable inside tools. If you need to change tool context
 between steps, inspect the previous step in `prepareStep` and return an updated
 `toolsContext`.
 
+For `ToolLoopAgent`, set context in the constructor. For context that changes
+with each invocation, use `callOptionsSchema` and `prepareCall`. See
+[Configuring Call Options](/docs/agents/configuring-call-options).
+
 ## Telemetry Context Filtering
 
 Context often contains values that are useful inside your application but should
@@ -131,7 +135,7 @@ include selected top-level runtime context properties in telemetry, and
 `telemetry.includeToolsContext` to include selected top-level tool context
 properties per tool.
 
-```ts highlight="34-43"
+```ts
 import { ToolLoopAgent, tool } from 'ai';
 import { z } from 'zod';
 
@@ -156,10 +160,6 @@ const customerLookup = tool({
 const agent = new ToolLoopAgent({
   model: __MODEL__,
   tools: { customerLookup },
-});
-
-const result = await agent.generate({
-  prompt: 'Check whether customer cust_123 is eligible for priority support.',
   runtimeContext: {
     requestId: 'req_abc',
     tenantId: 'tenant_123',
@@ -182,6 +182,10 @@ const result = await agent.generate({
     },
   },
 });
+
+const result = await agent.generate({
+  prompt: 'Check whether customer cust_123 is eligible for priority support.',
+});
 ```
 
 In this example, telemetry receives `runtimeContext` with only `requestId` and the

package/docs/03-ai-sdk-core/25-settings.mdx

@@ -101,9 +101,10 @@ Controls how much reasoning the model performs before generating a response.
 | `'low'`              | Fast, concise reasoning                                              |
 | `'medium'`           | Balanced reasoning                                                   |
 | `'high'`             | Thorough reasoning                                                   |
-| `'xhigh'`            | Maximum reasoning                                                    |
+| `'xhigh'`            | Extra-high reasoning                                                 |
+| `'max'`              | Maximum reasoning                                                    |
 
-If you also set reasoning-related options in `providerOptions` (e.g. `openai.reasoningEffort` or `anthropic.thinking`), the provider-specific options take precedence and the top-level `reasoning` parameter is ignored.
+Provider-specific settings take precedence over the corresponding fields derived from `reasoning`. Partial configurations can still use portable reasoning to fill missing fields; summary and display options can be used alongside it. For example, Bedrock preserves an explicit thinking budget while deriving a missing enabled type from portable reasoning.
 
 See the [reasoning guide](/docs/ai-sdk-core/reasoning) for details on per-provider mapping and migration from `providerOptions`.
 

package/docs/03-ai-sdk-core/26-reasoning.mdx

@@ -29,7 +29,8 @@ The `reasoning` parameter accepts the following values:
 | `'low'`              | Fast, concise reasoning                                              |
 | `'medium'`           | Balanced reasoning                                                   |
 | `'high'`             | Thorough reasoning                                                   |
-| `'xhigh'`            | Maximum reasoning                                                    |
+| `'xhigh'`            | Extra-high reasoning                                                 |
+| `'max'`              | Maximum reasoning                                                    |
 
 ## Streaming
 
@@ -55,7 +56,7 @@ for await (const part of result.stream) {
 
 ## Precedence Rules
 
-The top-level `reasoning` parameter and provider-specific `providerOptions` are **never merged**. If you set reasoning-related options in `providerOptions`, they take full precedence and the top-level `reasoning` parameter is ignored.
+Provider-specific settings take precedence over the corresponding fields derived from `reasoning`. Partial configurations may still use portable reasoning to fill missing fields; summary and display settings can be used alongside it.
 
 ```ts
 import { generateText } from 'ai';
@@ -77,9 +78,15 @@ This design lets you use the portable `reasoning` parameter by default and fall
 
 ## Provider Support
 
-The `reasoning` parameter is supported by the following providers: OpenAI, Anthropic, Google, xAI, Groq, DeepSeek, Fireworks, Amazon Bedrock, and Perplexity. Each provider translates the value to its native reasoning API. Some providers support all six levels natively, while others coerce to fewer levels (a warning is emitted when coercion occurs). Some providers use a numeric token budget instead of an enum for reasoning control; in those cases the top-level `reasoning` value is mapped to a budget calculated as a percentage of the model's maximum output tokens.
+The `reasoning` parameter is supported by providers including OpenAI, Anthropic, Google, xAI, Groq, DeepSeek, Moonshot AI, Fireworks, Amazon Bedrock, Mistral, Cohere, Alibaba, Open Responses, OpenAI Compatible, and Perplexity. Each provider translates the value to its native reasoning API.
 
-Providers that do not support reasoning (e.g. Mistral and Cohere) emit an `unsupported` warning and ignore the parameter.
+Providers with a distinct native maximum tier, such as supported OpenAI, Anthropic, DeepSeek, and Moonshot AI models, receive `'max'` directly. Amazon Bedrock preserves `'max'` for its Anthropic and OpenAI effort mappings, while Amazon Nova 2 maps `'xhigh'` and `'max'` to `'high'` with a compatibility warning. Providers whose highest native tier is lower coerce `'max'` to their closest supported tier and emit a compatibility warning when their adapter supports warning propagation. OpenAI-compatible and Open Responses endpoints receive `'max'` directly so compatible servers can interpret it.
+
+Some providers use a numeric token budget instead of an enum for reasoning control. In those cases, `'max'` maps to 95% of the model's maximum output tokens by default, subject to the provider's minimum and maximum reasoning budget limits.
+
+Maximum reasoning can substantially increase token usage, latency, cost, and the chance of reaching request or output limits. Use it when the model's additional reasoning depth is worth those tradeoffs.
+
+Providers and models that do not support reasoning configuration emit an `unsupported` warning and ignore the parameter.
 
 ## Migrating from `providerOptions`
 
@@ -188,4 +195,4 @@ const { text } = await generateText({
 });
 ```
 
-Note that `providerOptions` can still be used alongside `reasoning` for provider-specific features unrelated to reasoning effort. However, if `providerOptions` includes reasoning effort/budget settings (e.g. `reasoningEffort`, `thinking`, `thinkingConfig.thinkingBudget`), those take full precedence and the top-level `reasoning` parameter is ignored.
+You can combine `providerOptions` with `reasoning` for provider-specific features such as reasoning summaries or display settings. Explicit effort or budget values override the corresponding mapped fields; partial configurations may still use portable reasoning to fill missing fields. See [Precedence Rules](#precedence-rules) for details.

package/docs/03-ai-sdk-core/{32-evaluation.mdx → 32-decisions.mdx}

@@ -1,24 +1,24 @@
 ---
-title: Evaluation
-description: Evaluate Choice, Score, and Boolean questions against shared state.
+title: Decisions
+description: Decide answers to Choice, Score, and Boolean questions against shared state.
 ---
 
-# Evaluation
+# Decisions
 
-`experimental_evaluate` evaluates named questions against one shared state using
-an evaluation model. State can be a string, JSON object, or JSON array. An array
+`experimental_decide` decides answers to named questions against one shared state using
+a decision model. State can be a string, JSON object, or JSON array. An array
 is one state, not a batch of unrelated inputs.
 
-This API and the evaluation model specification are experimental and may change
-in patch releases. Pass an evaluation model instance, resolve a model through a
+This API and the decision model specification are experimental and may change
+in patch releases. Pass a decision model instance, resolve a model through a
 provider registry, or use a string ID. Strings resolve through Vercel AI Gateway
-unless you configure an evaluation-capable default provider.
+unless you configure a decision-capable default provider.
 
 ```ts
-import { experimental_evaluate, type Experimental_EvaluationModel } from 'ai';
+import { experimental_decide, type Experimental_DecisionModel } from 'ai';
 
-async function triage(model: Experimental_EvaluationModel, message: string) {
-  return experimental_evaluate({
+async function triage(model: Experimental_DecisionModel, message: string) {
+  return experimental_decide({
     model,
     state: { message },
     questions: {
@@ -46,34 +46,31 @@ async function triage(model: Experimental_EvaluationModel, message: string) {
 
 ## Provider models
 
-Use a provider's `evaluationModel` factory:
-
-| Provider    | Example model                                            |
-| ----------- | -------------------------------------------------------- |
-| TypeSafe AI | `typeSafeAi.evaluationModel('jev-latest')`               |
-| OpenAI      | `openai.evaluationModel('gpt-5.6-luna')`                 |
-| Anthropic   | `anthropic.evaluationModel('claude-haiku-4-5-20251001')` |
-| Google      | `google.evaluationModel('gemini-3.5-flash-lite')`        |
-
-TypeSafe AI's [Jev](https://vercel.com/i/what-is-jev) supplies native Choice, Score, and Boolean evaluations. OpenAI,
-Anthropic, and Google adapt structured language-model output for all three types.
-Boolean answers contain prompted estimates of P(true), validated to be finite
-and in `[0, 1]`. These estimates are not guaranteed to be calibrated. Choice and
-Score answers do not include probability distributions. Select a model that
-supports the provider's structured-output API; judge quality against your own
-labeled examples before choosing a model for a task.
-
-The language-model adapters evaluate all questions in one prompt. They do not
-provide TypeSafe's native independent-question execution semantics. The example
-model IDs demonstrate API compatibility; they are not benchmark-selected defaults.
-
-Language-model adapters request `reasoning: 'none'` by default. Each provider
-maps this setting to its model's reasoning controls; it does not guarantee that
-every model runs without thinking. To enable reasoning for more demanding
-evaluations, pass the model's supported reasoning settings through
-`providerOptions`, which take precedence over this default. For example, use
-`providerOptions: { openai: { reasoningEffort: 'high' } }` with an OpenAI model
-that supports that effort.
+Use a provider's `decisionModel` factory:
+
+| Provider    | Example model                                          |
+| ----------- | ------------------------------------------------------ |
+| TypeSafe AI | `typeSafeAi.decisionModel('jev-latest')`               |
+| OpenAI      | `openai.decisionModel('gpt-6-luna')`                   |
+| Anthropic   | `anthropic.decisionModel('claude-haiku-4-5-20251001')` |
+| Google      | `google.decisionModel('gemini-3.5-flash-lite')`        |
+
+TypeSafe AI's [Jev](https://vercel.com/i/what-is-jev) and OpenAI's
+[Decisions API](https://developers.openai.com/api/docs/guides/decisions)
+supply native Choice, Score, and Boolean decisions. Each question is evaluated
+independently. Choice and Score answers include native probability distributions.
+
+Anthropic and Google adapt structured language-model output for all three types,
+evaluating all questions in one prompt. Their Boolean answers contain prompted
+estimates of P(true), and Choice and Score answers omit probability distributions.
+Select a model that supports the provider's structured-output API and judge quality
+against your own labeled examples before choosing a model for a task.
+
+The Anthropic and Google language-model adapters request `reasoning: 'none'` by
+default. Each provider maps this setting to its model's reasoning controls. Pass
+supported reasoning settings through `providerOptions` to override this default.
+OpenAI decision models use the Decisions endpoint and do not accept Responses
+API reasoning options.
 
 ## Model aliases and registries
 
@@ -86,22 +83,22 @@ import { openai } from '@ai-sdk/openai';
 import {
   customProvider,
   createProviderRegistry,
-  experimental_evaluate,
+  experimental_decide,
 } from 'ai';
 
 const registry = createProviderRegistry({
   triage: customProvider({
-    evaluationModels: {
-      native: typeSafeAi.evaluationModel('jev-latest'),
-      compact: openai.evaluationModel('gpt-6-luna'),
+    decisionModels: {
+      native: typeSafeAi.decisionModel('jev-latest'),
+      compact: openai.decisionModel('gpt-6-luna'),
     },
     fallbackProvider: typeSafeAi,
   }),
   openai,
 });
 
-const result = await experimental_evaluate({
-  model: registry.evaluationModel('triage:native'),
+const result = await experimental_decide({
+  model: registry.decisionModel('triage:native'),
   state: 'I was charged twice.',
   questions: {
     department: {
@@ -118,10 +115,10 @@ result.answers.department.choice; // 'billing' | 'support'
 Registry IDs use `providerId:modelId`; the `separator` option changes the
 separator. Only the first separator is used, so model IDs can contain it.
 Custom aliases take precedence over a fallback provider. A fallback only resolves
-unknown model IDs; it does not retry failed evaluations or substitute a model
+unknown model IDs; it does not retry failed decisions or substitute a model
 when a question type is unsupported. Registered providers keep their own
 credentials and settings. Registry language/image middleware does not wrap
-evaluation models.
+decision models.
 
 ### Default-provider strings
 
@@ -129,9 +126,9 @@ String IDs use Vercel AI Gateway by default. Configure Gateway authentication
 with `AI_GATEWAY_API_KEY` or Vercel OIDC, then pass a Gateway model ID:
 
 ```ts
-import { experimental_evaluate } from 'ai';
+import { experimental_decide } from 'ai';
 
-const result = await experimental_evaluate({
+const result = await experimental_decide({
   model: 'typesafe-ai/jev',
   state: 'I was charged twice. Please refund the extra charge.',
   questions: {
@@ -149,10 +146,10 @@ provider once at application startup:
 ```ts
 // Using the registry above, expose an alias through a custom provider:
 globalThis.AI_SDK_DEFAULT_PROVIDER = customProvider({
-  evaluationModels: { native: registry.evaluationModel('triage:native') },
+  decisionModels: { native: registry.decisionModel('triage:native') },
 });
 
-const result = await experimental_evaluate({
+const result = await experimental_decide({
   model: 'native',
   state: 'I was charged twice.',
   questions: {
@@ -165,20 +162,20 @@ const result = await experimental_evaluate({
 ```
 
 A direct provider such as `typeSafeAi` can also be the default; then use its
-unprefixed model ID, such as `'jev-latest'`. String values in `evaluationModels`
+unprefixed model ID, such as `'jev-latest'`. String values in `decisionModels`
 also resolve through this global default. Prefer model instances in aliases to
 avoid resolution cycles. Global configuration affects other AI SDK functions
 too; avoid changing it per request in a shared process.
 
-An explicitly configured default provider must expose an `evaluationModel`
+An explicitly configured default provider must expose a `decisionModel`
 method; Gateway is used only when no default provider is configured. Missing
-registry providers throw `NoSuchProviderError`; missing models or evaluation
+registry providers throw `NoSuchProviderError`; missing models or decision
 capabilities throw
-`NoSuchModelError` with `modelType: 'evaluationModel'`. Unsupported model versions
+`NoSuchModelError` with `modelType: 'decisionModel'`. Unsupported model versions
 throw `UnsupportedModelVersionError`, including models returned by registries.
 The stable `ProviderV4` and `ProviderRegistryProvider` interfaces are unchanged;
-keep the inferred registry type, or use `Experimental_EvaluationProviderRegistry`,
-to retain its experimental `evaluationModel` method.
+keep the inferred registry type, or use `Experimental_DecisionProviderRegistry`,
+to retain its experimental `decisionModel` method.
 
 ## Question types
 
@@ -214,7 +211,7 @@ are preserved, never silently normalized.
 Choice and Score distributions are optional. Boolean probability is required:
 `0.98` means a strong yes and `0.02` means a strong no. It is not confidence in
 either outcome. The SDK does not promise calibration across providers. Structured
-language-model adapters prompt the model to estimate P(true); native evaluation providers return
+language-model adapters prompt the model to estimate P(true); native decision providers return
 their API probabilities. Provider-specific confidence statistics belong
 in `providerMetadata`. TypeSafe exposes its separate Choice/Score confidence
 statistic at `result.providerMetadata?.typesafe?.confidence`, keyed by question
@@ -245,34 +242,34 @@ if (result.answers.requestsRefund.probability >= 0.8) {
 
 The model's `supportedQuestionTypes` are checked before calling the provider.
 Any unsupported question fails the entire call with
-`Experimental_EvaluationUnsupportedQuestionTypeError`. Successful calls return
+`Experimental_DecisionUnsupportedQuestionTypeError`. Successful calls return
 an answer for every question; there is no partial success, and Core does not
 substitute models automatically.
 
 Invalid inputs throw `InvalidArgumentError`. Missing answers, mismatched answer
 types, invalid options, scores, or probabilities throw `InvalidResponseDataError`.
 Transient provider failures use the normal retry policy (`maxRetries: 2` by
-default). Use `abortSignal` to cancel evaluation, `headers` for request headers,
+default). Use `abortSignal` to cancel the decisions request, `headers` for request headers,
 and `providerOptions` for provider-specific settings.
 
 The result includes `usage`, `warnings`, `providerMetadata`, and `response`.
 Unknown token counts stay `undefined`; `totalTokens` is available only when both
 input and output counts are known.
 
-For tests, use `Experimental_EvaluationMockModelV4` from `ai/test`.
+For tests, use `Experimental_DecisionMockModelV4` from `ai/test`.
 
 ## Scope and examples
 
-Evaluation currently returns one complete result for one shared state. It does
+`experimental_decide` currently returns one complete result for one shared state. It does
 not stream answers, perform multilabel classification, or batch unrelated
 states. Run separate calls for separate states. Provider support and judgment
 quality depend on the chosen model. Core does not choose another model, but a
 provider can implement routing through its provider options. For example, AI
-Gateway supports conditional evaluation fallbacks under
+Gateway supports conditional decision fallbacks under
 `providerOptions.gateway.models`.
 
 Runnable examples are in
-[`examples/ai-functions/src/evaluate`](https://github.com/vercel/ai/tree/main/examples/ai-functions/src/evaluate),
+[`examples/ai-functions/src/decide`](https://github.com/vercel/ai/tree/main/examples/ai-functions/src/decide),
 including basic examples for TypeSafe, OpenAI, Anthropic, and Google, model
 registries, custom aliases, default-provider strings, and probability-based routing.
 
@@ -281,7 +278,7 @@ registries, custom aliases, default-provider strings, and probability-based rout
 Explore use cases, implementation guides, and a deployable template for using
 Jev from TypeSafe AI with the AI SDK:
 
-- [Jev use cases](https://vercel.com/i/jev-use-cases): Explore ideas for applying evaluation in your application.
-- [Classify, route, and score with Jev and AI SDK](https://vercel.com/kb/guide/typesafe-jev-and-ai-sdk): Learn how to ask typed questions, route answers using probabilities, and test routing logic with a mock evaluation model.
+- [Jev use cases](https://vercel.com/i/jev-use-cases): Explore ideas for applying decisions in your application.
+- [Classify, route, and score with Jev and AI SDK](https://vercel.com/kb/guide/typesafe-jev-and-ai-sdk): Learn how to ask typed questions, route answers using probabilities, and test routing logic with a mock decision model.
 - [Jev and AI SDK form router guide](https://vercel.com/kb/guide/jev-ai-sdk-form-router): Explore form routing with Jev and the AI SDK.
-- [Jev and AI SDK form router template](https://vercel.com/templates/next.js/jev-and-ai-sdk): Deploy a Next.js application that routes form submissions with Jev and uses a language model fallback for uncertain or failed evaluations.
+- [Jev and AI SDK form router template](https://vercel.com/templates/next.js/jev-and-ai-sdk): Deploy a Next.js application that routes form submissions with Jev and uses a language model fallback for uncertain or failed decisions.

package/docs/03-ai-sdk-core/35-image-generation.mdx

@@ -308,7 +308,7 @@ __PROVIDER_IMPORT__;
 const model = wrapImageModel({
   model: __IMAGE_MODEL__,
   middleware: {
-    specificationVersion: 'v3',
+    specificationVersion: 'v4',
     transformParams: async ({ params }) => ({
       ...params,
       size: params.size ?? '1024x1024',
@@ -378,9 +378,11 @@ for (const file of result.files) {
 | [Google](/providers/ai-sdk-providers/google#image-models)                       | `gemini-2.5-flash-image`                                     | 1:1, 2:3, 3:2, 3:4, 4:3, 4:5, 5:4, 9:16, 16:9, 21:9                                                                                                                 |
 | [Google](/providers/ai-sdk-providers/google#image-models)                       | `gemini-3-pro-image-preview`                                 | 1:1, 2:3, 3:2, 3:4, 4:3, 4:5, 5:4, 9:16, 16:9, 21:9                                                                                                                 |
 | [Google](/providers/ai-sdk-providers/google#image-models)                       | `gemini-3.1-flash-image-preview`                             | 1:1, 2:3, 3:2, 3:4, 4:3, 4:5, 5:4, 9:16, 16:9, 21:9                                                                                                                 |
+| [Google](/providers/ai-sdk-providers/google#image-models)                       | `gemini-nano-banana-2.1`                                     | 1:1, 2:3, 3:2, 3:4, 4:3, 4:5, 5:4, 9:16, 16:9, 21:9, 1:8, 8:1, 1:4, 4:1                                                                                             |
 | [Google Vertex](/providers/ai-sdk-providers/google-vertex#image-models)         | `gemini-2.5-flash-image`                                     | 1:1, 2:3, 3:2, 3:4, 4:3, 4:5, 5:4, 9:16, 16:9, 21:9                                                                                                                 |
 | [Google Vertex](/providers/ai-sdk-providers/google-vertex#image-models)         | `gemini-3-pro-image-preview`                                 | 1:1, 2:3, 3:2, 3:4, 4:3, 4:5, 5:4, 9:16, 16:9, 21:9                                                                                                                 |
 | [Google Vertex](/providers/ai-sdk-providers/google-vertex#image-models)         | `gemini-3.1-flash-image-preview`                             | 1:1, 2:3, 3:2, 3:4, 4:3, 4:5, 5:4, 9:16, 16:9, 21:9                                                                                                                 |
+| [Google Vertex](/providers/ai-sdk-providers/google-vertex#image-models)         | `gemini-nano-banana-2.1`                                     | 1:1, 2:3, 3:2, 3:4, 4:3, 4:5, 5:4, 9:16, 16:9, 21:9, 1:8, 8:1, 1:4, 4:1                                                                                             |
 | [Fireworks](/providers/ai-sdk-providers/fireworks#image-models)                 | `accounts/fireworks/models/flux-1-dev-fp8`                   | 1:1, 2:3, 3:2, 4:5, 5:4, 16:9, 9:16, 9:21, 21:9                                                                                                                     |
 | [Fireworks](/providers/ai-sdk-providers/fireworks#image-models)                 | `accounts/fireworks/models/flux-1-schnell-fp8`               | 1:1, 2:3, 3:2, 4:5, 5:4, 16:9, 9:16, 9:21, 21:9                                                                                                                     |
 | [Fireworks](/providers/ai-sdk-providers/fireworks#image-models)                 | `accounts/fireworks/models/playground-v2-5-1024px-aesthetic` | 640x1536, 768x1344, 832x1216, 896x1152, 1024x1024, 1152x896, 1216x832, 1344x768, 1536x640                                                                           |

package/docs/03-ai-sdk-core/45-provider-management.mdx

@@ -469,12 +469,12 @@ const result = await streamText({
 
 This simplifies provider usage and makes it easier to switch between providers without changing your model references throughout your codebase.
 
-## Experimental evaluation models
-
-Custom providers accept `evaluationModels` aliases, and registries expose
-`evaluationModel('provider:model')`. These methods return model instances for
-`experimental_evaluate`. Direct string IDs use Gateway by default, or an
-explicitly configured default provider with an `evaluationModel` method. Registry
-middleware for language and image models does not apply to evaluation.
-See [Evaluation](/docs/ai-sdk-core/evaluation#model-aliases-and-registries)
+## Experimental decision models
+
+Custom providers accept `decisionModels` aliases, and registries expose
+`decisionModel('provider:model')`. These methods return model instances for
+`experimental_decide`. Direct string IDs use Gateway by default, or an
+explicitly configured default provider with a `decisionModel` method. Registry
+middleware for language and image models does not apply to decision.
+See [Decisions](/docs/ai-sdk-core/decisions#model-aliases-and-registries)
 for aliases, default-provider configuration, and capability differences.