Developer Platform Updates & Release Notes

Browser Run Session Recordings now include an Inspect panel, giving you more context to understand what happened during a browser session without having to reproduce it.

Inspecting logs, network requests, and the DOM in a Browser Run Session Recording

The Logs tab lets you search captured console output and filter messages by level. The Network tab shows each request's method, status, headers, payload, response, and timing waterfall, with the option to download the session's network activity as a HAR file.

You can also retrieve recorded network activity via API as raw JSON or a HAR file for use in your own debugging and analysis workflows.

The DOM tab provides an expandable view of the page structure at the end of the recording and lets you copy the reconstructed HTML. For sessions with multiple browser tabs, the Inspect panel updates to show data for the tab selected in the recording viewer.

To get started, enable recording when launching a browser session. After the session closes, open Browser Run > Runs in the Cloudflare dashboard ↗︎ and select the recording icon next to the session. …

You can now delete one or up to 100 Workflow instances and their stored state via the Workflows API or Wrangler 4.125.0 and later. Deleting an instance frees its stored state and stops its current execution. Storage billing is based on the average daily peak.

Delete one instance by calling delete() on its handle:

const instance = await env.MY_WORKFLOW.get("instance-abc");
await instance.delete();

If a Workflow deletes its own instance, execution stops during await instance.delete(). Code after the call does not run.

Delete multiple instances by calling deleteBatch() on the Workflow binding:

const result = await env.MY_WORKFLOW.deleteBatch([
	"instance-abc",
	"instance-def",
]);

console.log(result.deleted);
console.log(result.errors);

The batch result contains { id } entries for successful deletions and per-instance errors. IDs that do not exist are returned as errors. Duplicate IDs count toward the limit and are deleted once, with the result repeated for each input position. …

The rejectIfBusy option lets synchronous Workers AI inference requests fail when capacity is unavailable. Use it when your application should not wait in a capacity queue.

Pass the option as the third argument to the Workers AI binding:

const response = await env.AI.run(
	"@cf/google/gemma-4-26b-a4b-it",
	{
		messages: [{ role: "user", content: "Explain capacity queues." }],
	},
	{ rejectIfBusy: true },
);

const response = await env.AI.run(
	"@cf/google/gemma-4-26b-a4b-it",
	{
		messages: [{ role: "user", content: "Explain capacity queues." }],
	},
	{ rejectIfBusy: true },
);

For the native REST API, add the option to the request body:

curl --request POST \
  --url "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/ai/run/@cf/google/gemma-4-26b-a4b-it" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
    "messages": [{ "role": "user", "content": "Explain capacity queues." }],
    "options": { "rejectIfBusy": true }
  }'

Refer to Reject busy requests for OpenAI-compatible usage and error behavior.

Workers traces can now follow JavaScript RPC calls across Worker boundaries and into Durable Objects. Previously, a trace stopped at the caller's RPC boundary. The dashboard now shows the caller-side session and method calls alongside the callee invocation, nested calls, and callbacks into another Worker.

A session span covers the lifetime of a caller-side session and groups calls that reuse it. Individual call spans show each method invocation. Execution colors distinguish the Workers or Durable Object entrypoints involved, while arrows mark outgoing and incoming calls. Together, these details show where time was spent, which calls reused a session, and how returned stubs and callbacks fit into the request.

A Workers trace of a Worker-to-Worker RPC session, showing the session span, the caller's getCounter and increment call spans, and the callee's invocation and matching call spans

Enable tracing with one setting in your Wrangler configuration file:

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "observability": {
    "traces": {
      "enabled": true
    }
  }
}

[observability.traces]
enabled = true
``` …

R2 Data Catalog now provides table-level maintenance visibility and manual compaction queueing in the Cloudflare dashboard. These updates make it easier to understand when maintenance is eligible to run, inspect completed operations, and request maintenance without leaving the table view.

To view table maintenance details:

1. In the Cloudflare dashboard, go to R2 Data Catalog.
2. Select a catalog, then select the Explorer tab. The Explorer tab opens by default.
3. Select a table.
4. Select the Maintenance tab.

Maintenance tab for an R2 Data Catalog table showing schedules and recent runs

The updated dashboard includes:

• Maintenance tab — View compaction and snapshot expiration settings, schedules, and next eligibility alongside the table's Schema and Metadata tabs.
• Recent runs — Review a paginated audit log with job status, duration, and expandable details for manifest rewrites, compaction, and snapshot expiration. Expanded rows include operation metrics for each maintenance operation. …

You can now stream Workflow instance events via WorkflowInstance.subscribe() and the GET /subscribe API endpoint. Workers and HTTP clients can react to workflow and step events, including attempts, sleeps, waits, and rollbacks, without polling for instance status.

A subscription first streams the entire event history of the Workflow instance. After streaming past events, the subscription waits for new events as the instance runs. You can use filter to receive only specific event types or cursor to start a subscription at a specific event.

Use .subscribe() to update Workflow status in user-facing dashboards, send notifications when steps complete, or trigger follow-up work for specific events.

const instance = await env.MY_WORKFLOW.get("report-123");

using subscription = await instance.subscribe();

while (true) {
	const { value, done } = await subscription.next();
	if (done) {
		break;
	}

	console.log(value.type, value);
}

const instance = await env.MY_WORKFLOW.get("report-123");

using subscription = await instance.subscribe();

while (true) {
	const { value, done } = await subscription.next();
	if (done) {
		break;
	}

	console.log(value.type, value);
}
``` …

You can now grant access to specific Workers and choose from four roles to control the level of access you give teammates, agents, and CI/CD workflows.

Choose from four roles to control the level of access:

• Metadata Read-Only: View settings, metrics, logs, and traces without access to Worker code or the ability to make changes.
• Content Read-Only: Read Worker code, settings, and observability data without the ability to modify or deploy changes.
• Editor: Update and deploy a Worker without the ability to delete it.
• Admin: Everything in Editor, plus the ability to delete the Worker.

Permission policy form showing four roles scoped to an individual Worker

Worker-level access controls are available today for all customers. You can configure them in the Cloudflare dashboard, through the API, or with Terraform.

Roles designed for how teams build

…

AI Gateway can now require credentials for third-party provider requests. Credentials must accompany the request or be stored on the gateway. This setting prevents fallback to Unified Billing with Cloudflare-managed credentials.

Turn on Require provider credentials in your gateway settings. To use the API, set byok_only to true in the request body of a PUT request to update the gateway:

{
	"byok_only": true
}

To require provider credentials for one third-party request, set the cf-aig-no-wholesale header to true. This header cannot relax the gateway setting.

Requests without applicable credentials then return an HTTP 400 response. Workers AI requests remain allowed, and the setting does not change their configured billing mode.

For configuration details and request-level controls, refer to Prevent Unified Billing fallback for BYOK third-party providers.

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"],
		},
	});
}
``` …

@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);
});

About the Voice package

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.

Turn metrics

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. …

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.

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.

Email Routing rule created by Wrangler in dashboard

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.