Changelog

The Network Services menu structure in Cloudflare's dashboard has been updated to reflect solutions and capabilities instead of product names. This will make it easier for you to find what you need and better reflects how our services work together.

Your existing configurations will remain the same, and you will have access to all of the same features and functionality.

The changes visible in your dashboard may vary based on the products you use. Overall, changes relate to Magic Transit ↗, Magic WAN ↗, and Magic Firewall ↗.

Summary of changes:

• A new Overview page provides access to the most common tasks across Magic Transit and Magic WAN.
• Product names have been removed from top-level navigation.
• Magic Transit and Magic WAN configuration is now organized under Routes and Connectors. For example, you will find IP Prefixes under Routes, and your GRE/IPsec Tunnels under Connectors.
• Magic Firewall policies are now called Firewall Policies.
• Magic WAN Connectors and Connector On-Ramps are now referenced in the dashboard as Appliances and Appliance profiles. They can be found under Connectors > Appliances.
• Network analytics, network health, and real-time analytics are now available under Insights.
• Packet Captures are found under Insights > Diagnostics.
• You can manage your Sites from Insights > Network health.
• You can find Magic Network Monitoring under Insights > Network flow.

If you would like to provide feedback, complete this form ↗. You can also find these details in the January 7, 2026 email titled [FYI] Upcoming Network Services Dashboard Navigation Update.

Preview:

Cloudflare One has expanded its [User Risk Scoring] (/cloudflare-one/insights/risk-score/) capabilities by introducing two new behaviors for organizations using the [CrowdStrike integration] (/cloudflare-one/integrations/service-providers/crowdstrike/).

Administrators can now automatically escalate the risk score of a user if their device matches specific CrowdStrike Zero Trust Assessment (ZTA) score ranges. This allows for more granular security policies that respond dynamically to the health of the endpoint.

New risk behaviors The following risk scoring behaviors are now available:

• CrowdStrike low device score: Automatically increases a user's risk score when the connected device reports a "Low" score from CrowdStrike.
• CrowdStrike medium device score: Automatically increases a user's risk score when the connected device reports a "Medium" score from CrowdStrike.

