cloudflareMay 1, 2026

Introducing Dynamic Workflows: durable execution that follows the tenant (opens in new tab)

Dynamic Workflows extends Cloudflare’s durable execution system to multi-tenant and dynamically generated applications. While Dynamic Workers provide isolated runtime compute, Durable Object Facets provide tenant-specific storage, and Artifacts provide versioned source control, Dynamic Workflows lets each tenant supply its own long-running workflow code. The result is durable execution that can resume the correct tenant’s workflow after failures, hibernation, or delays of days. ## The Gap Between Durable and Dynamic Execution - Cloudflare Workflows turns a `run(event, step)` function into a durable program. - Workflow steps can: - Survive isolate recycling and failures - Sleep for hours or days - Wait for external events - Resume from the exact point where execution stopped - Workflows V2 supports up to 50,000 concurrent instances and 300 new instances per second per account. - Traditional Workflows assume the workflow class is included in the deployment and statically configured in `wrangler.jsonc`. - That model breaks for: - Multi-tenant SaaS platforms - AI-generated tenant applications - Repository-specific CI/CD pipelines - Agents that create their own durable plans - In these systems, workflow code varies by tenant, agent, repository, or request, so a single statically bound class is insufficient. ## Dynamic Workflows - `@cloudflare/dynamic-workflows` is a roughly 300-line TypeScript library. - It introduces a Worker Loader that: - Loads each tenant’s code dynamically - Routes workflow creation to the appropriate tenant - Ensures later workflow execution returns to that tenant’s code - The Loader creates a dynamic Worker with: - A tenant-specific module - A `TenantWorkflow` entrypoint - A wrapped `WORKFLOWS` binding - The dynamic entrypoint is registered as the workflow class in `wrangler.jsonc`. - Tenant code remains ordinary Cloudflare Workflows code and does not need to know it is being dynamically dispatched. ## Tenant Workflow Behavior - Tenants can use the normal Workflow APIs, including: - `env.WORKFLOWS.create(...)` - Workflow IDs and `.status()` - `.pause()` - Retries and durable steps - `step.sleep('24 hours')` - `step.waitForEvent()` - A tenant can define a standard `WorkflowEntrypoint` with a `run(event, step)` method. - The library’s primary responsibility is preserving the association between a workflow instance and the tenant implementation when the workflow resumes later. ## Three-Layer Execution Model - Dynamic Workflows consists of three layers: - The Cloudflare Workflows engine - The platform’s Worker Loader - The tenant’s dynamically loaded Worker code - A request first enters the Loader, which identifies the tenant and routes execution to its dynamic code. - The workflow engine then persists the workflow state and later invokes `run(event, step)`. - The Loader resolves the correct tenant implementation when execution resumes, even after delays or failures. Dynamic Workflows provides the missing durable-execution counterpart to Cloudflare’s dynamic compute, storage, and source-control primitives. It is particularly suited to platforms where customers or agents generate workflow code at runtime while still requiring standard durable guarantees.

database-designtypescriptcloudflare-workerssqlite+4

cloudflareApr 30, 2026

Agents can now create Cloudflare accounts, buy domains, and deploy (opens in new tab)

Agents can now take an application from development to production by creating Cloudflare accounts, obtaining API tokens, purchasing domains, and deploying code. Cloudflare’s integration with Stripe Projects removes most manual setup while keeping humans involved for permissions, terms acceptance, and payment approvals. The underlying protocol combines service discovery, authorization, and tokenized payments so agents can provision infrastructure on a user’s behalf. ## Zero-to-production deployment - Users install the Stripe CLI, authenticate, and run: ```bash stripe projects init ``` - An agent can then build an application and deploy it to a new domain. - If no Cloudflare account exists, one is provisioned automatically. - If an account already exists, the user authorizes access through OAuth. - The agent can: - Create a Cloudflare account - Obtain an API token - Register a domain - Deploy the application to production - Humans are prompted only when approval, terms acceptance, or payment setup is required. ## The protocol: discovery, authorization, and payment - **Discovery:** Agents query a catalog of available provider services and select the resources needed for the user’s request. - **Authorization:** The orchestrating platform verifies the user’s identity and enables providers to create accounts, connect existing accounts, and issue credentials securely. - **Payment:** Tokenized payment credentials let providers charge the user without exposing raw card details to the agent. - The approach builds on OAuth, OIDC, and payment-tokenization standards. ## Service discovery through a catalog - Agents can inspect available services with: ```bash stripe projects catalog ``` - They can select Cloudflare Registrar with: ```bash stripe projects add cloudflare/registrar:domain ``` - Providers expose service catalogs through REST APIs returning JSON. - This gives agents the context to choose appropriate products without requiring users to know which provider offers them. ## Automatic account creation and authorization - Stripe acts as the identity provider and attests to the user’s identity. - Cloudflare creates a new account automatically when the user has none. - Credentials are securely stored by the Stripe Projects CLI but made available to the agent for authenticated Cloudflare API requests. - Existing Cloudflare users authorize the integration through a conventional OAuth flow. ## Controlled agent spending - Agents never receive the user’s raw credit card information. - Stripe supplies Cloudflare with a payment token for subscriptions and purchases. - Spending is initially capped at $100 per month per provider. - Users can raise the limit and configure Cloudflare Budget Alerts as needed. ## Broader platform integration - The protocol is not limited to Stripe Projects. - Any platform with signed-in users can act as the orchestrator and integrate with Cloudflare. - This enables coding-agent platforms to let users deploy directly to production without requiring separate dashboard logins, token copying, or manual account setup. - Cloudflare is also enhancing the experience through its Code Mode MCP server and Agent Skills. Cloudflare and Stripe’s integration makes infrastructure provisioning an agent-driven workflow while retaining safeguards around identity, consent, and spending. For platforms building coding agents, adopting the protocol could provide a frictionless path from generated code to a live, paid production deployment.

