Changelog

Browser Run now supports guardrails, which limit a browser session's HTTP and HTTPS requests to permitted hostnames.

Use guardrails when you need to:

• Keep a browser workflow limited to a specific website and its subdomains.
• Load only known third-party APIs, scripts, images, and fonts.
• Generate a screenshot or PDF from HTML you provide while preventing it from loading external content.

Set guardrails when starting a session with Puppeteer, Playwright, or the REST API. With a browser binding named MYBROWSER, pass guardrails when launching Puppeteer:

import puppeteer from "@cloudflare/puppeteer";

export async function startGuardedSession(env) {
	return puppeteer.launch(env.MYBROWSER, {
		guardrails: {
			allowedDomains: ["example.com", "*.example.com"],
		},
	});
}

import puppeteer from "@cloudflare/puppeteer";

interface Env {
	MYBROWSER: Fetcher;
}

export async function startGuardedSession(env: Env) {
	return puppeteer.launch(env.MYBROWSER, {
		guardrails: {
			allowedDomains: ["example.com", "*.example.com"],
		},
	});
}

In addition to session guardrails, Browser Run now supports a read-only mode for Live View. Live View lets you watch and interact with an active Browser Run session in real time. A read-only link lets someone watch without clicking, typing, navigating, or running JavaScript.

To create a read-only link, set { mode: "readonly" } when generating the Live View URL. This setting affects only the person using that link. The session's hostname restrictions remain unchanged.

Refer to the guardrails documentation for more information.

@cloudflare/voice v0.4.0 now lets you inspect where each Voice Agent turn spends time and how it ends.

client.addEventListener("turnmetrics", (turn) => {
	console.log(turn.outcome, turn.turnTotalMs);
});

The @cloudflare/voice package lets you build real-time voice agents with Cloudflare Agents. It streams microphone audio to an Agent over WebSocket, transcribes speech, runs your model through onTurn(), converts the response to speech, and streams audio back to the caller.

A turn moves through several stages:

User speaks -> speech-to-text -> model -> text-to-speech -> audio

Previously, the package's four aggregate metrics covered successful, non-empty speech turns. They did not show how failed, aborted, empty, or text turns ended.

Each speech or text turn now produces a typed VoiceTurnMetrics summary with:

• A turnId for correlating events from the same turn.
• A terminal outcome such as completed, no_output, output_limit, content_filtered, model_error, tts_error, or aborted.
• Timings for important stages, including speech-to-final-transcript, model-to-first-text, TTS-to-first-audio, and total turn duration.

These timings can overlap and are not additive. Timings for stages that a turn did not reach are omitted.

The latest summary is available through VoiceClient, useVoiceAgent(), and useVoiceInput(). Voice input includes only the speech and transcription timings it can measure.

If an agent produces no audio, you can now distinguish between the model returning no output, reaching an output limit, encountering content filtering, or failing.

For local debugging, you can forward server lifecycle events to the browser console:

import { Agent } from "agents";
import { withVoice } from "@cloudflare/voice";

const VoiceAgent = withVoice(Agent, {
	diagnostics: {
		browserConsole: true,
	},
});

import { Agent } from "agents";
import { withVoice } from "@cloudflare/voice";

const VoiceAgent = withVoice(Agent, {
	diagnostics: {
		browserConsole: true,
	},
});

The browser console combines server lifecycle events with local microphone, connection, and playback events, including model start, first model text, first audio, and playback start. Diagnostics are off by default, and their event names and fields can change.

VoiceClient also exposes typed events for speech-to-text failures, connection errors, and model outcomes. The SDK removes known content fields and does not read arbitrary provider responses, but custom error messages must not contain sensitive data.

Install the release with a compatible Agents SDK version:

npm i @cloudflare/voice@^0.4.0 agents@^0.22.0

yarn add @cloudflare/voice@^0.4.0 agents@^0.22.0

pnpm add @cloudflare/voice@^0.4.0 agents@^0.22.0

bun add @cloudflare/voice@^0.4.0 agents@^0.22.0