These scores are derived from [CrowdStrike device posture attributes] (/cloudflare-one/integrations/service-providers/crowdstrike/#device-posture-attributes), including OS signals and sensor configurations.

We have made it easier to validate connectivity when deploying WARP Connector as part of your software-defined private network.

You can now ping the WARP Connector host directly on its LAN IP address immediately after installation. This provides a fast, familiar way to confirm that the Connector is online and reachable within your network before testing access to downstream services.

Starting with version 2025.10.186.0, WARP Connector responds to traffic addressed to its own LAN IP, giving you immediate visibility into Connector reachability.

Learn more about deploying WARP Connector and building private network connectivity with Cloudflare One.

This week's release focuses on improvements to existing detections to enhance coverage.

Key Findings

• Existing rule enhancements have been deployed to improve detection resilience against SQL Injection.

We've partnered with Black Forest Labs (BFL) again to bring their optimized FLUX.2 [klein] 4B model to Workers AI! This distilled model offers faster generation and cost-effective pricing, while maintaining great output quality. With a fixed 4-step inference process, Klein 4B is ideal for rapid prototyping and real-time applications where speed matters.

Read the BFL blog ↗ to learn more about the model itself, or try it out yourself on our multi modal playground ↗.

Pricing documentation is available on the model page or pricing page.

The model hosted on Workers AI is optimized for speed with a fixed 4-step inference process and supports up to 4 image inputs. Since this is a distilled model, the steps parameter is fixed at 4 and cannot be adjusted. Like FLUX.2 [dev], this image model uses multipart form data inputs, even if you just have a prompt.

With the REST API, the multipart form data input looks like this:

curl --request POST \
  --url 'https://api.cloudflare.com/client/v4/accounts/{ACCOUNT}/ai/run/@cf/black-forest-labs/flux-2-klein-4b' \
  --header 'Authorization: Bearer {TOKEN}' \
  --header 'Content-Type: multipart/form-data' \
  --form 'prompt=a sunset at the alps' \
  --form width=1024 \
  --form height=1024

With the Workers AI binding, you can use it as such:

const form = new FormData();
form.append("prompt", "a sunset with a dog");
form.append("width", "1024");
form.append("height", "1024");

// FormData doesn't expose its serialized body or boundary. Passing it to a
// Request (or Response) constructor serializes it and generates the Content-Type
// header with the boundary, which is required for the server to parse the multipart fields.
const formResponse = new Response(form);
const formStream = formResponse.body;
const formContentType = formResponse.headers.get('content-type');

const resp = await env.AI.run("@cf/black-forest-labs/flux-2-klein-4b", {
	multipart: {
		body: formStream,
		contentType: formContentType,
	},
});

The parameters you can send to the model are detailed here:

## Multi-Reference Images

The FLUX.2 klein-4b model supports generating images based on reference images, just like FLUX.2 [dev]. You can use this feature to apply the style of one image to another, add a new character to an image, or iterate on past generated images. You would use it with the same multipart form data structure, with the input images in binary. The model supports up to 4 input images.

For the prompt, you can reference the images based on the index, like `take the subject of image 1 and style it like image 0` or even use natural language like `place the dog beside the woman`.

Note: you have to name the input parameter as `input_image_0`, `input_image_1`, `input_image_2`, `input_image_3` for it to work correctly. All input images must be smaller than 512x512.

```bash
curl --request POST \
  --url 'https://api.cloudflare.com/client/v4/accounts/{ACCOUNT}/ai/run/@cf/black-forest-labs/flux-2-klein-4b' \
  --header 'Authorization: Bearer {TOKEN}' \
  --header 'Content-Type: multipart/form-data' \
  --form 'prompt=take the subject of image 1 and style it like image 0' \
  --form input_image_0=@/Users/johndoe/Desktop/icedoutkeanu.png \
  --form input_image_1=@/Users/johndoe/Desktop/me.png \
  --form width=1024 \
  --form height=1024

Through Workers AI Binding:

//helper function to convert ReadableStream to Blob
async function streamToBlob(stream: ReadableStream, contentType: string): Promise<Blob> {
  const reader = stream.getReader();
  const chunks = [];

  while (true) {
    const { done, value } = await reader.read();
    if (done) break;
    chunks.push(value);
  }

  return new Blob(chunks, { type: contentType });
}

const image0 = await fetch("http://image-url");
const image1 = await fetch("http://image-url");
const form = new FormData();

const image_blob0 = await streamToBlob(image0.body, "image/png");
const image_blob1 = await streamToBlob(image1.body, "image/png");
form.append('input_image_0', image_blob0)
form.append('input_image_1', image_blob1)
form.append('prompt', 'take the subject of image 1 and style it like image 0')

// FormData doesn't expose its serialized body or boundary. Passing it to a
// Request (or Response) constructor serializes it and generates the Content-Type
// header with the boundary, which is required for the server to parse the multipart fields.
const formResponse = new Response(form);
const formStream = formResponse.body;
const formContentType = formResponse.headers.get('content-type');

const resp = await env.AI.run("@cf/black-forest-labs/flux-2-klein-4b", {
    multipart: {
        body: formStream,
        contentType: formContentType
    }
})

We have expanded the reporting capabilities of the Cloudflare URL Scanner. In addition to existing JSON and HAR exports, users can now generate and download a PDF report directly from the Cloudflare dashboard. This update streamlines how security analysts can share findings with stakeholders who may not have access to the Cloudflare dashboard or specialized tools to parse JSON and HAR files.

Key Benefits:

• Consolidate scan results, including screenshots, security signatures, and metadata, into a single, portable document
• Easily share professional-grade summaries with non-technical stakeholders or legal teams for faster incident response

What’s new:

• PDF Export Button: A new download option is available in the URL Scanner results page within the Cloudflare dashboard
• Unified Documentation: Access all scan details—from high-level summaries to specific security flags—in one offline-friendly file

To get started with the URL Scanner and explore our reporting capabilities, visit the URL Scanner API documentation ↗.

A new GA release for the Windows WARP client is now available on the stable releases downloads page.

This release contains minor fixes, improvements, and new features. New features include the ability to manage WARP client connectivity for all devices in your fleet using an external signal, and a new WARP client device posture check for Antivirus.

Changes and improvements

• Added a new feature to manage WARP client connectivity for all devices using an external signal. This feature allows administrators to send a global signal from an on-premises HTTPS endpoint that force disconnects or reconnects all WARP clients in an account based on configuration set on the endpoint.
• Fixed an issue that caused occasional audio degradation and increased CPU usage on Windows by optimizing route configurations for large domain-based split tunnel rules.
• The Local Domain Fallback feature has been fixed for devices running WARP client version 2025.4.929.0 and newer. Previously, these devices could experience failures with Local Domain Fallback unless a fallback server was explicitly configured. This configuration is no longer a requirement for the feature to function correctly.
• Proxy mode now supports transparent HTTP proxying in addition to CONNECT-based proxying.
• Fixed an issue where sending large messages to the daemon by Inter-Process Communication (IPC) could cause the daemon to fail and result in service interruptions.
• Added support for a new WARP client device posture check for Antivirus. The check confirms the presence of an antivirus program on a Windows device with the option to check if the antivirus is up to date.

Known issues

• For Windows 11 24H2 users, Microsoft has confirmed a regression that may lead to performance issues like mouse lag, audio cracking, or other slowdowns. Cloudflare recommends users experiencing these issues upgrade to a minimum Windows 11 24H2 KB5062553 or higher for resolution.

• Devices with KB5055523 installed may receive a warning about Win32/ClickFix.ABA being present in the installer. To resolve this false positive, update Microsoft Security Intelligence to version 1.429.19.0 or later.

• DNS resolution may be broken when the following conditions are all true:

  • WARP is in Secure Web Gateway without DNS filtering (tunnel-only) mode.
  • A custom DNS server address is configured on the primary network adapter.
  • The custom DNS server address on the primary network adapter is changed while WARP is connected.

  To work around this issue, reconnect the WARP client by toggling off and back on.

A new GA release for the macOS WARP client is now available on the stable releases downloads page.

This release contains minor fixes, improvements, and new features, including the ability to manage WARP client connectivity for all devices in your fleet using an external signal.

Changes and improvements

• The Local Domain Fallback feature has been fixed for devices running WARP client version 2025.4.929.0 and newer. Previously, these devices could experience failures with Local Domain Fallback unless a fallback server was explicitly configured. This configuration is no longer a requirement for the feature to function correctly.
• Proxy mode now supports transparent HTTP proxying in addition to CONNECT-based proxying.
• Added a new feature to manage WARP client connectivity for all devices using an external signal. This feature allows administrators to send a global signal from an on-premises HTTPS endpoint that force disconnects or reconnects all WARP clients in an account based on configuration set on the endpoint.

A new GA release for the Linux WARP client is now available on the stable releases downloads page.

This release contains minor fixes, improvements, and new features, including the ability to manage WARP client connectivity for all devices in your fleet using an external signal.

WARP client version 2025.8.779.0 introduced an updated public key for Linux packages. The public key must be updated if it was installed before September 12, 2025 to ensure the repository remains functional after December 4, 2025. Instructions to make this update are available at pkg.cloudflareclient.com.

Changes and improvements

• The Local Domain Fallback feature has been fixed for devices running WARP client version 2025.4.929.0 and newer. Previously, these devices could experience failures with Local Domain Fallback unless a fallback server was explicitly configured. This configuration is no longer a requirement for the feature to function correctly.
• Linux disk encryption posture check now supports non-filesystem encryption types like dm-crypt.
• Proxy mode now supports transparent HTTP proxying in addition to CONNECT-based proxying.
• Fixed an issue where the GUI becomes unresponsive when the Re-Authenticate in browser button is clicked.
• Added a new feature to manage WARP client connectivity for all devices using an external signal. This feature allows administrators to send a global signal from an on-premises HTTPS endpoint that force disconnects or reconnects all WARP clients in an account based on configuration set on the endpoint.

Account administrators can now assign the AI Crawl Control Read Only role to provide read-only access to AI Crawl Control at the domain level.

Users with this role can view the Overview, Crawlers, Metrics, Robots.txt, and Settings tabs but cannot modify crawler actions or settings.

This role is specific for AI Crawl Control. You still require correct permissions to access other areas / features of the dashboard.

To assign, go to Manage Account > Members and add a policy with the AI Crawl Control Read Only role scoped to the desired domain.

The wrangler types command now generates TypeScript types for bindings from all environments defined in your Wrangler configuration file by default.

Previously, wrangler types only generated types for bindings in the top-level configuration (or a single environment when using the --env flag). This meant that if you had environment-specific bindings — for example, a KV namespace only in production or an R2 bucket only in staging — those bindings would be missing from your generated types, causing TypeScript errors when accessing them.

Now, running wrangler types collects bindings from all environments and includes them in the generated Env type. This ensures your types are complete regardless of which environment you deploy to.

If you want the previous behavior of generating types for only a specific environment, you can use the --env flag:

wrangler types --env production

Learn more about generating types for your Worker in the Wrangler documentation.

The Action Log now provides enriched data for post-delivery actions to improve troubleshooting. In addition to success confirmations, failed actions now display the targeted Destination folder and a specific failure reason within the Activity field.

This update allows you to see the full lifecycle of a failed action. For instance, if an administrator tries to move an email that has already been deleted or moved manually, the log will now show the multiple retry attempts and the specific destination error.

This applies to all Email Security packages:

• Enterprise
• Enterprise + PhishGuard

The ip.src.metro_code field in the Ruleset Engine is now populated with DMA (Designated Market Area) data.

You can use this field to build rules that target traffic based on geographic market areas, enabling more granular location-based policies for your applications.

Example filter expression:

ip.src.metro_code eq "501"

For more information, refer to the Fields reference.

We are excited to announce that Cloudflare Threat Events now supports the STIX2 (Structured Threat Information Expression) format. This was a highly requested feature designed to streamline how security teams consume and act upon our threat intelligence.

By adopting this industry-standard format, you can now integrate Cloudflare's threat events data more effectively into your existing security ecosystem.

• Eliminate the need for custom parsers, as STIX2 allows for "out of the box" ingestion into major Threat Intel Platforms (TIPs), SIEMs, and SOAR tools.

• STIX2 provides a standardized way to represent relationships between indicators, sightings, and threat actors, giving your analysts a clearer picture of the threat landscape.

For technical details on how to query events using this format, please refer to our Threat Events API Documentation ↗.

This week's release focuses on improvements to existing detections to enhance coverage.

Key Findings

• Existing rule enhancements have been deployed to improve detection resilience against SQL Injection.

Wrangler now supports a --check flag for the wrangler types command. This flag validates that your generated types are up to date without writing any changes to disk.

This is useful in CI/CD pipelines where you want to ensure that developers have regenerated their types after making changes to their Wrangler configuration. If the types are out of date, the command will exit with a non-zero status code.

npx wrangler types --check

If your types are up to date, the command will succeed silently. If they are out of date, you'll see an error message indicating which files need to be regenerated.

For more information, see the Wrangler types documentation.

You can now receive notifications when your Workers' builds start, succeed, fail, or get cancelled using Event Subscriptions.

Workers Builds publishes events to a Queue that your Worker can read messages from, and then send notifications wherever you need — Slack, Discord, email, or any webhook endpoint.

You can deploy this Worker ↗ to your own Cloudflare account to send build notifications to Slack:

The template includes:

• Build status with Preview/Live URLs for successful deployments
• Inline error messages for failed builds
• Branch, commit hash, and author name

For setup instructions, refer to the template README ↗ or the Event Subscriptions documentation.

Wrangler now includes built-in shell tab completion support, making it faster and easier to navigate commands without memorizing every option. Press Tab as you type to autocomplete commands, subcommands, flags, and even option values like log levels.

Tab completions are supported for Bash, Zsh, Fish, and PowerShell.

Generate the completion script for your shell and add it to your configuration file:

# Bash
wrangler complete bash >> ~/.bashrc

# Zsh
wrangler complete zsh >> ~/.zshrc

# Fish
wrangler complete fish >> ~/.config/fish/config.fish

# PowerShell
wrangler complete powershell >> $PROFILE

After adding the script, restart your terminal or source your configuration file for the changes to take effect. Then you can simply press Tab to see available completions:

wrangler d<TAB>          # completes to 'deploy', 'dev', 'd1', etc.
wrangler kv <TAB>        # shows subcommands: namespace, key, bulk

Tab completions are dynamically generated from Wrangler's command registry, so they stay up-to-date as new commands and options are added. This feature is powered by @bomb.sh/tab ↗.

See the wrangler complete documentation for more details.

Cloudflare admin activity logs now capture each time a DNS over HTTP (DoH) user is created.

These logs can be viewed from the Cloudflare One dashboard ↗, pulled via the Cloudflare API, and exported through Logpush.

You can now use the HAVING clause and LIKE pattern matching operators in Workers Analytics Engine ↗.

Workers Analytics Engine allows you to ingest and store high-cardinality data at scale and query your data through a simple SQL API.

The HAVING clause complements the WHERE clause by enabling you to filter groups based on aggregate values. While WHERE filters rows before aggregation, HAVING filters groups after aggregation is complete.

You can use HAVING to filter groups where the average exceeds a threshold:

SELECT
    blob1 AS probe_name,
    avg(double1) AS average_temp
FROM temperature_readings
GROUP BY probe_name
HAVING average_temp > 10

You can also filter groups based on aggregates such as the number of items in the group:

SELECT
    blob1 AS probe_name,
    count() AS num_readings
FROM temperature_readings
GROUP BY probe_name
HAVING num_readings > 100

The new pattern matching operators enable you to search for strings that match specific patterns using wildcard characters:

• LIKE - case-sensitive pattern matching
• NOT LIKE - case-sensitive pattern exclusion
• ILIKE - case-insensitive pattern matching
• NOT ILIKE - case-insensitive pattern exclusion

Pattern matching supports two wildcard characters: % (matches zero or more characters) and _ (matches exactly one character).

You can match strings starting with a prefix:

SELECT *
FROM logs
WHERE blob1 LIKE 'error%'

You can also match file extensions (case-insensitive):

SELECT *
FROM requests
WHERE blob2 ILIKE '%.jpg'

Another example is excluding strings containing specific text:

SELECT *
FROM events
WHERE blob3 NOT ILIKE '%debug%'

Learn more about the HAVING clause or pattern matching operators in the Workers Analytics Engine SQL reference documentation.

Custom instance types are now enabled for all Cloudflare Containers users. You can now specify specific vCPU, memory, and disk amounts, rather than being limited to pre-defined instance types. Previously, only select Enterprise customers were able to customize their instance type.

To use a custom instance type, specify the instance_type property as an object with vcpu, memory_mib, and disk_mb fields in your Wrangler configuration:

[[containers]]
image = "./Dockerfile"
instance_type = { vcpu = 2, memory_mib = 6144, disk_mb = 12000 }

Individual limits for custom instance types are based on the standard-4 instance type (4 vCPU, 12 GiB memory, 20 GB disk). You must allocate at least 1 vCPU for custom instance types. For workloads requiring less than 1 vCPU, use the predefined instance types like lite or basic.

See the limits documentation for the full list of constraints on custom instance types. See the getting started guide to deploy your first Container,

You can now deploy microfrontends to Cloudflare, splitting a single application into smaller, independently deployable units that render as one cohesive application. This lets different teams using different frameworks develop, test, and deploy each microfrontend without coordinating releases.

Microfrontends solve several challenges for large-scale applications:

• Independent deployments: Teams deploy updates on their own schedule without redeploying the entire application
• Framework flexibility: Build multi-framework applications (for example, Astro, Remix, and Next.js in one app)
• Gradual migration: Migrate from a monolith to a distributed architecture incrementally

Create a microfrontend project:

This template automatically creates a router worker with pre-configured routing logic, and lets you configure Service bindings to Workers you have already deployed to your Cloudflare account. The router Worker analyzes incoming requests, matches them against configured routes, and forwards requests to the appropriate microfrontend via service bindings. The router automatically rewrites HTML, CSS, and headers to ensure assets load correctly from each microfrontend's mount path. The router includes advanced features like preloading for faster navigation between microfrontends, smooth page transitions using the View Transitions API, and automatic path rewriting for assets, redirects, and cookies.

Each microfrontend can be a full-framework application, a static site with Workers Static Assets, or any other Worker-based application.

Get started with the microfrontends template ↗, or read the microfrontends documentation for implementation details.

Magic WAN Connector now exports NetFlow data for breakout traffic to Magic Network Monitoring (MNM), providing visibility into traffic that bypasses Cloudflare's security filtering.

This feature allows you to:

• Monitor breakout traffic statistics in the Cloudflare dashboard.
• View traffic patterns for applications configured to bypass Cloudflare.
• Maintain visibility across all traffic passing through your Magic WAN Connector.

For more information, refer to NetFlow statistics.

We've shipped a new release for the Agents SDK ↗ v0.3.0 bringing full compatibility with AI SDK v6 ↗ and introducing the unified tool pattern, dynamic tool approval, and enhanced React hooks with improved tool handling.

This release includes improved streaming and tool support, dynamic tool approval (for "human in the loop" systems), enhanced React hooks with onToolCall callback, improved error handling for streaming responses, and seamless migration from v5 patterns.

This makes it ideal for building production AI chat interfaces with Cloudflare Workers AI models, agent workflows, human-in-the-loop systems, or any application requiring reliable tool execution and approval workflows.

Additionally, we've updated workers-ai-provider v3.0.0, the official provider for Cloudflare Workers AI models, and ai-gateway-provider v3.0.0, the provider for Cloudflare AI Gateway, to be compatible with AI SDK v6.

AI SDK v6 introduces a unified tool pattern where all tools are defined on the server using the tool() function. This replaces the previous client-side AITool pattern.

import { tool } from "ai";
import { z } from "zod";

// Server: Define ALL tools on the server
const tools = {
	// Server-executed tool
	getWeather: tool({
		description: "Get weather for a city",
		inputSchema: z.object({ city: z.string() }),
		execute: async ({ city }) => fetchWeather(city)
	}),

	// Client-executed tool (no execute = client handles via onToolCall)
	getLocation: tool({
		description: "Get user location from browser",
		inputSchema: z.object({})
		// No execute function
	}),

	// Tool requiring approval (dynamic based on input)
	processPayment: tool({
		description: "Process a payment",
		inputSchema: z.object({ amount: z.number() }),
		needsApproval: async ({ amount }) => amount > 100,
		execute: async ({ amount }) => charge(amount)
	})
};

// Client: Handle client-side tools via onToolCall callback
import { useAgentChat } from "agents/ai-react";

const { messages, sendMessage, addToolOutput } = useAgentChat({
	agent,
	onToolCall: async ({ toolCall, addToolOutput }) => {
		if (toolCall.toolName === "getLocation") {
			const position = await new Promise((resolve, reject) => {
				navigator.geolocation.getCurrentPosition(resolve, reject);
			});
			addToolOutput({
				toolCallId: toolCall.toolCallId,
				output: {
					lat: position.coords.latitude,
					lng: position.coords.longitude
				}
			});
		}
	}
});

Key benefits of the unified tool pattern:

• Server-defined tools: All tools are defined in one place on the server
• Dynamic approval: Use needsApproval to conditionally require user confirmation
• Cleaner client code: Use onToolCall callback instead of managing tool configs
• Type safety: Full TypeScript support with proper tool typing

Creates a new chat interface with enhanced v6 capabilities.

// Basic chat setup with onToolCall
const { messages, sendMessage, addToolOutput } = useAgentChat({
	agent,
	onToolCall: async ({ toolCall, addToolOutput }) => {
		// Handle client-side tool execution
		await addToolOutput({
			toolCallId: toolCall.toolCallId,
			output: { result: "success" }
		});
	}
});

Use needsApproval on server tools to conditionally require user confirmation:

const paymentTool = tool({
	description: "Process a payment",
	inputSchema: z.object({
		amount: z.number(),
		recipient: z.string()
	}),
	needsApproval: async ({ amount }) => amount > 1000,
	execute: async ({ amount, recipient }) => {
		return await processPayment(amount, recipient);
	}
});

The isToolUIPart and getToolName functions now check both static and dynamic tool parts:

import { isToolUIPart, getToolName } from "ai";

const pendingToolCallConfirmation = messages.some((m) =>
	m.parts?.some(
		(part) => isToolUIPart(part) && part.state === "input-available",
	),
);

// Handle tool confirmation
if (pendingToolCallConfirmation) {
	await addToolOutput({
		toolCallId: part.toolCallId,
		output: "User approved the action"
	});
}

If you need the v5 behavior (static-only checks), use the new functions:

import { isStaticToolUIPart, getStaticToolName } from "ai";

The convertToModelMessages() function is now asynchronous. Update all calls to await the result:

import { convertToModelMessages } from "ai";

const result = streamText({
	messages: await convertToModelMessages(this.messages),
	model: openai("gpt-4o")
});

The CoreMessage type has been removed. Use ModelMessage instead:

import { convertToModelMessages, type ModelMessage } from "ai";

const modelMessages: ModelMessage[] = await convertToModelMessages(messages);

The mode option for generateObject has been removed:

// Before (v5)
const result = await generateObject({
	mode: "json",
	model,
	schema,
	prompt
});

// After (v6)
const result = await generateObject({
	model,
	schema,
	prompt
});

While generateObject and streamObject are still functional, the recommended approach is to use generateText/streamText with the Output.object() helper:

import { generateText, Output, stepCountIs } from "ai";

const { output } = await generateText({
	model: openai("gpt-4"),
	output: Output.object({
		schema: z.object({ name: z.string() })
	}),
	stopWhen: stepCountIs(2),
	prompt: "Generate a name"
});

Note: When using structured output with generateText, you must configure multiple steps with stopWhen because generating the structured output is itself a step.

Seamless integration with Cloudflare Workers AI models through the updated workers-ai-provider v3.0.0 with AI SDK v6 support.

Use Cloudflare Workers AI models directly in your agent workflows:

import { createWorkersAI } from "workers-ai-provider";
import { useAgentChat } from "agents/ai-react";

// Create Workers AI model (v3.0.0 - enhanced v6 internals)
const model = createWorkersAI({
	binding: env.AI,
})("@cf/meta/llama-3.2-3b-instruct");

Workers AI models now support v6 file handling with automatic conversion:

// Send images and files to Workers AI models
sendMessage({
	role: "user",
	parts: [
		{ type: "text", text: "Analyze this image:" },
		{
			type: "file",
			data: imageBuffer,
			mediaType: "image/jpeg",
		},
	],
});

// Workers AI provider automatically converts to proper format

Enhanced streaming support with automatic warning detection:

// Streaming with Workers AI models
const result = await streamText({
	model: createWorkersAI({ binding: env.AI })("@cf/meta/llama-3.2-3b-instruct"),
	messages: await convertToModelMessages(messages),
	onChunk: (chunk) => {
		// Enhanced streaming with warning handling
		console.log(chunk);
	},
});

The ai-gateway-provider v3.0.0 now supports AI SDK v6, enabling you to use Cloudflare AI Gateway with multiple AI providers including Anthropic, Azure, AWS Bedrock, Google Vertex, and Perplexity.

Use Cloudflare AI Gateway to add analytics, caching, and rate limiting to your AI applications:

import { createAIGateway } from "ai-gateway-provider";

// Create AI Gateway provider (v3.0.0 - enhanced v6 internals)
const model = createAIGateway({
	gatewayUrl: "https://gateway.ai.cloudflare.com/v1/your-account-id/gateway",
	headers: {
		"Authorization": `Bearer ${env.AI_GATEWAY_TOKEN}`
	}
})({
	provider: "openai",
	model: "gpt-4o"
});

The following APIs are deprecated in favor of the unified tool pattern:

1. Unified Tool Pattern: All tools must be defined on the server using tool()
2. convertToModelMessages() is async: Add await to all calls
3. CoreMessage removed: Use ModelMessage instead
4. generateObject mode removed: Remove mode option
5. isToolUIPart behavior changed: Now checks both static and dynamic tool parts

Update your dependencies to use the latest versions:

npm install agents@^0.3.0 workers-ai-provider@^3.0.0 ai-gateway-provider@^3.0.0 ai@^6.0.0 @ai-sdk/react@^3.0.0 @ai-sdk/openai@^3.0.0

• Migration Guide ↗ - Comprehensive migration documentation from v5 to v6
• AI SDK v6 Documentation ↗ - Official AI SDK migration guide
• AI SDK v6 Announcement ↗ - Learn about new features in v6
• AI SDK Documentation ↗ - Complete AI SDK reference
• GitHub Issues ↗ - Report bugs or request features

We'd love your feedback! We're particularly interested in feedback on:

• Migration experience - How smooth was the upgrade from v5 to v6?
• Unified tool pattern - How does the new server-defined tool pattern work for you?
• Dynamic tool approval - Does the needsApproval feature meet your needs?
• AI Gateway integration - How well does the new provider work with your setup?

Earlier this year, we announced the launch of the new Terraform v5 Provider. We are aware of the high number of issues reported by the Cloudflare community related to the v5 release. We have committed to releasing improvements on a 2-3 week cadence ↗ to ensure its stability and reliability, including the v5.15 release. We have also pivoted from an issue-to-issue approach to a resource-per-resource approach ↗ - we will be focusing on specific resources to not only stabilize the resource but also ensure it is migration-friendly for those migrating from v4 to v5.

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

This release includes bug fixes, the stabilization of even more popular resources, and more.

• ai_search: Add AI Search endpoints (6f02adb ↗)
• certificate_pack: Ensure proper Terraform resource ID handling for path parameters in API calls (081f32a ↗)
• worker_version: Support startup_time_ms (286ab55 ↗)
• zero_trust_dlp_custom_entry: Support upload_status (7dc0fe3 ↗)
• zero_trust_dlp_entry: Support upload_status (7dc0fe3 ↗)
• zero_trust_dlp_integration_entry: Support upload_status (7dc0fe3 ↗)
• zero_trust_dlp_predefined_entry: Support upload_status (7dc0fe3 ↗)
• zero_trust_gateway_policy: Support forensic_copy (5741fd0 ↗)
• zero_trust_list: Support additional types (category, location, device) (5741fd0 ↗)

• access_rules: Add validation to prevent state drift. Ideally, we'd use Semantic Equality but since that isn't an option, this will remove a foot-gun. (4457791 ↗)
• cloudflare_pages_project: Addressing drift issues (6edffcf ↗) (3db318e ↗)
• cloudflare_worker: Can be cleanly imported (4859b52 ↗)
• cloudflare_worker: Ensure clean imports (5b525bc ↗)
• list_items: Add validation for IP List items to avoid inconsistent state (b6733dc ↗)
• zero_trust_access_application: Remove all conditions from sweeper (3197f1a ↗)
• spectrum_application: Map missing fields during spectrum resource import (#6495 ↗) (ddb4e72 ↗)

We suggest waiting to migrate to v5 while we work on stabilization. This helps with avoiding any blocking issues while the Terraform resources are actively being stabilized ↗. We will be releasing a new migration tool in March 2026 to help support v4 to v5 transitions for our most popular resources.

• Terraform Provider ↗
• Documentation on using Terraform with Cloudflare