Changelog

Meet @cf/cloudflare/clef and @cf/cloudflare/clef-flash, the first models trained by the Cloudflare Workers AI team, available on Workers AI today.

Clef is a decision model, in the same family as Typesafe's Jev ↗︎. Instead of generating text, it reads an input state and a set of typed questions, then returns a probability for every allowed answer. Your agent gets a structured decision it can act on immediately, for example: route the ticket, block the request, or escalate to a human. There is no free-form output to parse and no reasoning tokens to wait for.

Both models are hosted on Workers AI as Clef and Clef-flash. We are also open-sourcing the weights under the Apache 2.0 license on Hugging Face: Clef ↗︎ and Clef-flash ↗︎. Read the launch blog post ↗︎ for the full story, including how we trained them.

We are also launching a reinforcement learning (RL) fine-tuning service to help you tune Clef for your own workloads. Sign up to work with us as a design partner ↗︎.

Clef is designed to be fast so decisions come back in milliseconds. Across our 43 benchmark runs, we achieved speeds where Clef is 2.5x faster than Jev at the median, and Clef-flash 13x faster.

Hosting on Workers AI adds to that speed. Requests run on GPUs across Cloudflare's network, running close to your users, so the network round trip stays short. You can put Clef directly in the request path of your agent, then hand off to an LLM on Workers AI to take action.

Across 10 decision benchmarks, a Clef model scores highest on 7, ahead of Jev and other open decision models. A few highlights:

On Typesafe's own workflow evals, Clef beats Jev in 3 of 4 areas: invoice processing, customer service, and security incidents. The full results are on the Hugging Face model card ↗︎.

Clef follows the System One API, so you can switch an existing Jev integration to Clef by changing the endpoint and model. Ask up to 64 questions per request, in three types:

• noul: A yes/no question. Returns the probability that the answer is yes.
• choice: Pick one option from a set you define. Returns the chosen option, a probability per option, and a confidence value.
• score: Rate against an ordered rubric. Returns a probability-weighted score and a probability per level.

const response = await env.AI.run("@cf/cloudflare/clef", {
	model: "clef",
	state: "Checkout has been failing for every customer for the last hour.",
	questions: {
		urgent: {
			type: "noul",
			instructions: "Is this support request urgent?",
		},
		team: {
			type: "choice",
			instructions: "Which team should handle this request?",
			criteria: {
				billing: "Payments, invoices, and refunds",
				technical: "Outages, errors, and configuration",
				sales: "Plans and upgrades",
			},
		},
	},
});

// response.answers.urgent.noul -> probability the request is urgent
// response.answers.team.choice -> highest-probability team

const response = await env.AI.run("@cf/cloudflare/clef", {
	model: "clef",
	state: "Checkout has been failing for every customer for the last hour.",
	questions: {
		urgent: {
			type: "noul",
			instructions: "Is this support request urgent?",
		},
		team: {
			type: "choice",
			instructions: "Which team should handle this request?",
			criteria: {
				billing: "Payments, invoices, and refunds",
				technical: "Outages, errors, and configuration",
				sales: "Plans and upgrades",
			},
		},
	},
});

// response.answers.urgent.noul -> probability the request is urgent
// response.answers.team.choice -> highest-probability team

• Support triage: Decide whether a ticket is urgent and which team owns it, then route it without a human in the loop.
• Threat intelligence: Classify a website by category. Paired with Browser Run, Clef fetched, rendered, and classified a domain in 2.2 seconds, compared to 4.7 seconds for gpt-oss-120b in the same workflow.
• Trust and safety: Score user submissions against your own policy rubric and act on the probability.
• Agent guardrails: Let an agent check "should I take this action?" in tens of milliseconds before calling a tool.
• Visual classification: Pass up to four images alongside the state. Unlike text-only decision models, Clef has a vision encoder.

Use Clef through the Workers AI binding (env.AI.run()) or the REST API at /ai/run. You can also use AI Gateway with these endpoints.

For more information, refer to the Clef model page, the Clef-flash model page, and pricing.

@cloudflare/workers-oauth-provider ↗︎ is now v1, with a new split API. One Worker acts as the authorization server: it signs users in and issues tokens. Your MCP server acts as the resource server, and can run in another Worker. It validates each token with the authorization server over a Service Binding, without crossing the public Internet.

