Flagship: Cloudflare Feature Flags for AI Apps

Last updated: October 18, 2026

Updated October 18, 2026: The earlier version of this post showed new Flagship({ token }) with flags.model(), flags.prompt(), flags.gate() and flags.report(), and described built-in model flags, a prompt registry, automatic circuit breakers and A/B dashboards. None of that is in Cloudflare's announcement or in the @cloudflare/flagship package, which is an OpenFeature provider. The code is now adapted from Cloudflare's announcement (the Worker binding and the OpenFeature SDK), the feature list matches what Cloudflare documents, and the latency, propagation and templating claims were removed. Flagship is in public beta as of May 26, 2026, with pricing to be announced before general availability.

Flags For AI Are Different#

Every team running AI in production ends up building the same three controls: a way to choose which model a cohort gets, a kill switch for an agent behaving badly, and a way to change a prompt version without a deploy. Those are all flag-shaped problems.

For broader context, pair this with Every AI Coding Tool Compared: The 2026 Matrix and What Is an AI Coding Agent? The Complete 2026 Guide; those companion pieces show where this fits in the wider AI developer workflow.

Cloudflare's framing for Flagship, announced during Agents Week 2026, is about agents shipping code: an agent writes a new code path behind a flag, deploys with the flag off, enables it for itself or a small cohort, watches the results, ramps the rollout, and disables the flag if something breaks. The human sets the boundaries; the flag controls the blast radius.

Flagship is not an AI-specific product with model or prompt primitives. It is a general flag service that happens to be very well placed for AI apps on Workers. The AI patterns are things you build with its typed values.

What Flagship Actually Ships#

From the announcement:

• OpenFeature-native. Flagship implements OpenFeature, the CNCF standard for flag evaluation, so evaluation code is portable across providers.
• Runs everywhere, fastest on Workers. It works in Workers, Node.js, Bun, Deno and the browser. On Workers, a binding evaluates flags inside the runtime with no HTTP round trip.
• Built on Cloudflare primitives. Flag changes are written to a Durable Object, which is the source of truth and changelog, and synced to Workers KV within seconds. Evaluation reads from KV and runs in the isolate handling the request.
• Typed values. Flags can be booleans, strings, numbers or full JSON objects.
• Targeting and rollouts. Rules are evaluated in priority order, conditions can nest AND/OR logic up to five levels deep, and percentage rollouts use consistent hashing on a context attribute so users do not flip between variations.
• Audit trail and dashboard. Every change is recorded with field-level diffs, and anyone on the team can toggle a flag or adjust a rollout without touching code.

What it does not ship, at least in the announcement: model-aware routing, a prompt registry with templating, or circuit breakers that flip flags automatically from your metrics. If you want those, you build them on top.

What It Looks Like in Code#

On Workers, add the binding to wrangler.jsonc:

{
  "flagship": [
    {
      "binding": "FLAGS",
      "app_id": "<APP_ID>"
    }
  ]
}

Then evaluate flags with typed accessors. This is adapted from the announcement's binding example, with an AI-shaped kill switch and a JSON model config:

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const userId = request.headers.get("x-user-id") ?? "anon";

    // Kill switch: default to off if evaluation fails
    const agentEnabled = await env.FLAGS.getBooleanValue("agent-tools-enabled", false, {
      userId,
    });
    if (!agentEnabled) {
      return Response.json({ error: "Agent temporarily unavailable" }, { status: 503 });
    }

    // Model choice as a string flag, with the reason it was selected
    const model = await env.FLAGS.getStringDetails("primary-chat-model", "your-default-model", {
      userId,
    });
    // model.value, model.variant, model.reason (for example "TARGETING_MATCH")

    return Response.json({ model: model.value, variant: model.variant });
  },
};

The binding also has getStringValue(), getNumberValue() and getObjectValue(), plus *Details() variants. Cloudflare's documented error behavior is worth designing around: on evaluation errors the default value is returned, and on type mismatches the binding throws, because that is a bug in your code rather than a transient failure.

Outside Workers, or if you want portable evaluation code, use the OpenFeature SDK with the Flagship provider. This is close to verbatim from the announcement:

import { OpenFeature } from "@openfeature/server-sdk";
import { FlagshipServerProvider } from "@cloudflare/flagship/server";

await OpenFeature.setProviderAndWait(
  new FlagshipServerProvider({
    appId: "your-app-id",
    accountId: "your-account-id",
    authToken: "your-cloudflare-api-token",
  })
);

const client = OpenFeature.getClient();
const showNewCheckout = await client.getBooleanValue("new-checkout-flow", false, {
  targetingKey: "user-42",
  plan: "enterprise",
  country: "US",
});

On Workers you can pass the binding to the same provider, new FlagshipServerProvider({ binding: env.FLAGS }), and authentication is implicit. Install with npm i @cloudflare/flagship. A client-side provider for browsers pre-fetches the flags you specify and serves them from a cache with a configurable TTL.