Refer to the Voice pipeline metrics and Voice Agent example ↗︎ to get started.

AI Search can index R2 objects without filename extensions when they include supported Content-Type metadata. This supports object keys that do not include file extensions while preserving file-type validation during indexing.

For supported file types and Content-Type requirements, refer to R2 data sources.

Workflows created on or after September 10, 2026, on the Workers Paid plan retain completed and errored instance state for seven days by default (previously 30 days). The seven day default helps to reduce storage costs by default. The maximum retention limit remains 30 days.

The retention period for existing Workflows is unchanged. The Workers Free plan retains its three-day default and limit.

To set the retention period for a Workflow instance, specify successRetention, errorRetention, or both:

const instance = await env.MY_WORKFLOW.create({
	retention: {
		successRetention: "2 days",
		errorRetention: "30 days",
	},
});

const instance = await env.MY_WORKFLOW.create({
	retention: {
		successRetention: "2 days",
		errorRetention: "30 days",
	},
});

You can also set the retention period per Workflow and per instance in the Cloudflare dashboard ↗︎.

For retention details, refer to Workflows pricing and the WorkflowInstanceCreateOptions API reference.

The OpenAI Agents API gives your application access to Codex through an OpenAI-managed API.

OpenAI manages sessions, orchestration, context compaction, and recovery while your application provides tools and uses Cloudflare Containers as the execution environment.

Cloudflare Containers can now provide self-hosted execution environments for the OpenAI Agents API. The open-source OpenAI Agents API Workers template ↗︎ provides a reference implementation. The Worker maintains a Cloudflare Container for each Codex session, keeps active work running, reconnects on follow-up input, and shuts down automatically when idle.

You can configure the reference implementation to meet your needs by extending the Container to provide controlled access to data and the network or by integrating it with other Cloudflare products.

To get started, refer to Run Codex on Cloudflare using the OpenAI Agents API.

AI Gateway custom costs now support cache-read and cache-write token rates. This lets custom cost metrics reflect negotiated cache pricing across providers.

Add per_cache_read_token or per_cache_write_token to the cf-aig-custom-cost header:

{
	"per_token_in": 0.000001,
	"per_token_out": 0.000002,
	"per_cache_read_token": 0.0000001,
	"per_cache_write_token": 0.0000005
}

Cache-token pricing activates when either cache rate is present. An omitted cache rate defaults to per_token_in. If both cache rates are omitted, AI Gateway preserves the existing input and output calculation.

Providers can include cache tokens within input tokens or report them separately. AI Gateway automatically accounts for these differences and prevents double-counting.

For more information, refer to Custom costs.

You can now configure observability for each container application when you deploy Containers with Wrangler. This lets you change logging for one container without changing the rest of your Worker.

If you omit containers[].observability, Wrangler uses the top-level observability setting for that container. If you set it, the container setting overrides the top-level setting.

Use target_instance_percentage or target_instance_count to apply an observability change to a subset of running instances.

{
	"observability": {
		"enabled": false,
	},
	"containers": [
		{
			"class_name": "MyContainer",
			"image": "./Dockerfile",
			"observability": {
				"enabled": true,
				"target_instance_percentage": 25,
			},
		},
	],
}

[observability]
enabled = false

[[containers]]
class_name = "MyContainer"
image = "./Dockerfile"

  [containers.observability]
  enabled = true
  target_instance_percentage = 25

For more information about Workers Logs, refer to Workers Logs.

Miniflare v5 prepares Cloudflare local development tooling for the upcoming cf CLI.

Miniflare powers local Workers development behind wrangler dev, the Cloudflare Vite plugin, and @cloudflare/vitest-plugin. Most projects should use those tools instead of depending on Miniflare directly, and Miniflare v5 will not require any action.

The most significant change is a new configuration shape which aligns Miniflare with cloudflare.config.ts, the programmatic Cloudflare configuration format now available for testing.

Other breaking changes include:

