Developer Platform Updates & Release Notes

GPT-5.6 Sol is available through AI Gateway, and for a limited time you can use it at 50% off. If you are already using AI Gateway, point to the openai/gpt-5.6-sol model and the discounted pricing applies automatically — no promo code needed.

The promotion is available for Unified Billing users only (not Bring Your Own Keys). Load credits onto AI Gateway and start sending requests to openai/gpt-5.6-sol.

Discounted pricing during the promotion:

Usage Promotional price Standard price Input $2.50 per 1M tokens $5 per 1M tokens Output $15 per 1M tokens $30 per 1M tokens Cache read $0.25 per 1M tokens $0.50 per 1M tokens

The promotion runs through September 18, 2026. After that date, GPT-5.6 Sol requests return to standard pricing.

For more details, refer to the Unified Billing documentation and the GPT-5.6 Sol model page.

Original source

R2 now supports a us jurisdiction, which guarantees that bucket data is stored and processed within the United States. Use this jurisdiction when you need explicit US data residency guarantees.

Use the jurisdiction-specific S3 endpoint to create and access buckets in the us jurisdiction:

https://<ACCOUNT_ID>.us.r2.cloudflarestorage.com

To access a bucket in the us jurisdiction from Workers, set jurisdiction in your R2 binding:

{
  "r2_buckets": [
    {
      "binding": "MY_BUCKET",
      "bucket_name": "<YOUR_BUCKET_NAME>",
      "jurisdiction": "us"
    }
  ]
}

[[r2_buckets]]
binding = "MY_BUCKET"
bucket_name = "<YOUR_BUCKET_NAME>"
jurisdiction = "us"

Once an R2 bucket is created, its jurisdiction cannot be changed.

For setup instructions and the full list of supported jurisdictions, refer to R2 data location.

Original source

@cf/qwen/qwen3.8-27b is now available on Workers AI.

Qwen 3.8 27B is a 27-billion-parameter instruction-tuned vision language model from Alibaba's Qwen family. It processes images and text together, with reasoning and function calling for agentic workflows.

Key capabilities:

• Vision: Accept image and text inputs and generate text responses.
• Reasoning: Support thinking mode for complex, step-by-step problem-solving.
• Function calling: Build agents that invoke tools and APIs across multiple conversation turns.
• 262,144 token context window: Retain long conversations and multimodal inputs across extended agent sessions.

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

For more information, refer to the Qwen 3.8 27B model page and pricing.

Original source

@cf/deepseek-ai/deepseek-v4-pro-0813 and @cf/deepseek-ai/deepseek-v4-flash-0731 are now available on Workers AI.

DeepSeek V4 Flash and DeepSeek V4 Pro are the first Workers AI models with a full one million (1,048,576) token context window. Use them for long-horizon agentic workflows, large codebases, and multi-step reasoning that exceed the context limits of every other model hosted on the platform.

DeepSeek V4 Flash is the faster, lower-cost sibling. This release supersedes the preview version with substantially enhanced agentic capabilities.

Key capabilities

• Reasoning: Both models support thinking mode for complex, step-by-step problem-solving.
• Function calling: Build agents that invoke tools and APIs across multiple conversation turns.
• Long context: Both models support a full 1,048,576 token context window.

Both models require the Workers Paid plan or prepaid AI Gateway credits.

Use these models through the Workers AI binding (env.AI.run()), the REST API, the OpenAI-compatible endpoint, or AI Gateway.

For more information, refer to the DeepSeek V4 Pro model page, the DeepSeek V4 Flash model page, and pricing.

Original source

You now have two new ways to protect your Workers with Cloudflare Access.

Protect an application across all its domains at once

Until now, if a Worker was reachable on a route, a Custom Domain, and a workers.dev URL, you had to manually add each one to an Access application and keep the list in sync whenever routes or domains changed.

Now, Access attaches the policy to the Worker itself, so every associated domain and preview URL stays protected even when its routes or domains change.

Protect all new and existing Workers by default

