update-provider-models

SkillCloud & infra

This skill lets an agent add new or remove obsolete model IDs for existing AI SDK providers. It searches the codebase for references to a similar model, then updates type unions, documentation tables, and example files while respecting sort order and exact matching. Changes are limited to model IDs and related references only.

Then ask your AI: use the update-provider-models skill

Details

Instructions available. Your AI can read the instructions. Execution depends on the setup they require.

Have the AI SDK codebase available and know the provider name and exact model ID.

What your AI can do with it

  • Add a new model ID to a provider package and the AI Gateway
  • Remove an obsolete model ID from type unions and docs
  • Search the codebase for references to a similar model
  • Update documentation tables and example files
  • Process a list of model changes from an issue
  • Respect existing sort order and exact matching

Getting started

  1. Have the AI SDK codebase available and know the provider name and exact model ID.
  2. Decide whether you are adding a new model ID or removing an obsolete one.
  3. Ask the agent to run the skill for that model ID, or provide a list of model changes from an issue.
  4. Let the agent search for a similar model and update type unions, docs, and examples.
  5. Review the changes to confirm only model IDs and related references were modified.

What this skill tells your AI

The instructions your AI receives, as published by vercel/ai in skills/update-provider-models/SKILL.md and read by Ahel’s review.

Update Provider Model IDs

This skill covers adding new model IDs and removing obsolete ones across the AI SDK codebase. Each workflow uses search to discover all locations that need changes.

You may be asked to add or remove a single model ID, or to process a list of multiple model ID changes from an issue. For each model ID, follow the appropriate workflow:

  • If a new model ID is being added, follow the <adding-new-model> workflow.
  • If an obsolete model ID is being removed, follow the <removing-obsolete-model> workflow.

Critical Rules

  • Exact matching: Model IDs are often substrings of others (e.g. grok-3 vs grok-3-mini). Always verify each search result is the exact model, not a substring match.
  • Respect sort order: When inserting into any list (type unions, table rows, arrays), observe the existing order and place the new entry accordingly.
  • File naming for examples: Use kebab-case with hyphens replacing dots (e.g. gpt-5.4-codex → gpt-5-4-codex.ts).
  • Sequential processing: When handling multiple models, complete the full workflow for one model before starting the next.
  • Affected providers: New model IDs always need to be added to the primary provider package and the AI Gateway. There may be additional affected packages (e.g. Bedrock, Vertex, OpenAI-compatible) if the model is available there or referenced in tests/docs.
  • Never make unrelated changes: Only update model IDs and related references. Don't modify any other code, text, or formatting in the files you edit.
  • Never modify CHANGELOG.md files of packages/codemod: Changelog files are historical records, codemods are migration scripts. Do not edit either when updating model IDs.

Workflow for Adding a New Model ID

Step 1: Identify Scope

Determine:

  • Provider name (e.g. anthropic, openai, google, xai)
  • Exact model ID string (e.g. claude-haiku-4-5-20260218, gemini-3.1-pro, gpt-5.4-codex)
  • Model type: chat, embedding, image, etc.
  • Whether this is a new version of an existing older model, or even the stable version of an existing preview or experimental model
  • Whether any provider packages other than the primary one and the AI Gateway need to be updated (e.g. Bedrock, Vertex, OpenAI-compatible)
    • If a similar model ID is listed in one of those other provider packages, the new model ID should likely be added there as well. Check the provider's documentation for clues on availability.

Step 2: Find Where Similar Models Are Referenced

Search for a similar existing model from the same provider (e.g. a lower version, or the preview version being replaced) across packages/, content/, and examples/. This reveals all locations that need updates.

# Search quoted occurrences to find all reference locations
grep -r "'<similar-model-id>'" packages/ content/ examples/ --include='*.ts' --include='*.mdx' --include='*.md'
grep -r '"<similar-model-id>"' packages/ content/ examples/ --include='*.ts' --include='*.mdx' --include='*.md'

Step 3: Update Type Definitions

For each relevant packages file found, add the new model ID to the type union (and const arrays if present), respecting existing sort order.

