Changelog

Run the Codex agent loop in a Cloudflare Durable Object with this experimental Agents SDK example ↗︎. Conversations, files, and completed model and tool results persist across restarts, allowing the agent to recover after interruptions.

The example adapts Codex’s Rust turn-processing code ↗︎ to WebAssembly and uses Agents SDK capabilities for storage and recovery.

The harness combines Agents SDK capabilities for durable execution:

• Tasks journals model calls and tool execution. Completed steps reuse their recorded results after a restart. Interrupted steps can run again.
• Sessions stores conversation history and compacts the model context.
• Streams stores ordered events for replay after reconnecting.
• Workspace provides tools to read and write persistent files.

For example, use OpenAI's GPT-6.1 Sol through AI Gateway. Configure the model with createAI and install the capabilities on a Durable Object:

import { DurableObject } from "cloudflare:workers";
import { Workspace } from "@cloudflare/computer";
import { Lifecycle } from "agents/lifecycle";
import { createAI } from "agents/models/ai-sdk";
import { Sessions } from "agents/sessions";
import { Streams } from "agents/streams";
import { Tasks } from "agents/tasks";
import { CodexHarness } from "./codex-harness";

export class Coder extends DurableObject {
	tasks = new Tasks();
	streams = new Streams();
	sessions = new Sessions();
	workspace = new Workspace({ storage: this.ctx.storage });

	codex = new CodexHarness({
		tasks: this.tasks,
		streams: this.streams,
		sessions: this.sessions,
		workspace: this.workspace,
		model: createAI({ binding: this.env.AI, id: "default" })(
			"openai/gpt-6.1-sol",
		),
	});

	lifecycle = Lifecycle.install(this)
		.use(this.tasks)
		.use(this.streams)
		.use(this.sessions)
		.use(this.codex);
}

import { DurableObject } from "cloudflare:workers";
import { Workspace } from "@cloudflare/computer";
import { Lifecycle } from "agents/lifecycle";
import { createAI } from "agents/models/ai-sdk";
import { Sessions } from "agents/sessions";
import { Streams } from "agents/streams";
import { Tasks } from "agents/tasks";
import { CodexHarness } from "./codex-harness";

export class Coder extends DurableObject<Env> {
	tasks = new Tasks();
	streams = new Streams();
	sessions = new Sessions();
	workspace = new Workspace({ storage: this.ctx.storage });

	codex = new CodexHarness({
		tasks: this.tasks,
		streams: this.streams,
		sessions: this.sessions,
		workspace: this.workspace,
		model: createAI({ binding: this.env.AI, id: "default" })("openai/gpt-6.1-sol"),
	});

	lifecycle = Lifecycle.install(this)
		.use(this.tasks)
		.use(this.streams)
		.use(this.sessions)
		.use(this.codex);
}

To use this model, configure the default gateway with Unified Billing or a stored OpenAI API key.

For setup, models, tools, and recovery behavior, refer to the Codex harness guide.

You can now run Exo agents on Cloudflare, with Durable Objects coordinating conversations and Cloudflare Sandboxes running Linux tools. Define an agent in Markdown, then use Exo's CLI or HTTP API to run it.

After deploying the Cloudflare adapter and configuring your Exo provider ↗︎, add an openai vault credential and save this definition as agent.md:

---
harness: basic
model:
  name: gpt-6.1-sol
  credential: openai
---

Help the user with their task.

Run the agent against your Cloudflare deployment with Exo's CLI:

exo --provider cloudflare agent run --agent-file agent.md

The Exo project maintains the Cloudflare adapter independently of Cloudflare. It does not require the Agents SDK.

Follow the Exo guide for architecture, recovery behavior, and upstream setup instructions.

You can now run Nanocode ↗︎ coding agents in Cloudflare Durable Objects, with persistent session history and recovery after interruptions.

Nanocode's Rust engine runs as WebAssembly and implements Codex and Claude Code prompt and tool conventions. Its Cloudflare host saves turn progress and tool results in SQLite and uses alarms to resume pending work. The Nanocode project maintains the host independently of Cloudflare; it does not require the Agents SDK.

Start with the reference Worker ↗︎ and follow Nanocode on Workers for setup, models, and recovery limits.