database-designcloudflarestripeoauth+4

cloudflareApr 22, 2026

Making Rust Workers reliable: panic and abort recovery in wasm‑bindgen (opens in new tab)

Rust Workers historically treated Rust panics and aborts as fatal WebAssembly failures, potentially poisoning a Worker instance and causing unrelated requests to fail. Cloudflare’s latest work upstreamed into `wasm-bindgen` adds comprehensive recovery: `panic=unwind` preserves application state after recoverable panics, while abort handling ensures Rust code cannot run again after an unrecoverable abort. ## Initial Recovery Mitigations - Early Rust Workers used a custom panic handler to track failures and reinitialize the entire application before serving later requests. - JavaScript bindings were wrapped with Proxy-based indirection so every Rust entry point passed through recovery logic. - Generated bindings were modified to reinitialize the WebAssembly module after failures. - This approach shipped by default in `workers-rs` 0.6 and prevented persistent failure modes, but reinitialization could discard in-memory state. ## Panic Unwinding with WebAssembly Exception Handling - WebAssembly’s `wasm32-unknown-unknown` target traditionally defaults to `panic=abort`, turning panics into traps and `WebAssembly.RuntimeError` exceptions. - With WebAssembly Exception Handling support, Rust can be compiled using: ```bash RUSTFLAGS='-Cpanic=unwind' cargo build -Zbuild-std ``` - Unwinding allows Rust destructors to run, preserving state and cleaning up resources instead of terminating the entire instance. - `std::panic::catch_unwind` can translate a Rust panic into a recoverable `Result`. ## Changes to wasm-bindgen - The Walrus WebAssembly parser was updated to understand `try`/`catch` exception-handling instructions. - The descriptor interpreter was updated to evaluate code containing exception blocks. - Generated exports now catch Rust panics at the Rust–JavaScript boundary and expose them as `PanicError` exceptions. - Async exports reject their JavaScript promises with `PanicError`. - Exported functions use `extern "C-unwind"` so unwinding is explicitly permitted across the boundary. - A `MaybeUnwindSafe` trait checks `UnwindSafe` requirements only when compiling with `panic=unwind`. - For closures that cannot safely unwind, `Closure::new_aborting` provides an explicit alternative that terminates on panic rather than risking invalid state. ## Results of `panic=unwind` - Panics in exported Rust functions are caught by `wasm-bindgen`. - JavaScript receives a `PanicError`. - Async calls reject their promises instead of poisoning the Worker. - Rust destructors execute correctly. - The WebAssembly instance remains valid and reusable. - Stateful applications, including Durable Objects, can recover without losing all in-memory state. ## Abort Recovery - `panic=unwind` cannot handle aborts such as out-of-memory failures because aborts do not unwind. - The remaining recovery mechanism prevents Rust code from being re-entered after an abort, avoiding repeated execution in a corrupted WebAssembly state. - Together, unwinding and abort recovery prevent one failed request from poisoning sibling or future requests. The recommended approach is to use the latest `wasm-bindgen` and Rust Workers releases, enabling `panic=unwind` where state preservation matters while using explicit aborting closures when unwind safety cannot be guaranteed.

database-designrustwebassemblywasm-bindgen+2

cloudflareApr 20, 2026

The AI engineering stack we built internally — on the platform we ship (opens in new tab)

Cloudflare built an internal AI engineering stack that now supports AI coding tools for 93% of its R&D organization. The system combines centralized authentication and model routing with internal knowledge, automated review, and sandboxed agent execution. Cloudflare argues that building these capabilities on its own platform improved security, visibility, cost control, and developer velocity, while also serving as a proving ground for products it ships publicly. ## Adoption and Impact - Over the previous 30 days: - 3,683 employees used AI coding tools, representing 60% of the company and 93% of R&D. - AI tools generated 47.95 million requests. - 295 teams used agentic AI tools or coding assistants. - AI Gateway handled 20.18 million requests and routed 241.37 billion tokens. - Workers AI processed 51.83 billion tokens. - The four-week rolling average of merge requests increased from roughly 5,600 per week to more than 8,700. - The week of March 23 reached 10,952 merge requests, nearly twice the Q4 baseline. - Cloudflare’s initial focus was MCP servers, but the effort expanded to standards, code review, onboarding, and propagating changes across thousands of repositories. ## Architecture at a Glance Cloudflare organized the stack into three layers: - **Platform layer:** Authentication, model routing, inference, MCP access, and code execution. - **Knowledge layer:** System context and repository guidance through Backstage and `AGENTS.md`. - **Enforcement layer:** Automated quality controls using AI Code Reviewer and the Engineering Codex. The stack uses Cloudflare products including: - **Cloudflare Access** for zero-trust authentication. - **AI Gateway** for centralized LLM routing, cost tracking, bring-your-own-key support, and zero-data-retention controls. - **Workers AI** for open-weight model inference. - **Workers and Access** for an MCP Server Portal with single OAuth. - **Dynamic Workers** for sandboxed agent-generated code execution. - **Agents SDK and Durable Objects** for stateful, long-running agent sessions. - **Sandbox SDK** for isolated cloning, building, and testing environments. - **Workflows** for durable, multi-step processes. - **Backstage** for a 16,000-plus-entity knowledge graph. ## Centralized Authentication and AI Routing - Cloudflare Access authenticates users and enforces zero-trust policies. - Every LLM request passes through AI Gateway, providing a single control point for: - Provider credentials - Usage and cost attribution - Model selection - Data-retention policies - Provider permissions - In the past month, frontier providers handled 91.16% of requests, while Workers AI handled 8.84%. - Cloudflare routes requests through a proxy Worker rather than connecting clients directly to AI Gateway. - The proxy enables later additions such as per-user attribution, model catalogs, permission enforcement, and support for new coding tools without changing client configurations. ## Workers AI and Open-Weight Models - Workers AI runs open-source models on GPUs distributed across Cloudflare’s global network. - Keeping inference on the same network as Workers, Durable Objects, and storage reduces latency, network failures, and cross-cloud configuration. - Kimi K2.5, with a 256,000-token context window, tool calling, and structured outputs, processes more than 7 billion tokens per day for a Cloudflare security agent. - Cloudflare estimates that running this workload on Workers AI is 77% cheaper than using a mid-tier proprietary model. - Workers AI is also used for: - Documentation review in CI - Generating `AGENTS.md` files - Lightweight inference where latency matters more than maximum model capability - Cloudflare expects open-source models to handle an increasing proportion of its internal workloads. ## One-Command Client Configuration - Engineers begin setup with: ```bash opencode auth login https://opencode.internal.domain ``` - The command uses an OpenCode discovery endpoint at: ```text https://opencode.internal.domain/.well-known/opencode ``` - The Worker-hosted endpoint provides authentication and configuration information. - This mechanism is designed to configure providers, models, MCP servers, agents, commands, and permissions without requiring engineers to edit configuration files manually. ## Overall Recommendation Cloudflare’s experience suggests that organizations adopting AI coding tools should build a centralized control plane early: authenticate users consistently, route model traffic through one managed gateway, maintain shared system knowledge, and enforce quality through automated review and isolated execution. Using the same production platform for internal tooling can also expose product gaps and accelerate improvements to the platform itself.

