@ai-sdk/provider 4.x breaking changes: 4.0.22 to 4.0.29

@ai-sdk/provider 4.0.22: Experimental_EvaluationModelV4 and its types are deprecated

@ai-sdk/provider 4.0.22 released 5 October 2026Published 5 October 2026

@ai-sdk/provider 4.0.22 renames the experimental evaluation model to a decision model and deprecates the seven old exports. All seven are still exported and still work, so nothing breaks on upgrade. Every import of an Experimental_Evaluation name from @ai-sdk/provider now carries a deprecation, and anyone who implements the model has a method to rename.

What changed

• Five types and one error class have Experimental_Decision replacements. Experimental_EvaluationModelV4Answer, Experimental_EvaluationModelV4CallOptions, Experimental_EvaluationModelV4Input, Experimental_EvaluationModelV4Question and Experimental_EvaluationModelV4Result are now aliases of the matching Experimental_DecisionModelV4Answer, Experimental_DecisionModelV4CallOptions, Experimental_DecisionModelV4Input, Experimental_DecisionModelV4Question and Experimental_DecisionModelV4Result. Experimental_EvaluationUnsupportedQuestionTypeError is the same kind of alias of Experimental_DecisionUnsupportedQuestionTypeError, as both a value and a type.
• The model type changes shape, not just name. Experimental_EvaluationModelV4 is now Experimental_DecisionModelV4 with doEvaluate where doDecide was. Code that implements the model must rename that method when it moves to the new name.

Before and after

An import of one of the deprecated names:

import { Experimental_EvaluationModelV4 } from '@ai-sdk/provider';

After the rename, the same import uses the replacement the 4.0.22 declarations name:

import { Experimental_DecisionModelV4 } from '@ai-sdk/provider';

For a model you implement, the method moves with the type. At 4.0.21 the interface declared doEvaluate; at 4.0.22 the new type declares doDecide:

// 4.0.21
doEvaluate(options: EvaluationModelV4CallOptions): PromiseLike<EvaluationModelV4Result>;

// 4.0.22
doDecide(options: DecisionModelV4CallOptions): PromiseLike<DecisionModelV4Result>;

The other five types and the error class change only the name in the import and wherever the name is used.

Migration guidance and its limits

All seven rewrites are assisted. Emendant writes them only when you name a model provider, on the command line or in emendant.json. Without one, each import is reported with the guidance and nothing is changed. A patch is checked with your typecheck and tests.

Rename the type and the imports first, then rename doEvaluate to doDecide on any object you build against Experimental_EvaluationModelV4. A model that is only passed around and never implemented needs the name change alone.

The scan reports named imports from @ai-sdk/provider. A name imported from another module, or an unrelated import renamed locally to one of these names, is not reported. A clean scan does not show that nothing else in your code depends on the evaluation names, and it says nothing about the rest of 4.0.22.

What Emendant detects, fixes and verifies

7 changes in @ai-sdk/provider 4.0.22. 0 automatic fixes, 7 fixes requiring a model provider you choose, 0 report only. Each patch states which checks passed. Understand patch evidence.

emendant explain <change-id> prints any row's entry, guidance and sources at the terminal.

Requires emendant@0.3.0 or later. Feed entry feed/npm/@ai-sdk/provider/4.0.22.json, snapshot 2026-10-05.1.

Primary sources

• @ai-sdk/provider@4.0.22npm registry, the published package
• @ai-sdk/provider@4.0.21npm registry, the published package

@ai-sdk/provider 4.0.25: decision and evaluation call options now take state as content parts

@ai-sdk/provider 4.0.25 released 8 October 2026Published 8 October 2026

Release 4.0.25 changes the type of state on Experimental_DecisionModelV4CallOptions and Experimental_EvaluationModelV4CallOptions. It was a string, JSON object or JSON array. It is now a list of text, file or JSON parts. This affects code that implements or calls an experimental decision model with these options.

What changed

• state is a list of parts. In 4.0.24 state was DecisionModelV4Input. In 4.0.25 it is DecisionModelV4State, a readonly list whose entries are a LanguageModelV4TextPart, a LanguageModelV4FilePart or { type: 'json', value }. A bare string or object no longer type-checks.
• The evaluation options change with it. Experimental_EvaluationModelV4CallOptions is an alias of the decision options, so it carries the same change. Its Input alias is deprecated in favour of Experimental_DecisionModelV4Input.

Before and after

The declaration in 4.0.24:

type DecisionModelV4CallOptions = {
  state: DecisionModelV4Input; // string | JSON object | JSON array
  // ...
};

And in 4.0.25:

type DecisionModelV4CallOptions = {
  state: DecisionModelV4State; // readonly (text part | file part | json part)[]
  // ...
};

