Skip to content
Cloudflare Docs
Docs DirectoryAPIsSDKs

Changelog

New updates and improvements at Cloudflare.

Subscribe to RSS View RSS feeds
Developer platform
hero image

  1. Stream live inputs can now be disabled and enabled

    Stream

    You can now disable a live input to reject incoming RTMPS and SRT connections. When a live input is disabled, any broadcast attempts will fail to connect.

    This gives you more control over your live inputs:

    • Temporarily pause an input without deleting it
    • Programmatically end creator broadcasts
    • Prevent new broadcasts from starting on a specific input

    To disable a live input via the API, set the enabled property to false:

    Terminal window
    curl --request PUT \
    https://api.cloudflare.com/client/v4/accounts/{account_id}/stream/live_inputs/{input_id} \
    --header "Authorization: Bearer <API_TOKEN>" \
    --data '{"enabled": false}'

    You can also disable or enable a live input from the Live inputs list page or the live input detail page in the Dashboard.

    All existing live inputs remain enabled by default. For more information, refer to Start a live stream.

  1. Backup and restore API for Sandbox SDK

    Agents R2 Containers

    Sandboxes now support createBackup() and restoreBackup() methods for creating and restoring point-in-time snapshots of directories.

    This allows you to restore environments quickly. For instance, in order to develop in a sandbox, you may need to include a user's codebase and run a build step. Unfortunately git clone and npm install can take minutes, and you don't want to run these steps every time the user starts their sandbox.

    Now, after the initial setup, you can just call createBackup(), then restoreBackup() the next time this environment is needed. This makes it practical to pick up exactly where a user left off, even after days of inactivity, without repeating expensive setup steps.

    TypeScript
    const sandbox = getSandbox(env.Sandbox, "my-sandbox");
    

    // Make non-trivial changes to the file system
    await sandbox.gitCheckout(endUserRepo, { targetDir: "/workspace" });
    await sandbox.exec("npm install", { cwd: "/workspace" });
    

    // Create a point-in-time backup of the directory
    const backup = await sandbox.createBackup({ dir: "/workspace" });
    

    // Store the handle for later use
    await env.KV.put(`backup:${userId}`, JSON.stringify(backup));
    

    // ... in a future session...
    

    // Restore instead of re-cloning and reinstalling
    await sandbox.restoreBackup(backup);

    Backups are stored in R2 and can take advantage of R2 object lifecycle rules to ensure they do not persist forever.

    Key capabilities:

    • Persist and reuse across sandbox sessions — Easily store backup handles in KV, D1, or Durable Object storage for use in subsequent sessions
    • Usable across multiple instances — Fork a backup across many sandboxes for parallel work
    • Named backups — Provide optional human-readable labels for easier management
    • TTLs — Set time-to-live durations so backups are automatically removed from storage once they are no longer needed

    To get started, refer to the backup and restore guide for setup instructions and usage patterns, or the Backups API reference for full method documentation.

  1. Hyperdrive no longer caches queries using STABLE PostgreSQL functions

    Hyperdrive

    Hyperdrive now treats queries containing PostgreSQL STABLE functions as uncacheable, in addition to VOLATILE functions.

    Previously, only functions that PostgreSQL categorizes ↗ as VOLATILE (for example, RANDOM(), LASTVAL()) were detected as uncacheable. STABLE functions (for example, NOW(), CURRENT_TIMESTAMP, CURRENT_DATE) were incorrectly allowed to be cached.

    Because STABLE functions can return different results across different SQL statements within the same transaction, caching their results could serve stale or incorrect data. This change aligns Hyperdrive's caching behavior with PostgreSQL's function volatility semantics.

    If your queries use STABLE functions, and you were relying on them being cached, move the function call to your application code and pass the result as a query parameter. For example, instead of WHERE created_at > NOW(), compute the timestamp in your Worker and pass it as WHERE created_at > $1.

    Hyperdrive uses text-based pattern matching to detect uncacheable functions. References to function names like NOW() in SQL comments also cause the query to be marked as uncacheable.

    For more information, refer to Query caching and Troubleshoot and debug.

  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

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

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

    Upgrade

    Terminal window
    npm i @cloudflare/codemode@latest

  1. Manage Cloudflare Tunnel directly from the main Cloudflare Dashboard

    Cloudflare Tunnel Cloudflare Tunnel for SASE

    Cloudflare Tunnel is now available in the main Cloudflare Dashboard at Networking > Tunnels ↗, bringing first-class Tunnel management to developers using Tunnel for securing origin servers.

    Manage Tunnels in the Core Dashboard

    This new experience provides everything you need to manage Tunnels for public applications, including:

    Choose the right dashboard for your use case

    Core Dashboard: Navigate to Networking > Tunnels ↗ to manage Tunnels for:

    Cloudflare One Dashboard: Navigate to Zero Trust > Networks > Connectors ↗ to manage Tunnels for:

    Both dashboards provide complete Tunnel management capabilities — choose based on your primary workflow.

    Get started

    New to Tunnel? Learn how to get started with Cloudflare Tunnel or explore advanced use cases like securing SSH servers or running Tunnels in Kubernetes.

  1. AI dashboard experience improvements

    AI Gateway Workers AI

    Workers AI and AI Gateway have received a series of dashboard improvements to help you get started faster and manage your AI workloads more easily.

    Navigation and discoverability

    AI now has its own top-level section in the Cloudflare dashboard sidebar, so you can find AI features without digging through menus.

    AI sidebar navigation in the Cloudflare dashboard

    Onboarding and getting started

    Getting started with AI Gateway is now simpler. When you create your first gateway, we now show your gateway's OpenAI-compatible endpoint and step-by-step guidance to help you configure it. The Playground also includes helpful prompts, and usage pages have clear next steps if you have not made any requests yet.

    AI Gateway onboarding flow

    We've also combined the previously separate code example sections into one view with dropdown selectors for API type, provider, SDK, and authentication method so you can now customize the exact code snippet you need from one place.

    Dynamic Routing

    • The route builder is now more performant and responsive.
    • You can now copy route names to your clipboard with a single click.
    • Code examples use the Universal Endpoint format, making it easier to integrate routes into your application.

    Observability and analytics

    • Small monetary values now display correctly in cost analytics charts, so you can accurately track spending at any scale.

    Accessibility

    • Improvements to keyboard navigation within the AI Gateway, specifically when exploring usage by provider.
    • Improvements to sorting and filtering components on the Workers AI models page.

    For more information, refer to the AI Gateway documentation.

  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. Docker-in-Docker support added to Containers and Sandboxes

    Containers

    Sandboxes and Containers now support running Docker for "Docker-in-Docker" setups. This is particularly useful when your end users or agents want to run a full sandboxed development environment.

    This allows you to:

    • Develop containerized applications with your Sandbox
    • Run isolated test environments for images
    • Build container images as part of CI/CD workflows
    • Deploy arbitrary images supplied at runtime within a container

    For Sandbox SDK users, see the Docker-in-Docker guide for instructions on combining Docker with the SandboxSDK. For general Containers usage, see the Containers FAQ.

  1. Quick Editor devtools replaced with log viewer

    Workers

    Cloudflare has deprecated the Workers Quick Editor dev tools inspector and replaced it with a lightweight log viewer.

    This aligns our logging with wrangler tail and gives us the opportunity to focus our efforts on bringing benefits from the work we have invested in observability, which would not be possible otherwise.

    We have made improvements to this logging viewer based on your feedback such that you can log object and array types, and easily clear the list of logs. This does not include class instances. Limitations are documented in the Workers Playground docs.

    If you do need to develop your Worker with a remote inspector, you can still do this using Wrangler locally. Cloning a project from your quick editor to your computer for local development can be done with the wrangler init --from-dash command. For more information, refer to Wrangler commands.

  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.
    JSONC
    {
      "name": "my-worker",
      "main": "src/index.ts",
      // Set this to today's date
      "compatibility_date": "2026-04-29",
      "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. Cloudflare Python SDK v5.0.0-beta.1 now available

    Cloudflare Fundamentals SDK

    Disclaimer: Please note that v5.0.0-beta.1 is in Beta and we are still testing it for stability.

    Full Changelog: v4.3.1...v5.0.0-beta.1 ↗

    In this release, you'll see a large number of breaking changes. This is primarily due to a change in OpenAPI definitions, which our libraries are based off of, and codegen updates that we rely on to read those OpenAPI definitions and produce our SDK libraries. As the codegen is always evolving and improving, so are our code bases.

    There may be changes that are not captured in this changelog. Feel free to open an issue to report any inaccuracies, and we will make sure it gets into the changelog before the v5.0.0 release.

    Most of the breaking changes below are caused by improvements to the accuracy of the base OpenAPI schemas, which sometimes translates to breaking changes in downstream clients that depend on those schemas.

    Please ensure you read through the list of changes below and the migration guide before moving to this version - this will help you understand any down or upstream issues it may cause to your environments.

    Breaking Changes

    The following resources have breaking changes. See the v5 Migration Guide ↗ for detailed migration instructions.

    • abusereports
    • acm.totaltls
    • apigateway.configurations
    • cloudforceone.threatevents
    • d1.database
    • intel.indicatorfeeds
    • logpush.edge
    • origintlsclientauth.hostnames
    • queues.consumers
    • radar.bgp
    • rulesets.rules
    • schemavalidation.schemas
    • snippets
    • zerotrust.dlp
    • zerotrust.networks

    Features

    New API Resources

    • abusereports - Abuse report management
    • abusereports.mitigations - Abuse report mitigation actions
    • ai.tomarkdown - AI-powered markdown conversion
    • aigateway.dynamicrouting - AI Gateway dynamic routing configuration
    • aigateway.providerconfigs - AI Gateway provider configurations
    • aisearch - AI-powered search functionality
    • aisearch.instances - AI Search instance management
    • aisearch.tokens - AI Search authentication tokens
    • alerting.silences - Alert silence management
    • brandprotection.logomatches - Brand protection logo match detection
    • brandprotection.logos - Brand protection logo management
    • brandprotection.matches - Brand protection match results
    • brandprotection.queries - Brand protection query management
    • cloudforceone.binarystorage - CloudForce One binary storage
    • connectivity.directory - Connectivity directory services
    • d1.database - D1 database management
    • diagnostics.endpointhealthchecks - Endpoint health check diagnostics
    • fraud - Fraud detection and prevention
    • iam.sso - IAM Single Sign-On configuration
    • loadbalancers.monitorgroups - Load balancer monitor groups
    • organizations - Organization management
    • organizations.organizationprofile - Organization profile settings
    • origintlsclientauth.hostnamecertificates - Origin TLS client auth hostname certificates
    • origintlsclientauth.hostnames - Origin TLS client auth hostnames
    • origintlsclientauth.zonecertificates - Origin TLS client auth zone certificates
    • pipelines - Data pipeline management
    • pipelines.sinks - Pipeline sink configurations
    • pipelines.streams - Pipeline stream configurations
    • queues.subscriptions - Queue subscription management
    • r2datacatalog - R2 Data Catalog integration
    • r2datacatalog.credentials - R2 Data Catalog credentials
    • r2datacatalog.maintenanceconfigs - R2 Data Catalog maintenance configurations
    • r2datacatalog.namespaces - R2 Data Catalog namespaces
    • radar.bots - Radar bot analytics
    • radar.ct - Radar certificate transparency data
    • radar.geolocations - Radar geolocation data
    • realtimekit.activesession - Real-time Kit active session management
    • realtimekit.analytics - Real-time Kit analytics
    • realtimekit.apps - Real-time Kit application management
    • realtimekit.livestreams - Real-time Kit live streaming
    • realtimekit.meetings - Real-time Kit meeting management
    • realtimekit.presets - Real-time Kit preset configurations
    • realtimekit.recordings - Real-time Kit recording management
    • realtimekit.sessions - Real-time Kit session management
    • realtimekit.webhooks - Real-time Kit webhook configurations
    • tokenvalidation.configuration - Token validation configuration
    • tokenvalidation.rules - Token validation rules
    • workers.beta - Workers beta features

    New Endpoints (Existing Resources)

    acm.totaltls

    • edit()
    • update()

    cloudforceone.threatevents

    • list()

    contentscanning

    • create()
    • get()
    • update()

    dns.records

    • scan_list()
    • scan_review()
    • scan_trigger()

    intel.indicatorfeeds

    • create()
    • delete()
    • list()

    leakedcredentialchecks.detections

    • get()

    queues.consumers

    • list()

    radar.ai

    • summary()
    • timeseries()
    • timeseries_groups()

    radar.bgp

    • changes()
    • snapshot()

    workers.subdomains

    • delete()

    zerotrust.networks

    • create()
    • delete()
    • edit()
    • get()
    • list()

    General Fixes and Improvements

    Type System & Compatibility

    • Type inference improvements: Allow Pyright to properly infer TypedDict types within SequenceNotStr
    • Type completeness: Add missing types to method arguments and response models
    • Pydantic compatibility: Ensure compatibility with Pydantic versions prior to 2.8.0 when using additional fields

    Request/Response Handling

    • Multipart form data: Correctly handle sending multipart/form-data requests with JSON data
    • Header handling: Do not send headers with default values set to omit
    • GET request headers: Don't send Content-Type header on GET requests
    • Response body model accuracy: Broad improvements to the correctness of models

    Parsing & Data Processing

    • Discriminated unions: Correctly handle nested discriminated unions in response parsing
    • Extra field types: Parse extra field types correctly
    • Empty metadata: Ignore empty metadata fields during parsing
    • Singularization rules: Update resource name singularization rules for better consistency

  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. Origin CA certificate support for Workers VPC

    Workers VPC

    Workers VPC now supports Cloudflare Origin CA certificates when connecting to your private services over HTTPS. Previously, Workers VPC only trusted certificates issued by publicly trusted certificate authorities (for example, Let's Encrypt, DigiCert).

    With this change, you can use free Cloudflare Origin CA certificates on your origin servers within private networks and connect to them from Workers VPC using the https scheme. This is useful for encrypting traffic between the tunnel and your service without needing to provision certificates from a public CA.

    For more information, refer to Supported TLS certificates.

  1. Terraform v5.17.0 now available

    Cloudflare Fundamentals Terraform

    In January 2025, we announced the launch of the new Terraform v5 Provider. We greatly appreciate the proactive engagement and valuable feedback from the Cloudflare community following the v5 release. In response, we have established a consistent and rapid 2-3 week cadence ↗ for releasing targeted improvements, demonstrating our commitment to stability and reliability.

    With the help of the community, we have a growing number of resources that we have marked as stable ↗, with that list continuing to grow with every release. The most used resources ↗ are on track to be stable by the end of March 2026, when we will also be releasing a new migration tool to help you migrate from v4 to v5 with ease.

    This release brings new capabilities for AI Search, enhanced Workers Script placement controls, and numerous bug fixes based on community feedback. We also begun laying foundational work for improving the v4 to v5 migration process. Stay tuned for more details as we approach the March 2026 release timeline.

    Thank you for continuing to raise issues. They make our provider stronger and help us build products that reflect your needs.

    Features

    • ai_search_instance: add data source for querying AI Search instances
    • ai_search_token: add data source for querying AI Search tokens
    • account: add support for tenant unit management with new unit field
    • account: add automatic mapping from managed_by.parent_org_id to unit.id
    • authenticated_origin_pulls_certificate: add data source for querying authenticated origin pull certificates
    • authenticated_origin_pulls_hostname_certificate: add data source for querying hostname-specific authenticated origin pull certificates
    • authenticated_origin_pulls_settings: add data source for querying authenticated origin pull settings
    • workers_kv: add value field to data source to retrieve KV values directly
    • workers_script: add script field to data source to retrieve script content
    • workers_script: add support for simple rate limit binding
    • workers_script: add support for targeted placement mode with placement.target array for specifying placement targets (region, hostname, host)
    • workers_script: add placement_mode and placement_status computed fields
    • zero_trust_dex_test: add data source with filter support for finding specific tests
    • zero_trust_dlp_predefined_profile: add enabled_entries field for flexible entry management

    Bug Fixes

    • account: map managed_by.parent_org_id to unit.id in unmarshall and add acceptance tests
    • authenticated_origin_pulls_certificate: add certificate normalization to prevent drift
    • authenticated_origin_pulls: handle array response and implement full lifecycle
    • authenticated_origin_pulls_hostname_certificate: fix resource and tests
    • cloudforce_one_request_message: use correct request_id field instead of id in API calls
    • dns_zone_transfers_incoming: use correct zone_id field instead of id in API calls
    • dns_zone_transfers_outgoing: use correct zone_id field instead of id in API calls
    • email_routing_settings: use correct zone_id field instead of id in API calls
    • hyperdrive_config: add proper handling for write-only fields to prevent state drift
    • hyperdrive_config: add normalization for empty mtls objects to prevent unnecessary diffs
    • magic_network_monitoring_rule: use correct account_id field instead of id in API calls
    • mtls_certificates: fix resource and test
    • pages_project: revert build_config to computed optional
    • stream_key: use correct account_id field instead of id in API calls
    • total_tls: use upsert pattern for singleton zone setting
    • waiting_room_rules: use correct waiting_room_id field instead of id in API calls
    • workers_script: add support for placement mode/status
    • zero_trust_access_application: update v4 version on migration tests
    • zero_trust_device_posture_rule: update tests to match API
    • zero_trust_dlp_integration_entry: use correct entry_id field instead of id in API calls
    • zero_trust_dlp_predefined_entry: use correct entry_id field instead of id in API calls
    • zero_trust_organization: fix plan issues

    Chores

    • add state upgraders to 95+ resources to lay the foundation for replacing Grit (still under active development)
    • certificate_pack: add state migration handler for SDKv2 to Framework conversion
    • custom_hostname_fallback_origin: add comprehensive lifecycle test and migration support
    • dns_record: add state migration handler for SDKv2 to Framework conversion
    • leaked_credential_check: add import functionality and tests
    • load_balancer_pool: add state migration handler with detection for v4 vs v5 format
    • pages_project: add state migration handlers
    • tiered_cache: add state migration handlers
    • zero_trust_dlp_predefined_profile: deprecate entries field in favor of enabled_entries

    For more information

  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.

    JSONC
    {
      "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.

    JSONC
    {
      "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. Interactive browser terminals in Sandboxes

    Agents

    The Sandbox SDK ↗ now supports PTY (pseudo-terminal) passthrough, enabling browser-based terminal UIs to connect to sandbox shells via WebSocket.

    sandbox.terminal(request)

    The new terminal() method proxies a WebSocket upgrade to the container's PTY endpoint, with output buffering for replay on reconnect.

    JavaScript
    // Worker: proxy WebSocket to container terminal
    return sandbox.terminal(request, { cols: 80, rows: 24 });

    Multiple terminals per sandbox

    Each session can have its own terminal with an isolated working directory and environment, so users can run separate shells side-by-side in the same container.

    JavaScript
    // Multiple isolated terminals in the same sandbox
    const dev = await sandbox.getSession("dev");
    return dev.terminal(request);

    xterm.js addon

    The new @cloudflare/sandbox/xterm export provides a SandboxAddon for xterm.js ↗ with automatic reconnection (exponential backoff + jitter), buffered output replay, and resize forwarding.

    JavaScript
    import { SandboxAddon } from "@cloudflare/sandbox/xterm";
    

    const addon = new SandboxAddon({
      getWebSocketUrl: ({ sandboxId, origin }) =>
        `${origin}/ws/terminal?id=${sandboxId}`,
      onStateChange: (state, error) => updateUI(state),
    });
    terminal.loadAddon(addon);
    addon.connect({ sandboxId: "my-sandbox" });

    Upgrade

    To update to the latest version:

    Terminal window
    npm i @cloudflare/sandbox@latest

  1. AI Search now with more granular controls over indexing

    AI Search

    Get your content updates into AI Search faster and avoid a full rescan when you do not need it.

    Reindex individual files without a full sync

    Updated a file or need to retry one that errored? When you know exactly which file changed, you can now reindex it directly instead of rescanning your entire data source.

    Go to Overview > Indexed Items and select the sync icon next to any file to reindex it immediately.

    Sync individual files from Indexed Items

    Crawl only the sitemap you need

    By default, AI Search crawls all sitemaps listed in your robots.txt, up to the maximum files per index limit. If your site has multiple sitemaps but you only want to index a specific set, you can now specify a single sitemap URL to limit what the crawler visits.

    For example, if your robots.txt lists both blog-sitemap.xml and docs-sitemap.xml, you can specify just https://example.com/docs-sitemap.xml to index only your documentation.

    Configure your selection anytime in Settings > Parsing options > Specific sitemaps, then trigger a sync to apply the changes.

    Specify a sitemap in Parsinh options

    Learn more about indexing controls and website crawling configuration.

  1. R2 SQL now supports approximate aggregation functions

    R2 SQL

    R2 SQL now supports five approximate aggregation functions for fast analysis of large datasets. These functions trade minor precision for improved performance on high-cardinality data.

    New functions

    • APPROX_PERCENTILE_CONT(column, percentile) — Returns the approximate value at a given percentile (0.0 to 1.0). Works on integer and decimal columns.
    • APPROX_PERCENTILE_CONT_WITH_WEIGHT(column, weight, percentile) — Weighted percentile calculation where each row contributes proportionally to its weight column value.
    • APPROX_MEDIAN(column) — Returns the approximate median. Equivalent to APPROX_PERCENTILE_CONT(column, 0.5).
    • APPROX_DISTINCT(column) — Returns the approximate number of distinct values. Works on any column type.
    • APPROX_TOP_K(column, k) — Returns the k most frequent values with their counts as a JSON array.

    All functions support WHERE filters. All except APPROX_TOP_K support GROUP BY.

    Examples

    -- Percentile analysis on revenue data
    SELECT approx_percentile_cont(total_amount, 0.25),
           approx_percentile_cont(total_amount, 0.5),
           approx_percentile_cont(total_amount, 0.75)
    FROM my_namespace.sales_data
    -- Median per department
    SELECT department, approx_median(total_amount)
    FROM my_namespace.sales_data
    GROUP BY department
    -- Approximate distinct customers by region
    SELECT region, approx_distinct(customer_id)
    FROM my_namespace.sales_data
    GROUP BY region
    -- Top 5 most frequent departments
    SELECT approx_top_k(department, 5)
    FROM my_namespace.sales_data
    -- Combine approximate and standard aggregations
    SELECT COUNT(*),
           AVG(total_amount),
           approx_percentile_cont(total_amount, 0.5),
           approx_distinct(customer_id)
    FROM my_namespace.sales_data
    WHERE region = 'North'

    For the full syntax and additional examples, refer to the SQL reference.

  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. Cloudflare Queues now available on Workers Free plan

    Queues

    Cloudflare Queues is now part of the Workers free plan, offering guaranteed message delivery across up to 10,000 queues to either Cloudflare Workers or HTTP pull consumers. Every Cloudflare account now includes 10,000 operations per day across reads, writes, and deletes. For more details on how each operation is defined, refer to Queues pricing ↗.

    All features of the existing Queues functionality are available on the free plan, including unlimited event subscriptions. Note that the maximum retention period on the free tier, however, is 24 hours rather than 14 days.

    If you are new to Cloudflare Queues, follow this guide ↗ or try one of our tutorials to get started.

  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. Agents SDK v0.3.7: Workflows integration, synchronous state, and scheduleEvery()

    Agents Workflows

    The latest release of the Agents SDK ↗ brings first-class support for Cloudflare Workflows, synchronous state management, and new scheduling capabilities.

    Cloudflare Workflows integration

    Agents excel at real-time communication and state management. Workflows excel at durable execution. Together, they enable powerful patterns where Agents handle WebSocket connections while Workflows handle long-running tasks, retries, and human-in-the-loop flows.

    Use the new AgentWorkflow class to define workflows with typed access to your Agent:

    JavaScript
    import { AgentWorkflow } from "agents/workflows";
    export class ProcessingWorkflow extends AgentWorkflow {
      async run(event, step) {
        // Call Agent methods via RPC
        await this.agent.updateStatus(event.payload.taskId, "processing");
    

        // Non-durable: progress reporting to clients
        await this.reportProgress({ step: "process", percent: 0.5 });
        this.broadcastToClients({ type: "update", taskId: event.payload.taskId });
    

        // Durable via step: idempotent, won't repeat on retry
        await step.mergeAgentState({ taskProgress: 0.5 });
    

        const result = await step.do("process", async () => {
          return processData(event.payload.data);
        });
    

        await step.reportComplete(result);
        return result;
      }
    }

    Start workflows from your Agent with runWorkflow() and handle lifecycle events:

    JavaScript
    export class MyAgent extends Agent {
      async startTask(taskId, data) {
        const instanceId = await this.runWorkflow("PROCESSING_WORKFLOW", {
          taskId,
          data,
        });
        return { instanceId };
      }
    

      async onWorkflowProgress(workflowName, instanceId, progress) {
        this.broadcast(JSON.stringify({ type: "progress", progress }));
      }
    

      async onWorkflowComplete(workflowName, instanceId, result) {
        console.log(`Workflow ${instanceId} completed`);
      }
    

      async onWorkflowError(workflowName, instanceId, error) {
        console.error(`Workflow ${instanceId} failed:`, error);
      }
    }

    Key workflow methods on your Agent:

    • runWorkflow(workflowName, params, options?) — Start a workflow with optional metadata
    • getWorkflow(workflowId) / getWorkflows(criteria?) — Query workflows with cursor-based pagination
    • approveWorkflow(workflowId) / rejectWorkflow(workflowId) — Human-in-the-loop approval flows
    • pauseWorkflow(), resumeWorkflow(), terminateWorkflow() — Workflow control

    Synchronous setState()

    State updates are now synchronous with a new validateStateChange() validation hook:

    JavaScript
    export class MyAgent extends Agent {
      validateStateChange(oldState, newState) {
        // Return false to reject the change
        if (newState.count < 0) return false;
        // Return modified state to transform
        return { ...newState, lastUpdated: Date.now() };
      }
    }

    scheduleEvery() for recurring tasks

    The new scheduleEvery() method enables fixed-interval recurring tasks with built-in overlap prevention:

    JavaScript
    // Run every 5 minutes
    await this.scheduleEvery("syncData", 5 * 60 * 1000, { source: "api" });

    Callable system improvements

    • Client-side RPC timeout — Set timeouts on callable method invocations
    • StreamingResponse.error(message) — Graceful stream error signaling
    • getCallableMethods() — Introspection API for discovering callable methods
    • Connection close handling — Pending calls are automatically rejected on disconnect
    JavaScript
    await agent.call("method", [args], {
      timeout: 5000,
      stream: { onChunk, onDone, onError },
    });

    Email and routing enhancements

    Secure email reply routing — Email replies are now secured with HMAC-SHA256 signed headers, preventing unauthorized routing of emails to agent instances.

    Routing improvements:

    • basePath option to bypass default URL construction for custom routing
    • Server-sent identity — Agents send name and agent type on connect
    • New onIdentity and onIdentityChange callbacks on the client
    JavaScript
    const agent = useAgent({
      basePath: "user",
      onIdentity: (name, agentType) => console.log(`Connected to ${name}`),
    });

    Upgrade

    To update to the latest version:

    Terminal window
    npm i agents@latest

    For the complete Workflows API reference and patterns, see Run Workflows.

  1. Improve Global Upload Performance with R2 Local Uploads - Now in Open Beta

    R2

    Local Uploads is now available in open beta. Enable it on your R2 bucket to improve upload performance when clients upload data from a different region than your bucket. With Local Uploads enabled, object data is written to storage infrastructure near the client, then asynchronously replicated to your bucket. The object is immediately accessible and remains strongly consistent throughout. Refer to How R2 works for details on how data is written to your bucket.

    In our tests, we observed up to 75% reduction in Time to Last Byte (TTLB) for upload requests when Local Uploads is enabled.

    Local Uploads latency comparison showing p50 TTLB dropping from around 2 seconds to 500ms after enabling Local Uploads

    This feature is ideal when:

    • Your users are globally distributed
    • Upload performance and reliability is critical to your application
    • You want to optimize write performance without changing your bucket's primary location

    To enable Local Uploads on your bucket, find Local Uploads in your bucket settings in the Cloudflare Dashboard ↗, or run:

    Terminal window
    npx wrangler r2 bucket local-uploads enable <BUCKET_NAME>

    Enabling Local Uploads on a bucket is seamless: existing uploads will complete as expected and there’s no interruption to traffic. There is no additional cost to enable Local Uploads. Upload requests incur the standard Class A operation costs same as upload requests made without Local Uploads.

    For more information, refer to Local Uploads.

Search all changelog entries