database-designci-cdopen-sourcepostgresql+4

cloudflareApr 20, 2026

Orchestrating AI Code Review at scale (opens in new tab)

Cloudflare built a CI-native AI code review system to reduce review bottlenecks without overwhelming engineers with noisy or generic model feedback. Instead of using one large prompt, it orchestrates up to seven specialized agents for areas such as security, performance, compliance, and documentation, then uses a coordinator to deduplicate and assess findings. The system now reviews tens of thousands of merge requests, approving clean changes and blocking serious bugs or vulnerabilities. ## Why Naive AI Review Wasn’t Enough - Traditional code review can leave merge requests waiting for hours and creates repeated context switching. - Commercial AI review tools provided useful functionality but lacked the flexibility and customization required across Cloudflare’s organization. - A basic “send the Git diff to an LLM” approach produced: - Vague recommendations - Hallucinated syntax errors - Repetitive advice such as adding error handling where it already existed - Complex codebases required specialized analysis rather than generic summarization. ## Specialized Agents and Coordination - The system launches up to seven focused reviewers covering: - Security - Performance - Code quality - Documentation - Release management - Internal Engineering Codex compliance - A coordinator agent: - Deduplicates overlapping findings - Evaluates the actual severity of issues - Produces one structured review comment - The system can actively block merges when it detects serious defects or security vulnerabilities. ## Plugin-Based Architecture - The platform uses composable plugins so it can support different: - Version-control systems - AI providers - Internal standards - Repository-specific requirements - Each plugin implements a `ReviewPlugin` interface with three lifecycle phases: - `bootstrap`: Runs concurrently and is non-fatal. - `configure`: Runs sequentially and is fatal if essential configuration fails. - `postConfigure`: Handles asynchronous work after configuration assembly. - Through `ConfigureContext`, plugins can: - Register agents and AI providers - Set environment variables - Inject prompt sections - Configure agent permissions - Plugins contribute through the context API rather than accessing the final configuration directly. - The core assembler combines these contributions into `opencode.json`. - This separation prevents unrelated components from becoming tightly coupled; for example, GitLab logic does not need to understand Cloudflare AI Gateway settings. ## Plugin Responsibilities - `@opencode-reviewer/gitlab` - Provides GitLab merge request data and a comment server. - `@opencode-reviewer/cloudflare` - Configures AI Gateway model tiers and fallback chains. - `@opencode-reviewer/codex` - Checks compliance with internal engineering RFCs. - `@opencode-reviewer/braintrust` - Adds distributed tracing and observability. - `@opencode-reviewer/agents-md` - Verifies that repository `AGENTS.md` instructions are current. - `@opencode-reviewer/reviewer-config` - Retrieves remote model overrides for individual reviewers. - `@opencode-reviewer/telemetry` - Tracks reviews asynchronously. ## Why OpenCode - Cloudflare already used OpenCode extensively and understood its behavior. - Its open-source implementation allows engineers to: - Investigate problems directly - Contribute fixes upstream - Extend the system through its SDK - Cloudflare engineers had contributed more than 45 upstream pull requests at the time of writing. - Its server-first design was especially important: - Review sessions can be created programmatically. - Prompts can be sent through an SDK. - Multiple concurrent sessions can be managed without scraping or wrapping a CLI interface. ## Coordinator Process - The coordinator runs OpenCode as a child process using `Bun.spawn`. - Its prompt is passed through `stdin` rather than a command-line argument. - This avoids Linux’s `ARG_MAX` limit, which previously caused `E2BIG` failures for unusually large merge requests containing extensive descriptions or logs. - OpenCode runs with `--format json`, emitting JSONL events through standard output. - This event-based interface allows the orchestration layer to collect and process results from concurrent reviewer sessions. A practical takeaway is to treat AI review as an orchestrated CI system rather than a single LLM prompt. Specialized agents, strict plugin boundaries, structured outputs, and observability are essential for making automated review reliable enough to influence merge decisions at organizational scale.

