Skip to content
Cloudflare Docs

Changelog

New updates and improvements at Cloudflare.

Subscribe to RSS View RSS feeds
Workers
hero image

  1. Agents SDK v0.6.0: RPC transport for MCP, optional OAuth, hardened schema conversion, and @cloudflare/ai-chat fixes

    Agents Workers

    The latest release of the Agents SDK ↗ lets you define an Agent and an McpAgent in the same Worker and connect them over RPC — no HTTP, no network overhead. It also makes OAuth opt-in for simple MCP connections, hardens the schema converter for production workloads, and ships a batch of @cloudflare/ai-chat reliability fixes.

    RPC transport for MCP

    You can now connect an Agent to an McpAgent in the same Worker using a Durable Object binding instead of an HTTP URL. The connection stays entirely within the Cloudflare runtime — no network round-trips, no serialization overhead.

    Pass the Durable Object namespace directly to addMcpServer:

    JavaScript
    import { Agent } from "agents";
    

    export class MyAgent extends Agent {
      async onStart() {
        // Connect via DO binding — no HTTP, no network overhead
        await this.addMcpServer("counter", env.MY_MCP);
    

        // With props for per-user context
        await this.addMcpServer("counter", env.MY_MCP, {
          props: { userId: "user-123", role: "admin" },
        });
      }
    }

    The addMcpServer method now accepts string | DurableObjectNamespace as the second parameter with full TypeScript overloads, so HTTP and RPC paths are type-safe and cannot be mixed.

    Key capabilities:

    • Hibernation support — RPC connections survive Durable Object hibernation automatically. The binding name and props are persisted to storage and restored on wake-up, matching the behavior of HTTP MCP connections.
    • Deduplication — Calling addMcpServer with the same server name returns the existing connection instead of creating duplicates. Connection IDs are stable across hibernation restore.
    • Smaller surface area — The RPC transport internals have been rewritten and reduced from 609 lines to 245 lines. RPCServerTransport now uses JSONRPCMessageSchema from the MCP SDK for validation instead of hand-written checks.

    Optional OAuth for MCP connections

    addMcpServer() no longer eagerly creates an OAuth provider for every connection. For servers that do not require authentication, a simple call is all you need:

    JavaScript
    // No callbackHost, no OAuth config — just works
    await this.addMcpServer("my-server", "https://mcp.example.com");

    If the server responds with a 401, the SDK throws a clear error: "This MCP server requires OAuth authentication. Provide callbackHost in addMcpServer options to enable the OAuth flow." The restore-from-storage flow also handles missing callback URLs gracefully, skipping auth provider creation for non-OAuth servers.

    Hardened JSON Schema to TypeScript converter

    The schema converter used by generateTypes() and getAITools() now handles edge cases that previously caused crashes in production:

    • Depth and circular reference guards — Prevents stack overflows on recursive or deeply nested schemas
    • $ref resolution — Supports internal JSON Pointers (#/definitions/..., #/$defs/..., #)
    • Tuple support — prefixItems (JSON Schema 2020-12) and array items (draft-07)
    • OpenAPI 3.0 nullable: true — Supported across all schema branches
    • Per-tool error isolation — One malformed schema cannot crash the full pipeline in generateTypes() or getAITools()
    • Missing inputSchema fallback — getAITools() falls back to { type: "object" } instead of throwing

    @cloudflare/ai-chat fixes

    • Tool denial flow — Denied tool approvals (approved: false) now transition to output-denied with a tool_result, fixing Anthropic provider compatibility. Custom denial messages are supported via state: "output-error" and errorText.
    • Abort/cancel support — Streaming responses now properly cancel the reader loop when the abort signal fires and send a done signal to the client.
    • Duplicate message persistence — persistMessages() now reconciles assistant messages by content and order, preventing duplicate rows when clients resend full history.
    • requestId in OnChatMessageOptions — Handlers can now send properly-tagged error responses for pre-stream failures.
    • redacted_thinking preservation — The message sanitizer no longer strips Anthropic redacted_thinking blocks.
    • /get-messages reliability — Endpoint handling moved from a prototype onRequest() override to a constructor wrapper, so it works even when users override onRequest without calling super.onRequest().
    • Client tool APIs undeprecated — createToolsFromClientSchemas, clientTools, AITool, extractClientToolSchemas, and the tools option on useAgentChat are restored for SDK use cases where tools are defined dynamically at runtime.
    • jsonSchema initialization — Fixed jsonSchema not initialized error when calling getAITools() in onChatMessage.

    Upgrade

    To update to the latest version:

    Terminal window
    npm i agents@latest @cloudflare/ai-chat@latest

  1. Better Windows support for Python Workers

    Workers

    Pywrangler ↗, the CLI tool for managing Python Workers and packages, now supports Windows, allowing you to develop and deploy Python Workers from Windows environments. Previously, Pywrangler was only available on macOS and Linux.

    You can install and use Pywrangler on Windows the same way you would on other platforms. Specify your Worker's Python dependencies in your pyproject.toml file, then use the following commands to develop and deploy:

    Terminal window
    uvx --from workers-py pywrangler dev
    uvx --from workers-py pywrangler deploy

    All existing Pywrangler functionality, including package management, local development, and deployment, works on Windows without any additional configuration.

    Requirements

    This feature requires the following minimum versions:

    • wrangler >= 4.64.0
    • workers-py >= 1.72.0
    • uv >= 0.29.8

    To upgrade workers-py (which includes Pywrangler) in your project, run:

    Terminal window
    uv tool upgrade workers-py

    To upgrade wrangler, run:

    Terminal window
    npm install -g wrangler@latest

    To upgrade uv, run:

    Terminal window
    uv self update

    To get started with Python Workers on Windows, refer to the Python packages documentation for full details on Pywrangler.

  1. Write structured queries to filter and search your Workers logs and traces

    Workers

    Workers Observability now includes a query language that lets you write structured queries directly in the search bar to filter your logs and traces. The search bar doubles as a free text search box — type any term to search across all metadata and attributes, or write field-level queries for precise filtering.

    Workers Observability search bar with autocomplete suggestions and Query Builder sidebar filters

    Queries written in the search bar sync with the Query Builder sidebar, so you can write a query by hand and then refine it visually, or build filters in the Query Builder and see the corresponding query syntax. The search bar provides autocomplete suggestions for metadata fields and operators as you type.

    The query language supports:

    • Free text search — search everywhere with a keyword like error, or match an exact phrase with "exact phrase"
    • Field queries — filter by specific fields using comparison operators (for example, status = 500 or $workers.wallTimeMs > 100)
    • Operators — =, !=, >, >=, <, <=, and : (contains)
    • Functions — contains(field, value), startsWith(field, prefix), regex(field, pattern), and exists(field)
    • Boolean logic — add conditions with AND, OR, and NOT

    Select the help icon next to the search bar to view the full syntax reference, including all supported operators, functions, and keyboard shortcuts.

    Go to the Workers Observability dashboard ↗ to try the query language.

  1. No config? No problem. Just `wrangler deploy`

    Workers

    You can now deploy any existing project to Cloudflare Workers — even without a Wrangler configuration file — and wrangler deploy will just work.

    Starting with Wrangler 4.68.0, running wrangler deploy automatically configures your project by detecting your framework, installing required adapters, and deploying it to Cloudflare Workers.

    Using Wrangler locally

    Terminal window
    npx wrangler deploy

    When you run wrangler deploy in a project without a configuration file, Wrangler:

    1. Detects your framework from package.json
    2. Prompts you to confirm the detected settings
    3. Installs any required adapters
    4. Generates a wrangler.jsonc configuration file
    5. Deploys your project to Cloudflare Workers

    You can also use wrangler setup to configure without deploying, or pass --yes to skip prompts.

    Using the Cloudflare dashboard

    Automatic configuration pull request created by Workers Builds

    When you connect a repository through the Workers dashboard ↗, a pull request is generated for you with all necessary files, and a preview deployment to check before merging.

    Background

    In December 2025, we introduced automatic configuration as an experimental feature. It is now generally available and the default behavior.

    If you have questions or run into issues, join the GitHub discussion ↗.

  1. deleteAll() now deletes Durable Object alarm

    Durable Objects Workers

    deleteAll() now deletes a Durable Object alarm in addition to stored data for Workers with a compatibility date of 2026-02-24 or later. This change simplifies clearing a Durable Object's storage with a single API call.

    Previously, deleteAll() only deleted user-stored data for an object. Alarm usage stores metadata in an object's storage, which required a separate deleteAlarm() call to fully clean up all storage for an object. The deleteAll() change applies to both KV-backed and SQLite-backed Durable Objects.

    JavaScript
    // Before: two API calls required to clear all storage
    await this.ctx.storage.deleteAlarm();
    await this.ctx.storage.deleteAll();
    

    // Now: a single call clears both data and the alarm
    await this.ctx.storage.deleteAll();

    For more information, refer to the Storage API documentation.

  1. Dropped event metrics, typed Pipelines bindings, and improved setup

    Pipelines Workers

    Cloudflare Pipelines ingests streaming data via Workers or HTTP endpoints, transforms it with SQL, and writes it to R2 as Apache Iceberg tables. Today we're shipping three improvements to help you understand why streaming events get dropped, catch data quality issues early, and set up Pipelines faster.

    Dropped event metrics

    When stream events don't match the expected schema, Pipelines accepts them during ingestion but drops them when attempting to deliver them to the sink. To help you identify the root cause of these issues, we are introducing a new dashboard and metrics that surface dropped events with detailed error messages.

    The Errors tab in the Cloudflare dashboard showing deserialization errors grouped by type with individual error details

    Dropped events can also be queried programmatically via the new pipelinesUserErrorsAdaptiveGroups GraphQL dataset. The dataset breaks down failures by specific error type (missing_field, type_mismatch, parse_failure, or null_value) so you can trace issues back to the source.

    query GetPipelineUserErrors(
      $accountTag: String!
      $pipelineId: String!
      $datetimeStart: Time!
      $datetimeEnd: Time!
    ) {
      viewer {
        accounts(filter: { accountTag: $accountTag }) {
          pipelinesUserErrorsAdaptiveGroups(
            limit: 100
            filter: {
              pipelineId: $pipelineId
              datetime_geq: $datetimeStart
              datetime_leq: $datetimeEnd
            }
            orderBy: [count_DESC]
          ) {
            count
            dimensions {
              errorFamily
              errorType
            }
          }
        }
      }
    }

    For the full list of dimensions, error types, and additional query examples, refer to User error metrics.

    Typed Pipelines bindings

    Sending data to a Pipeline from a Worker previously used a generic Pipeline<PipelineRecord> type, which meant schema mismatches (wrong field names, incorrect types) were only caught at runtime as dropped events.

    Running wrangler types now generates schema-specific TypeScript types for your Pipeline bindings. TypeScript catches missing required fields and incorrect field types at compile time, before your code is deployed.

    TypeScript
    declare namespace Cloudflare {
      type EcommerceStreamRecord = {
        user_id: string;
        event_type: string;
        product_id?: string;
        amount?: number;
      };
      interface Env {
        STREAM: import("cloudflare:pipelines").Pipeline<Cloudflare.EcommerceStreamRecord>;
      }
    }

    For more information, refer to Typed Pipeline bindings.

    Improved Pipelines setup

    Setting up a new Pipeline previously required multiple manual steps: creating an R2 bucket, enabling R2 Data Catalog, generating an API token, and configuring format, compression, and rolling policies individually.

    The wrangler pipelines setup command now offers a Simple setup mode that applies recommended defaults and automatically creates the R2 bucket and enables R2 Data Catalog if they do not already exist. Validation errors during setup prompt you to retry inline rather than restarting the entire process.

    For a full walkthrough, refer to the Getting started guide.

  1. @cloudflare/codemode v0.1.0: a new runtime agnostic modular architecture

    Agents Workers

    The @cloudflare/codemode ↗ package has been rewritten into a modular, runtime-agnostic SDK.

    Code Mode ↗ enables LLMs to write and execute code that orchestrates your tools, instead of calling them one at a time. This can (and does) yield significant token savings, reduces context window pressure and improves overall model performance on a task.

    The new Executor interface is runtime agnostic and comes with a prebuilt DynamicWorkerExecutor to run generated code in a Dynamic Worker Loader.

    Breaking changes

    • Removed experimental_codemode() and CodeModeProxy — the package no longer owns an LLM call or model choice
    • New import path: createCodeTool() is now exported from @cloudflare/codemode/ai

    New features

    • createCodeTool() — Returns a standard AI SDK Tool to use in your AI agents.
    • Executor interface — Minimal execute(code, fns) contract. Implement for any code sandboxing primitive or runtime.

    DynamicWorkerExecutor

    Runs code in a Dynamic Worker. It comes with the following features:

    • Network isolation — fetch() and connect() blocked by default (globalOutbound: null) when using DynamicWorkerExecutor
    • Console capture — console.log/warn/error captured and returned in ExecuteResult.logs
    • Execution timeout — Configurable via timeout option (default 30s)

    Usage

    JavaScript
    import { createCodeTool } from "@cloudflare/codemode/ai";
    import { DynamicWorkerExecutor } from "@cloudflare/codemode";
    import { streamText } from "ai";
    

    const executor = new DynamicWorkerExecutor({ loader: env.LOADER });
    const codemode = createCodeTool({ tools: myTools, executor });
    

    const result = streamText({
      model,
      tools: { codemode },
      messages,
    });

    Wrangler configuration

    {
      "worker_loaders": [{ "binding": "LOADER" }],
    }

    See the Code Mode documentation for full API reference and examples.

    Upgrade

    Terminal window
    npm i @cloudflare/codemode@latest

  1. Agents SDK v0.5.0: Protocol message control, retry utilities, data parts, and @cloudflare/ai-chat v0.1.0

    Agents Workers

    The latest release of the Agents SDK ↗ adds built-in retry utilities, per-connection protocol message control, and a fully rewritten @cloudflare/ai-chat with data parts, tool approval persistence, and zero breaking changes.

    Retry utilities

    A new this.retry() method lets you retry any async operation with exponential backoff and jitter. You can pass an optional shouldRetry predicate to bail early on non-retryable errors.

    JavaScript
    class MyAgent extends Agent {
      async onRequest(request) {
        const data = await this.retry(() => callUnreliableService(), {
          maxAttempts: 4,
          shouldRetry: (err) => !(err instanceof PermanentError),
        });
        return Response.json(data);
      }
    }

    Retry options are also available per-task on queue(), schedule(), scheduleEvery(), and addMcpServer():

    JavaScript
    // Per-task retry configuration, persisted in SQLite alongside the task
    await this.schedule(
      Date.now() + 60_000,
      "sendReport",
      { userId: "abc" },
      {
        retry: { maxAttempts: 5 },
      },
    );
    

    // Class-level retry defaults
    class MyAgent extends Agent {
      static options = {
        retry: { maxAttempts: 3 },
      };
    }

    Retry options are validated eagerly at enqueue/schedule time, and invalid values throw immediately. Internal retries have also been added for workflow operations (terminateWorkflow, pauseWorkflow, and others) with Durable Object-aware error detection.

    Per-connection protocol message control

    Agents automatically send JSON text frames (identity, state, MCP server lists) to every WebSocket connection. You can now suppress these per-connection for clients that cannot handle them — binary-only devices, MQTT clients, or lightweight embedded systems.

    JavaScript
    class MyAgent extends Agent {
      shouldSendProtocolMessages(connection, ctx) {
        // Suppress protocol messages for MQTT clients
        const subprotocol = ctx.request.headers.get("Sec-WebSocket-Protocol");
        return subprotocol !== "mqtt";
      }
    }

    Connections with protocol messages disabled still fully participate in RPC and regular messaging. Use isConnectionProtocolEnabled(connection) to check a connection's status at any time. The flag persists across Durable Object hibernation.

    See Protocol messages for full documentation.

    @cloudflare/ai-chat v0.1.0

    The first stable release of @cloudflare/ai-chat ships alongside this release with a major refactor of AIChatAgent internals — new ResumableStream class, WebSocket ChatTransport, and simplified SSE parsing — with zero breaking changes. Existing code using AIChatAgent and useAgentChat works as-is.

    Key new features:

    • Data parts — Attach typed JSON blobs (data-*) to messages alongside text. Supports reconciliation (type+id updates in-place), append, and transient parts (ephemeral via onData callback). See Data parts.
    • Tool approval persistence — The needsApproval approval UI now survives page refresh and DO hibernation. The streaming message is persisted to SQLite when a tool enters approval-requested state.
    • maxPersistedMessages — Cap SQLite message storage with automatic oldest-message deletion.
    • body option on useAgentChat — Send custom data with every request (static or dynamic).
    • Incremental persistence — Hash-based cache to skip redundant SQL writes.
    • Row size guard — Automatic two-pass compaction when messages approach the SQLite 2 MB limit.
    • autoContinueAfterToolResult defaults to true — Client-side tool results and tool approvals now automatically trigger a server continuation, matching server-executed tool behavior. Set autoContinueAfterToolResult: false in useAgentChat to restore the previous behavior.

    Notable bug fixes:

    • Resolved stream resumption race conditions
    • Resolved an issue where setMessages functional updater sent empty arrays
    • Resolved an issue where client tool schemas were lost after DO hibernation
    • Resolved InvalidPromptError after tool approval (approval.id was dropped)
    • Resolved an issue where message metadata was not propagated on broadcast/resume paths
    • Resolved an issue where clearAll() did not clear in-memory chunk buffers
    • Resolved an issue where reasoning-delta silently dropped data when reasoning-start was missed during stream resumption

    Synchronous queue and schedule getters

    getQueue(), getQueues(), getSchedule(), dequeue(), dequeueAll(), and dequeueAllByCallback() were unnecessarily async despite only performing synchronous SQL operations. They now return values directly instead of wrapping them in Promises. This is backward compatible — existing code using await on these methods will continue to work.

    Other improvements

    • Fix TypeScript "excessively deep" error — A depth counter on CanSerialize and IsSerializableParam types bails out to true after 10 levels of recursion, preventing the "Type instantiation is excessively deep" error with deeply nested types like AI SDK CoreMessage[].
    • POST SSE keepalive — The POST SSE handler now sends event: ping every 30 seconds to keep the connection alive, matching the existing GET SSE handler behavior. This prevents POST response streams from being silently dropped by proxies during long-running tool calls.
    • Widened peer dependency ranges — Peer dependency ranges across packages have been widened to prevent cascading major bumps during 0.x minor releases. @cloudflare/ai-chat and @cloudflare/codemode are now marked as optional peer dependencies.

    Upgrade

    To update to the latest version:

    Terminal window
    npm i agents@latest @cloudflare/ai-chat@latest

  1. New Best Practices guide for Workers

    Workers

    A new Workers Best Practices guide provides opinionated recommendations for building fast, reliable, observable, and secure Workers. The guide draws on production patterns, Cloudflare internal usage, and best practices observed from developers building on Workers.

    Key guidance includes:

    • Keep your compatibility date current and enable nodejs_compat — Ensure you have access to the latest runtime features and Node.js built-in modules.
    {
      "name": "my-worker",
      "main": "src/index.ts",
      // Set this to today's date
      "compatibility_date": "2026-02-28",
      "compatibility_flags": ["nodejs_compat"],
    }
    • Generate binding types with wrangler types — Never hand-write your Env interface. Let Wrangler generate it from your actual configuration to catch mismatches at compile time.
    • Stream request and response bodies — Avoid buffering large payloads in memory. Use TransformStream and pipeTo to stay within the 128 MB memory limit and improve time-to-first-byte.
    • Use bindings, not REST APIs — Bindings to KV, R2, D1, Queues, and other Cloudflare services are direct, in-process references with no network hop and no authentication overhead.
    • Use Queues and Workflows for background work — Move long-running or retriable tasks out of the critical request path. Use Queues for simple fan-out and buffering, and Workflows for multi-step durable processes.
    • Enable Workers Logs and Traces — Configure observability before deploying to production so you have data when you need to debug.
    • Avoid global mutable state — Workers reuse isolates across requests. Storing request-scoped data in module-level variables causes cross-request data leaks.
    • Always await or waitUntil your Promises — Floating promises cause silent bugs and dropped work.
    • Use Web Crypto for secure token generation — Never use Math.random() for security-sensitive operations.

    To learn more, refer to Workers Best Practices.

  1. Introducing GLM-4.7-Flash on Workers AI, @cloudflare/tanstack-ai, and workers-ai-provider v3.1.1

    Workers Agents Workers AI

    We're excited to announce GLM-4.7-Flash on Workers AI, a fast and efficient text generation model optimized for multilingual dialogue and instruction-following tasks, along with the brand-new @cloudflare/tanstack-ai ↗ package and workers-ai-provider v3.1.1 ↗.

    You can now run AI agents entirely on Cloudflare. With GLM-4.7-Flash's multi-turn tool calling support, plus full compatibility with TanStack AI and the Vercel AI SDK, you have everything you need to build agentic applications that run completely at the edge.

    GLM-4.7-Flash — Multilingual Text Generation Model

    @cf/zai-org/glm-4.7-flash is a multilingual model with a 131,072 token context window, making it ideal for long-form content generation, complex reasoning tasks, and multilingual applications.

    Key Features and Use Cases:

    • Multi-turn Tool Calling for Agents: Build AI agents that can call functions and tools across multiple conversation turns
    • Multilingual Support: Built to handle content generation in multiple languages effectively
    • Large Context Window: 131,072 tokens for long-form writing, complex reasoning, and processing long documents
    • Fast Inference: Optimized for low-latency responses in chatbots and virtual assistants
    • Instruction Following: Excellent at following complex instructions for code generation and structured tasks

    Use GLM-4.7-Flash through the Workers AI binding (env.AI.run()), the REST API at /run or /v1/chat/completions, AI Gateway, or via workers-ai-provider for the Vercel AI SDK.

    Pricing is available on the model page or pricing page.

    @cloudflare/tanstack-ai v0.1.1 — TanStack AI adapters for Workers AI and AI Gateway

    We've released @cloudflare/tanstack-ai, a new package that brings Workers AI and AI Gateway support to TanStack AI ↗. This provides a framework-agnostic alternative for developers who prefer TanStack's approach to building AI applications.

    Workers AI adapters support four configuration modes — plain binding (env.AI), plain REST, AI Gateway binding (env.AI.gateway(id)), and AI Gateway REST — across all capabilities:

    • Chat (createWorkersAiChat) — Streaming chat completions with tool calling, structured output, and reasoning text streaming.
    • Image generation (createWorkersAiImage) — Text-to-image models.
    • Transcription (createWorkersAiTranscription) — Speech-to-text.
    • Text-to-speech (createWorkersAiTts) — Audio generation.
    • Summarization (createWorkersAiSummarize) — Text summarization.

    AI Gateway adapters route requests from third-party providers — OpenAI, Anthropic, Gemini, Grok, and OpenRouter — through Cloudflare AI Gateway for caching, rate limiting, and unified billing.

    To get started:

    Terminal window
    npm install @cloudflare/tanstack-ai @tanstack/ai

    workers-ai-provider v3.1.1 — transcription, speech, reranking, and reliability

    The Workers AI provider for the Vercel AI SDK ↗ now supports three new capabilities beyond chat and image generation:

    • Transcription (provider.transcription(model)) — Speech-to-text with automatic handling of model-specific input formats across binding and REST paths.
    • Text-to-speech (provider.speech(model)) — Audio generation with support for voice and speed options.
    • Reranking (provider.reranking(model)) — Document reranking for RAG pipelines and search result ordering.
    TypeScript
    import { createWorkersAI } from "workers-ai-provider";
    import {
      experimental_transcribe,
      experimental_generateSpeech,
      rerank,
    } from "ai";
    

    const workersai = createWorkersAI({ binding: env.AI });
    

    const transcript = await experimental_transcribe({
      model: workersai.transcription("@cf/openai/whisper-large-v3-turbo"),
      audio: audioData,
      mediaType: "audio/wav",
    });
    

    const speech = await experimental_generateSpeech({
      model: workersai.speech("@cf/deepgram/aura-1"),
      text: "Hello world",
      voice: "asteria",
    });
    

    const ranked = await rerank({
      model: workersai.reranking("@cf/baai/bge-reranker-base"),
      query: "What is machine learning?",
      documents: ["ML is a branch of AI.", "The weather is sunny."],
    });

    This release also includes a comprehensive reliability overhaul (v3.0.5):

    • Fixed streaming — Responses now stream token-by-token instead of buffering all chunks, using a proper TransformStream pipeline with backpressure.
    • Fixed tool calling — Resolved issues with tool call ID sanitization, conversation history preservation, and a heuristic that silently fell back to non-streaming mode when tools were defined.
    • Premature stream termination detection — Streams that end unexpectedly now report finishReason: "error" instead of silently reporting "stop".
    • AI Search support — Added createAISearch as the canonical export (renamed from AutoRAG). createAutoRAG still works with a deprecation warning.

    To upgrade:

    Terminal window
    npm install workers-ai-provider@latest ai

    Resources

  1. Workers are no longer limited to 1000 subrequests

    Workers

    Workers no longer have a limit of 1000 subrequests per invocation, allowing you to make more fetch() calls or requests to Cloudflare services on every incoming request. This is especially important for long-running Workers requests, such as open websockets on Durable Objects or long-running Workflows, as these could often exceed this limit and error.

    By default, Workers on paid plans are now limited to 10,000 subrequests per invocation, but this limit can be increased up to 10 million by setting the new subrequests limit in your Wrangler configuration file.

    {
      "limits": {
        "subrequests": 50000,
      },
    }

    Workers on the free plan remain limited to 50 external subrequests and 1000 subrequests to Cloudflare services per invocation.

    To protect against runaway code or unexpected costs, you can also set a lower limit for both subrequests and CPU usage.

    {
      "limits": {
        "subrequests": 10,
        "cpu_ms": 1000,
      },
    }

    For more information, refer to the Wrangler configuration documentation for limits and subrequest limits.

  1. Improved React Server Components support in the Cloudflare Vite plugin

    Workers

    The Cloudflare Vite plugin now integrates seamlessly @vitejs/plugin-rsc ↗, the official Vite plugin for React Server Components ↗.

    A childEnvironments option has been added to the plugin config to enable using multiple environments within a single Worker. The parent environment can then import modules from a child environment in order to access a separate module graph. For a typical RSC use case, the plugin might be configured as in the following example:

    vite.config.ts
    export default defineConfig({
      plugins: [
        cloudflare({
          viteEnvironment: {
            name: "rsc",
            childEnvironments: ["ssr"],
          },
        }),
      ],
    });

    @vitejs/plugin-rsc provides the lower level functionality that frameworks, such as React Router ↗, build upon. The GitHub repository includes a basic Cloudflare example ↗.

  1. Agents SDK v0.4.0: Readonly connections, MCP security improvements, x402 v2 migration, and custom MCP OAuth providers

    Agents Workers

    The latest release of the Agents SDK ↗ brings readonly connections, MCP protocol and security improvements, x402 payment protocol v2 migration, and the ability to customize OAuth for MCP server connections.

    Readonly connections

    Agents can now restrict WebSocket clients to read-only access, preventing them from modifying agent state. This is useful for dashboards, spectator views, or any scenario where clients should observe but not mutate.

    New hooks: shouldConnectionBeReadonly, setConnectionReadonly, isConnectionReadonly. Readonly connections block both client-side setState() and mutating @callable() methods, and the readonly flag survives hibernation.

    JavaScript
    class MyAgent extends Agent {
      shouldConnectionBeReadonly(connection) {
        // Make spectators readonly
        return connection.url.includes("spectator");
      }
    }

    Custom MCP OAuth providers

    The new createMcpOAuthProvider method on the Agent class allows subclasses to override the default OAuth provider used when connecting to MCP servers. This enables custom authentication strategies such as pre-registered client credentials or mTLS, beyond the built-in dynamic client registration.

    JavaScript
    class MyAgent extends Agent {
      createMcpOAuthProvider(callbackUrl) {
        return new MyCustomOAuthProvider(this.ctx.storage, this.name, callbackUrl);
      }
    }

    MCP SDK upgrade to 1.26.0

    Upgraded the MCP SDK to 1.26.0 to prevent cross-client response leakage. Stateless MCP Servers should now create a new McpServer instance per request instead of sharing a single instance. A guard is added in this version of the MCP SDK which will prevent connection to a Server instance that has already been connected to a transport. Developers will need to modify their code if they declare their McpServer instance as a global variable.

    MCP OAuth callback URL security fix

    Added callbackPath option to addMcpServer to prevent instance name leakage in MCP OAuth callback URLs. When sendIdentityOnConnect is false, callbackPath is now required — the default callback URL would expose the instance name, undermining the security intent. Also fixes callback request detection to match via the state parameter instead of a loose /callback URL substring check, enabling custom callback paths.

    Deprecate onStateUpdate in favor of onStateChanged

    onStateChanged is a drop-in rename of onStateUpdate (same signature, same behavior). onStateUpdate still works but emits a one-time console warning per class. validateStateChange rejections now propagate a CF_AGENT_STATE_ERROR message back to the client.

    x402 v2 migration

    Migrated the x402 MCP payment integration from the legacy x402 package to @x402/core and @x402/evm v2.

    Breaking changes for x402 users:

    • Peer dependencies changed: replace x402 with @x402/core and @x402/evm
    • PaymentRequirements type now uses v2 fields (e.g. amount instead of maxAmountRequired)
    • X402ClientConfig.account type changed from viem.Account to ClientEvmSigner (structurally compatible with privateKeyToAccount())
    Terminal window
    npm uninstall x402
    npm install @x402/core @x402/evm

    Network identifiers now accept both legacy names and CAIP-2 format:

    TypeScript
    // Legacy name (auto-converted)
    {
      network: "base-sepolia",
    }
    

    // CAIP-2 format (preferred)
    {
      network: "eip155:84532",
    }

    Other x402 changes:

    • X402ClientConfig.network is now optional — the client auto-selects from available payment requirements
    • Server-side lazy initialization: facilitator connection is deferred until the first paid tool invocation
    • Payment tokens support both v2 (PAYMENT-SIGNATURE) and v1 (X-PAYMENT) HTTP headers
    • Added normalizeNetwork export for converting legacy network names to CAIP-2 format
    • Re-exports PaymentRequirements, PaymentRequired, Network, FacilitatorConfig, and ClientEvmSigner from agents/x402

    Other improvements

    • Fix useAgent and AgentClient crashing when using basePath routing
    • CORS handling delegated to partyserver's native support (simpler, more reliable)
    • Client-side onStateUpdateError callback for handling rejected state updates

    Upgrade

    To update to the latest version:

    Terminal window
    npm i agents@latest

  1. Visualize data, share links, and create exports with the new Workers Observability dashboard

    Workers

    The Workers Observability dashboard ↗ has some major updates to make it easier to debug your application's issues and share findings with your team.

    Workers Observability dashboard showing events view with event details and share options

    You can now:

    • Create visualizations — Build charts from your Worker data directly in a Worker's Observability tab
    • Export data as JSON or CSV — Download logs and traces for offline analysis or to share with teammates
    • Share events and traces — Generate direct URLs to specific events, invocations, and traces that open standalone pages with full context
    • Customize table columns — Improved field picker to add, remove, and reorder columns in the events table
    • Expandable event details — Expand events inline to view full details without leaving the table
    • Keyboard shortcuts — Navigate the dashboard with hotkey support
    Workers Observability dashboard showing a P99 CPU time visualization grouped by outcome

    These updates are now live in the Cloudflare dashboard, both in a Worker's Observability tab and in the account-level Observability dashboard for a unified experience. To get started, go to Workers & Pages > select your Worker > Observability.

  1. Visualize your Workflows in the Cloudflare dashboard

    Workflows Workers

    Cloudflare Workflows now automatically generates visual diagrams from your code

    Your Workflow is parsed to provide a visual map of the Workflow structure, allowing you to:

    • Understand how steps connect and execute
    • Visualize loops and nested logic
    • Follow branching paths for conditional logic
    Example diagram

    You can collapse loops and nested logic to see the high-level flow, or expand them to see every step.

    Workflow diagrams are available in beta for all JavaScript and TypeScript Workflows. Find your Workflows in the Cloudflare dashboard ↗ to see their diagrams.

  1. New Placement Hints for Workers

    Workers

    You can now configure Workers to run close to infrastructure in legacy cloud regions to minimize latency to existing services and databases. This is most useful when your Worker makes multiple round trips.

    To set a placement hint, set the placement.region property in your Wrangler configuration file:

    {
      "placement": {
        "region": "aws:us-east-1",
      },
    }

    Placement hints support Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure region identifiers. Workers run in the Cloudflare data center ↗ with the lowest latency to the specified cloud region.

    If your existing infrastructure is not in these cloud providers, expose it to placement probes with placement.host for layer 4 checks or placement.hostname for layer 7 checks. These probes are designed to locate single-homed infrastructure and are not suitable for anycasted or multicasted resources.

    {
      "placement": {
        "host": "my_database_host.com:5432",
      },
    }
     
    {
      "placement": {
        "hostname": "my_api_server.com",
      },
    }

    This is an extension of Smart Placement, which automatically places your Workers closer to back-end APIs based on measured latency. When you do not know the location of your back-end APIs or have multiple back-end APIs, set mode: "smart":

    {
      "placement": {
        "mode": "smart",
      },
    }

  1. Use auxiliary Workers alongside full-stack frameworks

    Workers

    Auxiliary Workers are now fully supported when using full-stack frameworks, such as React Router and TanStack Start, that integrate with the Cloudflare Vite plugin. They are included alongside the framework's build output in the build output directory. Note that this feature requires Vite 7 or above.

    Auxiliary Workers are additional Workers that can be called via service bindings from your main (entry) Worker. They are defined in the plugin config, as in the example below:

    vite.config.ts
    import { defineConfig } from "vite";
    import { tanstackStart } from "@tanstack/react-start/plugin/vite";
    import { cloudflare } from "@cloudflare/vite-plugin";
    

    export default defineConfig({
      plugins: [
        tanstackStart(),
        cloudflare({
          viteEnvironment: { name: "ssr" },
          auxiliaryWorkers: [{ configPath: "./wrangler.aux.jsonc" }],
        }),
      ],
    });

    See the Vite plugin API docs for more info.

  1. Import SQL files as additional modules by default

    Workers

    The .sql file extension is now automatically configured to be importable in your Worker code when using Wrangler or the Cloudflare Vite plugin. This is particular useful for importing migrations in Durable Objects and means you no longer need to configure custom rules when using Drizzle ↗.

    SQL files are imported as JavaScript strings:

    TypeScript
    // `example` will be a JavaScript string
    import example from "./example.sql";

  1. `wrangler types` now generates types for all environments

    Workers

    The wrangler types command now generates TypeScript types for bindings from all environments defined in your Wrangler configuration file by default.

    Previously, wrangler types only generated types for bindings in the top-level configuration (or a single environment when using the --env flag). This meant that if you had environment-specific bindings — for example, a KV namespace only in production or an R2 bucket only in staging — those bindings would be missing from your generated types, causing TypeScript errors when accessing them.

    Now, running wrangler types collects bindings from all environments and includes them in the generated Env type. This ensures your types are complete regardless of which environment you deploy to.

    Generating types for a specific environment

    If you want the previous behavior of generating types for only a specific environment, you can use the --env flag:

    Terminal window
    wrangler types --env production

    Learn more about generating types for your Worker in the Wrangler documentation.

  1. Validate your generated types with `wrangler types --check`

    Workers

    Wrangler now supports a --check flag for the wrangler types command. This flag validates that your generated types are up to date without writing any changes to disk.

    This is useful in CI/CD pipelines where you want to ensure that developers have regenerated their types after making changes to their Wrangler configuration. If the types are out of date, the command will exit with a non-zero status code.

    Terminal window
    npx wrangler types --check

    If your types are up to date, the command will succeed silently. If they are out of date, you'll see an error message indicating which files need to be regenerated.

    For more information, see the Wrangler types documentation.

  1. Get notified when your Workers builds succeed or fail

    Workers Queues

    You can now receive notifications when your Workers' builds start, succeed, fail, or get cancelled using Event Subscriptions.

    Workers Builds publishes events to a Queue that your Worker can read messages from, and then send notifications wherever you need — Slack, Discord, email, or any webhook endpoint.

    You can deploy this Worker ↗ to your own Cloudflare account to send build notifications to Slack:

    Deploy to Cloudflare

    The template includes:

    • Build status with Preview/Live URLs for successful deployments
    • Inline error messages for failed builds
    • Branch, commit hash, and author name
    Slack notifications showing build events

    For setup instructions, refer to the template README ↗ or the Event Subscriptions documentation.

  1. Shell tab completions for Wrangler CLI

    Workers

    Wrangler now includes built-in shell tab completion support, making it faster and easier to navigate commands without memorizing every option. Press Tab as you type to autocomplete commands, subcommands, flags, and even option values like log levels.

    Tab completions are supported for Bash, Zsh, Fish, and PowerShell.

    Setup

    Generate the completion script for your shell and add it to your configuration file:

    Terminal window
    # Bash
    wrangler complete bash >> ~/.bashrc
    

    # Zsh
    wrangler complete zsh >> ~/.zshrc
    

    # Fish
    wrangler complete fish >> ~/.config/fish/config.fish
    

    # PowerShell
    wrangler complete powershell >> $PROFILE

    After adding the script, restart your terminal or source your configuration file for the changes to take effect. Then you can simply press Tab to see available completions:

    Terminal window
    wrangler d<TAB>          # completes to 'deploy', 'dev', 'd1', etc.
    wrangler kv <TAB>        # shows subcommands: namespace, key, bulk

    Tab completions are dynamically generated from Wrangler's command registry, so they stay up-to-date as new commands and options are added. This feature is powered by @bomb.sh/tab ↗.

    See the wrangler complete documentation for more details.

  1. Workers Analytics Engine SQL now supports filtering using HAVING and LIKE

    Workers Analytics Engine Workers

    You can now use the HAVING clause and LIKE pattern matching operators in Workers Analytics Engine ↗.

    Workers Analytics Engine allows you to ingest and store high-cardinality data at scale and query your data through a simple SQL API.

    Filtering using HAVING

    The HAVING clause complements the WHERE clause by enabling you to filter groups based on aggregate values. While WHERE filters rows before aggregation, HAVING filters groups after aggregation is complete.

    You can use HAVING to filter groups where the average exceeds a threshold:

    SELECT
        blob1 AS probe_name,
        avg(double1) AS average_temp
    FROM temperature_readings
    GROUP BY probe_name
    HAVING average_temp > 10

    You can also filter groups based on aggregates such as the number of items in the group:

    SELECT
        blob1 AS probe_name,
        count() AS num_readings
    FROM temperature_readings
    GROUP BY probe_name
    HAVING num_readings > 100

    Pattern matching using LIKE

    The new pattern matching operators enable you to search for strings that match specific patterns using wildcard characters:

    • LIKE - case-sensitive pattern matching
    • NOT LIKE - case-sensitive pattern exclusion
    • ILIKE - case-insensitive pattern matching
    • NOT ILIKE - case-insensitive pattern exclusion

    Pattern matching supports two wildcard characters: % (matches zero or more characters) and _ (matches exactly one character).

    You can match strings starting with a prefix:

    SELECT *
    FROM logs
    WHERE blob1 LIKE 'error%'

    You can also match file extensions (case-insensitive):

    SELECT *
    FROM requests
    WHERE blob2 ILIKE '%.jpg'

    Another example is excluding strings containing specific text:

    SELECT *
    FROM events
    WHERE blob3 NOT ILIKE '%debug%'

    Ready to get started?

    Learn more about the HAVING clause or pattern matching operators in the Workers Analytics Engine SQL reference documentation.

  1. Build microfrontend applications on Workers

    Workers

    You can now deploy microfrontends to Cloudflare, splitting a single application into smaller, independently deployable units that render as one cohesive application. This lets different teams using different frameworks develop, test, and deploy each microfrontend without coordinating releases.

    Microfrontends solve several challenges for large-scale applications:

    • Independent deployments: Teams deploy updates on their own schedule without redeploying the entire application
    • Framework flexibility: Build multi-framework applications (for example, Astro, Remix, and Next.js in one app)
    • Gradual migration: Migrate from a monolith to a distributed architecture incrementally

    Create a microfrontend project:

    Deploy to Cloudflare

    This template automatically creates a router worker with pre-configured routing logic, and lets you configure Service bindings to Workers you have already deployed to your Cloudflare account. The router Worker analyzes incoming requests, matches them against configured routes, and forwards requests to the appropriate microfrontend via service bindings. The router automatically rewrites HTML, CSS, and headers to ensure assets load correctly from each microfrontend's mount path. The router includes advanced features like preloading for faster navigation between microfrontends, smooth page transitions using the View Transitions API, and automatic path rewriting for assets, redirects, and cookies.

    Each microfrontend can be a full-framework application, a static site with Workers Static Assets, or any other Worker-based application.

    Get started with the microfrontends template ↗, or read the microfrontends documentation for implementation details.

  1. Agents SDK v0.3.0, workers-ai-provider v3.0.0, and ai-gateway-provider v3.0.0 with AI SDK v6 support

    Agents Workers

    We've shipped a new release for the Agents SDK ↗ v0.3.0 bringing full compatibility with AI SDK v6 ↗ and introducing the unified tool pattern, dynamic tool approval, and enhanced React hooks with improved tool handling.

    This release includes improved streaming and tool support, dynamic tool approval (for "human in the loop" systems), enhanced React hooks with onToolCall callback, improved error handling for streaming responses, and seamless migration from v5 patterns.

    This makes it ideal for building production AI chat interfaces with Cloudflare Workers AI models, agent workflows, human-in-the-loop systems, or any application requiring reliable tool execution and approval workflows.

    Additionally, we've updated workers-ai-provider v3.0.0, the official provider for Cloudflare Workers AI models, and ai-gateway-provider v3.0.0, the provider for Cloudflare AI Gateway, to be compatible with AI SDK v6.

    Agents SDK v0.3.0

    Unified Tool Pattern

    AI SDK v6 introduces a unified tool pattern where all tools are defined on the server using the tool() function. This replaces the previous client-side AITool pattern.

    Server-Side Tool Definition

    TypeScript
    import { tool } from "ai";
    import { z } from "zod";
    

    // Server: Define ALL tools on the server
    const tools = {
      // Server-executed tool
      getWeather: tool({
        description: "Get weather for a city",
        inputSchema: z.object({ city: z.string() }),
        execute: async ({ city }) => fetchWeather(city)
      }),
    

      // Client-executed tool (no execute = client handles via onToolCall)
      getLocation: tool({
        description: "Get user location from browser",
        inputSchema: z.object({})
        // No execute function
      }),
    

      // Tool requiring approval (dynamic based on input)
      processPayment: tool({
        description: "Process a payment",
        inputSchema: z.object({ amount: z.number() }),
        needsApproval: async ({ amount }) => amount > 100,
        execute: async ({ amount }) => charge(amount)
      })
    };

    Client-Side Tool Handling

    TypeScript
    // Client: Handle client-side tools via onToolCall callback
    import { useAgentChat } from "agents/ai-react";
    

    const { messages, sendMessage, addToolOutput } = useAgentChat({
      agent,
      onToolCall: async ({ toolCall, addToolOutput }) => {
        if (toolCall.toolName === "getLocation") {
          const position = await new Promise((resolve, reject) => {
            navigator.geolocation.getCurrentPosition(resolve, reject);
          });
          addToolOutput({
            toolCallId: toolCall.toolCallId,
            output: {
              lat: position.coords.latitude,
              lng: position.coords.longitude
            }
          });
        }
      }
    });

    Key benefits of the unified tool pattern:

    • Server-defined tools: All tools are defined in one place on the server
    • Dynamic approval: Use needsApproval to conditionally require user confirmation
    • Cleaner client code: Use onToolCall callback instead of managing tool configs
    • Type safety: Full TypeScript support with proper tool typing

    useAgentChat(options)

    Creates a new chat interface with enhanced v6 capabilities.

    TypeScript
    // Basic chat setup with onToolCall
    const { messages, sendMessage, addToolOutput } = useAgentChat({
      agent,
      onToolCall: async ({ toolCall, addToolOutput }) => {
        // Handle client-side tool execution
        await addToolOutput({
          toolCallId: toolCall.toolCallId,
          output: { result: "success" }
        });
      }
    });

    Dynamic Tool Approval

    Use needsApproval on server tools to conditionally require user confirmation:

    TypeScript
    const paymentTool = tool({
      description: "Process a payment",
      inputSchema: z.object({
        amount: z.number(),
        recipient: z.string()
      }),
      needsApproval: async ({ amount }) => amount > 1000,
      execute: async ({ amount, recipient }) => {
        return await processPayment(amount, recipient);
      }
    });

    Tool Confirmation Detection

    The isToolUIPart and getToolName functions now check both static and dynamic tool parts:

    TypeScript
    import { isToolUIPart, getToolName } from "ai";
    

    const pendingToolCallConfirmation = messages.some((m) =>
      m.parts?.some(
        (part) => isToolUIPart(part) && part.state === "input-available",
      ),
    );
    

    // Handle tool confirmation
    if (pendingToolCallConfirmation) {
      await addToolOutput({
        toolCallId: part.toolCallId,
        output: "User approved the action"
      });
    }

    If you need the v5 behavior (static-only checks), use the new functions:

    TypeScript
    import { isStaticToolUIPart, getStaticToolName } from "ai";

    convertToModelMessages() is now async

    The convertToModelMessages() function is now asynchronous. Update all calls to await the result:

    TypeScript
    import { convertToModelMessages } from "ai";
    

    const result = streamText({
      messages: await convertToModelMessages(this.messages),
      model: openai("gpt-4o")
    });

    ModelMessage type

    The CoreMessage type has been removed. Use ModelMessage instead:

    TypeScript
    import { convertToModelMessages, type ModelMessage } from "ai";
    

    const modelMessages: ModelMessage[] = await convertToModelMessages(messages);

    generateObject mode option removed

    The mode option for generateObject has been removed:

    TypeScript
    // Before (v5)
    const result = await generateObject({
      mode: "json",
      model,
      schema,
      prompt
    });
    

    // After (v6)
    const result = await generateObject({
      model,
      schema,
      prompt
    });

    Structured Output with generateText

    While generateObject and streamObject are still functional, the recommended approach is to use generateText/streamText with the Output.object() helper:

    TypeScript
    import { generateText, Output, stepCountIs } from "ai";
    

    const { output } = await generateText({
      model: openai("gpt-4"),
      output: Output.object({
        schema: z.object({ name: z.string() })
      }),
      stopWhen: stepCountIs(2),
      prompt: "Generate a name"
    });

    Note: When using structured output with generateText, you must configure multiple steps with stopWhen because generating the structured output is itself a step.

    workers-ai-provider v3.0.0

    Seamless integration with Cloudflare Workers AI models through the updated workers-ai-provider v3.0.0 with AI SDK v6 support.

    Model Setup with Workers AI

    Use Cloudflare Workers AI models directly in your agent workflows:

    TypeScript
    import { createWorkersAI } from "workers-ai-provider";
    import { useAgentChat } from "agents/ai-react";
    

    // Create Workers AI model (v3.0.0 - enhanced v6 internals)
    const model = createWorkersAI({
      binding: env.AI,
    })("@cf/meta/llama-3.2-3b-instruct");

    Enhanced File and Image Support

    Workers AI models now support v6 file handling with automatic conversion:

    TypeScript
    // Send images and files to Workers AI models
    sendMessage({
      role: "user",
      parts: [
        { type: "text", text: "Analyze this image:" },
        {
          type: "file",
          data: imageBuffer,
          mediaType: "image/jpeg",
        },
      ],
    });
    

    // Workers AI provider automatically converts to proper format

    Streaming with Workers AI

    Enhanced streaming support with automatic warning detection:

    TypeScript
    // Streaming with Workers AI models
    const result = await streamText({
      model: createWorkersAI({ binding: env.AI })("@cf/meta/llama-3.2-3b-instruct"),
      messages: await convertToModelMessages(messages),
      onChunk: (chunk) => {
        // Enhanced streaming with warning handling
        console.log(chunk);
      },
    });

    ai-gateway-provider v3.0.0

    The ai-gateway-provider v3.0.0 now supports AI SDK v6, enabling you to use Cloudflare AI Gateway with multiple AI providers including Anthropic, Azure, AWS Bedrock, Google Vertex, and Perplexity.

    AI Gateway Setup

    Use Cloudflare AI Gateway to add analytics, caching, and rate limiting to your AI applications:

    TypeScript
    import { createAIGateway } from "ai-gateway-provider";
    

    // Create AI Gateway provider (v3.0.0 - enhanced v6 internals)
    const model = createAIGateway({
      gatewayUrl: "https://gateway.ai.cloudflare.com/v1/your-account-id/gateway",
      headers: {
        "Authorization": `Bearer ${env.AI_GATEWAY_TOKEN}`
      }
    })({
      provider: "openai",
      model: "gpt-4o"
    });

    Migration from v5

    Deprecated APIs

    The following APIs are deprecated in favor of the unified tool pattern:

    DeprecatedReplacement
    AITool typeUse AI SDK's tool() function on server
    extractClientToolSchemas()Define tools on server, no client schemas needed
    createToolsFromClientSchemas()Define tools on server with tool()
    toolsRequiringConfirmation optionUse needsApproval on server tools
    experimental_automaticToolResolutionUse onToolCall callback
    tools option in useAgentChatUse onToolCall for client-side execution
    addToolResult()Use addToolOutput()

    Breaking Changes Summary

    1. Unified Tool Pattern: All tools must be defined on the server using tool()
    2. convertToModelMessages() is async: Add await to all calls
    3. CoreMessage removed: Use ModelMessage instead
    4. generateObject mode removed: Remove mode option
    5. isToolUIPart behavior changed: Now checks both static and dynamic tool parts

    Installation

    Update your dependencies to use the latest versions:

    Terminal window
    npm install agents@^0.3.0 workers-ai-provider@^3.0.0 ai-gateway-provider@^3.0.0 ai@^6.0.0 @ai-sdk/react@^3.0.0 @ai-sdk/openai@^3.0.0

    Resources

    Feedback Welcome

    We'd love your feedback! We're particularly interested in feedback on:

    • Migration experience - How smooth was the upgrade from v5 to v6?
    • Unified tool pattern - How does the new server-defined tool pattern work for you?
    • Dynamic tool approval - Does the needsApproval feature meet your needs?
    • AI Gateway integration - How well does the new provider work with your setup?
Search all changelog entries