Make all Workers private by default, so every existing and newly created Worker requires sign-in before anyone can reach it.

If a specific Worker should remain publicly accessible, add a Worker-level bypass to exempt it.

Whether you protect a single application or all Workers at once, you can choose whether to protect preview deployments only or both previews and production, and control who can sign in by Cloudflare account membership, email address, or email domain.

For more advanced policy options, edit the policy in Zero Trust ↗.

View all of your Worker Access policies

You can view and manage all of your Access policies in the Access tab of the Workers & Pages section in the dashboard.

See who is accessing your Worker

When Access is enabled on your Worker, every authenticated request includes ctx.access. Call ctx.access.getIdentity() to get the user's email, name, and groups — no manual JWT validation required.

export default {
async fetch(request, env, ctx) {
if (!ctx.access) {
return new Response("Access did not run", { status: 401 });
}
const identity = await ctx.access.getIdentity();
return Response.json({ aud: ctx.access.aud, email: identity?.email });
},
};

Test Access locally

You can now test Cloudflare Access locally with wrangler dev. Add a dev block to your wrangler.jsonc:

{
"access": {
"dev": {
"aud": "my-app",
"identity": { "email": "[email protected]" }
}
}
}

Your Worker will receive this identity through ctx.access and ctx.access.getIdentity(), letting you test authenticated and unauthenticated flows without deploying. Remove the dev block to simulate unauthenticated requests.

API and programmatic access

You can also set up these policies through the Workers API instead of the dashboard.

Original source

Artifacts now supports jurisdictions, allowing you to select the European Union or the United States as the only location where repo data is stored and processed.

Select a jurisdiction when you create a namespace. Every repo in that namespace automatically uses the selected jurisdiction.

curl --request POST \
"https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/artifacts/namespaces" \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
--header "Content-Type: application/json" \
--data '{
"namespace": "my-eu-namespace",
"jurisdiction": "eu"
}'

Jurisdictions cannot be changed after namespace creation. If you omit the jurisdiction, Artifacts creates an unrestricted namespace.

For supported jurisdictions and usage details, refer to Data localization.

Original source

Cloudflare Realtime SFU is a WebRTC selective forwarding unit that runs on Cloudflare's global network. It forwards audio, video, and application data between WebRTC clients without requiring you to manage SFU infrastructure or regions.

DataChannels are WebRTC channels for application messages. A client publishes a named DataChannel to Realtime SFU, and the SFU forwards its messages to every client that subscribes to that channel. Use DataChannels for low-latency payloads such as chat messages, game state, sensor updates, and control events.

What changed

Realtime SFU DataChannels now support unordered and partially reliable delivery. DataChannels remain reliable and ordered by default, so existing channels keep their current behavior.

With ordered delivery, a delayed message can block later messages. For game state or sensor updates, recent data may be more useful than recovering an older message. Unordered delivery lets later messages proceed, while partial reliability limits retransmission attempts or delivery time.

Choose delivery behavior

Delivery settings answer two questions: whether newer messages can bypass a delayed message, and when the transport should stop retrying delivery.

Choose the policy that matches how long your payload remains useful:

Goal Settings Use when Reliable, ordered delivery (default) Omit ordered, maxRetransmits, and maxPacketLifeTime Messages remain useful and must arrive in order Reliable, unordered delivery Set ordered: false; omit both retry fields Messages remain useful, but later messages should not wait for earlier messages No retries or ordering Set ordered: false and maxRetransmits: 0 The application tolerates message loss and discards out-of-date updates Limited retries Set maxRetransmits: <COUNT> Brief recovery is useful, but repeated retries are not Time-bounded delivery Set maxPacketLifeTime: <MILLISECONDS> A message loses value after a known time window

ordered controls ordering independently from retries. maxRetransmits and maxPacketLifeTime are alternative retry budgets, so set at most one for each channel. Omit both for reliable delivery, whether ordered or unordered.

Apply the policy end to end