Cloudflare has improved how it chooses where to start a Durable Object after the object has been inactive.

Reactivated Durable Objects now start on the machine that last ran them whenever possible, so their data doesn't need to be loaded again.

This can make cold starts less frequent for SQLite-backed Durable Objects that are reactivated soon after going idle. Actual results depend on your workload and traffic patterns.

The change is live in all regions. No action is needed by customers to see benefits from this change.

To learn more about how Durable Objects are placed, refer to Data location.

Markdown for Agents is generally available, with new tools to monitor conversions and investigate partial or failed output.

In the Cloudflare dashboard, select your zone and go to Agent Readiness > Markdown for Agents:

• Analytics shows conversion outcomes, estimated token reduction, top converted pages, top user agents, failure reasons, content limits, and pages with partial or failed conversions.
• Logs provides sampled conversion events with outcome, failure reason, and content-limit filters.
• Playground requests Markdown for a page on your zone and compares it with HTML. Inspect the Markdown, preview, response headers, and estimated token reduction.

The GraphQL Analytics API exposes the same analytics through markdownForAgentsAdaptiveGroups at zone and account scope. Query conversion totals, outcomes, estimated token savings, and page diagnostics over the last seven days. Counts are sample-weighted estimates. Token savings use byte-based estimates from full conversions, not tokenizer counts.

Cloudflare Traces includes a markdown_conversion span for sampled streaming conversions. Inspect conversion outcomes, input and output bytes, converter CPU time, and content-limit flags alongside the rest of the request timeline.

For details and a GraphQL query example, refer to the Markdown for Agents documentation.

The Cloudflare Radar Bots Directory ↗︎ now uses BotBase, Cloudflare's catalog of the bots and agents it tracks, and has a new design matching the Radar homepage.

Each bot page has a new Identity section showing the bot's access level, content use, Web Bot Auth verification, and user agents. Bot operators are also searchable from the Radar site search.

The List bots and Get bot details endpoints now describe each bot with:

• categories: a bot can now have more than one category. Categories follow BotBase's groups, which add COMMERCE, and some older categories are now part of broader groups.
• accessLevel: DIRECT if the bot reaches websites under its own identity, or INTERMEDIARY if it acts on behalf of another agent or a person.
• contentUse: full if the content it fetches is kept and reused (for example, for model training or a search index), reference if it is cited or linked back to the source, or immediate if it is used once to answer a user's request.
• documentationUrl and operatorWebsiteUrl (bot details only).

category and operatorUrl are deprecated in favor of categories and documentationUrl.

Visit the Bots Directory ↗︎ on Cloudflare Radar.

AI Gateway now shows usage activity for your stored provider keys. Use this information to review credentials for rotation or removal.

In Provider Keys, keys are grouped by provider with masked previews, aliases, and last-used and last-updated dates. The Key security section highlights keys with recorded activity older than 90 days. You can review these keys and delete them after checking their dependencies.

Usage tracking starts November 2026.

For details on storing, rotating, and removing provider keys, refer to Bring your own keys.

Cloudflare Access supports passkeys as a login method for protected applications and the App Launcher. Users can sign in with a passkey saved on their device, security key, or password manager instead of entering a one-time PIN or configuring an identity provider.

Users verify their identity with an existing login method once before enrolling a passkey. Administrators choose which applications accept passkeys and can remove a user's registered passkeys. Access policies still determine whether a user can access an application.

For setup and enrollment instructions, refer to Passkeys.

Cloudflare One now includes fast flux detection as a predefined risk behavior for user and entity behavior analytics (UEBA). When enabled, detections contribute to a user's risk score.

Fast flux is a DNS technique that rapidly changes the IP addresses returned for a domain. Threat actors can use it to make malicious infrastructure harder to track and take down. Detecting it can help security teams identify potentially risky activity and investigate it sooner.

To turn on fast flux detection, go to Risk score > Risk behaviors in the Cloudflare Zero Trust dashboard.

Fast flux detection is available on Enterprise plans.

For more information, refer to User risk score.

User API tokens now use a redesigned dashboard experience that more closely matches Account API tokens, making it easier to create and review user-owned credentials while preserving their user-scoped behavior.

