Durable Objects now remain alive for the duration of active outbound connections created via connect() or an outbound WebSocket. Previously, a Durable Object would be evicted after 70-140 seconds of no incoming traffic, even if the object had an open outbound connection, which is a common pattern when streaming responses from a large language model (LLM) over TCP or an outbound WebSocket.
With this change, each active outbound connection prevents eviction. Once all outbound connections close, the standard 70-140 second inactivity window applies before the Durable Object is evicted.
Before: streaming connections were cut off by eviction
After: active outbound connections keep the Durable Object alive
If you are building agents on Cloudflare, this is especially relevant. An agent that streams tokens from an LLM while calling models, or that performs long-running tasks over an outbound connection, now stays alive for the duration of that connection instead of being evicted mid-stream.
Limits:
Each outbound connection keeps the Durable Object alive for a maximum of 15 minutes. After 15 minutes, the connection stops preventing eviction (the connection itself continues operating), and the standard eviction rules resume.
AI agents can now deploy Workers to Cloudflare without first requiring a user to sign up, open a browser-based OAuth flow, click through the dashboard, or create an API token. When an agent tries to deploy without Cloudflare credentials, Wrangler can tell it to rerun with --temporary, then deploy the Worker to a temporary preview account.
To try this with your agent, update to Wrangler 4.102.0 or later, make sure you are logged out (wrangler logout), and then ask your agent to build something and deploy it to Cloudflare. The agent should follow Wrangler's output and deploy using the --temporary flag.
wrangler deploy --temporary
The temporary deployment stays live for 60 minutes. During that window, the agent can verify the Worker, redeploy changes, and return both the live Worker URL and claim URL. Opening the claim URL lets you sign in to or create a Cloudflare account and make the temporary account permanent.
Temporary preview accounts currently support a limited set of products, including Workers, Workers Static Assets, Workers KV, D1, Durable Objects, Hyperdrive, Queues, and SSL/TLS certificates. For supported products, limits, and claim behavior, refer to Claim deployments (temporary accounts).
exec() is now available for Containers. Use this.ctx.container.exec() to start processes inside a running Container, stream standard input and output, inspect exit codes, and signal each process.
Call exec() from a class extending Container, or from another Durable Object through this.ctx.container. The associated Container must already be running.
This example starts the Container when needed, then reads its Node.js version:
src/index.jsjs
import { Container } from "@cloudflare/containers";export class MyContainer extends Container { async readVersion() { if (!this.ctx.container.running) { await this.start(); } const process = await this.ctx.container.exec(["node", "--version"]); const output = await process.output(); const decoder = new TextDecoder(); return { exitCode: output.exitCode, stdout: decoder.decode(output.stdout), stderr: decoder.decode(output.stderr), }; }}
src/index.tsts
import { Container } from "@cloudflare/containers";export class MyContainer extends Container { async readVersion() { if (!this.ctx.container.running) { await this.start(); } const process = await this.ctx.container.exec(["node", "--version"]); const output = await process.output(); const decoder = new TextDecoder(); return { exitCode: output.exitCode, stdout: decoder.decode(output.stdout), stderr: decoder.decode(output.stderr), }; }}
The command array starts an executable directly, without an implicit shell. Invoke a shell explicitly for pipes, redirects, or variable expansion.
One RPC method can coordinate multiple exec() calls in one caller-to-Durable Object round trip. It can also pass byte-oriented ReadableStream input or return streamed output with flow control.
You can create PlanetScale Postgres and MySQL databases from Cloudflare and bill PlanetScale database usage through your Cloudflare account as a pay-as-you-go customer. Cloudflare contract customers will be able to add PlanetScale usage to their contract in July so reach out to your Cloudflare account team if interested.
Create a PlanetScale database from the Cloudflare dashboard to check out globally distributed Workers optimized for regional data access.
PlanetScale databases created from Cloudflare work with Workers through Hyperdrive. Hyperdrive manages database connection pools and query caching, so you can use PlanetScale as a centralized relational database for Workers applications without changing your database drivers, object-relational mapping (ORM) libraries, or SQL tooling.
PlanetScale usage appears on your Cloudflare invoice each billing period as a dollar total at PlanetScale's standard pricing ↗. You can introspect per-database billing usage via PlanetScale's dashboard ↗.
When you create a PlanetScale database from the Cloudflare dashboard, you receive the same PlanetScale developer experience, including development branches, query insights, and Model Context Protocol (MCP) server support for agents.
You can now configure Artifacts namespaces, repos, and tokens directly from the Cloudflare dashboard.
Artifacts is Git-compatible storage that lets you store repos on Cloudflare and interact with them using standard Git workflows.
You can view and create namespaces, which are top-level containers for repos:
You can view, create, fork, and search repos within a namespace:
You can open a repo to view its files and copy its Git remote URL.
You can also provision tokens directly from the dashboard to scope Git access to a single repo, with read tokens for clone, fetch, and pull workflows, or write tokens when a client needs to push changes.
To get started, go to the Cloudflare dashboard ↗ and select Storage & databases > Artifacts.
If you are enrolled in the Artifacts beta, you can use the dashboard to set up Artifacts. If you would like to join the beta, complete the request form ↗.
The latest release of the Agents SDK ↗ makes it easier to build agents that can safely interact with real systems and keep working through interruptions.
Agents can now browse websites through Browser Run, write code against external tools through Code Mode, use client-provided tools when delegating to Think sub-agents, and recover more reliably from deploys, Durable Object evictions, and connection churn.
Safer browser automation
Agents can now use Browser Run through a single durable browser_execute tool. Instead of choosing from a fixed list of actions, the model writes code against the Chrome DevTools Protocol (CDP) and can inspect pages, capture screenshots, read rendered content, debug frontend behavior, and interact with live browser sessions.
Browser sessions can be one-time, reused, or promoted from one-time to persistent during a run. This is useful when an agent needs a human to log in, complete MFA, or approve a sensitive action. The run can pause, keep the same tabs and cookies, and resume after approval.
The browser tools also add Live View URLs, optional session recording, and quick actions such as browser_markdown, browser_extract, browser_links, and browser_scrape for one-shot browsing tasks.
Resumable code execution with approvals
Code Mode now uses createCodemodeRuntime, connectors, and a durable execution log. This lets you give a model one codemode tool instead of a large prompt full of tool definitions. The model can discover the capabilities it needs, write code against typed globals, and reuse saved snippets.
When the code reaches an approval-gated action, the runtime pauses execution and returns a pending approval. After approval, completed calls replay from the durable log, the approved action runs, and the same code continues. This makes it practical to build agents that create issues, update external systems, or perform other side effects without custom pause-and-resume logic for every tool.
Better Think delegation
Think sub-agents can now use client-defined tools over the RPC chat() path. A parent agent can pass tool schemas with clientTools and resolve tool calls through onClientToolCall. This lets delegated agents use caller-provided capabilities without requiring a browser WebSocket.
Think Workflows also improve step.prompt(). A prompt step now runs a full agentic turn before returning structured output, so the agent can call tools before producing the typed result. This makes Workflow steps more useful for durable triage, research, and approval flows.
The unified Think execute tool can also include cdp.* browser capabilities alongside state.* and tools.* when Browser Run is bound.
Voice output device selection
Voice clients can route assistant audio to a specific output device. Use outputDeviceId with useVoiceAgent, or call client.setOutputDevice() from the framework-agnostic client.
We are excited to announce GLM-5.2 on Workers AI, Z.ai's flagship agentic coding model.
@cf/zai-org/glm-5.2 is a text generation model built for agentic coding workflows. With function calling and reasoning support, it can handle long codebases, multi-step planning, and tool-augmented agents.
Key features and use cases:
Agentic coding: Designed for autonomous coding tasks, long-horizon planning, and complex software engineering workflows
Large context window: GLM-5.2 supports up to a 1,048,576 token context window. Workers AI is launching the model with a 262,144 token context window and plans to increase this in the future
Function calling: Build agents that invoke tools and APIs across multiple conversation turns
Reasoning: Tackles complex problem-solving and step-by-step reasoning tasks
Use GLM-5.2 through the Workers AI binding (env.AI.run()), the REST API at /run or /v1/chat/completions, or AI Gateway.
VPC Network bindings now support the connect() Socket API for raw TCP connections to private destinations, in addition to HTTP traffic via fetch().
This means Workers can now open TCP sockets to any private service reachable through the bound Cloudflare Tunnel, Cloudflare Mesh, or Cloudflare WAN on-ramp — Redis, Memcached, MQTT, custom binary protocols, or any other TCP-based service.
You can now create custom trace spans in your Workers code using tracing.enterSpan(). Custom spans appear alongside the automatic platform instrumentation (fetch calls, KV reads, D1 queries, and other platform operations) in your traces and OpenTelemetry exports, with correct parent-child nesting.
The API is available via import { tracing } from "cloudflare:workers" or through the handler context as ctx.tracing:
import { tracing } from "cloudflare:workers";export default { async fetch(request, env, ctx) { return tracing.enterSpan("handleRequest", async (span) => { span.setAttribute("url.path", new URL(request.url).pathname); const data = await env.MY_KV.get("key"); return new Response(data); }); },};
Spans nest automatically based on the JavaScript async context, and are auto-ended when the callback returns or its returned promise settles. The Span object provides setAttribute(key, value) for attaching metadata and an isTraced property to check whether the current request is being sampled.
AI Gateway logs now capture the user agent of the client that made each request, making it easier to identify which SDK, library, or application sent the traffic flowing through your gateway. For example, you can tell apart requests coming from openai-python versus a custom application or a Cloudflare Worker.
The user agent appears alongside the other details in each log entry, and you can filter logs by user agent (equals, does not equal, or contains) in the dashboard.
You can now filter the Metrics tab for a Durable Objects namespace by an individual Durable Object's ID or name in the Cloudflare dashboard. Previously, metrics charts only showed aggregate, namespace-level data, making it difficult to isolate the behavior of a specific object.
Start typing an ID or name into the filter and select a match from the autocomplete dropdown. The autocomplete only shows objects with invocations during the selected time range, so an object that does not appear has not been invoked in that window. This does not necessarily mean the object has been deleted. Every chart on the page updates to reflect only the selected object. This makes it easier to identify and investigate a single Durable Object when debugging a high-traffic object, an error spike, or unexpected storage usage. Clear the filter to return to namespace-level metrics.
Metrics are powered by the GraphQL Analytics API, so standard analytics behavior such as ingestion delay and sampling applies.
Cloudflare's Terraform v5 Provider makes it easy for developers to manage their Cloudflare infrastructure using a configuration as code approach. It releases every 2-3 weeks ↗ to ensure that you can always manage the latest features in the platform. This week, we launched Terraform v5.20.0, which adds 24 new resources, bumps the underlying Go SDK to cloudflare-go v7, and includes a range of bug fixes and state upgraders based on community feedback.
New resources
cloudflare_ai_search_namespace: Manage AI Search namespaces
@cf/moonshotai/kimi-k2.7-code is now available on Workers AI. Kimi K2.7 Code is a code-optimized variant of the Kimi K2 family, built on a Mixture-of-Experts architecture with 1T total parameters and 32B active per token.
Improved coding and agent performance
K2.7 Code delivers meaningful gains over K2.6 on coding and agentic benchmarks:
+21.8% on Kimi Code Bench v2
+11.0% on Program Bench
+31.5% on MLS Bench Lite
Reasoning efficiency
K2.7 Code uses 30% fewer reasoning tokens compared to K2.6, reducing overthinking and lowering inference cost for reasoning-heavy workloads.
Key capabilities
262.1k token context window for retaining full conversation history, tool definitions, and codebases across long-running agent sessions
Long-horizon coding with improved instruction following and higher end-to-end coding task success rates
Vision inputs for processing images alongside text
Thinking mode with configurable reasoning depth via chat_template_kwargs.thinking
Multi-turn tool calling for building agents that invoke tools across multiple conversation turns
Structured outputs with JSON schema support
Differences from Kimi K2.6
If you are migrating from Kimi K2.6, note the following:
K2.7 Code is optimized for coding tasks with improved benchmark performance and reasoning efficiency
Cached input token pricing is $0.19 per M tokens (vs $0.16 for K2.6)
API usage is identical — no parameter changes required
Get started
Use Kimi K2.7 Code through the Workers AI binding (env.AI.run()), the REST API at /ai/run, or the OpenAI-compatible endpoint at /v1/chat/completions. You can also use AI Gateway with any of these endpoints.
Browser Run's /snapshot endpoint now supports a formats parameter that lets you return multiple page formats in a single API call. Previously, /snapshot returned only HTML content and a screenshot. You can now also include Markdown and the accessibility tree in the same response.
These formats are particularly useful for AI agent workflows:
Markdown provides a token-efficient representation of page content that LLMs can process directly, without parsing HTML markup.
The accessibility tree provides a structured representation of a page's elements, including roles, labels, and hierarchy, helping LLMs understand page structure and navigate its contents.
The following example returns a screenshot, Markdown, and the accessibility tree in one call:
Customers can now view the number of Dynamic Workers invoked during their billing period from the Workers overview page in the Cloudflare dashboard.
This count reflects the number of Dynamic Workers that Cloudflare would bill for during the selected billing period. Dynamic Workers usage data only goes back to June 1, 2026.
You can also query this count through the GraphQL Analytics API by using workersInvocationsByOwnerAndScriptGroups and selecting distinctDynamicWorkerCount:
The Flagship API reference is now available. You can use the Cloudflare API to create and update apps, and to create, update, delete, and list feature flags without using the dashboard.
For example, create a new boolean flag with the API:
To create an API token, go to Account API Tokens ↗ in the Cloudflare dashboard and search for Flagship.
The API reference includes endpoints for Flagship apps, flags, changelog entries, and flag evaluation. Agents can also use the Flagship reference in the Cloudflare skill ↗ to create and manage Flagship resources.
Refer to the Flagship documentation to learn more about evaluating feature flags from your applications.
Use the Images binding to upload, list, retrieve, update, and delete images stored in Images directly from your Worker without managing API tokens or making HTTP requests.
The env.IMAGES.hosted namespace supports the following storage and management operations:
Today we are announcing the deprecation of several features from the Sandbox SDK. The SDK has grown and matured substantially since it first launched. As agent workflows have developed, we have shipped many new features and experiments so developers can easily integrate secure, isolated code execution into their workflows.
We want the SDK to continue providing a stable foundation for agentic workflows while we iterate quickly on the codebase. These deprecated features have either been superseded by newer capabilities or seen low adoption. Do not build new work on them. Migrate using the 2026 deprecation migration guide, or move to the Sandbox SDK 1.0 preview when you can.
HTTP and WebSocket transports
In April 2026, we released the new RPC transport and deprecated the WebSocket transport. This setting governs how the sandbox container talks to the Workers ecosystem. The RPC transport removes the limitations of both the HTTP and WebSocket transports. As of this announcement, RPC is the recommended default. HTTP and WebSocket transports are deprecated and will not ship in future Sandbox SDK majors.
To migrate, update the SANDBOX_TRANSPORT variable to rpc or set the transport option when calling getSandbox(). For more information, refer to the transport configuration documentation.
Desktop
The desktop feature ran a full Linux desktop inside the sandbox (display server, desktop environment, and VNC/noVNC) so agents and apps could drive a GUI with screenshots, mouse, and keyboard — the same computer-use shape other sandbox products expose for UI automation. Adoption stayed low, and we removed it in 0.10.2. If you need that capability again, you can build it on top of the sandbox with extensions rather than a built-in sandbox.desktop API.
Expose ports
We recently released support for Cloudflare Tunnel in the Sandbox SDK. This provides a robust API for exposing services running in your sandbox to the public internet. It fixes issues many were facing with local development and deployment to workers.dev domains. To migrate from exposePort() to tunnels, refer to the tunnels API documentation and the expose services guide.
Default sessions
By default, the exec() method in the Sandbox SDK maintains a default session across all calls, so a cd in one call is honored in the next. This convenience helped developers writing exec statements by hand, but confused agents and caused hard-to-trace bugs. As of 0.10.3, we have introduced the enableDefaultSession flag on the getSandbox() interface to turn this off. Default sessions as a concept — and the flag — will be removed in an upcoming release.
We recommend setting enableDefaultSession: false today and using the sandbox.createSession() API when you need the previous behavior.
Other changes
We are also consolidating all APIs that buffer data to support streaming by default. This includes readFile, writeFile, and exec. The stream equivalents will be removed.
We are exploring moving non-core features like the code interpreter, terminal, and git APIs into helpers. These features will retain their existing APIs, so migration should be simple.
If you are moving to Sandbox SDK 1.0 (@next), use the 1.0 preview and Migrate guides instead — or the sandbox-migrate-to-next skill after installing Cloudflare Skills. New projects should prefer sandbox-next on @next.
You can now send emails through Cloudflare Email Service using authenticated SMTP submission on smtp.mx.cloudflare.net:465. SMTP joins the REST API and the Workers binding as a third way to send transactional email — useful for existing applications that already speak SMTP and language-native SMTP libraries (Nodemailer, smtplib, PHPMailer, JavaMail).
Setting
Value
Host
smtp.mx.cloudflare.net
Port
465 (implicit TLS)
AUTH
PLAIN or LOGIN
Username
api_token
Password
A Cloudflare API token (account-owned or user-owned) with Email Sending: Edit
Submissions enter the same delivery pipeline as the REST API and Workers binding: identical limits, automatic DKIM and ARC signing, and shared dashboard logs.
R2 SQL now supports set operations (UNION, INTERSECT, EXCEPT) and SELECT DISTINCT, expanding the range of analytical queries you can run directly on Apache Iceberg ↗ tables in R2 Data Catalog.
Set operations
Combine the results of multiple SELECT statements:
UNION — returns all rows from both queries, removing duplicates
UNION ALL — returns all rows from both queries, including duplicates
INTERSECT — returns only rows that appear in both queries
EXCEPT — returns rows from the first query that do not appear in the second
-- Find zones that had either firewall blocks OR high-risk requestsSELECT zone_id FROM my_namespace.firewall_events WHERE action = 'block'UNIONSELECT zone_id FROM my_namespace.http_requests WHERE risk_score > 0.8
-- Find zones with both firewall blocks AND high trafficSELECT zone_id FROM my_namespace.firewall_events WHERE action = 'block'INTERSECTSELECT zone_id FROM my_namespace.http_requestsGROUP BY zone_idHAVING COUNT(*) > 10000
-- Find enterprise zones that have not been compactedSELECT zone_id FROM my_namespace.zones WHERE plan = 'enterprise'EXCEPTSELECT zone_id FROM my_namespace.compaction_history
RealtimeKit lets you build products where people meet over live audio and video — such as HealthTech, EdTech, proctoring, and other real-time platforms — on Cloudflare's global WebRTC infrastructure.
Post-meeting transcription is now Generally Available, so completed RealtimeKit meetings can automatically produce full transcript files after they end. Those transcripts can also power AI-generated summaries for meeting notes, review workflows, and follow-up tasks after the transcript is available.
Post-meeting transcription is a managed service powered by Workers AI using Whisper Large v3 Turbo. RealtimeKit handles transcription processing and can return transcript and summary files through webhooks or the REST API, so you do not need to run your own transcription infrastructure.
Generate transcripts and summaries
To generate a transcript after a meeting ends, set transcribe_on_end: true when creating a meeting. To also generate an AI summary automatically after the transcript is available, set summarize_on_end: true:
When RealtimeKit finishes processing a meeting, it creates download URLs for the transcript and, if summarize_on_end is set, the summary. You can receive those URLs automatically with webhooks, or fetch them later for a specific session with the REST API.
To receive results as soon as they are ready, configure the meeting.transcript and meeting.summary webhook events:
Workflows now supports saga-style rollbacks, allowing you to add compensating logic to each step.do() in case of downstream failures. If the instance fails, the rollback handlers will execute in reverse step-start order.
This is useful for multi-step operations that touch external systems, such as inventory reservations, payment authorization, ticket creation, or infrastructure provisioning. Instead of writing all cleanup logic in a top-level catch, you can keep each compensating action next to the step it undoes.
Rollback handlers support their own retry and timeout configuration, and Workflows now exposes rollback outcomes in instance status responses. Workflows analytics also emits rollback lifecycle events, making it easier to distinguish a forward execution failure from a rollback failure when debugging production workflows.
AI Gateway now supports spend limits — cost-based budgets that track cumulative dollar spend and block requests when the budget is exceeded. Unlike rate limiting, which caps the number of requests, spend limits track actual cost based on token usage and model pricing.
You can scope limits by model, provider, or custom metadata dimensions. For example, give each user a $200/day budget, cap total gateway spend at $10,000/day, or limit a specific model to $50/day per user. Each rule uses a configurable time window with fixed or sliding enforcement.
Spend limits work with both Unified Billing and BYOK requests for models with known pricing.