database-designllmgitlabci-cd+4

cloudflareApr 17, 2026

Introducing the Agent Readiness score. Check to see if your site is agent-ready (opens in new tab)

Cloudflare argues that websites must evolve beyond browser and search-engine compatibility to become usable by AI agents. Its new Agent Readiness score evaluates whether sites support standards for discovery, content access, bot control, and agent capabilities. Early data shows adoption is extremely low, creating both a challenge and an opportunity for sites that adopt these standards early. ## Agent readiness across the web - Cloudflare analyzed the 200,000 most visited domains, excluding categories unlikely to need agent interaction. - The resulting Cloudflare Radar dataset tracks adoption of AI-agent standards and will be updated weekly. - robots.txt exists on 78% of sites, but most files target traditional search crawlers rather than AI agents. - Only 4% of sites declare AI usage preferences through Content Signals. - Just 3.9% support Markdown content negotiation via `Accept: text/markdown`. - MCP Server Cards and API Catalogs based on RFC 9727 appear on fewer than 15 sites, showing how early these standards remain. ## The Agent Readiness score Site owners can test their websites at **isitagentready.com**. Cloudflare scans the site and scores it across four dimensions: - **Discoverability:** robots.txt, sitemap.xml, and Link Headers under RFC 8288. - **Content:** Markdown for Agents. - **Bot Access Control:** Content Signals, AI-specific robots.txt rules, and Web Bot Auth. - **Capabilities:** Agent Skills, API Catalogs, OAuth discovery standards, MCP Server Cards, and WebMCP. - The tool also checks commerce standards such as x402, Universal Commerce Protocol, and Agentic Commerce Protocol, though these do not yet affect the score. - Each failed check includes a prompt that can be handed to a coding agent for implementation. The service itself supports agents through a stateless MCP server with a `scan_site` tool and publishes Agent Skills documents explaining how to implement each supported standard. ## Discoverability for AI agents - robots.txt helps agents understand crawl permissions and locate sitemaps. - Sitemaps provide a structured list of site paths, reducing the need to discover content by following every HTML link. - HTTP Link headers, defined by RFC 8288, expose important resources directly in responses without requiring agents to parse page markup. - Sites can use headers such as `rel="api-catalog"` to point agents toward machine-readable capabilities. ## Making content easier to read - `llms.txt` provides an LLM-oriented reading list at the site root, describing the site and linking to important content in a format designed for model context windows. - Markdown content negotiation lets agents request a clean Markdown version of a page with `Accept: text/markdown`. - Cloudflare measured token reductions of up to 80% compared with HTML, improving speed, cost, and the likelihood that agents can consume an entire document within their context limits. Cloudflare’s recommendation is to evaluate sites with the Agent Readiness tool and adopt the relevant standards incrementally. With current adoption so low, early support can make a site significantly easier for AI agents to discover, understand, authenticate with, and use.

database-designai-agentcloudflaremarkdown+4

cloudflareApr 17, 2026

Introducing Flagship: feature flags built for the age of AI (opens in new tab)

AI-generated code is moving toward autonomous production deployment, making safety and controlled rollout essential. The post argues that feature flags provide the guardrails: agents can deploy disabled code, test it with limited cohorts, monitor results, and roll back automatically. Cloudflare’s new Flagship service is designed for this workflow, evaluating flags at the edge through Workers, KV, and Durable Objects. ## Feature Flags for Autonomous Deployment - Agents can ship code behind an off flag without affecting users. - They can enable features for themselves or small test cohorts, observe metrics, and expand or disable rollouts. - Humans define boundaries while flags limit the blast radius. - This separates not only deployment from release, but also routine shipping decisions from constant human attention. ## Problems with Feature Flags on Workers - Hardcoded flags are initially convenient because Workers deploy quickly. - Over time, flags become fragmented across teams, with no central visibility or audit trail. - Troubleshooting may require searching version history with tools such as `git blame`. - Calling an external flag service adds a network request to every user request, potentially introducing significant latency. - This undermines the advantage of running applications close to users at the edge. ## Why Local Evaluation Is Difficult on Workers - Traditional local-evaluation SDKs download rules into a long-lived process. - Worker isolates may be created and evicted between requests, requiring repeated initialization. - Serverless environments therefore need a distribution system with edge-local reads and managed synchronization. - Flagship uses Cloudflare KV to provide this distribution without persistent connections or per-request external calls. ## How Flagship Works - Flagship is built on Workers, Durable Objects, and KV, without external databases or centralized evaluation servers. - Durable Objects provide a globally unique, SQLite-backed source of truth for flag configuration and changelogs. - Changes are synchronized to KV within seconds and replicated throughout Cloudflare’s network. - Evaluations read configuration from KV at the edge and execute targeting and rollout logic inside the Worker isolate. - Both flag data and evaluation logic remain close to the request. ## Worker Binding and Typed Evaluation - Workers connect Flagship through a `wrangler.jsonc` binding containing a binding name and `app_id`. - The binding supports typed methods including: - `getBooleanValue()` - `getStringValue()` - `getNumberValue()` - `getObjectValue()` - `*Details()` methods return the value, matched variant, and selection reason. - Evaluation errors return the supplied default value. - Type mismatches throw exceptions because they indicate application bugs rather than temporary service failures. ## OpenFeature Integration - Flagship is built on OpenFeature, the CNCF standard for feature-flag evaluation. - It supports Workers as well as Node.js, Bun, Deno, and browser environments. - The service is currently available in closed beta. Flagship is positioned as an edge-native feature-flag system for safely automating deployment and rollout. For Cloudflare Workers, its direct binding avoids network round-trips while providing centralized configuration, targeting, auditability, and controlled release mechanisms.