• A more consistent creation flow: User API tokens now follow the same modern dashboard pattern as Account API tokens, including a clearer create and review experience.
• Improved policy editing: Policies are now easier to read and manage, with inline controls to add, edit, and remove policy blocks before creating the token.
• Clearer restrictions during setup: Expiration presets and client IP address filtering are built directly into the creation flow so you can review token restrictions in one place.

These tokens still act on behalf of the creating user, even though the dashboard experience is now more consistent with Account API tokens. For more information, refer to Create API token, Create tokens via API, and Account API tokens.

The runtime now retries fetch() and RPC calls to a Durable Object when they fail with a retryable error before reaching it. This applies whether the caller is a Worker or another Durable Object. Short disruptions, such as brief network interruptions, no longer need a retry loop in your code.

By default, the runtime retries a call up to four times, and starts no retry more than 10 seconds after the initial call starts. It does not retry errors thrown by your Durable Object code, or errors with .overloaded set to true.

If the connection drops and the runtime cannot tell whether the Durable Object received the call, it still retries, but the Durable Object rejects the retry if the first attempt arrived. A method never runs twice because of a retry, unless you mark it with retryable() from cloudflare:durable-objects:

import { DurableObject } from "cloudflare:workers";
import { retryable } from "cloudflare:durable-objects";

export class Cart extends DurableObject {
	static {
		retryable(this.prototype.setQuantity);
	}
	// Idempotent: a second run sets the same quantity.
	async setQuantity(itemId, quantity) {
		await this.ctx.storage.put(itemId, quantity);
	}

	// Not retryable: a second run would add another item.
	async addOne(itemId) {
		const quantity = (await this.ctx.storage.get(itemId)) ?? 0;
		await this.ctx.storage.put(itemId, quantity + 1);
	}
}

import { DurableObject } from "cloudflare:workers";
import { retryable } from "cloudflare:durable-objects";

export class Cart extends DurableObject {
	static {
		retryable(this.prototype.setQuantity);
	}
	// Idempotent: a second run sets the same quantity.
	async setQuantity(itemId: string, quantity: number): Promise<void> {
		await this.ctx.storage.put(itemId, quantity);
	}

	// Not retryable: a second run would add another item.
	async addOne(itemId: string): Promise<void> {
		const quantity = (await this.ctx.storage.get<number>(itemId)) ?? 0;
		await this.ctx.storage.put(itemId, quantity + 1);
	}
}

To change the limits for one stub, pass a retry option to get() or getByName(). maxRetries accepts 0 to 10 retries, and timeoutMs accepts 500 to 60,000 milliseconds:

const stub = env.CART.getByName("user-123", {
	retry: { maxRetries: 1, timeoutMs: 2000 },
});

const stub = env.CART.getByName("user-123", {
	retry: { maxRetries: 1, timeoutMs: 2000 },
});

If you already retry Durable Object calls in your own code, each of your attempts now includes the runtime's retries. Lower your own attempt count, or set maxRetries: 0 on stubs where your code handles retries.

To use retryable() and the retry option, update to Wrangler 4.158.0 or later.

For more information, refer to Automatic retries.

Email security now lets you set an expiration date when creating an allow or block policy. This helps you apply temporary policy changes without removing them manually.

After the selected date passes, the policy expires and no longer applies.

This feature is available to all Email security customers, regardless of plan.

We are refreshing the Workers AI model catalog to make room for new releases and updated models. Update your apps to remove references to the models listed below before November 20, 2026. We originally stated these models would be deprecated on November 15, 2026, and have moved the deprecation date to November 20, 2026.

Starting November 20, 2026, these models will stop returning responses. Requests to them will fail with an HTTP 410 Gone error and error code 5028.

We recommend moving to newer models for the best token efficiency and throughput. For pricing, refer to the Workers AI pricing page.

• For frontier model needs: @cf/deepseek-ai/deepseek-v4.1-flash-1017 and @cf/zai-org/glm-5.3.
• For smaller model needs: @cf/google/gemma-4-26b-a4b-it and @cf/qwen/qwen3.8-27b.