• It supports the MCP 2026-07-28 authorization specification ↗︎, including Client ID Metadata Documents ↗︎ and issuer identification ↗︎. It still works with older clients, including those using Dynamic Client Registration ↗︎.
• insufficientScope() gives you step-up authorization ↗︎ in one line.
• The authorization server and the resource server can run in different Workers ↗︎ with different WAF and rate limiting rules.
• One authorization server can issue tokens for many MCP servers ↗︎.
• A migration skill ↗︎ ships in the npm package so a coding agent can perform the upgrade.

import {
	OAuthAuthorizationServer,
	OAuthResourceServer,
	insufficientScope,
} from "@cloudflare/workers-oauth-provider";
import { WorkerEntrypoint } from "cloudflare:workers";

// auth-server Worker: signs users in and issues tokens for both MCP servers.
const authorizationServer = new OAuthAuthorizationServer({
	issuer: "https://auth.example.com",
	resources: [
		"https://calendar.example.com/mcp",
		"https://drive.example.com/mcp",
	],
	scopesSupported: ["calendar:read", "calendar:write", "offline_access"],
	clientIdMetadataDocumentEnabled: true,
});

export class AuthServer extends WorkerEntrypoint {
	fetch(request) {
		if (new URL(request.url).pathname === "/authorize") {
			return showConsent(request, this.env);
		}
		return authorizationServer.fetch(request, this.env, this.ctx);
	}

	validateToken(resource, token) {
		return authorizationServer.validateToken(resource, token, this.env);
	}
}

// calendar MCP Worker: checks tokens with AuthServer over a Service Binding.
export const calendar = new OAuthResourceServer({
	resourceMetadata: {
		resource: "https://calendar.example.com/mcp",
		authorization_servers: ["https://auth.example.com"],
	},
	requiredScopes: ["calendar:read"],
	validateToken: (env) => env.AUTH_SERVER.validateToken,
	handler: {
		fetch(request, env, ctx) {
			if (
				request.method === "POST" &&
				!ctx.auth.scope.includes("calendar:write")
			) {
				return insufficientScope(ctx.auth, ["calendar:read", "calendar:write"]);
			}
			return handleMcp(request, ctx.props);
		},
	},
});

import {
	OAuthAuthorizationServer,
	OAuthResourceServer,
	insufficientScope,
} from "@cloudflare/workers-oauth-provider";
import { WorkerEntrypoint } from "cloudflare:workers";

// auth-server Worker: signs users in and issues tokens for both MCP servers.
const authorizationServer = new OAuthAuthorizationServer<Env>({
	issuer: "https://auth.example.com",
	resources: [
		"https://calendar.example.com/mcp",
		"https://drive.example.com/mcp",
	],
	scopesSupported: ["calendar:read", "calendar:write", "offline_access"],
	clientIdMetadataDocumentEnabled: true,
});

export class AuthServer extends WorkerEntrypoint<Env> {
	fetch(request: Request) {
		if (new URL(request.url).pathname === "/authorize") {
			return showConsent(request, this.env);
		}
		return authorizationServer.fetch(request, this.env, this.ctx);
	}

	validateToken(resource: string, token: string) {
		return authorizationServer.validateToken(resource, token, this.env);
	}
}

// calendar MCP Worker: checks tokens with AuthServer over a Service Binding.
export const calendar = new OAuthResourceServer<Env, AuthProps>({
	resourceMetadata: {
		resource: "https://calendar.example.com/mcp",
		authorization_servers: ["https://auth.example.com"],
	},
	requiredScopes: ["calendar:read"],
	validateToken: (env) => env.AUTH_SERVER.validateToken,
	handler: {
		fetch(request, env, ctx) {
			if (
				request.method === "POST" &&
				!ctx.auth.scope.includes("calendar:write")
			) {
				return insufficientScope(ctx.auth, ["calendar:read", "calendar:write"]);
			}
			return handleMcp(request, ctx.props);
		},
	},
});

In the example, env.AUTH_SERVER.validateToken is that Service Binding call. The calendar Worker needs no KV namespace of its own.

{
	"name": "calendar-mcp",
	"main": "src/index.ts",
	// Set this to today's date
	"compatibility_date": "2026-10-01",
	"services": [
		{
			"binding": "AUTH_SERVER",
			"service": "auth-server",
			"entrypoint": "AuthServer",
		},
	],
}

name = "calendar-mcp"
main = "src/index.ts"
# Set this to today's date
compatibility_date = "2026-10-01"

[[services]]
binding = "AUTH_SERVER"
service = "auth-server"
entrypoint = "AuthServer"