• Removed deprecated APIs and options, such as legacy alpha D1 bindings.
• Removed now-unused, internal APIs like wrappedBindings
• Removed Miniflare's built-in module discovery; higher-level tools like Wrangler and the Vite plugin should be providing the module graph.
• Moved local-only /cdn-cgi routes under /cdn-cgi/local.
• Replaced per-resource persistence options with shared persistence root options.

For a more comprehensive list, refer to Miniflare's changelog ↗︎

This work sets up a cleaner foundation for the next generation of local development tooling, including the new cf CLI.

Python workers now use Python 3.14 by default.

This change applies to all new Python workers using compatibility date 2026-09-08 or later.

Internally, this change updates the Pyodide runtime to 314.0.6.

You can now manage Email Routing rules that route emails to Workers from your Wrangler configuration. Add literal addresses or a catch-all address to the top-level addresses field:

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "name": "invoice-handler",
  "main": "src/index.ts",
  // Set this to today's date
  "compatibility_date": "2026-10-08",
  "addresses": [
    "invoice@yourdomain.com"
  ]
}

name = "invoice-handler"
main = "src/index.ts"
# Set this to today's date
compatibility_date = "2026-10-08"
addresses = ["invoice@yourdomain.com"]

When you run wrangler deploy, Wrangler creates rules for new addresses, updates existing rules managed by the Worker, and removes managed rules that are no longer in the configuration. Wrangler shows the planned changes and asks for confirmation before applying potentially destructive changes.

Email Routing rules created by Wrangler also appear in the dashboard but with an icon that identifies them.

Refer to Configure rules with Wrangler for more information.

Enterprise customers can now configure a zone's CDN Maximum Upload Size up to 5 GB directly from the Network page in the Cloudflare dashboard. This removes the need to contact your account team or Cloudflare Support when applications need to accept request bodies larger than 500 MB and no greater than 5 GB.

The default maximum upload size remains 500 MB. Upload limits above 5 GB still require additional configuration through your account team or Cloudflare Support.

Very large uploads may reach connection or read timeouts before reaching the configured size limit. Make sure clients and origins allow enough time to complete the transfer when increasing this setting.

Refer to Cache upload limits and Workers request body size limits for details.

R2 Data Access Logs are now generally available. Turn on logging for a bucket to record object read, write, list, multipart upload, and delete operations with response status codes below 400.

Data Access Logs cover requests made through the S3-compatible API, Cloudflare API and dashboard, Workers bindings, and public buckets through r2.dev or custom domains. Events are available in Workers Observability, where you can filter by bucket, operation, interface, actor, and other request fields.

Log delivery is asynchronous and best effort. Events may be delayed or omitted, so do not rely on Data Access Logs as a complete record of bucket activity.

Data Access Logs are available for non-jurisdictional buckets. For setup instructions, supported operations, and the event field reference, refer to R2 Data Access Logs.

You can now deploy Workers with larger dependencies, heavier frameworks, and more code without hitting size limits.

When you deploy a Worker, Wrangler bundles your code and compresses it before uploading. Previously, Cloudflare checked that compressed size and rejected deploys over 3 MB (Free) or 10 MB (Paid). That limit has been removed. Cloudflare now only checks the uncompressed size of your bundle, which is 64 MiB across all plans.

To check your Worker's bundle size before deploying:

wrangler deploy --outdir bundled/ --dry-run

Total Upload: 259.61 KiB / gzip: 47.23 KiB

The Total Upload value is your uncompressed bundle size. This is what counts against the 64 MiB limit. The gzip value is shown for reference but is no longer a limit.

For more information, refer to the Worker size limits documentation.

We've added more ways to manage and manipulate images with the Images binding. Here's what's new:

Render text into an image. Output a string of text into its own image or draw it over another image.

• Use the .text() method to rasterize text with the Images binding.
• Style content using the font, size, and color options.
• The draw array in cf.image now accepts a text key.

Manage hosted images without an API token.

• Metadata filtering: Pass filter.metadata to .list() to return images by custom metadata. Match a bounded range by setting two operators in one condition, for example, priority: { gte: 2, lte: 5 }.
• Server-side signing: Get a signed URL for a private image with .signedUrl().
• User uploads: Create a Direct Creator Upload link with .createDirectUpload() so that a client can upload an image to your storage.