A call that passed text as state wraps it in a part:

state: [{ type: 'text', text: 'The reply the customer received.' }],

A JSON object becomes [{ type: 'json', value: yourObject }]. Code that reads state in a model implementation now receives parts, so a string check on it needs to look at each part’s type.

Migration guidance and its limits

Both findings carry assisted fixes, so emendant fix asks a model once you name a provider on the command line or in emendant.json. Without one, each finding is reported with its guidance and nothing is sent anywhere. Emendant checks each patch in a copy of your repository at 4.0.25 and withholds patches that fail. Read the patch header to see which checks passed.

The scan reports each place that names one of the two options types imported from @ai-sdk/provider. Naming the type does not mean state reaches that code. Code that only passes the options through, or never touches state, may need no edit, and a patch may not be available there.

Where state is built or read, a patch can wrap values in parts. Review the choice between a text part and a JSON part, since the right one depends on how your model implementation reads it. A clean scan does not cover options types reached through your own re-exports. This page covers the two changes the feed carries for 4.0.25, both type-level.

What Emendant detects, fixes and verifies

2 changes in @ai-sdk/provider 4.0.25. 0 automatic fixes, 2 fixes requiring a model provider you choose, 0 report only. Each patch states which checks passed. Understand patch evidence.

emendant explain <change-id> prints any row's entry, guidance and sources at the terminal.

Requires emendant@0.3.0 or later. Feed entry feed/npm/@ai-sdk/provider/4.0.25.json, snapshot 2026-10-08.2.

Primary sources

• @ai-sdk/provider@4.0.25npm registry, the published package
• @ai-sdk/provider@4.0.24npm registry, the published package

@ai-sdk/provider 4.0.29: supportedQuestionTypes changed on Experimental_EvaluationModelV4 and Experimental_DecisionModelV4

@ai-sdk/provider 4.0.29 released 16 October 2026Published 17 October 2026

Release 4.0.29 of @ai-sdk/provider changes how supportedQuestionTypes is typed on Experimental_EvaluationModelV4 and Experimental_DecisionModelV4. The release adds a box decision question type. Code that implements either model, or reads that member, may stop type-checking after the upgrade.

What changed

• Experimental_DecisionModelV4. The changelog for 4.0.29 adds a box decision question type with image bounds. supportedQuestionTypes on this model is declared in terms of DecisionModelV4Question, so the list of question types a model can claim now covers the new kind.
• Experimental_EvaluationModelV4. This type is built from the decision model, so it carries the same supportedQuestionTypes change. Both findings are breaking.
• What the scan reports. Each place that names either type imported from @ai-sdk/provider is reported. Naming the type does not mean a changed member reaches that code, so some reports will turn out to need no edit.

Before and after

Neither finding has a deterministic rewrite. The code the scan reports is any type position that names one of the two types:

import type { Experimental_EvaluationModelV4 } from '@ai-sdk/provider';

The member sits in the 4.0.29 declaration of the decision model as:

readonly supportedQuestionTypes: readonly DecisionModelV4Question['type'][];

That line reads the same in 4.0.28. What differs is the question type behind it, which gained box in 4.0.29. Where your code supplies or reads supportedQuestionTypes, bring it into line with what the release declares and leave the rest of the file alone.

Migration guidance and its limits

Both findings carry assisted fixes. emendant fix writes a patch only when you name a model provider, on the command line or in your Emendant configuration. Without one, each finding is reported with its guidance and nothing is changed. Nothing in this release is report only. Run emendant scan first to see which files are named, then emendant fix for the patches.

Each patch is checked with your typecheck and tests. Read the patch header to see which checks passed, and review any edit to a place that lists question types. Whether a model should claim box depends on what it can actually answer, so that choice stays with you.

Code that only passes one of these models around, or never touches supportedQuestionTypes, may need no edit, and a patch may not be available for it.

A clean scan does not cover a type reached through your own re-export, or a name imported from another module. Those are not reported. This page covers the two changes the feed carries for 4.0.29 and nothing else in the release.

What Emendant detects, fixes and verifies

2 changes in @ai-sdk/provider 4.0.29. 0 automatic fixes, 2 fixes requiring a model provider you choose, 0 report only. Each patch states which checks passed. Understand patch evidence.

emendant explain <change-id> prints any row's entry, guidance and sources at the terminal.

Requires emendant@0.3.0 or later. Feed entry feed/npm/@ai-sdk/provider/4.0.29.json, snapshot 2026-10-17.1.

Primary sources

• @ai-sdk/provider@4.0.29npm registry, the published package
• @ai-sdk/provider@4.0.28npm registry, the published package