OAuthResourceServer publishes the RFC 9728 ↗︎ protected resource metadata that MCP clients use to find your authorization server. It answers requests without a token with a 401 challenge that points to that metadata. It also rejects tokens issued for any other resource.

You can still use OAuthProvider as both the authorization server and the MCP server. For most 0.x deployments, the only required change is to add resourceMetadata: { resource }.

• Consent page ↗︎ and upstream sign-in ↗︎ helpers implement the MCP confused deputy protections.
• Sliding refresh token expiry ↗︎ with refreshTokenIdleTTL.
• Resumable KV cleanup ↗︎ with purgeExpiredData().
• An internal reason ↗︎ on every error passed to onError.

npm i @cloudflare/workers-oauth-provider@latest

yarn add @cloudflare/workers-oauth-provider@latest

pnpm add @cloudflare/workers-oauth-provider@latest

bun add @cloudflare/workers-oauth-provider@latest

Point your coding agent at node_modules/@cloudflare/workers-oauth-provider/skills/migrate-to-1.0/SKILL.md, or follow the migration guide ↗︎.

For both Workers in full, refer to the split Workers example ↗︎.

AI Search is now generally available. Usage-based billing begins on November 1, 2026, with included monthly ingestion, storage, semantic query, and full-text query usage. Cloudflare will send a reminder email the week before billing begins.

Refer to Limits & pricing for rates and included usage.

New AI Search instances use hybrid search by default. Hybrid search combines semantic vector retrieval with full-text matching. You can choose a different index method when you create an instance.

Refer to Hybrid search for details.

Workers AI embedding and reranking calls made by AI Search are included in AI Search pricing. These calls no longer appear on your Workers AI bill or in your AI Gateway logs. Generation, query rewriting, and external providers continue to use your account and gateway.

Refer to Limits & pricing for details.

AI Search supports the @cf/qwen/qwen3-vl-embedding-2b and google-ai-studio/gemini-embedding-2 multimodal embedding models. Search and chat requests can include images through the REST API and public endpoint.

Refer to Supported models for the full list of embedding models.

Optical character recognition (OCR) is available on every account for scanned PDFs. Plain-text or code files and PDFs with OCR enabled can be up to 10 MiB. PDFs without OCR and other supported formats remain limited to 4 MiB.

Refer to Data source for file limits and Limits & pricing for OCR pricing.

When you create an AI Search instance, the type field is optional. AI Search infers a website source from an HTTP or HTTPS URL, or an R2 source from an existing bucket name.

Refer to Data source for details.

Artifacts, Cloudflare's versioned file system that speaks Git, is now in open beta. Artifacts is built for scale, so you can create a repository per project, user, session, or task.

With Artifacts, you can:

• Deploy repositories to Workers — Connect an Artifacts repository through Workers Builds. Pushes to the production branch deploy the updated Worker, while other branches create or update Worker Previews.
• Programmatically manage repositories — Use an Artifacts binding from a Worker to create or fork repos, inspect files and commits, read files by path, and issue repo-scoped Git tokens.
• React to repository changes — Subscribe to events when a repository is created, imported, forked, deleted, pushed to, cloned, or fetched.
• Control where repository data is stored — Choose to store and process your data in the US or EU.
• Monitor repository usage — View total operations, pulls, pushes, errors, and error rates in the Cloudflare dashboard or via API for analytics.

Artifacts is available for customers on the Workers Paid plan. Cloudflare will begin billing for Artifacts on October 14, 2026.

We are hosting a competition to see who can build the next GitHub on Cloudflare using Workers and Artifacts.

Apply today ↗︎ — submissions are open until October 14, 2026.

The first-place team will receive $25,000 in Cloudflare credits. The top three teams will be flown to San Francisco to present what they built at Cloudflare Connect.

Get started with the Artifacts documentation.

Each Basin Pipelines stream can now ingest up to 1 GB/s, increased from 5 MB/s.

The higher per-stream limit gives high-volume application events, telemetry, and logs more room to grow without splitting ingestion across streams solely to stay within the previous limit.

For the full list of stream, sink, and pipeline limits, refer to Basin Pipelines limits.

Basin, formerly the Cloudflare Data Platform, is now generally available. Basin brings an end-to-end analytics platform to the Developer Platform, enabling you to collect data from a variety of sources, such as apps, infrastructure, devices, and other Cloudflare services, then query it to answer analytical questions.