Set headers in a single call.

• Pass a headers option to .response() to set headers without rebuilding the Response.
• Content-Type is always taken from the optimized image and can't be overridden by a specified header.
• Set Cache-Control with Workers Cache to cache your optimized image at the edge.

For more information, refer to Optimize with Workers, Draw overlays and watermarks, and Manage hosted images with Workers.

You can now create multiple Cloudflare Tunnel and Cloudflare Mesh routes from the Routes page in a single action, instead of submitting one route at a time.

When creating a route, you can now:

• Add multiple destinations at once — Enter a comma-separated list of CIDR ranges or hostnames to create several routes of the same type and connector together.
• Queue up multiple routes — Select Add another to stage additional routes, including different types or connectors, before creating them all in one action.
• Retry only what failed — If some routes in a batch fail (for example, an invalid CIDR), the routes that were created successfully are removed from the form automatically, so you only need to fix and resubmit the ones that failed.

The same Routes UI already supports bulk creation for Cloudflare WAN static routes, so you can add multiple WAN destinations or queue up several WAN routes before creating them together as well.

For setup steps, refer to Add routes.

Cursor self-hosted machines ↗︎ let you run Cursor Cloud Agents on Cloudflare. Each assigned session runs in its own isolated environment backed by Cloudflare Containers.

Cursor hosts the agent loop, inference, and planning. Cloudflare runs commands, file edits, repository operations, and other tools inside infrastructure that you control. The open-source Cursor Cloudflare Workers template ↗︎ deploys the Worker, Durable Object namespace, container application, R2 bucket binding, and cron trigger used by the integration.

To get started, refer to Run Cursor Cloud Agents on Cloudflare via self-hosted machines.

Python web frameworks following the Web Server Gateway Interface (WSGI) ↗︎ or Asynchronous Server Gateway Interface (ASGI) ↗︎ specification can now be used in Python Workers.

Based on the web framework you are using, you can use either wsgi or asgi from the workers module.

For WSGI frameworks like Django or Flask:

from workers import wsgi

from django.core.wsgi import get_wsgi_application

app = get_wsgi_application()
Default = wsgi.entrypoint(app)

The wsgi.entrypoint is equivalent to creating a WorkerEntrypoint class and using the wsgi.fetch method. If you want more control over the WorkerEntrypoint class, you can do so:

from workers import wsgi, WorkerEntrypoint

class Default(WorkerEntrypoint):
    async def fetch(self, request):
        return await wsgi.fetch(app, request, self.env)

For ASGI frameworks like FastAPI or Starlette:

from workers import asgi

from fastapi import FastAPI

app = FastAPI()
Default = asgi.entrypoint(app)

For more information about using individual web frameworks, refer to the packages documentation in Python Workers.

AI Gateway monthly usage invoices, issued at the beginning of each month for the previous month's usage, now show a single total cost for each model. These invoices no longer break out input and output token quantities and unit prices into separate line items. This change does not apply to invoices for AI Gateway credit purchases.

For example, an invoice that previously included these separate line items:

• anthropic claude-haiku-4-5-20251001 Input Tokens: 40,000 tokens at $0.000001 ($0.04)
• anthropic claude-haiku-4-5-20251001 Output Tokens: 24,000 tokens at $0.000005 ($0.12)

The updated invoice includes one line item: anthropic/claude-haiku-4.5: $0.16.

AI Gateway has also standardized model names across invoices and logs. Model variants that previously appeared with provider-specific version suffixes now use a consistent provider/model identifier.

For more information, refer to the Unified Billing documentation and AI Gateway logging documentation.

Beginning September 1, 2026, D1 queries on the Workers Free plan will fail when an account exceeds the daily row read or row write limits. Queries via the Workers Binding API and the REST API will return errors until the limit resets at midnight UTC. Stored data is not affected.

You will receive email alerts when the daily limit is reached. The following errors indicate that a limit has been exceeded:

Inspect database query activity before the enforcement date to identify queries that may exceed these limits. To reduce row reads, add indexes to tables and review queries that perform full table scans. If usage requires higher limits after optimization, upgrade to a Workers Paid plan.

For more information on D1 errors and how to handle them, refer to the D1 error list.

The /crawl endpoint now respects the use directive of the Content Signals ↗︎ standard, letting site owners express the maximum level at which their content may be used.

You can declare your intended level with the new contentUse parameter. Allowed values, from least to most permissive, are reference and full, and the default is full. If a target site's robots.txt sets a use level that is more restrictive than your declared contentUse, the crawl request is rejected with a 400 error.

curl -X POST 'https://api.cloudflare.com/client/v4/accounts/{account_id}/browser-rendering/crawl' \
  -H 'Authorization: Bearer <apiToken>' \
  -H 'Content-Type: application/json' \
  -d '{
    "url": "https://example.com",
    "contentUse": "reference",
    "formats": ["markdown"]
  }'

For more information, refer to Content Signals in the /crawl endpoint documentation.

AI Search now supports @cf/zai-org/glm-5.3-flash for text generation. The model has a 1,048,576-token context window and runs on Workers AI.

To configure the model for an AI Search instance, refer to Supported models.

@cf/zai-org/glm-5.3 is now available on Workers AI. It is Z.ai's flagship agentic coding model, built for long-running, tool-driven development workflows rather than single-turn chat.

GLM-5.3 uses the same base model as GLM-5.2, with every gain coming from post-training. The results are substantial on coding and agentic benchmarks: Z.ai reports ↗︎ a 50% improvement over GLM-5.2 on its in-house Z.ai Code Bench, and calls GLM-5.3 the most capable open-weights model for coding. On public benchmarks, it scores 88.2 on Terminal Bench 2.1 (up from 81.0), 28.3 on Terminal Bench 3.0 — open-source state of the art, up from 4.6 — 66.9 on DeepSWE (up from 46.2), 78.1 on FrontierSWE (up from 67.5), and 42.5 on SWE-Marathon (up from 19.4). It is also the top-scoring model in Z.ai's comparisons on CyberGym for vulnerability discovery (84.5) and on long-horizon automation tasks like AutomationBench (48.2).

The price-to-performance ratio is the compelling part. On Workers AI, GLM-5.3 costs the same as GLM-5.2 — $1.40 per M input tokens, $0.26 per M cached input tokens, and $4.40 per M output tokens — while roughly doubling GLM-5.2's scores on long-horizon benchmarks like SWE-Marathon, and improving them by more than 6x on Terminal Bench 3.0.

GLM-5.3 requires the Workers Paid plan or prepaid AI Gateway credits.

Use GLM-5.3 through the Workers AI binding (env.AI.run()), the REST API, the OpenAI-compatible endpoint, or AI Gateway.

For more information, refer to the GLM-5.3 model page and pricing.

Durable Objects can have up to ten distinct Dynamic Workers with in-flight requests, increased from four. This limit applies across all concurrent requests to the same Durable Object because they share an input/output (I/O) context. Other Workers can have up to four distinct Dynamic Workers with in-flight requests per request.

Multiple in-flight requests to the same Dynamic Worker count as one toward this limit.

For more information, refer to Dynamic Workers limits.

AI Search now supports six additional Workers AI models for text generation:

These models run on Workers AI, so they do not require an additional provider key. Select a model when creating or updating an AI Search instance in the dashboard or through the API.

For the full list of supported models, refer to Supported models.

You can now create app-scoped API tokens for Flagship. These tokens grant access only to the Flagship apps you select, instead of every app in the account.

When you create a custom token, open the resource dropdown (it defaults to Entire Account) and select Specified Flagship apps. Then choose the app and a Flagship App permission: Evaluate, Read, or Write. Account-wide Flagship Evaluate, Read, and Write permissions still exist when you need access to every app.

Use app-scoped tokens in trusted server-side environments, such as Wrangler, CI, or a backend service that should only touch one app.

To create a token, refer to API tokens or open the app-scoped token form ↗︎ in the dashboard.