Realtime DataChannels use negotiated IDs, so browsers do not receive delivery settings from the remote peer. Apply the same settings when the publisher creates the local channel, each subscriber pulls the remote channel, and each client calls createDataChannel().

The following example configures unordered delivery with no retransmissions. It begins after you establish a DataChannel transport on both sessions and complete any required SDP exchange. Run the API requests from your backend with APP_ID, APP_TOKEN, PUBLISHER_SESSION_ID, and SUBSCRIBER_SESSION_ID set in your environment.

On the publisher session, create the local DataChannel:

curl --request POST \
--url "https://rtc.live.cloudflare.com/v1/apps/$APP_ID/sessions/$PUBLISHER_SESSION_ID/datachannels/new" \
--header "Authorization: Bearer $APP_TOKEN" \
--header "Content-Type: application/json" \
--data @- <<EOF
{
  "dataChannels": [
    {
      "location": "local",
      "dataChannelName": "player-state",
      "ordered": false,
      "maxRetransmits": 0
    }
  ]
}
EOF

On each subscriber session, pull the remote DataChannel with the same delivery settings:

curl --request POST \
--url "https://rtc.live.cloudflare.com/v1/apps/$APP_ID/sessions/$SUBSCRIBER_SESSION_ID/datachannels/new" \
--header "Authorization: Bearer $APP_TOKEN" \
--header "Content-Type: application/json" \
--data @- <<EOF
{
  "dataChannels": [
    {
      "location": "remote",
      "sessionId": "$PUBLISHER_SESSION_ID",
      "dataChannelName": "player-state",
      "ordered": false,
      "maxRetransmits": 0
    }
  ]
}
EOF

In the publisher and subscriber clients, create the negotiated browser DataChannel with the same settings. In this example, pc is the active RTCPeerConnection, and channelId is the ID returned by the corresponding API request:

const channel = pc.createDataChannel("player-state", {
  negotiated: true,
  id: channelId,
  ordered: false,
  maxRetransmits: 0,
});

Related documentation

• Realtime SFU overview
• DataChannels
• Connection API

Original source

Support for MySQL in Hyperdrive is now generally available. You can connect to any MySQL database from your Workers using Hyperdrive.

Hyperdrive makes your regional, MySQL databases fast when connecting from Cloudflare Workers. It eliminates unnecessary network roundtrips during connection setup, pools database connections globally, and can cache query results to provide the fastest possible response times.

You can connect using your existing drivers, ORMs, and query builders with Hyperdrive's secure credentials, with no code changes required. MySQL support is available at the same pricing as Postgres.

import { createConnection } from "mysql2/promise";

export default {
  async fetch(request, env, ctx) {
    const connection = await createConnection({
      host: env.HYPERDRIVE.host,
      user: env.HYPERDRIVE.user,
      password: env.HYPERDRIVE.password,
      database: env.HYPERDRIVE.database,
      port: env.HYPERDRIVE.port,
      disableEval: true, // Required for Workers compatibility
    });
    const [results, fields] = await connection.query("SHOW tables;");
    ctx.waitUntil(connection.end());
    return new Response(JSON.stringify({ results, fields }), {
      headers: {
        "Content-Type": "application/json",
        "Access-Control-Allow-Origin": "*",
      },
    });
  },
};

import { createConnection } from "mysql2/promise";

export interface Env {
  HYPERDRIVE: Hyperdrive;
}

export default {
  async fetch(request, env, ctx): Promise<Response> {
    const connection = await createConnection({
      host: env.HYPERDRIVE.host,
      user: env.HYPERDRIVE.user,
      password: env.HYPERDRIVE.password,
      database: env.HYPERDRIVE.database,
      port: env.HYPERDRIVE.port,
      disableEval: true, // Required for Workers compatibility
    });
    const [results, fields] = await connection.query("SHOW tables;");
    ctx.waitUntil(connection.end());
    return new Response(JSON.stringify({ results, fields }), {
      headers: {
        "Content-Type": "application/json",
        "Access-Control-Allow-Origin": "*",
      },
    });
  },
} satisfies ExportedHandler<Env>;