Basin Pipelines, formerly Cloudflare Pipelines, ingests events from Workers, HTTP endpoints, and Cloudflare Logpush. It transforms events with SQL and ingests them into Iceberg tables or files on R2. With Basin Pipelines you can:

• Ingest application and device events through HTTP endpoints or Workers bindings.
• Filter and reshape Cloudflare logs before storing them as Iceberg tables, Parquet, or JSON.
• Catch schema mismatches with typed bindings and investigate dropped events in the dashboard.

Basin Catalog, formerly R2 Data Catalog, manages and automatically maintains Apache Iceberg tables ↗︎ to keep them fast, cost-efficient, and accessible to any compatible query engine. With Basin Catalog you can:

• Connect DuckDB, Spark, Snowflake, or PyIceberg to the same tables.
• Maintain growing tables with compaction, snapshot expiration, and manifest optimization.
• Share analytical data across tools and clouds without paying egress fees.

Basin SQL, formerly R2 SQL, is a serverless, distributed SQL engine for querying large Apache Iceberg tables in Basin Catalog without managing or scaling compute. With Basin SQL you can:

• Summarize and rank data with standard and approximate aggregates, grouping sets, and window functions.
• Combine and inspect datasets with joins, subqueries, common table expressions, set operations, schema discovery, and EXPLAIN.
• Transform strings, timestamps, JSON, and complex values with more than 190 functions.

To get started with creating an end-to-end data pipeline, run:

npx wrangler basin pipelines setup

yarn wrangler basin pipelines setup

pnpm wrangler basin pipelines setup

Or get started by referring to the Basin getting started guide.

Durable Objects remain active while handling a request from a connected client. This change applies when no client is connected, such as when an agent continues a submitted job after its client disconnects.

This behavior is the default for Workers with a compatibility date of 2026-10-01 or later. To use it with an earlier date, add the durable_object_io_tasks_prevent_eviction compatibility flag. To opt out, add the durable_object_io_tasks_do_not_prevent_eviction flag.

Pending service binding requests now keep Durable Objects running while they wait for a response. Pending calls to another Durable Object through remote procedure call (RPC) or fetch(), as well as this.ctx.container.monitor(), now also keep the Durable Object running.

Promises passed to this.ctx.waitUntil() and pending setTimeout() and setInterval() timers also receive this protection.

Previously, Cloudflare could shut down an idle Durable Object while one of these operations remained pending without a connected client. This could stop unfinished work.

This change helps you run long-running tasks such as agents. An agent can call tools through service bindings, coordinate with other Durable Objects, or wait for a container process without relying on the original client to remain connected.

Outbound fetch() requests to external services, TCP sockets, and outbound WebSockets already keep Durable Objects running.

Each pending operation prevents idle shutdown for up to 15 minutes. Starting another one later can extend the Durable Object's time in memory. The limit applies to each operation, not to the total time in memory.

Duration charges continue while an operation prevents eviction.

For more information, refer to Lifecycle of a Durable Object.

The coalesce() function returns the first argument that is not nil. Use it to provide a fallback in rule expressions:

http.request.uri.path eq coalesce(http.request.uri.args["expected_path"][0], "/")

For details, refer to the coalesce() function reference.

Cloudflare Rules expressions now support dynamic values on both sides of equality and ordering comparisons. You can compare request fields or function results with one another.

For example, compare the current request path with its original value:

http.request.uri.path ne raw.http.request.uri.path

For supported operators and examples, refer to Compare dynamic values.

This update provides immediate defense against a vulnerability affecting Citrix NetScaler ADC and Gateway appliances, deploying protection against improper input validation vectors.

Key Findings

• CVE-2026-88771: An improper input validation vulnerability affecting Citrix NetScaler ADC and Gateway allows an unauthenticated attacker to execute arbitrary commands.

Impact

We strongly recommend that administrators apply the latest versions to fully secure origin servers. Additionally, customers should review configurations against applicable preconditions and follow standard incident response processes if signs of compromise are identified.

Detailed Rule Changes

The Workers Web Crypto API now supports ML-KEM-768, ML-KEM-1024, ML-DSA-44, ML-DSA-65, and ML-DSA-87. ML-KEM establishes shared secrets, while ML-DSA signs and verifies data.

The opt-in API also adds key encapsulation and decapsulation methods, getPublicKey(), SubtleCrypto.supports(), and JSON Web Keys (JWKs) with the AKP key type.

Turn on the webcrypto_modern_algorithms compatibility flag to use these features:

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "compatibility_flags": [
    "webcrypto_modern_algorithms"
  ]
}