• @cf/deepseek-ai/deepseek-r1-distill-qwen-32b
• @cf/nvidia/nemotron-3-120b-a12b
• @cf/deepseek-ai/deepseek-v4-pro-0813
• @cf/deepseek-ai/deepseek-v4-flash-0731
• @cf/qwen/qwq-32b
• @cf/qwen/qwen3-30b-a3b-fp8
• @cf/moonshotai/kimi-k2.6
• @cf/moonshotai/kimi-k2.7-code
• @cf/zai-org/glm-5.2
• @cf/zai-org/glm-5.3-flash
• @cf/meta-llama/llama-2-7b-chat-hf-lora
• @cf/google/gemma-2b-it-lora
• @cf/google/gemma-7b-it-lora
• @cf/meta/llama-3.1-8b-instruct-fp8
• @cf/meta/llama-3.2-1b-instruct
• @cf/meta/llama-3.2-3b-instruct

Each deprecated model is followed by its suggested replacement.

• @cf/myshell-ai/melotts → @cf/deepgram/aura-2-en
• @cf/stabilityai/stable-diffusion-xl-base-1.0 → @cf/black-forest-labs/flux-2-klein-9b
• @cf/runwayml/stable-diffusion-v1-5-inpainting → @cf/black-forest-labs/flux-2-klein-9b
• @cf/bytedance/stable-diffusion-xl-lightning → @cf/black-forest-labs/flux-2-klein-9b
• @cf/lykon/dreamshaper-8-lcm → @cf/black-forest-labs/flux-2-klein-9b
• @cf/openai/whisper-tiny-en → @cf/deepgram/nova-3
• @cf/llava-hf/llava-1.5-7b-hf → @cf/moondream/moondream3.1-9B-A2B
• @cf/google/embeddinggemma-300m → @cf/google/embeddinggemma-2 (available soon)

For the full list of available models, refer to the Workers AI model catalog.

AI Gateway now supports model aliases. A model alias is a pool of models that your application calls by one name, such as custom/support-fast. AI Gateway tries the models in the order you set and falls back to the next one if a request fails, or uses smart routing to choose a model for each request.

Because your application only references the alias, you can swap models or change the routing algorithm on your gateway without redeploying. Create and manage aliases on your gateway's Routing page, alongside dynamic routes.

To call an alias through the REST API, use its name as the model. For example, send this body to /accounts/{account_id}/ai/run:

{
	"model": "custom/support-fast",
	"input": {
		"messages": [{ "role": "user", "content": "Reply with a short greeting." }]
	}
}

Include the cf-aig-gateway-id header to select the gateway where you created the alias. Aliases are scoped to individual gateways.

For setup instructions and routing options, refer to Model aliases.

The Configure AI bot policies setting is now named AI Crawler and Agent access policies.

Personal agents act on a person's behalf, fetching information or browsing in response to a request. The updated policies let you set actions for the top Personal Agents individually. This gives you control over agent access while allowing visitors to use agents to find answers or compare products using your site's content.

Customize how Personal Agents access your site via Security > Settings > AI Crawler and Agent access policies.

For more information, check out our blog ↗︎ or refer to our documentation for AI Crawler and Agent access policies.

Isolation policies now support a third keyboard option in beta: Allow read-only actions. Previously, the keyboard setting was binary — allow all input or block everything. With Allow read-only actions, you can block data entry while preserving the built-in browser actions your users depend on.

In Allow read-only actions mode, users can still find in page, select all, copy, print, and zoom. All other keyboard input is blocked from reaching the isolated page. Copy and print remain subject to their own policy settings, so the controls compose instead of overriding each other. For example, setting the keyboard to Allow read-only actions and copy to Do not allow lets users search and zoom but prevents them from copying content.

To use this feature, set Keyboard to Allow read-only actions in your isolation policy settings. Via the API, set keyboard to enable_read_only_actions in the biso_admin_controls object with version set to v2.

For more information, refer to Keyboard.

Cloudflare Network Firewall has a new managed rule to help mitigate the Linux IPv4 TCP use-after-free vulnerability (CVE-2026-98432 ↗︎):

• Rule name: Block CVE-2026-98432 traffic
• Rule ID: 6a4df2bf984946a88c74b07349557e83

