---
title: Workers Changelog
image: https://edgetunnel-b2h.pages.dev/cf-twitter-card.png
---

> Documentation Index  
> Fetch the complete documentation index at: https://edgetunnel-b2h.pages.dev/changelog/llms.txt  
> Use this file to discover all available pages before exploring further. 

[Skip to content](#%5Ftop) 

# Changelog

New updates and improvements at Cloudflare.

[ Subscribe to RSS ](https://edgetunnel-b2h.pages.dev/changelog/rss/index.xml) [ View RSS feeds ](https://edgetunnel-b2h.pages.dev/fundamentals/new-features/available-rss-feeds/) 

Workers

![hero image](https://edgetunnel-b2h.pages.dev/_astro/hero.CVYJHPAd_26AMqX.svg) 

Mar 17, 2026
1. ### [@cloudflare/codemode v0.2.1: MCP barrel export, zero-dependency main entry point, and custom sandbox modules](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-17-codemode-sdk-v021/)  
[ Agents ](https://edgetunnel-b2h.pages.dev/agents/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
The latest releases of [@cloudflare/codemode ↗](https://www.npmjs.com/package/@cloudflare/codemode) add a new MCP barrel export, remove `ai` and `zod` as required peer dependencies from the main entry point, and give you more control over the sandbox.  
#### New `@cloudflare/codemode/mcp` export  
A new `@cloudflare/codemode/mcp` entry point provides two functions that wrap MCP servers with Code Mode:

  * **`codeMcpServer({ server, executor })`** — wraps an existing MCP server with a single `code` tool where each upstream tool becomes a typed `codemode.*` method.
  * **`openApiMcpServer({ spec, executor, request })`** — creates `search` and `execute` MCP tools from an OpenAPI spec with host-side request proxying and automatic `$ref` resolution.

  * [  JavaScript ](#tab-panel-3047)
  * [  TypeScript ](#tab-panel-3048)

**JavaScript**  
```js  
import { codeMcpServer } from "@cloudflare/codemode/mcp";  
import { DynamicWorkerExecutor } from "@cloudflare/codemode";  
const executor = new DynamicWorkerExecutor({ loader: env.LOADER });  
// Wrap an existing MCP server — all its tools become  
// typed methods the LLM can call from generated code  
const server = await codeMcpServer({ server: upstreamMcp, executor });  
```

**TypeScript**  
```ts  
import { codeMcpServer } from "@cloudflare/codemode/mcp";  
import { DynamicWorkerExecutor } from "@cloudflare/codemode";  
const executor = new DynamicWorkerExecutor({ loader: env.LOADER });  
// Wrap an existing MCP server — all its tools become  
// typed methods the LLM can call from generated code  
const server = await codeMcpServer({ server: upstreamMcp, executor });  
```  
#### Zero-dependency main entry point

**Breaking change in v0.2.0:** `generateTypes` and the `ToolDescriptor` / `ToolDescriptors` types have moved to `@cloudflare/codemode/ai`:

  * [  JavaScript ](#tab-panel-3045)
  * [  TypeScript ](#tab-panel-3046)

**JavaScript**  
```js  
// Before  
import { generateTypes } from "@cloudflare/codemode";  
// After  
import { generateTypes } from "@cloudflare/codemode/ai";  
```

**TypeScript**  
```ts  
// Before  
import { generateTypes } from "@cloudflare/codemode";  
// After  
import { generateTypes } from "@cloudflare/codemode/ai";  
```  
The main entry point (`@cloudflare/codemode`) no longer requires the `ai` or `zod` peer dependencies. It now exports:

| Export                      | Description                                                 |
| --------------------------- | ----------------------------------------------------------- |
| sanitizeToolName            | Sanitize tool names into valid JS identifiers               |
| normalizeCode               | Normalize LLM-generated code into async arrow functions     |
| generateTypesFromJsonSchema | Generate TypeScript type definitions from plain JSON Schema |
| jsonSchemaToType            | Convert a single JSON Schema to a TypeScript type string    |
| DynamicWorkerExecutor       | Sandboxed code execution via Dynamic Worker Loader          |
| ToolDispatcher              | RPC target for dispatching tool calls from sandbox to host  |  
The `ai` and `zod` peer dependencies are now optional — only required when importing from `@cloudflare/codemode/ai`.  
#### Custom sandbox modules  
`DynamicWorkerExecutor` now accepts an optional `modules` option to inject custom ES modules into the sandbox:

  * [  JavaScript ](#tab-panel-3049)
  * [  TypeScript ](#tab-panel-3050)

**JavaScript**  
```js  
const executor = new DynamicWorkerExecutor({  
  loader: env.LOADER,  
  modules: {  
    "utils.js": `export function add(a, b) { return a + b; }`,  
  },  
});  
// Sandbox code can then: import { add } from "utils.js"  
```

**TypeScript**  
```ts  
const executor = new DynamicWorkerExecutor({  
  loader: env.LOADER,  
  modules: {  
    "utils.js": `export function add(a, b) { return a + b; }`,  
  },  
});  
// Sandbox code can then: import { add } from "utils.js"  
```  
#### Internal normalization and sanitization  
`DynamicWorkerExecutor` now normalizes code and sanitizes tool names internally. You no longer need to call `normalizeCode()` or `sanitizeToolName()` before passing code and functions to `execute()`.  
#### Upgrade  
```sh  
npm i @cloudflare/codemode@latest  
```  
See the [Code Mode documentation](https://edgetunnel-b2h.pages.dev/agents/tools/codemode/) for the full API reference.

Mar 15, 2026
1. ### [Access Durable Object name via \`ctx.id.name\`](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-15-durable-object-id-name/)  
[ Durable Objects ](https://edgetunnel-b2h.pages.dev/durable-objects/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
When your Worker accesses a Durable Object via `idFromName()` or `getByName()`, the same name is now available on `ctx.id.name` inside the object — no need to pass it through method arguments or persist it in storage. This brings the runtime behavior in line with the [Workers runtime types](https://edgetunnel-b2h.pages.dev/workers/languages/typescript/).  
This is especially useful for [alarms](https://edgetunnel-b2h.pages.dev/durable-objects/api/alarms/), where there is no calling client to pass the name as an argument. When an alarm handler runs, `ctx.id.name` will hold the same name the object was originally accessed with.

**JavaScript**  
```js  
import { DurableObject } from "cloudflare:workers";  
export class ChatRoom extends DurableObject {  
  async getRoomName() {  
    // ctx.id.name returns the name passed to getByName() or idFromName()  
    return this.ctx.id.name;  
  }  
}  
// Worker  
export default {  
  async fetch(request, env) {  
    const stub = env.CHAT_ROOM.getByName("general");  
    const roomName = await stub.getRoomName();  
    return new Response(`Welcome to ${roomName}!`);  
  },  
};  
```  
`ctx.id.name` is `undefined` in the following cases:

  * For Durable Objects created with `newUniqueId()`.
  * When accessed via `idFromString()`, even if the ID was originally created from a name.
  * For [names longer than 1,024 bytes](https://edgetunnel-b2h.pages.dev/durable-objects/api/id/#name).  
This works the same way in local development with `wrangler dev` as it does in production. Run `npm update wrangler` to ensure you are on a version with this support.  
For more information, refer to the [Durable Object ID documentation](https://edgetunnel-b2h.pages.dev/durable-objects/api/id/#name).

Mar 06, 2026
1. ### [Workflow steps now expose retry attempt number via step context](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-06-step-context-available/)  
[ Workflows ](https://edgetunnel-b2h.pages.dev/workflows/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
Cloudflare Workflows allows you to configure specific retry logic for each step in your workflow execution. Now, you can access **which** retry attempt is currently executing for calls to `step.do()`:

**TypeScript**  
```ts  
await step.do("my-step", async (ctx) => {  
  // ctx.attempt is 1 on first try, 2 on first retry, etc.  
  console.log(`Attempt ${ctx.attempt}`);  
});  
```  
You can use the step context for improved logging & observability, progressive backoff, or conditional logic in your workflow definition.  
Note that the current attempt number is 1-indexed. For more information on retry behavior, refer to [Sleeping and Retrying](https://edgetunnel-b2h.pages.dev/workflows/build/sleeping-and-retrying/).

Mar 03, 2026
1. ### [Workflows step limit increased to 25,000 steps per instance](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-03-step-limits-to-25k/)  
[ Workflows ](https://edgetunnel-b2h.pages.dev/workflows/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
Each Workflow on Workers Paid now supports 10,000 steps by default, configurable up to 25,000 steps in your `wrangler.jsonc` file:  
```json  
{  
  "workflows": [  
    {  
      "name": "my-workflow",  
      "binding": "MY_WORKFLOW",  
      "class_name": "MyWorkflow",  
      "limits": {  
        "steps": 25000  
      }  
    }  
  ]  
}  
```  
Previously, each instance was limited to 1,024 steps. Now, Workflows can support more complex, long-running executions without the additional complexity of recursive or child workflow calls.  
Note that the maximum persisted state limit per Workflow instance remains **100 MB** for Workers Free and **1 GB** for Workers Paid. Refer to [Workflows limits](https://edgetunnel-b2h.pages.dev/workflows/reference/limits/) for more information.

Mar 02, 2026
1. ### [Agents SDK v0.7.0: Observability rewrite, keepAlive, and waitForMcpConnections](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-02-agents-sdk-v070/)  
[ Agents ](https://edgetunnel-b2h.pages.dev/agents/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
The latest release of the [Agents SDK ↗](https://github.com/cloudflare/agents) rewrites observability from scratch with `diagnostics_channel`, adds `keepAlive()` to prevent Durable Object eviction during long-running work, and introduces `waitForMcpConnections` so MCP tools are always available when `onChatMessage` runs.  
#### Observability rewrite  
The previous observability system used `console.log()` with a custom `Observability.emit()` interface. v0.7.0 replaces it with structured events published to [diagnostics channels](https://edgetunnel-b2h.pages.dev/workers/runtime-apis/nodejs/diagnostics-channel/) — silent by default, zero overhead when nobody is listening.  
Every event has a `type`, `payload`, and `timestamp`. Events are routed to seven named channels:

| Channel          | Event types                                                                                                                                      |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| agents:state     | state:update                                                                                                                                     |
| agents:rpc       | rpc, rpc:error                                                                                                                                   |
| agents:message   | message:request, message:response, message:clear, message:cancel, message:error, tool:result, tool:approval                                      |
| agents:schedule  | schedule:create, schedule:execute, schedule:cancel, schedule:retry, schedule:error, queue:retry, queue:error                                     |
| agents:lifecycle | connect, destroy                                                                                                                                 |
| agents:workflow  | workflow:start, workflow:event, workflow:approved, workflow:rejected, workflow:terminated, workflow:paused, workflow:resumed, workflow:restarted |
| agents:mcp       | mcp:client:preconnect, mcp:client:connect, mcp:client:authorize, mcp:client:discover                                                             |  
Use the typed `subscribe()` helper from `agents/observability` for type-safe access:

  * [  JavaScript ](#tab-panel-3059)
  * [  TypeScript ](#tab-panel-3060)

**JavaScript**  
```js  
import { subscribe } from "agents/observability";  
const unsub = subscribe("rpc", (event) => {  
  if (event.type === "rpc") {  
    console.log(`RPC call: ${event.payload.method}`);  
  }  
  if (event.type === "rpc:error") {  
    console.error(  
      `RPC failed: ${event.payload.method} — ${event.payload.error}`,  
    );  
  }  
});  
// Clean up when done  
unsub();  
```

**TypeScript**  
```ts  
import { subscribe } from "agents/observability";  
const unsub = subscribe("rpc", (event) => {  
  if (event.type === "rpc") {  
    console.log(`RPC call: ${event.payload.method}`);  
  }  
  if (event.type === "rpc:error") {  
    console.error(  
      `RPC failed: ${event.payload.method} — ${event.payload.error}`,  
    );  
  }  
});  
// Clean up when done  
unsub();  
```  
In production, all diagnostics channel messages are automatically forwarded to [Tail Workers](https://edgetunnel-b2h.pages.dev/workers/observability/logs/tail-workers/) — no subscription code needed in the agent itself:

  * [  JavaScript ](#tab-panel-3055)
  * [  TypeScript ](#tab-panel-3056)

**JavaScript**  
```js  
export default {  
  async tail(events) {  
    for (const event of events) {  
      for (const msg of event.diagnosticsChannelEvents) {  
        // msg.channel is "agents:rpc", "agents:workflow", etc.  
        console.log(msg.timestamp, msg.channel, msg.message);  
      }  
    }  
  },  
};  
```

**TypeScript**  
```ts  
export default {  
  async tail(events) {  
    for (const event of events) {  
      for (const msg of event.diagnosticsChannelEvents) {  
        // msg.channel is "agents:rpc", "agents:workflow", etc.  
        console.log(msg.timestamp, msg.channel, msg.message);  
      }  
    }  
  },  
};  
```  
The custom `Observability` override interface is still supported for users who need to filter or forward events to external services.  
For the full event reference, refer to the [Observability documentation](https://edgetunnel-b2h.pages.dev/agents/runtime/operations/observability/).  
#### `keepAlive()` and `keepAliveWhile()`  
Durable Objects are evicted after a period of inactivity (typically 70-140 seconds with no incoming requests, WebSocket messages, or alarms). During long-running operations — streaming LLM responses, waiting on external APIs, running multi-step computations — the agent can be evicted mid-flight.  
`keepAlive()` prevents this by creating a 30-second heartbeat schedule. The alarm firing resets the inactivity timer. Returns a disposer function that cancels the heartbeat when called.

  * [  JavaScript ](#tab-panel-3053)
  * [  TypeScript ](#tab-panel-3054)

**JavaScript**  
```js  
const dispose = await this.keepAlive();  
try {  
  const result = await longRunningComputation();  
  await sendResults(result);  
} finally {  
  dispose();  
}  
```

**TypeScript**  
```ts  
const dispose = await this.keepAlive();  
try {  
  const result = await longRunningComputation();  
  await sendResults(result);  
} finally {  
  dispose();  
}  
```  
`keepAliveWhile()` wraps an async function with automatic cleanup — the heartbeat starts before the function runs and stops when it completes:

  * [  JavaScript ](#tab-panel-3051)
  * [  TypeScript ](#tab-panel-3052)

**JavaScript**  
```js  
const result = await this.keepAliveWhile(async () => {  
  const data = await longRunningComputation();  
  return data;  
});  
```

**TypeScript**  
```ts  
const result = await this.keepAliveWhile(async () => {  
  const data = await longRunningComputation();  
  return data;  
});  
```  
Key details:

  * **Multiple concurrent callers** — Each `keepAlive()` call returns an independent disposer. Disposing one does not affect others.
  * **AIChatAgent built-in** — `AIChatAgent` automatically calls `keepAlive()` during streaming responses. You do not need to add it yourself.
  * **Uses the scheduling system** — The heartbeat does not conflict with your own schedules. It shows up in `getSchedules()` if you need to inspect it.  
Note  
`keepAlive()` is marked `@experimental` and may change between releases.  
For the full API reference and when-to-use guidance, refer to [Schedule tasks — Keeping the agent alive](https://edgetunnel-b2h.pages.dev/agents/runtime/execution/schedule-tasks/#keeping-the-agent-alive).  
#### `waitForMcpConnections`  
`AIChatAgent` now waits for MCP server connections to settle before calling `onChatMessage`. This ensures `this.mcp.getAITools()` returns the full set of tools, especially after Durable Object hibernation when connections are being restored in the background.

  * [  JavaScript ](#tab-panel-3061)
  * [  TypeScript ](#tab-panel-3062)

**JavaScript**  
```js  
export class ChatAgent extends AIChatAgent {  
  // Default — waits up to 10 seconds  
  // waitForMcpConnections = { timeout: 10_000 };  
  // Wait forever  
  waitForMcpConnections = true;  
  // Disable waiting  
  waitForMcpConnections = false;  
}  
```

**TypeScript**  
```ts  
export class ChatAgent extends AIChatAgent {  
  // Default — waits up to 10 seconds  
  // waitForMcpConnections = { timeout: 10_000 };  
  // Wait forever  
  waitForMcpConnections = true;  
  // Disable waiting  
  waitForMcpConnections = false;  
}  
```

| Value                | Behavior                                      |
| -------------------- | --------------------------------------------- |
| { timeout: 10\_000 } | Wait up to 10 seconds (default)               |
| { timeout: N }       | Wait up to N milliseconds                     |
| true                 | Wait indefinitely until all connections ready |
| false                | Do not wait (old behavior before 0.2.0)       |  
For lower-level control, call `this.mcp.waitForConnections()` directly inside `onChatMessage` instead.  
#### Other improvements

  * **MCP deduplication by name and URL** — `addMcpServer` with HTTP transport now deduplicates on both server name and URL. Calling it with the same name but a different URL creates a new connection. URLs are normalized before comparison (trailing slashes, default ports, hostname case).
  * **`callbackHost` optional for non-OAuth servers** — `addMcpServer` no longer requires `callbackHost` when connecting to MCP servers that do not use OAuth.
  * **MCP URL security** — Server URLs are validated before connection to prevent SSRF. Private IP ranges, loopback addresses, link-local addresses, and cloud metadata endpoints are blocked.
  * **Custom denial messages** — `addToolOutput` now supports `state: "output-error"` with `errorText` for custom denial messages in human-in-the-loop tool approval flows.
  * **`requestId` in chat options** — `onChatMessage` options now include a `requestId` for logging and correlating events.  
#### Upgrade  
To update to the latest version:  
```sh  
npm i agents@latest @cloudflare/ai-chat@latest  
```

Feb 25, 2026
1. ### [Agents SDK v0.6.0: RPC transport for MCP, optional OAuth, hardened schema conversion, and @cloudflare/ai-chat fixes](https://edgetunnel-b2h.pages.dev/changelog/post/2026-02-25-agents-sdk-v060/)  
[ Agents ](https://edgetunnel-b2h.pages.dev/agents/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
The latest release of the [Agents SDK ↗](https://github.com/cloudflare/agents) lets you define an Agent and an McpAgent in the same Worker and connect them over RPC — no HTTP, no network overhead. It also makes OAuth opt-in for simple MCP connections, hardens the schema converter for production workloads, and ships a batch of `@cloudflare/ai-chat` reliability fixes.  
#### RPC transport for MCP  
You can now connect an Agent to an McpAgent in the same Worker using a Durable Object binding instead of an HTTP URL. The connection stays entirely within the Cloudflare runtime — no network round-trips, no serialization overhead.  
Pass the Durable Object namespace directly to `addMcpServer`:

  * [  JavaScript ](#tab-panel-3063)
  * [  TypeScript ](#tab-panel-3064)

**JavaScript**  
```js  
import { Agent } from "agents";  
export class MyAgent extends Agent {  
  async onStart() {  
    // Connect via DO binding — no HTTP, no network overhead  
    await this.addMcpServer("counter", env.MY_MCP);  
    // With props for per-user context  
    await this.addMcpServer("counter", env.MY_MCP, {  
      props: { userId: "user-123", role: "admin" },  
    });  
  }  
}  
```

**TypeScript**  
```ts  
import { Agent } from "agents";  
export class MyAgent extends Agent {  
  async onStart() {  
    // Connect via DO binding — no HTTP, no network overhead  
    await this.addMcpServer("counter", env.MY_MCP);  
    // With props for per-user context  
    await this.addMcpServer("counter", env.MY_MCP, {  
      props: { userId: "user-123", role: "admin" },  
    });  
  }  
}  
```  
The `addMcpServer` method now accepts `string | DurableObjectNamespace` as the second parameter with full TypeScript overloads, so HTTP and RPC paths are type-safe and cannot be mixed.  
Key capabilities:

  * **Hibernation support** — RPC connections survive Durable Object hibernation automatically. The binding name and props are persisted to storage and restored on wake-up, matching the behavior of HTTP MCP connections.
  * **Deduplication** — Calling `addMcpServer` with the same server name returns the existing connection instead of creating duplicates. Connection IDs are stable across hibernation restore.
  * **Smaller surface area** — The RPC transport internals have been rewritten and reduced from 609 lines to 245 lines. `RPCServerTransport` now uses `JSONRPCMessageSchema` from the MCP SDK for validation instead of hand-written checks.  
Note  
RPC transport is experimental. The API may change based on feedback. Refer to [the tracking issue ↗](https://github.com/cloudflare/agents/issues/565) for updates.  
#### Optional OAuth for MCP connections  
`addMcpServer()` no longer eagerly creates an OAuth provider for every connection. For servers that do not require authentication, a simple call is all you need:

  * [  JavaScript ](#tab-panel-3057)
  * [  TypeScript ](#tab-panel-3058)

**JavaScript**  
```js  
// No callbackHost, no OAuth config — just works  
await this.addMcpServer("my-server", "https://mcp.example.com");  
```

**TypeScript**  
```ts  
// No callbackHost, no OAuth config — just works  
await this.addMcpServer("my-server", "https://mcp.example.com");  
```  
If the server responds with a 401, the SDK throws a clear error: `"This MCP server requires OAuth authentication. Provide callbackHost in addMcpServer options to enable the OAuth flow."` The restore-from-storage flow also handles missing callback URLs gracefully, skipping auth provider creation for non-OAuth servers.  
#### Hardened JSON Schema to TypeScript converter  
The schema converter used by `generateTypes()` and `getAITools()` now handles edge cases that previously caused crashes in production:

  * **Depth and circular reference guards** — Prevents stack overflows on recursive or deeply nested schemas
  * **`$ref` resolution** — Supports internal JSON Pointers (`#/definitions/...`, `#/$defs/...`, `#`)
  * **Tuple support** — `prefixItems` (JSON Schema 2020-12) and array `items` (draft-07)
  * **OpenAPI 3.0 `nullable: true`** — Supported across all schema branches
  * **Per-tool error isolation** — One malformed schema cannot crash the full pipeline in `generateTypes()` or `getAITools()`
  * **Missing `inputSchema` fallback** — `getAITools()` falls back to `{ type: "object" }` instead of throwing  
#### `@cloudflare/ai-chat` fixes

  * **Tool denial flow** — Denied tool approvals (`approved: false`) now transition to `output-denied` with a `tool_result`, fixing Anthropic provider compatibility. Custom denial messages are supported via `state: "output-error"` and `errorText`.
  * **Abort/cancel support** — Streaming responses now properly cancel the reader loop when the abort signal fires and send a done signal to the client.
  * **Duplicate message persistence** — `persistMessages()` now reconciles assistant messages by content and order, preventing duplicate rows when clients resend full history.
  * **`requestId` in `OnChatMessageOptions`** — Handlers can now send properly-tagged error responses for pre-stream failures.
  * **`redacted_thinking` preservation** — The message sanitizer no longer strips Anthropic `redacted_thinking` blocks.
  * **`/get-messages` reliability** — Endpoint handling moved from a prototype `onRequest()` override to a constructor wrapper, so it works even when users override `onRequest` without calling `super.onRequest()`.
  * **Client tool APIs undeprecated** — `createToolsFromClientSchemas`, `clientTools`, `AITool`, `extractClientToolSchemas`, and the `tools` option on `useAgentChat` are restored for SDK use cases where tools are defined dynamically at runtime.
  * **`jsonSchema` initialization** — Fixed `jsonSchema not initialized` error when calling `getAITools()` in `onChatMessage`.  
#### Upgrade  
To update to the latest version:  
```sh  
npm i agents@latest @cloudflare/ai-chat@latest  
```

Feb 25, 2026
1. ### [Better Windows support for Python Workers](https://edgetunnel-b2h.pages.dev/changelog/post/2026-02-13-pywrangler-windows-support/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
[Pywrangler ↗](https://github.com/cloudflare/workers-py?tab=readme-ov-file#pywrangler), the CLI tool for managing Python Workers and packages, now supports Windows, allowing you to develop and deploy Python Workers from Windows environments. Previously, Pywrangler was only available on macOS and Linux.  
You can install and use Pywrangler on Windows the same way you would on other platforms. [Specify your Worker's Python dependencies](https://edgetunnel-b2h.pages.dev/workers/languages/python/packages/) in your `pyproject.toml` file, then use the following commands to develop and deploy:  
```bash  
uvx --from workers-py pywrangler dev  
uvx --from workers-py pywrangler deploy  
```  
All existing Pywrangler functionality, including package management, local development, and deployment, works on Windows without any additional configuration.  
#### Requirements  
This feature requires the following minimum versions:

  * `wrangler` \>= 4.64.0
  * `workers-py` \>= 1.72.0
  * `uv` \>= 0.29.8  
To upgrade `workers-py` (which includes Pywrangler) in your project, run:  
```bash  
uv tool upgrade workers-py  
```  
To upgrade `wrangler`, run:  
```bash  
npm install -g wrangler@latest  
```  
To upgrade `uv`, run:  
```bash  
uv self update  
```  
To get started with Python Workers on Windows, refer to the [Python packages documentation](https://edgetunnel-b2h.pages.dev/workers/languages/python/packages/) for full details on Pywrangler.

Feb 25, 2026
1. ### [Write structured queries to filter and search your Workers logs and traces](https://edgetunnel-b2h.pages.dev/changelog/post/2026-02-24-observability-query-language/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
[Workers Observability](https://edgetunnel-b2h.pages.dev/workers/observability/) now includes a query language that lets you write structured queries directly in the search bar to filter your logs and traces. The search bar doubles as a free text search box — type any term to search across all metadata and attributes, or write field-level queries for precise filtering.  
![Workers Observability search bar with autocomplete suggestions and Query Builder sidebar filters](https://edgetunnel-b2h.pages.dev/_astro/2026-02-24-query-language.Ol8UX7m0_ZqdMnt.webp)  
Queries written in the search bar sync with the [Query Builder](https://edgetunnel-b2h.pages.dev/workers/observability/) sidebar, so you can write a query by hand and then refine it visually, or build filters in the Query Builder and see the corresponding query syntax. The search bar provides autocomplete suggestions for metadata fields and operators as you type.  
The query language supports:

  * **Free text search** — search everywhere with a keyword like `error`, or match an exact phrase with `"exact phrase"`
  * **Field queries** — filter by specific fields using comparison operators (for example, `status = 500` or `$workers.wallTimeMs > 100`)
  * **Operators** — `=`, `!=`, `>`, `>=`, `<`, `<=`, and `:` (contains)
  * **Functions** — `contains(field, value)`, `startsWith(field, prefix)`, `regex(field, pattern)`, and `exists(field)`
  * **Boolean logic** — add conditions with `AND`, `OR`, and `NOT`  
Select the help icon next to the search bar to view the full syntax reference, including all supported operators, functions, and keyboard shortcuts.  
Go to the [Workers Observability dashboard ↗](https://dash.cloudflare.com/?to=/:account/workers-and-pages/observability/) to try the query language.

Feb 25, 2026
1. ### [No config? No problem. Just \`wrangler deploy\`](https://edgetunnel-b2h.pages.dev/changelog/post/2026-02-25-wrangler-autoconfig-ga/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
You can now deploy any existing project to Cloudflare Workers — even without a Wrangler configuration file — and `wrangler deploy` will _just work_.  
Starting with Wrangler **4.68.0**, running [wrangler deploy](https://edgetunnel-b2h.pages.dev/workers/wrangler/commands/general/#deploy) [automatically configures your project](https://edgetunnel-b2h.pages.dev/workers/framework-guides/automatic-configuration/) by detecting your framework, installing required adapters, and deploying it to Cloudflare Workers.  
#### Using Wrangler locally  
```sh  
npx wrangler deploy  
```  
When you run `wrangler deploy` in a project without a configuration file, Wrangler:

  1. Detects your framework from `package.json`
  2. Prompts you to confirm the detected settings
  3. Installs any required adapters
  4. Generates a `wrangler.jsonc` [configuration file](https://edgetunnel-b2h.pages.dev/workers/wrangler/configuration/)
  5. Deploys your project to Cloudflare Workers  
You can also use [wrangler setup](https://edgetunnel-b2h.pages.dev/workers/wrangler/commands/general/#setup) to configure without deploying, or pass [\--yes](https://edgetunnel-b2h.pages.dev/workers/wrangler/commands/general/#deploy) to skip prompts.  
#### Using the Cloudflare dashboard  
![Automatic configuration pull request created by Workers Builds](https://edgetunnel-b2h.pages.dev/_astro/automatic-pr.CwJG6Bec_1cC506.webp)  
When you connect a repository through the [Workers dashboard ↗](https://dash.cloudflare.com/?to=/:account/workers-and-pages/create), a [pull request is generated](https://edgetunnel-b2h.pages.dev/workers/ci-cd/builds/automatic-prs/) for you with all necessary files, and a [preview deployment](https://edgetunnel-b2h.pages.dev/workers/versions-and-deployments/preview-urls/) to check before merging.  
Note  
A pull request is only generated when your deploy command is `npx wrangler deploy`. If you use a custom deploy command, automatic configuration still runs but a PR is not created.  
#### Background  
In December 2025, we [introduced automatic configuration](https://edgetunnel-b2h.pages.dev/changelog/2025-12-16-wrangler-autoconfig/) as an experimental feature. It is now generally available and the default behavior.  
If you have questions or run into issues, join the [GitHub discussion ↗](https://github.com/cloudflare/workers-sdk/discussions/11667).

Feb 24, 2026
1. ### [deleteAll() now deletes Durable Object alarm](https://edgetunnel-b2h.pages.dev/changelog/post/2026-02-24-deleteall-deletes-alarms/)  
[ Durable Objects ](https://edgetunnel-b2h.pages.dev/durable-objects/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
`deleteAll()` now deletes a Durable Object alarm in addition to stored data for Workers with a compatibility date of `2026-02-24` or later. This change simplifies clearing a Durable Object's storage with a single API call.  
Previously, `deleteAll()` only deleted user-stored data for an object. Alarm usage stores metadata in an object's storage, which required a separate `deleteAlarm()` call to fully clean up all storage for an object. The `deleteAll()` change applies to both KV-backed and SQLite-backed Durable Objects.

**JavaScript**  
```js  
// Before: two API calls required to clear all storage  
await this.ctx.storage.deleteAlarm();  
await this.ctx.storage.deleteAll();  
// Now: a single call clears both data and the alarm  
await this.ctx.storage.deleteAll();  
```  
For more information, refer to the [Storage API documentation](https://edgetunnel-b2h.pages.dev/durable-objects/api/sqlite-storage-api/#deleteall).

Feb 24, 2026
1. ### [Dropped event metrics, typed Pipelines bindings, and improved setup](https://edgetunnel-b2h.pages.dev/changelog/post/2026-02-24-typed-bindings-setup-improvements-error-metrics/)  
[ Pipelines ](https://edgetunnel-b2h.pages.dev/pipelines/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
[Cloudflare Pipelines](https://edgetunnel-b2h.pages.dev/pipelines/) ingests streaming data via [Workers](https://edgetunnel-b2h.pages.dev/workers/) or HTTP endpoints, transforms it with SQL, and writes it to [R2](https://edgetunnel-b2h.pages.dev/r2/) as Apache Iceberg tables. Today we're shipping three improvements to help you understand why streaming events get dropped, catch data quality issues early, and set up Pipelines faster.  
#### Dropped event metrics  
When [stream](https://edgetunnel-b2h.pages.dev/pipelines/streams/) events don't match the expected schema, Pipelines accepts them during ingestion but drops them when attempting to deliver them to the [sink](https://edgetunnel-b2h.pages.dev/pipelines/sinks/). To help you identify the root cause of these issues, we are introducing a new dashboard and metrics that surface dropped events with detailed error messages.  
![The Errors tab in the Cloudflare dashboard showing deserialization errors grouped by type with individual error details](https://edgetunnel-b2h.pages.dev/_astro/pipelines-error-log-dash.6JIa7r5d_Z1ILPxd.webp)  
Dropped events can also be queried programmatically via the new `pipelinesUserErrorsAdaptiveGroups` GraphQL dataset. The dataset breaks down failures by specific error type (`missing_field`, `type_mismatch`, `parse_failure`, or `null_value`) so you can trace issues back to the source.  
```graphql  
query GetPipelineUserErrors(  
  $accountTag: String!  
  $pipelineId: String!  
  $datetimeStart: Time!  
  $datetimeEnd: Time!  
) {  
  viewer {  
    accounts(filter: { accountTag: $accountTag }) {  
      pipelinesUserErrorsAdaptiveGroups(  
        limit: 100  
        filter: {  
          pipelineId: $pipelineId  
          datetime_geq: $datetimeStart  
          datetime_leq: $datetimeEnd  
        }  
        orderBy: [count_DESC]  
      ) {  
        count  
        dimensions {  
          errorFamily  
          errorType  
        }  
      }  
    }  
  }  
}  
```  
For the full list of dimensions, error types, and additional query examples, refer to [User error metrics](https://edgetunnel-b2h.pages.dev/pipelines/observability/metrics/#user-error-metrics).  
#### Typed Pipelines bindings  
Sending data to a Pipeline from a Worker previously used a generic `Pipeline<PipelineRecord>` type, which meant schema mismatches (wrong field names, incorrect types) were only caught at runtime as dropped events.  
Running `wrangler types` now generates schema-specific TypeScript types for your [Pipeline bindings](https://edgetunnel-b2h.pages.dev/pipelines/streams/writing-to-streams/#send-via-workers). TypeScript catches missing required fields and incorrect field types at compile time, before your code is deployed.

**TypeScript**  
```ts  
declare namespace Cloudflare {  
  type EcommerceStreamRecord = {  
    user_id: string;  
    event_type: string;  
    product_id?: string;  
    amount?: number;  
  };  
  interface Env {  
    STREAM: import("cloudflare:pipelines").Pipeline<Cloudflare.EcommerceStreamRecord>;  
  }  
}  
```  
For more information, refer to [Typed Pipeline bindings](https://edgetunnel-b2h.pages.dev/pipelines/streams/writing-to-streams/#typed-pipeline-bindings).  
#### Improved Pipelines setup  
Setting up a new Pipeline previously required multiple manual steps: creating an R2 bucket, enabling R2 Data Catalog, generating an API token, and configuring format, compression, and rolling policies individually.  
The `wrangler pipelines setup` command now offers a **Simple** setup mode that applies recommended defaults and automatically creates the [R2 bucket](https://edgetunnel-b2h.pages.dev/r2/buckets/) and enables [R2 Data Catalog](https://edgetunnel-b2h.pages.dev/r2/data-catalog/) if they do not already exist. Validation errors during setup prompt you to retry inline rather than restarting the entire process.  
For a full walkthrough, refer to the [Getting started guide](https://edgetunnel-b2h.pages.dev/pipelines/getting-started/).

Feb 20, 2026
1. ### [@cloudflare/codemode v0.1.0: a new runtime agnostic modular architecture](https://edgetunnel-b2h.pages.dev/changelog/post/2026-02-20-codemode-sdk-rewrite/)  
[ Agents ](https://edgetunnel-b2h.pages.dev/agents/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
The [@cloudflare/codemode ↗](https://www.npmjs.com/package/@cloudflare/codemode) package has been rewritten into a modular, runtime-agnostic SDK.  
[Code Mode ↗](https://blog.cloudflare.com/code-mode/) enables LLMs to write and execute code that orchestrates your tools, instead of calling them one at a time. This can (and does) yield significant token savings, reduces context window pressure and improves overall model performance on a task.  
The new `Executor` interface is runtime agnostic and comes with a prebuilt `DynamicWorkerExecutor` to run generated code in a [Dynamic Worker Loader](https://edgetunnel-b2h.pages.dev/workers/runtime-apis/bindings/worker-loader/).  
#### Breaking changes

  * Removed `experimental_codemode()` and `CodeModeProxy` — the package no longer owns an LLM call or model choice
  * New import path: `createCodeTool()` is now exported from `@cloudflare/codemode/ai`  
#### New features

  * **`createCodeTool()`** — Returns a standard AI SDK `Tool` to use in your AI agents.
  * **`Executor` interface** — Minimal `execute(code, fns)` contract. Implement for any code sandboxing primitive or runtime.  
#### `DynamicWorkerExecutor`  
Runs code in a [Dynamic Worker](https://edgetunnel-b2h.pages.dev/workers/runtime-apis/bindings/worker-loader/). It comes with the following features:

  * **Network isolation** — `fetch()` and `connect()` blocked by default (`globalOutbound: null`) when using `DynamicWorkerExecutor`
  * **Console capture** — `console.log/warn/error` captured and returned in `ExecuteResult.logs`
  * **Execution timeout** — Configurable via `timeout` option (default 30s)  
#### Usage

  * [  JavaScript ](#tab-panel-3067)
  * [  TypeScript ](#tab-panel-3068)

**JavaScript**  
```js  
import { createCodeTool } from "@cloudflare/codemode/ai";  
import { DynamicWorkerExecutor } from "@cloudflare/codemode";  
import { streamText } from "ai";  
const executor = new DynamicWorkerExecutor({ loader: env.LOADER });  
const codemode = createCodeTool({ tools: myTools, executor });  
const result = streamText({  
  model,  
  tools: { codemode },  
  messages,  
});  
```

**TypeScript**  
```ts  
import { createCodeTool } from "@cloudflare/codemode/ai";  
import { DynamicWorkerExecutor } from "@cloudflare/codemode";  
import { streamText } from "ai";  
const executor = new DynamicWorkerExecutor({ loader: env.LOADER });  
const codemode = createCodeTool({ tools: myTools, executor });  
const result = streamText({  
  model,  
  tools: { codemode },  
  messages,  
});  
```  
#### Wrangler configuration

  * [  wrangler.jsonc ](#tab-panel-3029)
  * [  wrangler.toml ](#tab-panel-3030)

**JSONC**  
```jsonc  
{  
  "worker_loaders": [{ "binding": "LOADER" }],  
}  
```

**TOML**  
```toml  
[[worker_loaders]]  
binding = "LOADER"  
```  
See the [Code Mode documentation](https://edgetunnel-b2h.pages.dev/agents/tools/codemode/) for full API reference and examples.  
#### Upgrade  
```sh  
npm i @cloudflare/codemode@latest  
```

Feb 17, 2026
1. ### [Agents SDK v0.5.0: Protocol message control, retry utilities, data parts, and @cloudflare/ai-chat v0.1.0](https://edgetunnel-b2h.pages.dev/changelog/post/2026-02-17-agents-sdk-v050/)  
[ Agents ](https://edgetunnel-b2h.pages.dev/agents/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
The latest release of the [Agents SDK ↗](https://github.com/cloudflare/agents) adds built-in retry utilities, per-connection protocol message control, and a fully rewritten `@cloudflare/ai-chat` with data parts, tool approval persistence, and zero breaking changes.  
#### Retry utilities  
A new `this.retry()` method lets you retry any async operation with exponential backoff and jitter. You can pass an optional `shouldRetry` predicate to bail early on non-retryable errors.

  * [  JavaScript ](#tab-panel-3065)
  * [  TypeScript ](#tab-panel-3066)

**JavaScript**  
```js  
class MyAgent extends Agent {  
  async onRequest(request) {  
    const data = await this.retry(() => callUnreliableService(), {  
      maxAttempts: 4,  
      shouldRetry: (err) => !(err instanceof PermanentError),  
    });  
    return Response.json(data);  
  }  
}  
```

**TypeScript**  
```ts  
class MyAgent extends Agent {  
  async onRequest(request: Request) {  
    const data = await this.retry(() => callUnreliableService(), {  
      maxAttempts: 4,  
      shouldRetry: (err) => !(err instanceof PermanentError),  
    });  
    return Response.json(data);  
  }  
}  
```  
Retry options are also available per-task on `queue()`, `schedule()`, `scheduleEvery()`, and `addMcpServer()`:

  * [  JavaScript ](#tab-panel-3075)
  * [  TypeScript ](#tab-panel-3076)

**JavaScript**  
```js  
// Per-task retry configuration, persisted in SQLite alongside the task  
await this.schedule(  
  Date.now() + 60_000,  
  "sendReport",  
  { userId: "abc" },  
  {  
    retry: { maxAttempts: 5 },  
  },  
);  
// Class-level retry defaults  
class MyAgent extends Agent {  
  static options = {  
    retry: { maxAttempts: 3 },  
  };  
}  
```

**TypeScript**  
```ts  
// Per-task retry configuration, persisted in SQLite alongside the task  
await this.schedule(Date.now() + 60_000, "sendReport", { userId: "abc" }, {  
  retry: { maxAttempts: 5 },  
});  
// Class-level retry defaults  
class MyAgent extends Agent {  
  static options = {  
    retry: { maxAttempts: 3 },  
  };  
}  
```  
Retry options are validated eagerly at enqueue/schedule time, and invalid values throw immediately. Internal retries have also been added for workflow operations (`terminateWorkflow`, `pauseWorkflow`, and others) with Durable Object-aware error detection.  
#### Per-connection protocol message control  
Agents automatically send JSON text frames (identity, state, MCP server lists) to every WebSocket connection. You can now suppress these per-connection for clients that cannot handle them — binary-only devices, MQTT clients, or lightweight embedded systems.

  * [  JavaScript ](#tab-panel-3069)
  * [  TypeScript ](#tab-panel-3070)

**JavaScript**  
```js  
class MyAgent extends Agent {  
  shouldSendProtocolMessages(connection, ctx) {  
    // Suppress protocol messages for MQTT clients  
    const subprotocol = ctx.request.headers.get("Sec-WebSocket-Protocol");  
    return subprotocol !== "mqtt";  
  }  
}  
```

**TypeScript**  
```ts  
class MyAgent extends Agent {  
  shouldSendProtocolMessages(connection: Connection, ctx: ConnectionContext) {  
    // Suppress protocol messages for MQTT clients  
    const subprotocol = ctx.request.headers.get("Sec-WebSocket-Protocol");  
    return subprotocol !== "mqtt";  
  }  
}  
```  
Connections with protocol messages disabled still fully participate in RPC and regular messaging. Use `isConnectionProtocolEnabled(connection)` to check a connection's status at any time. The flag persists across Durable Object hibernation.  
See [Protocol messages](https://edgetunnel-b2h.pages.dev/agents/runtime/communication/protocol-messages/) for full documentation.  
#### `@cloudflare/ai-chat` v0.1.0  
The first stable release of `@cloudflare/ai-chat` ships alongside this release with a major refactor of `AIChatAgent` internals — new `ResumableStream` class, WebSocket `ChatTransport`, and simplified SSE parsing — with zero breaking changes. Existing code using `AIChatAgent` and `useAgentChat` works as-is.  
Key new features:

  * **Data parts** — Attach typed JSON blobs (`data-*`) to messages alongside text. Supports reconciliation (type+id updates in-place), append, and transient parts (ephemeral via `onData` callback). See [Data parts](https://edgetunnel-b2h.pages.dev/agents/communication-channels/chat/chat-agents/#data-parts).
  * **Tool approval persistence** — The `needsApproval` approval UI now survives page refresh and DO hibernation. The streaming message is persisted to SQLite when a tool enters `approval-requested` state.
  * **`maxPersistedMessages`** — Cap SQLite message storage with automatic oldest-message deletion.
  * **`body` option on `useAgentChat`** — Send custom data with every request (static or dynamic).
  * **Incremental persistence** — Hash-based cache to skip redundant SQL writes.
  * **Row size guard** — Automatic two-pass compaction when messages approach the SQLite 2 MB limit.
  * **`autoContinueAfterToolResult` defaults to `true`** — Client-side tool results and tool approvals now automatically trigger a server continuation, matching server-executed tool behavior. Set `autoContinueAfterToolResult: false` in `useAgentChat` to restore the previous behavior.  
Notable bug fixes:

  * Resolved stream resumption race conditions
  * Resolved an issue where `setMessages` functional updater sent empty arrays
  * Resolved an issue where client tool schemas were lost after DO hibernation
  * Resolved `InvalidPromptError` after tool approval (`approval.id` was dropped)
  * Resolved an issue where message metadata was not propagated on broadcast/resume paths
  * Resolved an issue where `clearAll()` did not clear in-memory chunk buffers
  * Resolved an issue where `reasoning-delta` silently dropped data when `reasoning-start` was missed during stream resumption  
#### Synchronous queue and schedule getters  
`getQueue()`, `getQueues()`, `getSchedule()`, `dequeue()`, `dequeueAll()`, and `dequeueAllByCallback()` were unnecessarily `async` despite only performing synchronous SQL operations. They now return values directly instead of wrapping them in Promises. This is backward compatible — existing code using `await` on these methods will continue to work.  
#### Other improvements

  * **Fix TypeScript "excessively deep" error** — A depth counter on `CanSerialize` and `IsSerializableParam` types bails out to `true` after 10 levels of recursion, preventing the "Type instantiation is excessively deep" error with deeply nested types like AI SDK `CoreMessage[]`.
  * **POST SSE keepalive** — The POST SSE handler now sends `event: ping` every 30 seconds to keep the connection alive, matching the existing GET SSE handler behavior. This prevents POST response streams from being silently dropped by proxies during long-running tool calls.
  * **Widened peer dependency ranges** — Peer dependency ranges across packages have been widened to prevent cascading major bumps during 0.x minor releases. `@cloudflare/ai-chat` and `@cloudflare/codemode` are now marked as optional peer dependencies.  
#### Upgrade  
To update to the latest version:  
```sh  
npm i agents@latest @cloudflare/ai-chat@latest  
```

Feb 16, 2026
1. ### [Quick Editor devtools replaced with log viewer](https://edgetunnel-b2h.pages.dev/changelog/post/2026-02-12-quick-editor-dev-tools-deprecation/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
Cloudflare has deprecated the Workers Quick Editor dev tools inspector and replaced it with a lightweight log viewer.  
This aligns our logging with `wrangler tail` and gives us the opportunity to focus our efforts on bringing benefits from the work we have invested in observability, which would not be possible otherwise.  
We have made improvements to this logging viewer based on your feedback such that you can log object and array types, and easily clear the list of logs. This does not include class instances. Limitations are documented in the [Workers Playground docs](https://edgetunnel-b2h.pages.dev/workers/playground/).  
If you do need to develop your Worker with a remote inspector, you can still do this using Wrangler locally. Cloning a project from your quick editor to your computer for local development can be done with the `wrangler init --from-dash` command. For more information, refer to [Wrangler commands](https://edgetunnel-b2h.pages.dev/workers/wrangler/commands/general/#init).

Feb 15, 2026
1. ### [New Best Practices guide for Workers](https://edgetunnel-b2h.pages.dev/changelog/post/2026-02-15-workers-best-practices/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
A new [Workers Best Practices](https://edgetunnel-b2h.pages.dev/workers/best-practices/workers-best-practices/) guide provides opinionated recommendations for building fast, reliable, observable, and secure Workers. The guide draws on production patterns, Cloudflare internal usage, and best practices observed from developers building on Workers.  
Key guidance includes:

  * **Keep your compatibility date current and enable `nodejs_compat`** — Ensure you have access to the latest runtime features and Node.js built-in modules.

  * [  wrangler.jsonc ](#tab-panel-3031)
  * [  wrangler.toml ](#tab-panel-3032)

**JSONC**  
```jsonc  
{  
  "name": "my-worker",  
  "main": "src/index.ts",  
  // Set this to today's date  
  "compatibility_date": "2026-07-20",  
  "compatibility_flags": ["nodejs_compat"],  
}  
```

**TOML**  
```toml  
name = "my-worker"  
main = "src/index.ts"  
# Set this to today's date  
compatibility_date = "2026-07-20"  
compatibility_flags = [ "nodejs_compat" ]  
```

  * **Generate binding types with `wrangler types`** — Never hand-write your `Env` interface. Let Wrangler generate it from your actual configuration to catch mismatches at compile time.
  * **Stream request and response bodies** — Avoid buffering large payloads in memory. Use `TransformStream` and `pipeTo` to stay within the 128 MB memory limit and improve time-to-first-byte.
  * **Use bindings, not REST APIs** — Bindings to KV, R2, D1, Queues, and other Cloudflare services are direct, in-process references with no network hop and no authentication overhead.
  * **Use Queues and Workflows for background work** — Move long-running or retriable tasks out of the critical request path. Use Queues for simple fan-out and buffering, and Workflows for multi-step durable processes.
  * **Enable Workers Logs and Traces** — Configure observability before deploying to production so you have data when you need to debug.
  * **Avoid global mutable state** — Workers reuse isolates across requests. Storing request-scoped data in module-level variables causes cross-request data leaks.
  * **Always `await` or `waitUntil` your Promises** — Floating promises cause silent bugs and dropped work.
  * **Use Web Crypto for secure token generation** — Never use `Math.random()` for security-sensitive operations.  
To learn more, refer to [Workers Best Practices](https://edgetunnel-b2h.pages.dev/workers/best-practices/workers-best-practices/).

Feb 13, 2026
1. ### [Introducing GLM-4.7-Flash on Workers AI, @cloudflare/tanstack-ai, and workers-ai-provider v3.1.1](https://edgetunnel-b2h.pages.dev/changelog/post/2026-02-13-glm-47-flash-workers-ai/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)[ Agents ](https://edgetunnel-b2h.pages.dev/agents/)[ Workers AI ](https://edgetunnel-b2h.pages.dev/workers-ai/)  
We're excited to announce **GLM-4.7-Flash** on Workers AI, a fast and efficient text generation model optimized for multilingual dialogue and instruction-following tasks, along with the brand-new [**@cloudflare/tanstack-ai** ↗](https://www.npmjs.com/package/@cloudflare/tanstack-ai) package and [**workers-ai-provider v3.1.1** ↗](https://www.npmjs.com/package/workers-ai-provider).  
You can now run AI agents entirely on Cloudflare. With GLM-4.7-Flash's multi-turn tool calling support, plus full compatibility with TanStack AI and the Vercel AI SDK, you have everything you need to build agentic applications that run completely at the edge.  
#### GLM-4.7-Flash — Multilingual Text Generation Model  
[@cf/zai-org/glm-4.7-flash](https://edgetunnel-b2h.pages.dev/workers-ai/models/glm-4.7-flash/) is a multilingual model with a 131,072 token context window, making it ideal for long-form content generation, complex reasoning tasks, and multilingual applications.

**Key Features and Use Cases:**

  * **Multi-turn Tool Calling for Agents**: Build AI agents that can call functions and tools across multiple conversation turns
  * **Multilingual Support**: Built to handle content generation in multiple languages effectively
  * **Large Context Window**: 131,072 tokens for long-form writing, complex reasoning, and processing long documents
  * **Fast Inference**: Optimized for low-latency responses in chatbots and virtual assistants
  * **Instruction Following**: Excellent at following complex instructions for code generation and structured tasks  
Use GLM-4.7-Flash through the [Workers AI binding](https://edgetunnel-b2h.pages.dev/workers-ai/configuration/bindings/) (`env.AI.run()`), the REST API at `/run` or `/v1/chat/completions`, [AI Gateway](https://edgetunnel-b2h.pages.dev/ai-gateway/), or via [workers-ai-provider](https://edgetunnel-b2h.pages.dev/workers-ai/configuration/ai-sdk/) for the Vercel AI SDK.  
Pricing is available on the [model page](https://edgetunnel-b2h.pages.dev/workers-ai/models/glm-4.7-flash/) or [pricing page](https://edgetunnel-b2h.pages.dev/workers-ai/platform/pricing/).  
#### @cloudflare/tanstack-ai v0.1.1 — TanStack AI adapters for Workers AI and AI Gateway  
We've released `@cloudflare/tanstack-ai`, a new package that brings Workers AI and AI Gateway support to [TanStack AI ↗](https://tanstack.com/ai). This provides a framework-agnostic alternative for developers who prefer TanStack's approach to building AI applications.

**Workers AI adapters** support four configuration modes — plain binding (`env.AI`), plain REST, AI Gateway binding (`env.AI.gateway(id)`), and AI Gateway REST — across all capabilities:

  * **Chat** (`createWorkersAiChat`) — Streaming chat completions with tool calling, structured output, and reasoning text streaming.
  * **Image generation** (`createWorkersAiImage`) — Text-to-image models.
  * **Transcription** (`createWorkersAiTranscription`) — Speech-to-text.
  * **Text-to-speech** (`createWorkersAiTts`) — Audio generation.
  * **Summarization** (`createWorkersAiSummarize`) — Text summarization.

**AI Gateway adapters** route requests from third-party providers — OpenAI, Anthropic, Gemini, Grok, and OpenRouter — through Cloudflare AI Gateway for caching, rate limiting, and unified billing.  
To get started:  
```sh  
npm install @cloudflare/tanstack-ai @tanstack/ai  
```  
#### workers-ai-provider v3.1.1 — transcription, speech, reranking, and reliability  
The Workers AI provider for the [Vercel AI SDK ↗](https://ai-sdk.dev) now supports three new capabilities beyond chat and image generation:

  * **Transcription** (`provider.transcription(model)`) — Speech-to-text with automatic handling of model-specific input formats across binding and REST paths.
  * **Text-to-speech** (`provider.speech(model)`) — Audio generation with support for voice and speed options.
  * **Reranking** (`provider.reranking(model)`) — Document reranking for RAG pipelines and search result ordering.

**TypeScript**  
```typescript  
import { createWorkersAI } from "workers-ai-provider";  
import {  
  experimental_transcribe,  
  experimental_generateSpeech,  
  rerank,  
} from "ai";  
const workersai = createWorkersAI({ binding: env.AI });  
const transcript = await experimental_transcribe({  
  model: workersai.transcription("@cf/openai/whisper-large-v3-turbo"),  
  audio: audioData,  
  mediaType: "audio/wav",  
});  
const speech = await experimental_generateSpeech({  
  model: workersai.speech("@cf/deepgram/aura-1"),  
  text: "Hello world",  
  voice: "asteria",  
});  
const ranked = await rerank({  
  model: workersai.reranking("@cf/baai/bge-reranker-base"),  
  query: "What is machine learning?",  
  documents: ["ML is a branch of AI.", "The weather is sunny."],  
});  
```  
This release also includes a comprehensive reliability overhaul (v3.0.5):

  * **Fixed streaming** — Responses now stream token-by-token instead of buffering all chunks, using a proper `TransformStream` pipeline with backpressure.
  * **Fixed tool calling** — Resolved issues with tool call ID sanitization, conversation history preservation, and a heuristic that silently fell back to non-streaming mode when tools were defined.
  * **Premature stream termination detection** — Streams that end unexpectedly now report `finishReason: "error"` instead of silently reporting `"stop"`.
  * **AI Search support** — Added `createAISearch` as the canonical export (renamed from AutoRAG). `createAutoRAG` still works with a deprecation warning.  
To upgrade:  
```sh  
npm install workers-ai-provider@latest ai  
```  
#### Resources

  * [@cloudflare/tanstack-ai on npm ↗](https://www.npmjs.com/package/@cloudflare/tanstack-ai)
  * [workers-ai-provider on npm ↗](https://www.npmjs.com/package/workers-ai-provider)
  * [GitHub repository ↗](https://github.com/cloudflare/ai)

Feb 11, 2026
1. ### [Workers are no longer limited to 1000 subrequests](https://edgetunnel-b2h.pages.dev/changelog/post/2026-02-11-subrequests-limit/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
Workers no longer have a limit of 1000 subrequests per invocation, allowing you to make more `fetch()` calls or requests to Cloudflare services on every incoming request. This is especially important for long-running Workers requests, such as open websockets on [Durable Objects](https://edgetunnel-b2h.pages.dev/durable-objects) or long-running [Workflows](https://edgetunnel-b2h.pages.dev/workflows), as these could often exceed this limit and error.  
By default, Workers on paid plans are now limited to 10,000 subrequests per invocation, but this limit can be increased up to 10 million by setting the new `subrequests` limit in your Wrangler configuration file.

  * [  wrangler.jsonc ](#tab-panel-3033)
  * [  wrangler.toml ](#tab-panel-3034)

**JSONC**  
```jsonc  
{  
  "limits": {  
    "subrequests": 50000,  
  },  
}  
```

**TOML**  
```toml  
[limits]  
subrequests = 50_000  
```  
Workers on the free plan remain limited to 50 external subrequests and 1000 subrequests to Cloudflare services per invocation.  
To protect against runaway code or unexpected costs, you can also set a lower limit for both subrequests and CPU usage.

  * [  wrangler.jsonc ](#tab-panel-3035)
  * [  wrangler.toml ](#tab-panel-3036)

**JSONC**  
```jsonc  
{  
  "limits": {  
    "subrequests": 10,  
    "cpu_ms": 1000,  
  },  
}  
```

**TOML**  
```toml  
[limits]  
subrequests = 10  
cpu_ms = 1_000  
```  
For more information, refer to the [Wrangler configuration documentation for limits](https://edgetunnel-b2h.pages.dev/workers/wrangler/configuration/#limits) and [subrequest limits](https://edgetunnel-b2h.pages.dev/workers/platform/limits/#subrequests).

Feb 11, 2026
1. ### [Improved React Server Components support in the Cloudflare Vite plugin](https://edgetunnel-b2h.pages.dev/changelog/post/2026-02-11-vite-plugin-child-environments/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
The Cloudflare Vite plugin now integrates seamlessly [@vitejs/plugin-rsc ↗](https://github.com/vitejs/vite-plugin-react/tree/main/packages/plugin-rsc), the official Vite plugin for [React Server Components ↗](https://react.dev/reference/rsc/server-components).  
A `childEnvironments` option has been added to the plugin config to enable using multiple environments within a single Worker. The parent environment can then import modules from a child environment in order to access a separate module graph. For a typical RSC use case, the plugin might be configured as in the following example:

**vite.config.ts**  
```ts  
export default defineConfig({  
  plugins: [  
    cloudflare({  
      viteEnvironment: {  
        name: "rsc",  
        childEnvironments: ["ssr"],  
      },  
    }),  
  ],  
});  
```  
`@vitejs/plugin-rsc` provides the lower level functionality that frameworks, such as [React Router ↗](https://reactrouter.com/how-to/react-server-components), build upon. The GitHub repository includes a [basic Cloudflare example ↗](https://github.com/vitejs/vite-plugin-react/tree/f066114c3e6bf18f5209ff3d3ef6bf1ab46d3866/packages/plugin-rsc/examples/starter-cf-single).

Feb 09, 2026
1. ### [Agents SDK v0.4.0: Readonly connections, MCP security improvements, x402 v2 migration, and custom MCP OAuth providers](https://edgetunnel-b2h.pages.dev/changelog/post/2026-02-09-agents-sdk-v040/)  
[ Agents ](https://edgetunnel-b2h.pages.dev/agents/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
The latest release of the [Agents SDK ↗](https://github.com/cloudflare/agents) brings readonly connections, MCP protocol and security improvements, x402 payment protocol v2 migration, and the ability to customize OAuth for MCP server connections.  
#### Readonly connections  
Agents can now restrict WebSocket clients to read-only access, preventing them from modifying agent state. This is useful for dashboards, spectator views, or any scenario where clients should observe but not mutate.  
New hooks: `shouldConnectionBeReadonly`, `setConnectionReadonly`, `isConnectionReadonly`. Readonly connections block both client-side `setState()` and mutating `@callable()` methods, and the readonly flag survives hibernation.

  * [  JavaScript ](#tab-panel-3071)
  * [  TypeScript ](#tab-panel-3072)

**JavaScript**  
```js  
class MyAgent extends Agent {  
  shouldConnectionBeReadonly(connection) {  
    // Make spectators readonly  
    return connection.url.includes("spectator");  
  }  
}  
```

**TypeScript**  
```ts  
class MyAgent extends Agent {  
  shouldConnectionBeReadonly(connection) {  
    // Make spectators readonly  
    return connection.url.includes("spectator");  
  }  
}  
```  
#### Custom MCP OAuth providers  
The new `createMcpOAuthProvider` method on the `Agent` class allows subclasses to override the default OAuth provider used when connecting to MCP servers. This enables custom authentication strategies such as pre-registered client credentials or mTLS, beyond the built-in dynamic client registration.

  * [  JavaScript ](#tab-panel-3073)
  * [  TypeScript ](#tab-panel-3074)

**JavaScript**  
```js  
class MyAgent extends Agent {  
  createMcpOAuthProvider(callbackUrl) {  
    return new MyCustomOAuthProvider(this.ctx.storage, this.name, callbackUrl);  
  }  
}  
```

**TypeScript**  
```ts  
class MyAgent extends Agent {  
  createMcpOAuthProvider(callbackUrl: string): AgentMcpOAuthProvider {  
    return new MyCustomOAuthProvider(this.ctx.storage, this.name, callbackUrl);  
  }  
}  
```  
#### MCP SDK upgrade to 1.26.0  
Upgraded the MCP SDK to 1.26.0 to prevent cross-client response leakage. Stateless MCP Servers should now create a new `McpServer` instance per request instead of sharing a single instance. A guard is added in this version of the MCP SDK which will prevent connection to a Server instance that has already been connected to a transport. Developers will need to modify their code if they declare their `McpServer` instance as a global variable.  
#### MCP OAuth callback URL security fix  
Added `callbackPath` option to `addMcpServer` to prevent instance name leakage in MCP OAuth callback URLs. When `sendIdentityOnConnect` is `false`, `callbackPath` is now required — the default callback URL would expose the instance name, undermining the security intent. Also fixes callback request detection to match via the `state` parameter instead of a loose `/callback` URL substring check, enabling custom callback paths.  
#### Deprecate `onStateUpdate` in favor of `onStateChanged`  
`onStateChanged` is a drop-in rename of `onStateUpdate` (same signature, same behavior). `onStateUpdate` still works but emits a one-time console warning per class. `validateStateChange` rejections now propagate a `CF_AGENT_STATE_ERROR` message back to the client.  
#### x402 v2 migration  
Migrated the x402 MCP payment integration from the legacy `x402` package to `@x402/core` and `@x402/evm` v2.

**Breaking changes for x402 users:**

  * Peer dependencies changed: replace `x402` with `@x402/core` and `@x402/evm`
  * `PaymentRequirements` type now uses v2 fields (e.g. `amount` instead of `maxAmountRequired`)
  * `X402ClientConfig.account` type changed from `viem.Account` to `ClientEvmSigner` (structurally compatible with `privateKeyToAccount()`)  
```bash  
npm uninstall x402  
npm install @x402/core @x402/evm  
```  
Network identifiers now accept both legacy names and CAIP-2 format:

**TypeScript**  
```ts  
// Legacy name (auto-converted)  
{  
  network: "base-sepolia",  
}  
// CAIP-2 format (preferred)  
{  
  network: "eip155:84532",  
}  
```

**Other x402 changes:**

  * `X402ClientConfig.network` is now optional — the client auto-selects from available payment requirements
  * Server-side lazy initialization: facilitator connection is deferred until the first paid tool invocation
  * Payment tokens support both v2 (`PAYMENT-SIGNATURE`) and v1 (`X-PAYMENT`) HTTP headers
  * Added `normalizeNetwork` export for converting legacy network names to CAIP-2 format
  * Re-exports `PaymentRequirements`, `PaymentRequired`, `Network`, `FacilitatorConfig`, and `ClientEvmSigner` from `agents/x402`  
#### Other improvements

  * Fix `useAgent` and `AgentClient` crashing when using `basePath` routing
  * CORS handling delegated to partyserver's native support (simpler, more reliable)
  * Client-side `onStateUpdateError` callback for handling rejected state updates  
#### Upgrade  
To update to the latest version:  
```sh  
npm i agents@latest  
```

Feb 06, 2026
1. ### [Visualize data, share links, and create exports with the new Workers Observability dashboard](https://edgetunnel-b2h.pages.dev/changelog/post/2026-02-06-observability-ui-refresh/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
The [Workers Observability dashboard ↗](https://dash.cloudflare.com/?to=/:account/workers-and-pages/observability/) has some major updates to make it easier to debug your application's issues and share findings with your team.  
![Workers Observability dashboard showing events view with event details and share options](https://edgetunnel-b2h.pages.dev/_astro/2026-01-22-events_share_obs_wobs.BvzY4TNV_eC7Hu.webp)  
You can now:

  * **Create visualizations** — Build charts from your Worker data directly in a Worker's Observability tab
  * **Export data as JSON or CSV** — Download logs and traces for offline analysis or to share with teammates
  * **Share events and traces** — Generate direct URLs to specific events, invocations, and traces that open standalone pages with full context
  * **Customize table columns** — Improved field picker to add, remove, and reorder columns in the events table
  * **Expandable event details** — Expand events inline to view full details without leaving the table
  * **Keyboard shortcuts** — Navigate the dashboard with hotkey support  
![Workers Observability dashboard showing a P99 CPU time visualization grouped by outcome](https://edgetunnel-b2h.pages.dev/_astro/2026-01-22-vis_qb_wobs.Bb5eVQNT_at6AT.webp)  
These updates are now live in the Cloudflare dashboard, both in a Worker's Observability tab and in the account-level Observability dashboard for a unified experience. To get started, go to **Workers & Pages** \> select your Worker > **Observability**.

Feb 04, 2026
1. ### [Visualize your Workflows in the Cloudflare dashboard](https://edgetunnel-b2h.pages.dev/changelog/post/2026-02-03-workflows-visualizer/)  
[ Workflows ](https://edgetunnel-b2h.pages.dev/workflows/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
Cloudflare Workflows now automatically generates visual diagrams from your code  
Your Workflow is parsed to provide a visual map of the Workflow structure, allowing you to:

  * Understand how steps connect and execute
  * Visualize loops and nested logic
  * Follow branching paths for conditional logic  
![Example diagram](https://edgetunnel-b2h.pages.dev/_astro/2026-02-03-workflows-diagram.BfQAnWL3_Z203oFd.webp)  
You can collapse loops and nested logic to see the high-level flow, or expand them to see every step.  
Workflow diagrams are available in beta for all JavaScript and TypeScript Workflows. Find your Workflows in the [Cloudflare dashboard ↗](https://dash.cloudflare.com/?to=/:account/workers/workflows) to see their diagrams.

Jan 22, 2026
1. ### [New Placement Hints for Workers](https://edgetunnel-b2h.pages.dev/changelog/post/2026-01-22-explicit-placement-hints/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
You can now configure Workers to run close to infrastructure in legacy cloud regions to minimize latency to existing services and databases. This is most useful when your Worker makes multiple round trips.  
To [set a placement hint](https://edgetunnel-b2h.pages.dev/workers/configuration/placement/#configure-explicit-placement-hints), set the `placement.region` property in your Wrangler configuration file:

  * [  wrangler.jsonc ](#tab-panel-3037)
  * [  wrangler.toml ](#tab-panel-3038)

**JSONC**  
```jsonc  
{  
  "placement": {  
    "region": "aws:us-east-1",  
  },  
}  
```

**TOML**  
```toml  
[placement]  
region = "aws:us-east-1"  
```  
Placement hints support Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure region identifiers. Workers run in the [Cloudflare data center ↗](https://www.cloudflare.com/network/) with the lowest latency to the specified cloud region.  
If your existing infrastructure is not in these cloud providers, expose it to placement probes with `placement.host` for layer 4 checks or `placement.hostname` for layer 7 checks. These probes are designed to locate single-homed infrastructure and are not suitable for anycasted or multicasted resources.

  * [  wrangler.jsonc ](#tab-panel-3039)
  * [  wrangler.toml ](#tab-panel-3040)

**JSONC**  
```jsonc  
{  
  "placement": {  
    "host": "my_database_host.com:5432",  
  },  
}  
```

**TOML**  
```toml  
[placement]  
host = "my_database_host.com:5432"  
```

  * [  wrangler.jsonc ](#tab-panel-3041)
  * [  wrangler.toml ](#tab-panel-3042)

**JSONC**  
```jsonc  
{  
  "placement": {  
    "hostname": "my_api_server.com",  
  },  
}  
```

**TOML**  
```toml  
[placement]  
hostname = "my_api_server.com"  
```  
This is an extension of [Smart Placement](https://edgetunnel-b2h.pages.dev/workers/configuration/placement/#enable-smart-placement), which automatically places your Workers closer to back-end APIs based on measured latency. When you do not know the location of your back-end APIs or have multiple back-end APIs, set `mode: "smart"`:

  * [  wrangler.jsonc ](#tab-panel-3043)
  * [  wrangler.toml ](#tab-panel-3044)

**JSONC**  
```jsonc  
{  
  "placement": {  
    "mode": "smart",  
  },  
}  
```

**TOML**  
```toml  
[placement]  
mode = "smart"  
```

Jan 20, 2026
1. ### [Use auxiliary Workers alongside full-stack frameworks](https://edgetunnel-b2h.pages.dev/changelog/post/2026-01-20-auxiliary-workers/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
Auxiliary Workers are now fully supported when using full-stack frameworks, such as [React Router](https://edgetunnel-b2h.pages.dev/workers/framework-guides/web-apps/react-router/) and [TanStack Start](https://edgetunnel-b2h.pages.dev/workers/framework-guides/web-apps/tanstack-start/), that integrate with the [Cloudflare Vite plugin](https://edgetunnel-b2h.pages.dev/workers/vite-plugin/reference/api/). They are included alongside the framework's build output in the build output directory. Note that this feature requires Vite 7 or above.  
Auxiliary Workers are additional Workers that can be called via [service bindings](https://edgetunnel-b2h.pages.dev/workers/runtime-apis/bindings/service-bindings/) from your main (entry) Worker. They are defined in the plugin config, as in the example below:

**vite.config.ts**  
```ts  
import { defineConfig } from "vite";  
import { tanstackStart } from "@tanstack/react-start/plugin/vite";  
import { cloudflare } from "@cloudflare/vite-plugin";  
export default defineConfig({  
  plugins: [  
    tanstackStart(),  
    cloudflare({  
      viteEnvironment: { name: "ssr" },  
      auxiliaryWorkers: [{ configPath: "./wrangler.aux.jsonc" }],  
    }),  
  ],  
});  
```  
See the Vite plugin [API docs](https://edgetunnel-b2h.pages.dev/workers/vite-plugin/reference/api/) for more info.

Jan 20, 2026
1. ### [Import SQL files as additional modules by default](https://edgetunnel-b2h.pages.dev/changelog/post/2026-01-20-sql-module-rule/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
The `.sql` file extension is now automatically configured to be importable in your Worker code when using [Wrangler](https://edgetunnel-b2h.pages.dev/workers/wrangler/bundling/#including-non-javascript-modules) or the [Cloudflare Vite plugin](https://edgetunnel-b2h.pages.dev/workers/vite-plugin/reference/non-javascript-modules/). This is particular useful for importing migrations in Durable Objects and means you no longer need to configure custom rules when using [Drizzle ↗](https://orm.drizzle.team/docs/connect-cloudflare-do).  
SQL files are imported as JavaScript strings:

**TypeScript**  
```ts  
// `example` will be a JavaScript string  
import example from "./example.sql";  
```

Jan 13, 2026
1. ### [\`wrangler types\` now generates types for all environments](https://edgetunnel-b2h.pages.dev/changelog/post/2026-01-13-wrangler-types-multi-environment/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
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.  
#### Generating types for a specific environment  
If you want the previous behavior of generating types for only a specific environment, you can use the `--env` flag:  
```sh  
wrangler types --env production  
```  
Learn more about [generating types for your Worker](https://edgetunnel-b2h.pages.dev/workers/wrangler/commands/general/#types) in the Wrangler documentation.

```json
{"@context":"https://schema.org","@type":"BlogPosting","@id":"https://edgetunnel-b2h.pages.dev/changelog/product/workers/3/#page","headline":"Workers Changelog | Cloudflare Docs","url":"https://edgetunnel-b2h.pages.dev/changelog/product/workers/3/","inLanguage":"en","image":"https://edgetunnel-b2h.pages.dev/cf-twitter-card.png","publisher":{"@type":"Organization","name":"Cloudflare","url":"https://www.cloudflare.com/"},"isPartOf":{"@type":"WebSite","@id":"https://edgetunnel-b2h.pages.dev/#website","name":"Cloudflare Docs","url":"https://edgetunnel-b2h.pages.dev/"}}
```