compatibility_flags = ["webcrypto_modern_algorithms"]

This example uses ML-KEM-768 to establish the same shared secret on both sides:

const keyPair = await crypto.subtle.generateKey("ML-KEM-768", false, [
	"encapsulateBits",
	"decapsulateBits",
]);

if (!("publicKey" in keyPair)) {
	throw new Error("Expected an ML-KEM key pair");
}

const { sharedKey, ciphertext } = await crypto.subtle.encapsulateBits(
	"ML-KEM-768",
	keyPair.publicKey,
);

const recoveredSharedKey = await crypto.subtle.decapsulateBits(
	"ML-KEM-768",
	keyPair.privateKey,
	ciphertext,
);

const keyPair = await crypto.subtle.generateKey("ML-KEM-768", false, [
	"encapsulateBits",
	"decapsulateBits",
]);

if (!("publicKey" in keyPair)) {
	throw new Error("Expected an ML-KEM key pair");
}

const { sharedKey, ciphertext } = await crypto.subtle.encapsulateBits(
	"ML-KEM-768",
	keyPair.publicKey,
);

const recoveredSharedKey = await crypto.subtle.decapsulateBits(
	"ML-KEM-768",
	keyPair.privateKey,
	ciphertext,
);

Workers implements a subset of the evolving Modern Algorithms in the Web Cryptography API ↗︎ draft. ML-KEM-512 and the draft's other algorithms are not supported. The API may change as the draft evolves.

For current algorithm and operation support, refer to Web Crypto supported algorithms.

Containers now support the durable_object scheduling policy in public beta. This policy lets a Durable Object select the image and instance size for a Container at runtime instead of using one centrally managed configuration for the application.

To use custom images, configure the policy and one or more named images in Wrangler:

{
	"containers": [
		{
			"class_name": "AgentComputer",
			"scheduling_policy": "durable_object",
			"images": {
				"base": {
					"dockerfile": "./container/Dockerfile",
				},
			},
		},
	],
}

[[containers]]
class_name = "AgentComputer"
scheduling_policy = "durable_object"

[containers.images.base]
dockerfile = "./container/Dockerfile"

Wrangler prepares each image and exposes its immutable reference through ctx.container.images. Supply that reference and an instance size when you start the Container:

this.ctx.container.start({
	image: this.ctx.container.images.base,
	enableInternet: false,
	instance: "standard-2",
});

this.ctx.container.start({
	image: this.ctx.container.images.base,
	enableInternet: false,
	instance: "standard-2",
});

The durable_object policy also supports the new cloudflare/debian-trixie Cloudflare-managed image, which includes Node.js 24.20.0 on Debian Trixie slim. Start it directly without configuring a named image.

Durable Object-managed Container instances have independent lifecycles and do not participate in application-wide image rollouts.

For configuration, runtime sizing, snapshots, and update behavior, refer to Scheduling Policies.

Containers now support snapshot APIs in public beta for saving and restoring point-in-time filesystem state. Create a snapshot first, then pass it back to start() to restore files after container sleep, restart, or handoff to another Durable Object.

Use snapshotContainer() through the Durable Object Container API to capture the full container filesystem. Create a snapshot from a running Container, store its handle, and pass that handle to start() when you restore it later:

import { DurableObject } from "cloudflare:workers";

export class MyDurableObject extends DurableObject {
	async saveSnapshot() {
		// Create a snapshot from the running Container.
		const containerSnapshot = await this.ctx.container.snapshotContainer({});

		await this.ctx.storage.put("containerSnapshot", containerSnapshot);
	}

	async restoreSnapshot() {
		// Restore the saved snapshot later.
		const containerSnapshot = await this.ctx.storage.get("containerSnapshot");

		if (!containerSnapshot) {
			return;
		}

		this.ctx.container.start({ containerSnapshot, enableInternet: false });
	}
}

import { DurableObject } from "cloudflare:workers";

export class MyDurableObject extends DurableObject {
	async saveSnapshot() {
		// Create a snapshot from the running Container.
		const containerSnapshot = await this.ctx.container.snapshotContainer({});

		await this.ctx.storage.put("containerSnapshot", containerSnapshot);
	}

	async restoreSnapshot() {
		// Restore the saved snapshot later.
		const containerSnapshot =
			await this.ctx.storage.get<ContainerSnapshot>("containerSnapshot");

		if (!containerSnapshot) {
			return;
		}

		this.ctx.container.start({ containerSnapshot, enableInternet: false });
	}
}