Using It for AI Patterns#

Model rollouts. Store the model ID as a string flag, or a JSON object with model, temperature and max tokens. Ramp a new model with a percentage rollout keyed on user ID, so the same user keeps the same model across requests.

Prompt versions. Store a prompt version identifier as a string flag and keep the prompt text in your code or your own store. Rolling back is flipping the flag. If you want a dedicated registry instead, see how Langfuse, PromptLayer and the other prompt management tools compare.

Kill switches. A boolean flag with a safe default. Because errors return the default, choose a default that fails closed for risky tools.

Automatic fallbacks. Flagship does not flip flags from your metrics. If you want a circuit breaker, run it in your own code: track error rate, and switch to a hard-coded fallback model when it crosses a threshold. Keep that fallback outside the flag system so a flag outage cannot take it down too.

Where It Fits in the Agent Stack#

Flags sit above your inference layer because they decide which model and tools to use, and below your orchestration layer because the orchestrator only needs the resolved value.

In multi-step agent workflows, each step can read its own flags: one model for planning, another for execution, a third for verification. We use per-node model and prompt selection in Orchestrator, our product for declarative multi-agent workflows, and a flag service is a clean way to tune that from a dashboard.

The other place flags compose well is observability replay. When you see a bad agent run, you want the flag values that were active, not just the prompt and response. Traces records that context alongside the agent transcript.

I walked through flag-driven rollout strategies on the Developers Digest YouTube channel.

Wiring It Into A Real Product#

Start with one flag: model selection. Wrap your existing model call in a flag lookup, set the default to your current model, deploy. You now have an instant switch and a path to gradual rollouts.

Version every prompt change as a new flag value rather than editing the old one. The audit trail is worth the overhead, and rollback becomes trivial.

Keep a hard-coded last-resort default in code for every flag. If evaluation fails, your app should still work on safe defaults. Treat the flag service as a control plane, not a single point of failure.

What To Watch Next#

Pricing is the first thing to watch: Cloudflare says it will share details as Flagship approaches general availability. The second is how agents use it. The announcement's thesis is agents that enable, ramp and disable flags themselves within human-set boundaries, and the guardrails around that will matter more than any single feature.

FAQ#

What is Cloudflare Flagship?#

Flagship is Cloudflare's feature flag service, built on the OpenFeature standard and on Workers, Durable Objects and KV. It works in Workers, Node.js, Bun, Deno and the browser, and is fastest on Workers, where a binding evaluates flags in the runtime. It entered public beta on May 26, 2026.

How is Flagship different from LaunchDarkly or Statsig?#

Flagship's distinguishing traits are edge evaluation on Cloudflare's network (flag config is read from KV in the same location handling the request) and OpenFeature-native SDKs, so you can adopt or leave it without rewriting evaluation code. It does not ship AI-specific primitives; model and prompt selection are patterns you build with typed flag values.

Does Flagship work outside of Cloudflare Workers?#

Yes. Cloudflare says it works in Workers, Node.js, Bun, Deno and the browser. Outside Workers, use the OpenFeature server SDK with FlagshipServerProvider and an app ID, account ID and API token; in the browser, use the client-side provider, which pre-fetches flags and caches them with a TTL.

Does Flagship have circuit breakers?#

Not as a built-in feature. The announcement describes targeting rules, percentage rollouts, an audit trail and dashboard controls. Automatic fallback based on your metrics is something you implement in your own code.

What flag value types does Flagship support?#

Booleans, strings, numbers and full JSON objects. The Worker binding has getBooleanValue(), getStringValue(), getNumberValue() and getObjectValue(), plus *Details() variants that return the value, the matched variant and the reason.

How fast do flag changes propagate?#

Cloudflare says flag changes are written to a Durable Object and synced to Workers KV "within seconds," then read from KV at the edge. Keep a local override for development if you need instant changes while testing.

Should I use Flagship for A/B testing AI models?#

You can use percentage rollouts with consistent hashing to split users between models, and the variant and reason from the *Details() accessors to tag your telemetry. Measuring the result is up to your own analytics.

What happens if flag evaluation fails?#

On evaluation errors, the binding returns the default value you passed. On type mismatches, it throws. Choose defaults that fail safe, and keep a hard-coded fallback outside the flag system.

Sources#

• Cloudflare Flagship announcement: blog.cloudflare.com/flagship
• Flagship documentation: developers.cloudflare.com/flagship/get-started
• OpenFeature: openfeature.dev
• Cloudflare Workers documentation: developers.cloudflare.com/workers

Continue Reading#

• Cloudflare Agent Memory: A Developer's Guide to the New Primitive
• cdnjs Runs Entirely on Cloudflare's Developer Platform: 9 Billion Requests a Day on Workers
• In Praise of Memcached: Why Simpler Caching Might Be Better