The rule is disabled by default. To use it:

1. Go to Networking > Firewall Policies > Managed Rulesets.
2. Enable the rule with action Log first.
3. Review traffic that matches the rule.
4. If the matching traffic is not expected for your environment, change the action to Block.

For more information on enabling managed rulesets, refer to Enable managed rulesets.

For more details about the vulnerability, including an agent assessment prompt and evidence sources, refer to the Cloudflare Radar Zero Wire briefing ↗︎.

Private load balancers can now keep each user on the same endpoint. This helps with applications that keep session state on a single server.

Two options are available:

• Hash endpoint steering. In the dashboard, set a pool's Endpoint steering to Hash. Each user is mapped to an endpoint within the pool.
• Session affinity. With the API, set session_affinity to ip_cookie on the load balancer. Each user stays on the same endpoint while it remains healthy and your pools do not change. Refer to Session affinity.

For traffic from the Cloudflare One Client, Cloudflare identifies the user by their device, so a user stays on the same endpoint even if their IP address changes. For other traffic, such as from a Cloudflare WAN site, Cloudflare uses the source IP address.

This works for endpoints reached through Cloudflare Tunnel, Cloudflare Mesh, and Cloudflare WAN. Affinity pins the endpoint, not the cloudflared or Mesh replica that carries the traffic.

To learn how private load balancing fits with your connectors, refer to Load balance private network traffic.

A new GA release for the Linux Cloudflare One Client is now available on the stable releases downloads page.

This hotfix addresses an issue building trusted certificate chains.

Agents SDK v0.33.0 upgrades PiHarness to Pi 1.5 ↗︎. The release reduces storage transactions while streaming, improves throughput across many sessions, and reduces memory use when streaming large tool calls.

• Far fewer storage writes while streaming. Pi stores streamed answers and tool output in batches, within a second of each update, instead of on every update. Over SQLite, this cuts storage transactions by about 27x for long answers and 5.7x for turns with parallel tools, and CPU by about a quarter.
• Higher throughput across many sessions. Pi's scheduler no longer rechecks every conversation on each commit. In a SQLite benchmark with 2,048 sessions, one Pi harness went from 88 to 459 agent runs per second.
• Less memory on large answers. Streaming a 500 KB tool call used to take about 20 seconds of CPU and a 100 MB heap. Pi now appends new text instead of copying it on every update.

Streaming updates remain visible immediately, but are persisted in batches. With the default settings, a crash can lose up to about one second of streamed progress. Refer to Recovery to configure this interval.

• A view of each session. session.watch() replaces session.events(). It returns the newest transcript entries and the session's live state, such as the answer being streamed, running tools, and why the last run ended without an answer.
• Continue without adding a message. The new session.continue() API starts a new run using the existing transcript, for example after a model error or when a run reaches its turn limit.
• Turn limit. defaults.maxTurns caps the tool rounds a run can take in new sessions.
• Tasks that keep crashing end. Pi now ends a task cut off by its restart limit instead of parking it. retry() and the parked status are removed.
• Browser in Pi's code mode. Scripts in Pi's code mode can call browserTool and pass its screenshots to image(). browserTool also stops when the harness aborts its call.

For an existing session and submission operationId, check the result before offering a continuation. For example, after resolving a model error:

const result = await session.wait(operationId);

if (result.status === "unanswered" && result.reason === "model_error") {
	const receipt = await session.continue({
		operationId: `${operationId}:continue`,
	});
	const continued = await session.wait(receipt.operationId);
	console.log(continued.status, continued.text);
}

const result = await session.wait(operationId);

if (result.status === "unanswered" && result.reason === "model_error") {
	const receipt = await session.continue({
		operationId: `${operationId}:continue`,
	});
	const continued = await session.wait(receipt.operationId);
	console.log(continued.status, continued.text);
}

This starts a new run without appending a user message. The session must be idle. If the transcript already ends in an answer, the operation returns unanswered with reason nothing_to_answer. Refer to Work with sessions.

Once a conversation runs on Pi 1.5, Pi 1.4 cannot read it. After upgrading, roll forward to fix deployment issues rather than rolling back to Pi 1.4.