Snapshots are only supported for Container applications that use the durable_object scheduling policy. Snapshots are immutable, so create a new snapshot to persist filesystem changes made after a restore.

For more information, refer to Snapshots and the Durable Object Container API.

Sandbox SDK 1.0 is available. Your own Durable Object class now controls each sandbox container directly, through the Durable Object container API on this.ctx.container.

With 1.0, your class can:

• Choose the image and instance size each time it starts a sandbox. One class can run sandboxes on different images, and a deploy does not restart sandboxes that are running.
• Save the files of a sandbox as a snapshot, in public beta, and start the same sandbox or a new one from it.
• Decide when each sandbox stops, for example when a task finishes, when its user goes idle, or after it saves a snapshot.
• Run commands with streamed input and output, send them signals, and open terminals.
• Serve previews from ports in the sandbox, with your own hostnames and authentication.
• Handle outbound requests for each hostname in Worker code, so credentials and bindings stay in your Worker.
• Expose only the methods that you want callers to use.
• Run an agent in the same Durable Object, and give the model a tool that runs commands in the sandbox.

import { Files } from "@cloudflare/sandbox";
import { DurableObject } from "cloudflare:workers";

export class MySandbox extends DurableObject {
	container;
	files;

	constructor(ctx, env) {
		super(ctx, env);
		if (!ctx.container) {
			throw new Error("No container is configured");
		}
		this.container = ctx.container;
		this.files = new Files(ctx.container);
	}

	async run(script) {
		if (!this.container.running) {
			// Your code chooses the image, size, and network access.
			this.container.start({
				image: this.container.images.sandbox,
				instance: "lite",
				enableInternet: false,
			});
		}

		await this.files.writeFile("/tmp/task.sh", script);
		const proc = await this.container.exec(["sh", "/tmp/task.sh"]);
		return proc.output();
	}
}

import { Files } from "@cloudflare/sandbox";
import { DurableObject } from "cloudflare:workers";

export class MySandbox extends DurableObject<Env> {
	private readonly container: Container;
	private readonly files: Files;

	constructor(ctx: DurableObjectState, env: Env) {
		super(ctx, env);
		if (!ctx.container) {
			throw new Error("No container is configured");
		}
		this.container = ctx.container;
		this.files = new Files(ctx.container);
	}

	async run(script: string) {
		if (!this.container.running) {
			// Your code chooses the image, size, and network access.
			this.container.start({
				image: this.container.images.sandbox,
				instance: "lite",
				enableInternet: false,
			});
		}

		await this.files.writeFile("/tmp/task.sh", script);
		const proc = await this.container.exec(["sh", "/tmp/task.sh"]);
		return proc.output();
	}
}

Your class uses the container API directly, with the durable_object scheduling policy and container snapshots, both in public beta. @cloudflare/sandbox adds classes for work that the API does not include:

• Files streams files in and out of the running sandbox.
• S3Mount mounts an S3-compatible bucket, such as R2. Your Worker signs each storage request, so the credentials stay out of the sandbox.
• DirectoryBackup saves a directory to R2 and restores it into any sandbox, including one on a newer image.

Your 0.x applications keep running, and @cloudflare/sandbox 0.x stays on npm. Sandbox SDK 0.x receives bug and security fixes until 2026-12-31, and its documentation stays at Sandbox SDK 0.x.

When you are ready, Migrate from Sandbox SDK 0.x shows the 1.0 code for each 0.x feature, including preview URLs, tunnels, background processes, terminals, backups, and the code interpreter. The guide keeps the preview URLs and named tunnels that your 0.x application created working. You can move every sandbox in one deploy, or run a 1.0 class next to your 0.x class and move sandboxes one at a time. The deploy that moves an existing class to the new policy is one-way, so the guide shows how to rehearse it first.

The Sandboxes documentation also covers Dynamic Workers, for untrusted code in JavaScript, Python, or WebAssembly.

A new Beta release for the Windows Cloudflare One Client is now available on the beta releases downloads page.

This beta release includes the following changes and improvements:

• Fixed an issue that could briefly block traffic to split tunnel excluded resources while the client was connecting or reconnecting.
• Improved reauthentication reliability and fixed an issue where a reauthentication could force a new registration.
• Improved client reaction to the current network lowering its MTU.
• Added support for routing non-RFC 1918 local IPv4 networks through the WARP tunnel when unrestricted LAN inclusion is enabled by policy or MDM.
• Improved DNS reliability on networks with lower MTUs by clamping the TCP maximum segment size (MSS) for DNS-over-HTTPS connections sent through the tunnel.
• Improved API reliability by retrying requests dropped when reusing pooled connections.
• The client no longer requires the Windows WLAN AutoConfig service to be running.
• Implemented a service recovery mechanism backed by Windows scheduler task to start WARP service on system unlock if not already started.
• Fixed slow captive portal checks causing the client service to become unresponsive or restart while connecting.
• Fixed a race when switching tunnel protocols during key rotation that could prevent WireGuard from connecting.
• Fixed the client continuing to report 'No network' after a successful manual disconnect.
• Fixed Digital Experience Monitoring (DEX) HTTP tests failing TLS validation on Windows.
• Fixed the client UI crashing at startup when it could not write to the Windows registry.
• Fixed latency spikes and traffic interruptions during TPM-backed API authentication when hardware-backed registration is enabled.
• Fixed trailing whitespace in BIOS serial numbers causing serial-number and client-certificate device posture checks to fail.
• Fixed a client UI crash that could occur when the daemon connection was reset during an IPC request.
• Fixed a startup crash when date formatting data for the system locale had not yet loaded.

Known issues

• None

For Zero Trust documentation, see: https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/ For Consumer documentation, see: https://developers.cloudflare.com/warp-client/

AI Gateway now supports Machine Payments in beta. With Machine Payments, clients can use the x402 protocol to pay for eligible inference requests directly from a stablecoin wallet instead of maintaining a prepaid credit balance.

Machine Payments is available for the /ai/run endpoint with select open models. To request x402 payment, authenticate with a Cloudflare API token and include the Cloudflare-specific Payment-Method: x402 header:

curl -iX POST "https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/ai/run" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Payment-Method: x402" \
  --header "Content-Type: application/json" \
  --data '{
    "model": "z-ai/glm-4.7-flash",
    "input": {
      "messages": [
        {
          "role": "user",
          "content": "What is Cloudflare?"
        }
      ]
    }
  }'

An x402-compatible client handles the payment challenge, signs an authorization from the client's wallet, and retries the request. Machine Payments currently requires customers to be based in the United States and have a credit card on file.

For prerequisites, eligible models, and transaction details, refer to Machine Payments (x402).

Isolation policies support role-based access control (RBAC). Because isolation policies are Gateway HTTP policies with the Isolate action, Gateway's account-level and resource-scoped roles apply to them directly.

Use the Zero Trust HTTP Policies Admin account-level role to grant access to all HTTP policies in the account. You can also assign a resource-scoped role to let a team member manage a specific isolation policy without exposing other Gateway resources.

Policy settings such as copy/paste, file download/upload, keyboard, and printing are part of the policy object and follow the same permissions.

For setup instructions, refer to Granular permissions for Gateway.

Cloudflare Logpush is now available on Free, Pro, Business, and Enterprise plans with usage-based pricing. Free, Pro, and Business customers can enable Logpush through self-service. Enterprise customers continue to work with their account team. Logpush Transformers are also now generally available.

Each account receives included monthly usage before charges apply:

• Internal exports: 25 GB per month, then $0.03 per additional GB.
• External exports: 25 GB per month, then $0.10 per additional GB.
• Transformations: 1 GB per month, then $0.04 per additional GB.

R2 and Pipelines use the internal destination rate. All other destinations use the external destination rate.

Existing Enterprise contracts retain their current Logpush pricing through renewal. Workers Logpush for Workers Trace Events retains request-based pricing, and OpenTelemetry destinations retain event-based Workers Observability pricing.

For complete rates, measurement details, and billing examples, refer to Logpush pricing.

Transformers are now generally available for supported Logpush datasets on Free, Pro, Business, and Enterprise plans. Use SQL to filter records, reshape fields, redact sensitive values, compute new fields, or add metadata before Logpush delivers each batch.

Create and preview Transformers in Transformer Studio or through the Cloudflare API, then attach them to eligible account-scoped or zone-scoped Logpush jobs that use NDJSON output. Cloudflare validates each query against the dataset schema before saving it.

Each account includes 1 GB of transformation input per month. Additional input costs $0.04 per GB. For setup instructions, supported SQL, limits, and examples, refer to Transformers. For billing details, refer to Logpush pricing.

Monetization Gateway is now available in closed beta. Sellers can use it to charge agents for access to APIs, Model Context Protocol (MCP) tools, sites, and datasets.