database-designcloudflare-workerssqliteedge-computing+4

cloudflareApr 17, 2026

Unweight: how we compressed an LLM 22% without sacrificing quality (opens in new tab)

Unweight is Cloudflare’s lossless compression system for LLM weights, reducing model size by 15–22% while preserving bit-exact outputs. It targets the memory-bandwidth bottleneck in GPU inference by compressing weights in HBM and decompressing them directly into fast on-chip memory before tensor-core computation. On Llama-3.1-8B, the approach saves roughly 3 GB of VRAM and enables more models to run per GPU. ## The GPU Memory Bottleneck - LLM inference is often limited by memory bandwidth rather than computation. - Each generated token requires reading the model’s weights from GPU high-bandwidth memory (HBM). - NVIDIA H100 tensor cores can process data far faster than HBM can supply it. - Smaller weights reduce the amount of data transferred across the memory bus. - Decompression must be carefully integrated: if it adds latency that cannot overlap with matrix multiplication, token generation becomes slower. ## Why Lossless Compression Matters - Quantization commonly converts 16-bit values into 8- or 4-bit integers. - Because quantization is lossy, it can change model behavior and response quality unpredictably. - Unweight instead preserves exact outputs and does not require specialized hardware. - Existing systems were unsuitable because they focused on CPU decompression, custom FPGA hardware, or consumer GPUs rather than Hopper-generation GPUs and production inference. ## Compressing BF16 Weights - BF16 values contain: - A sign bit - An 8-bit exponent - A 7-bit mantissa - Sign and mantissa values appear largely random and are difficult to compress. - Exponents are highly predictable: the 16 most common exponent values account for more than 99% of weights in a typical layer. - Unweight applies Huffman coding to exponent bytes while leaving sign and mantissa bits unchanged. - Rare exponents are handled by storing an entire row of 64 weights verbatim, avoiding per-element branching during decoding. ## Selective Compression of Model Layers - Unweight compresses the MLP gate, up, and down projection matrices. - These matrices represent roughly two-thirds of model parameters and generate substantial memory traffic during decoding. - Attention weights, embeddings, and layer norms remain uncompressed. - The exponent compression produces about 30% savings in the targeted streams and approximately 20% reduction in total MLP weight size. - Overall model-size reductions reach 15–22%. ## Direct GPU Decompression - Model weights normally reside in large but slower HBM and are staged into small, fast shared memory before computation. - Conventional approaches decompress full matrices back into HBM and then run standard matrix multiplication, creating additional memory traffic. - Unweight decompresses weights in shared memory and feeds them directly to tensor cores. - Different execution strategies are used depending on the weight matrix and batch size. - An autotuner selects the fastest strategy for each workload. ## Results and Availability - Tests on Llama-3.1-8B achieved: - Around 30% compression for MLP weights - 15–22% reduction in total model size - Approximately 3 GB of VRAM savings - The savings allow more models to fit on each GPU, potentially reducing inference cost and improving global deployment coverage. - Cloudflare is publishing a technical paper and open-sourcing the GPU kernels. Unweight demonstrates that lossless, inference-time compression can improve GPU utilization without changing model behavior. The practical recommendation is to compress the portions of a model that dominate memory traffic while integrating decoding directly into the GPU execution path.

database-designllmrustmodel-inference+4

cloudflareApr 16, 2026

AI Search: the search primitive for your agents (opens in new tab)

AI Search is presented as a general-purpose search primitive for AI agents, handling retrieval across code, support documentation, customer history, and agent memory. It combines semantic and keyword search while providing built-in storage, indexing, and dynamically creatable search instances. The result is less infrastructure to build and the ability to maintain separate searchable contexts for agents, customers, languages, or other tenants. ## Why Agents Need Search - Agents often need access to information too large or dynamic to fit in a context window. - Common examples include: - Coding agents searching millions of repository files. - Support agents searching product documentation and ticket history. - Memory systems retrieving relevant past interactions. - Building this independently requires: - A vector index. - Document parsing and chunking. - An indexing pipeline that stays synchronized with changing data. - A separate keyword index and result-fusion layer if lexical search is also needed. ## Hybrid Search - AI Search runs vector search and BM25 keyword search in parallel. - Results are fused into a single ranking. - This supports both: - Semantic matches based on meaning. - Exact-term matches for names, identifiers, and technical terminology. - The blog’s own search is powered by AI Search. ## Built-In Storage and Dynamic Namespaces - New AI Search instances include managed storage and a vector index. - Files can be uploaded directly through an API and indexed automatically. - Developers do not need to configure R2 buckets or external data sources for every instance. - The `ai_search_namespaces` binding allows Workers to create and delete instances at runtime. - Instances can be created per: - Agent. - Customer. - Language. - Other isolated contexts. - Documents can include metadata used to boost rankings at query time. - A single query can search across multiple instances. ## Customer Support Agent Example - The example uses the Cloudflare Agents SDK and Workers AI. - A shared `product-knowledge` instance contains product documentation backed by an R2 bucket. - Each customer receives a separate instance such as `customer-abc123`. - After an issue is resolved, the agent stores a summary of the problem and its fix. - Over time, each customer’s instance becomes a searchable history of previous resolutions. ## Agent Tools and Retrieval Flow - The support agent extends `AIChatAgent` and uses Kimi K2.5 through Workers AI. - It defines tools for: - Searching shared product documentation and the current customer’s history in one call. - Saving a resolution after an issue is resolved. - The model decides when to invoke these tools based on the conversation. - Search results can prioritize recent documents using metadata, such as a descending `timestamp` boost. - The Agents SDK persists the conversation history across reconnects, while AI Search provides retrieval over larger knowledge collections. AI Search is recommended for teams that want agent-ready retrieval without separately assembling vector databases, keyword indexes, storage, and synchronization pipelines. Its dynamically isolated instances are particularly useful for multi-tenant agents and applications that need both shared knowledge and private, continuously growing context.