Examples of common locations for model ID type definitions:

  • packages/<provider>/src/*-options.ts — the primary provider package
  • packages/gateway/src/gateway-language-model-settings.ts — the AI Gateway package
  • packages/amazon-bedrock/src/**/*-options.ts — if the model is available on Amazon Bedrock
  • packages/google-vertex/src/*-options.ts — if the model is available on Google Vertex

This is NOT an exhaustive list — the search in Step 2 may reveal other files with model ID references that need updating as well.

Never replace a model ID here. Only add the new model ID. Replacing references to an older or preview model ID is only relevant in documentation and examples.

Example type union addition:

export type SomeModelId =
  | 'existing-model-a'
  | 'new-model-id' // ← add in sorted position
  | 'existing-model-b'
  | (string & {});

Example const array addition:

export const reasoningModelIds = [
  'existing-model-a',
  'new-model-id', // ← add in sorted position
  'existing-model-b',
] as const;

Step 4: Update Documentation

For each .mdx file found in content/, add or update entries:

  • Capability tables: Add a row for the new model in the correct position with the appropriate capability checks (<Check /> or <Cross />).
  • Inline code examples: If replacing a preview/older model as the recommended one, update code snippets like const model = provider('old-model') to use the new model.
  • "Latest" descriptions: Update text like "Latest model with enhanced reasoning" to reference the new model.

If you found the similar model ID referenced in a specific package's README.md file, update the model ID in those code examples as well.

Step 5: Create or Update Examples

If the new model replaces an older one: Find existing examples using the old model and update them to use the new model ID.

If purely new with no predecessor: Create new example files, one file per top-level function that is relevant for the new model (e.g. generateText, streamText, generateImage). For example, if it's a new language model, you would create files like:

  • examples/ai-functions/src/generate-text/<provider>/<model-kebab>.ts
  • examples/ai-functions/src/stream-text/<provider>/<model-kebab>.ts

Or if it's a new image model, you might create:

  • examples/ai-functions/src/generate-image/<provider>/<model-kebab>.ts

Look for existing example files for the provider in the same folder, to use as a reference for your new example files.

In your search for the similar model ID, you may have found examples in which the model ID is part of a list of models (e.g. in an array of options for a test or example). In that case, add the new model ID to the same list in the example file, respecting sort order.

Step 6: Update Tests

Where reasonable, replace references to the older or preview model with the new model in test files, especially if the new model is now the recommended one.

Exception: Do not replace model IDs in fixtures or snapshots, or tests that use those fixtures or snapshots, as those are meant to be stable and reflect actual API responses captured.

Step 7: Run Tests

pnpm --filter @ai-sdk/<provider> test
pnpm --filter @ai-sdk/gateway test

Also run tests for any other affected packages:

pnpm --filter @ai-sdk/openai-compatible test  # if snapshots/tests were updated
pnpm --filter @ai-sdk/amazon-bedrock test     # if Bedrock options were updated
pnpm --filter @ai-sdk/google-vertex test      # if Vertex options were updated

Workflow for Removing an Obsolete Model ID

Step 1: Identify Successor

Determine which model replaces the removed one in examples, tests, and docs. This is relevant for updating references.

If there is no obvious successor, you should leave old references in place in examples, docs, and tests.

Step 2: Find All Exact Occurrences

Search for the model ID with quotes to avoid substring false positives:

# Single-quoted (TypeScript source, type unions)
grep -r "'<model-id>'" packages/ content/ examples/ --include='*.ts' --include='*.mdx' --include='*.md' --include='*.snap'

# Double-quoted (JSON in snapshots, test fixtures with embedded JSON, docs)
grep -r '"<model-id>"' packages/ content/ examples/ --include='*.ts' --include='*.mdx' --include='*.md' --include='*.snap'

Manually verify each result is the exact model and not a substring match (e.g. searching 'grok-3' must not match 'grok-3-mini').

Step 3: Remove from Type Definitions

Remove the | 'model-id' line from union types and entries from const arrays in *-options.ts files.

Step 4: Update Documentation

  • Remove rows from capability tables in .mdx files.
  • Replace inline code examples and descriptions referencing the removed model with the successor.
  • Update community provider docs in content/providers/05-community-providers/.

Step 5: Update Examples

  • Replace the removed model with the successor in example files that use it directly.
  • Remove from model lists in examples.
  • Delete dedicated example files only if no unique feature is demonstrated beyond the model itself (e.g. if the file is named after the model).

Step 6: Update Tests and Snapshots

  • Replace the model ID with the successor in *.test.ts files.
  • Replace the model ID in __snapshots__/*.snap files — model IDs appear in serialized JSON strings.
  • Replace in embedded JSON strings within test fixtures (e.g. "model":"old-model" → "model":"new-model").
  • Update examples/ai-functions/src/e2e/*.test.ts — remove from model arrays or replace.
  • Update packages/<provider>/README.md if it contains code examples.

Step 7: Run Tests

pnpm --filter @ai-sdk/<provider> test

Also run tests for any other affected packages (same as Workflow A Step 7).

Signals

GitHub stars
27k
Forks
5k
Last commit
Oct 2026

Others that do the same job

Questions

What does this skill do?
It guides an agent through adding new or removing obsolete model IDs in the AI SDK. It searches for a similar model, then updates type unions, documentation tables, and example files while respecting sort order and exact matching.
When should I use it?
Use it when adding a model to a provider, removing an obsolete model, or processing a list of model changes from an issue.
Which providers are affected?
New model IDs always need to be added to the primary provider package and the AI Gateway. Additional packages such as Bedrock, Vertex, or OpenAI-compatible may also need updates if the model is available there or referenced in tests or docs.
Advanced
Item type
skill
Key
update-provider-models-vercel
Source
github.com/vercel/ai