Migrating workers-ai-provider to createAI: What Changes in Existing Code?

TLDR

createAI replaces Cloudflare’s two older AI providers, which are deprecated and feature frozen.
Check SDK compatibility, credentials and model routing before removing the old dependencies.
AI Search has a separate replacement; fallback and stream recovery have distinct behavior.

Start with the calls in your application

Replacing createWorkersAI begins with an import from agents/models/ai-sdk. A Worker binding carries over, but credentials and AI Search need different changes. Cloudflare’s October 21 announcement freezes development of the older packages; it does not announce an immediate shutdown of existing applications.

Existing integration	Migration
`createWorkersAI` with a binding	Use `createAI` with the binding.
`accountId` and `apiKey`	Use `accountId` and `apiToken`.
`createAiGateway`	Move to `createAI`; review fallback behavior.
`createAISearch`	Use `createAISearchNamespace` from `ai-search-provider`.

Match the SDK before changing the import

The installation guide requires ai@^7 and @ai-sdk/provider@^4. The new provider is beta, with API changes possible in minor releases. Check the project’s installed versions first.

Inside a Worker, configure an AI binding and create the provider in your request handler. The model-selection portion looks like this:

import { createAI } from "agents/models/ai-sdk";

const ai = createAI({ binding: env.AI });
const model = ai("@cf/zai-org/glm-4.7-flash");

For HTTP credentials, the authentication reference distinguishes Workers AI Read permission for string IDs from AI Gateway Run for model objects.

A catalog ID and a vendor model object are different choices

Strings select Workers AI models, gateway catalog models or dynamic/… routes without requiring a vendor SDK package. Wrapping a vendor model object instead preserves that package’s request builder and response parser while routing through the gateway’s provider-native endpoint.

Keep that distinction when migrating code with vendor-specific behavior. For search, the old provider’s replacement notice points to ai-search-provider and its ai_search_namespaces binding. Renaming the model factory does not migrate those calls.

Test fallback separately from stream recovery

The migration issue’s October 20 closing comment clarifies a behavioral difference: createAI fallback runs on the client, unlike the old Universal Endpoint’s server-side mechanism. A dynamic route can apply its own gateway-side fallback.

Fallback tries another model when the primary fails before producing output. Stream recovery has a narrower purpose: binding-based catalog and dynamic-route streams can resume a dropped answer. Workers AI @cf/ streams and vendor model objects do not have that recovery path.

Verify a normal response and the failure modes your application relies on before removing the old providers. A successful text response alone does not test search migration or fallback equivalence.