database-designcloudflarevector-dbagents-sdk+4

cloudflareApr 16, 2026

Deploy Postgres and MySQL databases with PlanetScale + Workers (opens in new tab)

Cloudflare and PlanetScale are integrating more closely so developers can create and manage PlanetScale Postgres and MySQL databases from the Cloudflare dashboard and API. The integration connects these databases to Workers through Hyperdrive, providing connection pooling, query caching, and simplified configuration. Cloudflare billing for new PlanetScale databases is planned for next month, while existing setups remain billed through PlanetScale. ## Postgres and MySQL for Workers - Developers can use either PlanetScale Postgres or Vitess-based MySQL for Worker applications. - Postgres supports a broad ecosystem of tools and extensions such as `pgvector` for AI-oriented vector search. - After connecting a PlanetScale account, users can create databases from the Cloudflare dashboard. - A Hyperdrive binding in `wrangler.jsonc` connects a Worker to the database: ```json { "hyperdrive": [ { "binding": "DATABASE", "id": "<AUTO_CREATED_ID>" } ] } ``` - Workers can then use standard clients such as the Node.js `pg` package and access the connection string through `env.DATABASE`. ## PlanetScale’s Developer Experience - Cloudflare selected PlanetScale for its performance, reliability, and support for both Postgres and MySQL. - PlanetScale features include: - Query insights - Usage and cost breakdowns - Database branching for safer schema and code changes - Agent-assisted SQL performance improvements - Cloudflare users receive the standard PlanetScale experience and pricing, including all available features. - PlanetScale Postgres starts at $5 per month for a single node. ## Reducing Latency with Workers Placement - Workers normally execute close to the incoming user request, which can increase latency when accessing a centralized database. - Developers can configure explicit placement so the Worker runs near the database’s primary region: ```json { "placement": { "region": "aws:us-east-1" } } ``` - Cloudflare plans to automatically determine placement based on the PlanetScale database location, potentially reducing database access latency to single-digit milliseconds. ## Billing and Availability - PlanetScale databases can already be created or connected through the Cloudflare dashboard. - Until the billing integration launches, databases continue to be billed through PlanetScale. - Starting next month, new databases can be billed directly to a Cloudflare self-serve or enterprise account. - Cloudflare credits, startup-program benefits, and committed spend may also apply toward PlanetScale database costs. The integration is intended to give Workers developers a unified platform for globally deployed applications, with flexible SQL storage, optimized database connectivity, and eventually centralized Cloudflare billing.

database-designcloudflarepostgresqlmysql+3

cloudflareApr 16, 2026

Artifacts: versioned storage that speaks Git (opens in new tab)

Artifacts is a distributed, versioned filesystem designed for AI agents and other high-volume compute environments. It creates repositories programmatically while remaining compatible with standard Git clients, enabling isolated repositories for agent sessions, sandboxes, and large numbers of forks. Cloudflare argues that Git’s familiar data model—commits, history, diffs, and branching—can serve as a general-purpose state-management primitive beyond traditional source control. ## A Git-Compatible Filesystem for Agents - Artifacts repositories can be created through the Workers API or REST API. - Applications receive a Git remote and authentication token, allowing agents to clone and use repositories with ordinary Git commands. - Repositories can be created dynamically for: - Individual agent sessions - Sandbox instances - Large-scale forked environments - Non-Git clients such as Workers, Lambda functions, and Node.js applications can use the API directly or language-specific SDKs. - Existing repositories can be imported from sources such as GitHub, then independently forked for isolated or read-only work. ## Why Git Fits Agent Workflows - Most AI coding agents already understand Git, including common workflows and edge cases. - Git’s object and commit model works well for storing: - Source code and configuration - Session prompts and agent history - Other large collections of small, versioned data - Git provides built-in capabilities for: - Tracking state over time - Reverting changes - Comparing versions - Forking from historical points - Using Git avoids requiring agents to learn a new protocol, CLI, or specialized tool. ## Beyond Source Control - Artifacts can persist an entire agent session’s filesystem and history without requiring dedicated block storage. - Cloudflare uses per-session repositories to: - Restore sandbox state - Share sessions with other people - Time-travel through both prompts and filesystem changes - Fork a session from any point for collaboration or debugging - The same semantics can support non-code data, such as customer-specific configuration that needs rollback, cloning, or diffing. - Cloudflare expects non-Git use cases to be as important as conventional repository workflows. ## Implementation on Cloudflare - Artifacts are built on Durable Objects, which provide isolated, stateful compute capable of supporting millions of repository instances. - The system uses an in-house Git implementation written in Zig and compiled to WebAssembly for Cloudflare Workers. - The implementation was designed to be: - Small - Broadly Git-compatible - Extensible for features such as notes and Git LFS - Efficient in a Workers environment Artifacts is currently available in private beta for paid Workers customers, with a public beta planned for early May. It is intended as a practical way to give agents and applications disposable, persistent, and fully versioned environments without abandoning the Git ecosystem.

database-designtypescriptcloudflare-workersgit+4

cloudflareApr 15, 2026

Project Think: building the next generation of AI agents on Cloudflare (opens in new tab)