Update callers of session.events() to use session.watch(), and remove uses of retry() and the parked status. Refer to the Pi Durable 1.5.0 changelog ↗︎ for the full list of breaking changes.

The Agents SDK v0.33.0 changelog ↗︎ has step-by-step upgrade instructions. Point your coding agent at them and upgrade today:

Copy promptPrompt copied!

New AI Gateways now require authentication to prevent unauthorized requests. Once authentication is on, you cannot turn it off through the dashboard or API.

When you create a new AI Gateway through the API, authentication is on by default. You can leave out the authentication field or set it to true. If you set it to false, the API returns HTTP 400.

When you update an existing gateway, leaving out authentication keeps its current setting. If you try to turn off authentication after it is on, the API returns HTTP 400.

Existing gateways with authentication turned off can continue without it. You can turn it on in your gateway settings or include authentication: true in a gateway update request:

{
	"authentication": true
}

Before turning authentication on, configure HTTP clients to send a valid Cloudflare API token. Requests through Workers bindings remain pre-authenticated.

For setup instructions and supported authorization headers, refer to AI Gateway authentication.

Account Abuse Protection now shows when a recognized AI assistant makes a login or sign up request, and which account it was acting for.

• Population overview: See which AI assistants are active across your users and how many accounts use them.
• Account activity: Every login and sign up event shows whether an AI assistant made the request, and which one.
• AI assistant filters: filter accounts by number of AI assistant events or number of AI assistants.

Use this to investigate and mitigate a single account without blocking an assistant for everyone else who relies on it, and to tune your agent settings in AI Crawler and Agent access policies.

AI assistant visibility covers login and sign up events only. Requests from assistants that Cloudflare does not recognize appear as ordinary traffic.

For more information, refer to AI assistants.

Browser Run /crawl results now include more detailed diagnostics. Each URL record can include an outcome that identifies the specific processing result, such as success, robots_disallowed, timeout, or page_error.

The job-level robots array reports the robots.txt state for up to 50 origins encountered by the crawl. Each entry includes the origin, whether usable rules were available, and the HTTP status when the crawler received a response.

{
	"robots": [
		{
			"origin": "https://example.com",
			"state": "available",
			"status": 200
		}
	],
	"records": [
		{
			"url": "https://example.com/docs/",
			"status": "completed",
			"outcome": "success"
		}
	]
}

For field definitions and all possible outcome values, refer to URL outcomes and robots.txt diagnostics.

You can now compare regional activity and errors by HTTP status code on the Metrics page for a R2 bucket in the Cloudflare dashboard.

Use Request Distribution by Region to compare request activity and filter by writes, reads, errors, or rate-limited errors (429).

Use Errors by Status Code to compare error counts and trends.

To troubleshoot errors, refer to the R2 error code reference.

Cloudflare Radar now includes Zero Wire ↗︎, a hub for investigating critical Internet vulnerabilities and threats. Each briefing separates confirmed facts from open questions, lists remediation steps, and shows what Cloudflare observes about the threat.

Briefings are grouped by urgency. Needs attention covers active incidents, new guidance, or unresolved scope that security teams should review now. Reference keeps stable briefings available, even if not every affected system has been patched. Each card shows the recommended action and summarizes what happened, why it matters, and what to do.

Each briefing page expands on the card with an update chronology and an overview, followed by:

• What to do now: remediation steps, plus a prompt to copy into an AI agent with access to your infrastructure, asking for an evidence-based assessment of affected systems and exposure.
• Cloudflare coverage: the Cloudflare products that protect against the threat, and any impact on Cloudflare's own services.
• Evidence and sources: vendor advisories, CVE records, the CISA Known Exploited Vulnerabilities (KEV) catalog, and Radar charts, such as requests matching the related Cloudflare WAF rules.

Search briefings by CVE, name, or tag, or browse every briefing with a given tag. To follow new briefings and updates, subscribe to the Zero Wire RSS feed ↗︎ or to the feed of a single tag. New briefings also appear in the Caught on Radar ↗︎ section of the Radar homepage.

Send questions or feedback from any briefing page, or at radar@cloudflare.com.

For more details, read the blog post ↗︎ or visit Zero Wire ↗︎.