Learn more about how Hyperdrive works and get started building Workers that connect to MySQL with Hyperdrive.

Original source

Unified entrypoints and observability

Workers AI and AI Gateway now provide a unified path for accessing models and managing inference traffic. Use the same AI binding and REST API to call models hosted on Workers AI or by supported third-party providers, with AI Gateway providing observability, logging, caching, security, and billing controls.

The AI binding supports both Workers AI and third-party models through env.AI.run(). The REST API provides shared /ai/ endpoints with Cloudflare authentication across providers.

Route a Workers AI request through AI Gateway by specifying a gateway ID. Use default to automatically create a gateway on the first authenticated request, or specify an existing gateway to separate applications and workloads:

const response = await env.AI.run(
"@cf/zai-org/glm-5.2",
{
messages: [{ role: "user", content: "What is the capital of France?" }],
},
{
gateway: { id: "default" },
},
);
const response = await env.AI.run(
"@cf/zai-org/glm-5.2",
{
messages: [{ role: "user", content: "What is the capital of France?" }],
},
{
gateway: { id: "default" },
},
);

Requests routed through AI Gateway can be logged and included in analytics for request volume, errors, latency, token usage, and costs. You can also configure controls such as caching, rate limiting, and request retries on the gateway.

Unified billing and higher rate limits

You can now use prepaid AI Gateway credits to pay for Workers AI inference. This provides one credit balance for Workers AI and supported third-party model providers. To use credits for Workers AI, set the gateway's Workers AI billing setting to Unified billing. Workers AI requests routed through that gateway deduct from your credit balance in real time.

Prepaid credits also provide access to the following Workers AI frontier models without requiring the Workers Paid plan. Each frontier Workers AI model has a rate limit of 50 requests per minute per account, per model when billed with AI Gateway credits, compared to 20 requests per minute through standard Workers AI billing:

• @cf/moonshotai/kimi-k2.6
• @cf/moonshotai/kimi-k2.7-code
• @cf/zai-org/glm-5.2

These limits are designed for typical agentic and coding workloads, where requests to frontier models can take longer to complete.

For details, refer to Workers AI limits, Workers AI pricing, Unified Billing, and the AI Gateway model catalog.

Original source

Serve search from your own domain

AI Search gets you from a data source to a working search endpoint quickly. This release adds what you need to put that endpoint in front of real users: your own domain, authentication, and one endpoint across several instances. It also adds crawling for sites without a complete sitemap, so your index covers everything you want it to find.

Each of the following is a new option. The previous behavior is still the default, so nothing changes until you change it.

A public endpoint is a URL that a site or app can query directly, with no authentication in front of it. By default that URL is a generated hostname on search.ai.cloudflare.com. You can now serve the same endpoint from a custom domain, a hostname in a zone that you own:

https://search.example.com/search

Restrict who can query your content

Once your endpoint is on your own domain, you can put Cloudflare Access in front of it. For example, you usually want to give /mcp to specific agents rather than to anyone who finds the URL. Agents authenticate with an Access service token, and people who open the endpoint in a browser sign in through your identity provider.

Search several instances from one URL

A namespace can expose its own public endpoint with /search, /chat/completions, and /mcp paths that fan out across the instances you choose:

curl https://ns-<NAMESPACE_ENDPOINT_ID>.search.ai.cloudflare.com/search \
--header "Content-Type: application/json" \
--data '{
"messages": [{ "content": "How do I configure AI Search?", "role": "user" }],
"ai_search_options": { "instance_ids": ["docs", "support"] }
}'

Index your sites without a sitemap

Website data sources support a new discover parse type. It starts at the source URL and collects pages from both your sitemaps and the links it finds while crawling:

curl -X POST "https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/ai-search/instances" \
-H "Authorization: Bearer <API_TOKEN>" \
-H "Content-Type: application/json" \
-d '{
"id": "my-ai-search",
"type": "web-crawler",
"source": "example.com",
"source_params": {
"web_crawler": {
"parse_type": "discover",
"discover_options": { "source": "links", "limit": 5000, "depth": 3 }
}
}
}'

To learn more, refer to the AI Search documentation.

Original source

Kitesurf is Cloudflare's new stateless, highly scalable browser that runs entirely on top of Workers and is designed for AI agents. It is available for free while in beta.

Compared to Chromium, Kitesurf uses 3–7× less CPU and memory for common agentic tasks like screenshots and HTML extraction, so you can run more sessions and scale better for bursty, AI-driven workloads.

Your existing clients already work. To opt in, add the browser=kitesurf parameter to any Browser Run CDP or Quick Action endpoint:

curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/screenshot?browser=kitesurf' \
-H 'Authorization: Bearer <API_TOKEN>' \
-H 'Content-Type: application/json' \
-d '{
"url": "https://example.com"
}' \
--output "screenshot.png"

You can also explore Kitesurf without writing any code in the public playground ↗.

For more information, refer to the Kitesurf documentation and the blog announcement ↗.

Original source

AI Gateway now includes User Insights, a dashboard that gives you two things at once: clear visibility into how much your organization spends on AI, and a security signal that surfaces users whose usage suddenly looks abnormal. It works on the traffic already flowing through your gateway, so there is no additional setup.

On the spend side, User Insights shows organization-wide totals for cost, requests, tokens, and adoption, and lets you drill into an individual user to see their spend, top models and providers, cache hit rate, and more. To attribute usage to individual users, add a user identifier with custom metadata or put your gateway behind Cloudflare Access.

On the security side, User Insights baselines each user's normal usage from their 95th percentile (p95) session cost over the last 30 days, then flags sessions that exceed both that baseline and an organization-level threshold. A sudden jump above a user's own pattern is often the first sign of a compromised credential or a misbehaving agent, so you can investigate before it shows up on your bill.

User Insights is available to all AI Gateway customers at no additional cost.

Original source

AI Gateway now integrates with Cloudflare Access, giving you two new capabilities:

• Protect your gateway endpoint. Put your AI Gateway behind Access so you can set policies that control who is allowed to call a specific gateway's endpoint.
• Identity-aware controls. When traffic reaches AI Gateway through an Access-protected custom domain, AI Gateway can use the authenticated user's Access identity in logs, analytics, routing, and spend controls.

With identity-aware controls, you can set spend limits by authenticated user, control which gateways different users can access, filter logs by user, and build policies without passing user IDs from the client application. AI Gateway adds the verified Access user ID to request metadata as cf.user_id.

For setup instructions, refer to Cloudflare Access.

Original source

wrangler login now supports the OAuth 2.0 Device Authorization Grant ↗. Pass --device to authenticate without starting a temporary callback server on localhost:8976:

npx wrangler login --device

Wrangler prints a verification URL and a short user code, opens the URL in your default browser with the code already filled in, and polls Cloudflare for an access token while you approve the request:

⛅️ wrangler 4.119.0
────────────────────
Attempting to login via OAuth Device Authorization Grant...
To authorize Wrangler, please visit:
https://dash.cloudflare.com/oauth2/device
and enter the code:
WDJB-MJHT
You have 5 minutes to approve this request.
Opening a link in your default browser: https://dash.cloudflare.com/oauth2/device?user_code=WDJB-MJHT
Successfully logged in.

The default login flow needs your browser to reach localhost:8976, which is not always possible from containers, remote SSH sessions, or GitHub Codespaces. Previously these environments required forwarding ports or fetching the callback URL with curl from a second terminal session. Because --device has no callback server, those workarounds are no longer necessary.

Since the plain verification URL and user code are both printed to the terminal, you can also approve the request from a phone or another machine. Pass --browser=false to stop Wrangler from opening a browser at all.

Available in Wrangler version 4.119.0 or later. For more information, refer to wrangler login.

Original source