Project Think is Cloudflare’s next-generation Agents SDK for building persistent, scalable AI agents. It combines durable execution, sub-agents, persistent sessions, sandboxed code execution, and runtime-created extensions, while allowing developers to use individual primitives or an integrated Think base class. Its central argument is that agents should run as durable, one-to-one infrastructure rather than ephemeral processes on laptops or permanently running servers. ## Why Agents Need a New Foundation - Coding agents increasingly act as general-purpose assistants by reading context, writing and executing code, observing results, and iterating. - Existing agents are limited by: - Dependence on a laptop or costly VPS - Fixed costs while idle - Manual installation, updates, identity, and secret management - Unlike traditional applications, agents are typically one-to-one: each user, task, or conversation may require a distinct agent. - Supporting millions of concurrent agents with always-on containers would be economically impractical. ## Project Think’s Core Primitives Project Think introduces: - Durable execution through fibers, including checkpointing, crash recovery, and automatic keepalive - Isolated sub-agents with independent SQLite databases and typed RPC - Persistent, searchable sessions with message trees, branching, and compaction - Sandboxed code execution using Dynamic Workers, codemode, and runtime npm resolution - An execution ladder spanning workspaces, isolates, npm packages, browsers, and sandboxes - Self-authored extensions that let agents create tools dynamically ## Long-Running Agents with Durable Objects - Each agent is implemented as a Durable Object with: - A stable identity - Persistent SQLite-backed state - Message-based wake-up - Automatic hibernation when idle - Agents can resume after HTTP requests, WebSocket messages, alarms, or inbound email. - Hibernated agents consume no compute, allowing many more agents than an always-on VM or container model. - Durable Objects provide automatic routing, recovery, and per-agent state without separately managed load balancers, databases, or process supervisors. - For example, 10,000 agents active only 1% of the time require capacity for roughly 100 active agents rather than 10,000 continuously running instances. ## Durable Execution with Fibers - Long LLM calls and multi-step workflows can be interrupted by deployments, restarts, or resource limits. - `runFiber()` makes a function invocation durable by: - Registering it in SQLite before execution - Allowing progress to be checkpointed with `stash()` - Recovering interrupted work through `onFiberRecovered` - Agents can save intermediate findings, resume from the latest checkpoint, and broadcast progress to clients. - The SDK automatically keeps the agent alive while a fiber runs. - `keepAlive()` and `keepAliveWhile()` support active work lasting minutes or longer, such as CI pipelines, design reviews, and video generation. Project Think’s recommendation is to treat agents as persistent, addressable infrastructure: use the low-level primitives for customization, or adopt the Think base class for a faster, integrated starting point.

database-designdurable-objectssqliteagents-sdk+4

cloudflareApr 15, 2026

Introducing Agent Lee - a new interface to the Cloudflare stack (opens in new tab)

Agent Lee is Cloudflare’s new in-dashboard AI assistant, designed to replace complex navigation with natural-language interaction across the Cloudflare platform. It can inspect account data, troubleshoot issues, and—when explicitly approved—make changes or deploy resources. Built on Cloudflare’s own infrastructure, it combines sandboxed code execution, permission controls, and generative UI to provide an interactive way to manage real accounts. ## A Natural-Language Interface to Cloudflare - Agent Lee understands account resources such as Workers, zones, DNS settings, and error rates. - Users can ask it to: - Identify the top error messages for a Worker. - Diagnose access problems involving a `www` prefix. - Enable Cloudflare Access for a domain. - Create an R2 bucket and connect it to a Worker. - It can retrieve account-specific context, use the appropriate tools, and present results through charts and other visualizations. - The beta reportedly serves about 18,000 daily users and performs nearly 250,000 tool calls per day across services including DNS, Workers, SSL/TLS, R2, Registrar, Cache, Cloudflare Tunnel, and API Shield. ## Codemode and Sandboxed Execution - Instead of exposing raw MCP tool definitions to the model, Agent Lee uses Codemode. - The model writes TypeScript that calls a generated API, which is intended to improve accuracy and support multi-step operations in a single script. - Generated code runs through a Cloudflare MCP server and a Durable Object acting as a credentialed proxy. - The Durable Object: - Classifies operations as reads or writes by inspecting the method and request body. - Proxies read operations directly. - Blocks write operations until the user explicitly approves them. - Keeps API keys out of generated code and injects credentials server-side. ## MCP Permissions and User Approval - Agent Lee connects to Cloudflare’s MCP server through: - A search tool for querying API endpoints. - An execute tool for running code that performs API requests. - Any operation that changes the account must pass through an elicitation step. - Approval is an enforced permission boundary rather than merely a confirmation-oriented interface feature. - Agent Lee cannot bypass the approval gate before executing writes. ## Built on Cloudflare’s Public Stack - Agent Lee uses the same building blocks available to Cloudflare customers: - Agents SDK - Workers AI - Durable Objects - Cloudflare’s MCP infrastructure - Cloudflare developed and tested the system in production against real accounts. - The company positions this approach as a way to identify platform limitations and validate patterns that other developers can reuse. ## Generative UI - Agent Lee supplements text responses with dynamically generated interface components. - Questions about traffic can produce interactive line charts rather than plain numerical summaries. - An adaptive grid lets users reserve space for new UI blocks by dragging across the interface and describing what they want. - Supported components include: - Tables - Interactive charts - Architecture maps - Other dynamic visual blocks - The result is intended to turn conversation history into an evolving operational dashboard. ## Quality and Safety - Elicitations are used whenever Agent Lee needs to perform a non-read action, requiring explicit approval in the interface. - Cloudflare also evaluates the system’s: - Conversation success rate - Information accuracy - Because the product remains in beta, users may encounter limitations or edge cases as its reliability and performance continue to improve. Agent Lee’s central promise is to make Cloudflare operations conversational without removing control. Its most important design choice is the combination of broad account awareness with a structural approval gate for changes, while its generative UI makes the resulting information and workflows more actionable.