Sellers (domain owners) define which requests require payment, the cost, and where the payment should be sent. Buyers receive the payment instructions, sign an authorization, and receive the resource after the payment has been settled. The Monetization Gateway uses the x402 protocol to handle payment authorization within the HTTP request flow.

To learn more, request access in the Cloudflare dashboard ↗︎, review the Monetization Gateway documentation, or read the blog ↗︎.

This release introduces new detections to enhance protection against a specific GitLab path traversal vulnerability, alongside advanced generic rules targeting HTTP request smuggling, directory traversal, and command injection attempts.

Key Findings

• CVE-2026-85706: A path traversal vulnerability affecting GitLab.

A new Beta release for the Windows Cloudflare One Client is now available on the beta releases downloads page.

This beta release includes the following changes and improvements:

• Fixed an issue that could briefly block traffic to split tunnel excluded resources while the client was connecting or reconnecting.
• Improved reauthentication reliability and fixed an issue where a reauthentication could force a new registration.
• Improved client reaction to the current network lowering its MTU.
• Added support for routing non-RFC 1918 local IPv4 networks through the WARP tunnel when unrestricted LAN inclusion is enabled by policy or MDM.
• Improved DNS reliability on networks with lower MTUs by clamping the TCP maximum segment size (MSS) for DNS-over-HTTPS connections sent through the tunnel.
• Improved API reliability by retrying requests dropped when reusing pooled connections.
• The client no longer requires the Windows WLAN AutoConfig service to be running.
• Implemented a service recovery mechanism backed by Windows scheduler task to start WARP service on system unlock if not already started.
• Fixed slow captive portal checks causing the client service to become unresponsive or restart while connecting.
• Fixed a race when switching tunnel protocols during key rotation that could prevent WireGuard from connecting.
• Fixed the client continuing to report 'No network' after a successful manual disconnect.
• Fixed Digital Experience Monitoring (DEX) HTTP tests failing TLS validation on Windows.
• Fixed the client UI crashing at startup when it could not write to the Windows registry.
• Fixed latency spikes and traffic interruptions during TPM-backed API authentication when hardware-backed registration is enabled.
• Fixed trailing whitespace in BIOS serial numbers causing serial-number and client-certificate device posture checks to fail.
• Fixed a client UI crash that could occur when the daemon connection was reset during an IPC request.
• Fixed a startup crash when date formatting data for the system locale had not yet loaded.

Known issues

• None

A new Beta release for the macOS Cloudflare One Client is now available on the beta releases downloads page.

This beta release includes the following changes and improvements:

• Fixed an issue that could briefly block traffic to split tunnel excluded resources while the client was connecting or reconnecting.
• Improved reauthentication reliability and fixed an issue where a reauthentication could force a new registration.
• Improved client reaction to the current network lowering its MTU.
• Added support for routing non-RFC 1918 local IPv4 networks through the WARP tunnel when unrestricted LAN inclusion is enabled by policy or MDM.
• Improved DNS reliability on networks with lower MTUs by clamping the TCP maximum segment size (MSS) for DNS-over-HTTPS connections sent through the tunnel.
• Improved API reliability by retrying requests dropped when reusing pooled connections.
• Fixed Extra Logging failing to capture packets across all interfaces.
• Fixed an issue that could prevent remote diagnostics from completing.
• Fixed DNS connectivity checks failing on IPv6-only networks.
• Fixed the client service exiting when its route-monitoring socket was closed after sleep or wake.
• Fixed DNS enforcement checks making the client service unresponsive on systems with large routing tables.
• Fixed slow captive portal checks causing the client service to become unresponsive or restart while connecting.
• Fixed a race when switching tunnel protocols during key rotation that could prevent WireGuard from connecting.
• Fixed the client continuing to report 'No network' after a successful manual disconnect.
• Fixed a client UI crash that could occur when the daemon connection was reset during an IPC request.
• Fixed a startup crash when date formatting data for the system locale had not yet loaded.

Known issues

• None

AI Gateway User Insights now gives you more context about the traffic flowing through your gateway. It shows what users and agents are doing with AI, and where a selected model may be more capable than a task requires.

On the analysis side, User Insights groups conversations by task, tracks conversation turns, and helps you compare model fit with cost and latency.

The Potential Savings view highlights requests that may work with faster or less expensive models without compromising output quality. These are the same signals that Cloudflare's Auto Router uses to select a model based on task and cost.

These new insights are available to all AI Gateway customers at no additional cost. For more information, refer to User Insights.