database-designcloudflareui-designtypescript+4

cloudflareApr 15, 2026

Add voice to your agent (opens in new tab)

Cloudflare’s experimental `@cloudflare/voice` package adds real-time voice to existing Agents SDK applications without requiring a separate voice framework. Voice interactions use the same Durable Object, WebSocket connection, tools, and SQLite-backed history as text interactions. The package provides ready-made STT and TTS integrations while keeping provider interfaces open for alternative speech, telephony, and transport systems. ## Voice Support for Existing Agents - `withVoice(Agent)` enables full conversational voice agents. - `withVoiceInput(Agent)` supports speech-to-text-only features such as dictation and voice search. - React applications can use `useVoiceAgent` and `useVoiceInput`. - Framework-independent clients can use `VoiceClient`. - Built-in Workers AI providers include: - Deepgram Flux for continuous speech-to-text - Deepgram Nova 3 for speech-to-text - Deepgram Aura for text-to-speech - Developers can get started without external API keys. ## Minimal Server and Client Setup - A voice agent extends a class created with `withVoice(Agent)`. - The server configures a transcriber and TTS provider, then implements `onTurn()`. - `onTurn()` receives the user’s transcript and returns the agent’s response. - React clients can display: - Connection status - Interim and finalized transcripts - Conversation messages - Start, end, and mute controls - Non-React applications can connect through `@cloudflare/voice/client`. ## How the Voice Pipeline Works - The browser captures 16 kHz mono PCM microphone audio. - Audio streams over the agent’s existing WebSocket connection. - A continuous STT session remains active for the duration of the call. - The speech-to-text model detects completed utterances and produces stable transcripts. - Each transcript is passed to `onTurn()` for application or LLM logic. - The response is synthesized into audio and streamed back to the client. - Streamed responses can be sentence-chunked so audio begins playing before the full response is complete. - User and agent messages are persisted in the Durable Object’s SQLite database, surviving reconnections and deployments. ## Extensible Provider Architecture - The package is designed not to lock developers into one fixed voice stack. - Small provider interfaces allow speech, telephony, and transport providers to build integrations. - Developers can mix and match components based on their application’s requirements. - Voice therefore becomes another interaction mode for the same stateful agent rather than a separate application architecture. Cloudflare’s approach is best suited to developers who already use the Agents SDK and want to add conversational voice while preserving existing state, tools, persistence, and connection patterns. Since the package is experimental, teams should evaluate provider support and API stability before relying on it in production.

database-designreactsqlitespeech-to-text+3

cloudflareApr 15, 2026

Rearchitecting the Workflows control plane for the agentic era (opens in new tab)

Workflows was originally designed for human-paced events, but autonomous agents now create and manage workflow instances at machine speed. To support this shift, the platform increased its limits substantially and redesigned its control plane for horizontal scalability. The new architecture replaces V1’s account-level bottleneck with distributed components while preserving durable execution, retries, and human-in-the-loop pauses. ## The Shift to Agent-Driven Workloads - Workflows initially handled events such as sign-ups and purchases, typically requiring only one instance per person. - Persistent agents can operate for hours or days and launch dozens of workflows from a single session. - Concurrent agents can create thousands of workflow instances within seconds. - Workflows also serve as durable execution harnesses for agent loops, maintaining progress across failures and supporting asynchronous work. ## Higher Workflows Capacity The platform now supports: - **50,000 concurrent instances**, up from 4,500. - **300 instance creations per second per account**, up from 100. - **2 million queued instances per workflow**, up from 1 million. These increases were driven by observed usage patterns and a redesign of the control plane. ## V1: A Single Account-Level Bottleneck - Each workflow consists of durable, independently retryable steps that can run tasks, wait for events, or sleep until a scheduled time. - SQLite-backed Durable Objects provide execution, coordination, and storage. - An **Engine Durable Object** is created for each workflow instance and handles execution, retries, and sleeping. - A single **Account Durable Object** manages account-wide workflow and instance metadata. - All create, update, and list operations passed through the Account object. - High-volume customers could generate thousands of requests per second as instances started and completed, overwhelming the singleton. - The original rate limits were therefore hard architectural limits rather than adjustable product settings. ## V2: Horizontal Scaling Principles The redesigned control plane is based on several architectural changes: - The instance’s **Engine is now the sole source of truth** for whether that instance exists. - The system verifies that an Engine exists before queuing an instance, avoiding queued instances with no running execution object. - Instance lifecycle and liveness operations are distributed across workflows and regions so they can scale horizontally. - The Account singleton stores only essential metadata and has a bounded maximum number of concurrent requests. - Limits are designed to be flexible and increaseable rather than constrained by one central bottleneck. ## SousChef and Gatekeeper - V2 introduces two central components: **SousChef** and **Gatekeeper**. - SousChef acts as a “second in command” to the Account, taking over work that previously concentrated all workflow and instance management in one Durable Object. - Together, these components are intended to distribute control-plane responsibilities and enable higher creation rates and concurrency. - The migration was performed with live traffic, allowing customers to move to the new architecture without interruption. The redesign aligns Workflows with agentic workloads by moving coordination away from a single account-level Durable Object. Developers running high-volume or highly concurrent agents should benefit from the new limits and a control plane that can continue scaling independently.

database-designdurable-objectssqlitescalability+3