Cloudflare's New CLI cf: A Toolset Rebuilt for Agents

The people using Cloudflare's command-line tool Wrangler are turning into Agents. By Cloudflare's own numbers, Agents made up a quarter of Wrangler usage earlier this year, up from single-digit percentages a year before; last week that share reached 48%.

And Agents use it harder than people do: they run almost twice as many distinct commands per day, and are almost four times as likely to use six or more commands in one go.

Traffic across the whole network is moving the same way. Below is a screenshot from Cloudflare Radar (Cloudflare's public network-traffic statistics page): of web-page (HTML) requests, bots account for 57.5% and humans only 42.5%; and by response content type, JSON makes up 33.1%, well above HTML's 12%. Here "bot" means every kind of automated program. AI Agents are only one part of it, so this cannot be read directly as the Agent share, but it does show that machine-readable data formats are now more common than web pages.

Back to Cloudflare's own tooling: Wrangler covers only about 280 operations, while Cloudflare offers thousands of operations in total. So what an Agent can do on Cloudflare has been capped by Wrangler's command list. That is why Cloudflare built a new command-line tool, cf, which aims to bring the entire Cloudflare API into the terminal and is designed from the ground up with Agents as the first-class user. It is an open beta; install it with npm i -g cf.

Below, the four changes in cf are organized around where an Agent gets stuck.

One tool that can do everything on Cloudflare

First, why Wrangler stalled at 280. It was hand-built by individual product teams: to look up one resource, one team wrote d1 info, another hyperdrive get, another workflows describe; some teams shipped thousands of lines of custom experience that almost nobody used. With that many teams, a consistent command style was hard to keep.

cf takes a different approach: instead of hand-writing commands, it generates them directly from the API's OpenAPI specification (the standard document that describes every endpoint and its parameters). Every Cloudflare API already has this spec, used to generate API docs and SDKs for various languages; add a little extra annotation to it, and a unified generation pipeline called Forge can produce command-line commands as a by-product. The result: commands grow from about 280 to cover more than 3,000 API operations.

The most direct change for users: you can have an Agent use one tool to run a whole chain like "create a Worker (a small piece of server-side code that runs on Cloudflare), deploy it, monitor it, protect it with Cloudflare Access, buy a domain, and put a WAF (web application firewall) in front of it", with no tool switching and no clicking through the dashboard.

Output defaults to JSON, not tables for humans

When an Agent uses Wrangler, it adds --json to almost every command, then uses jq (a small command-line tool for filtering JSON fields) to keep only the few fields it needs. But only some Wrangler commands support --json; the rest print tables laid out for humans. An Agent can read a table too, it just costs more time and more tokens than a single jq filter.

cf flips this: JSON is the default output. It is pretty-printed for humans and compacted for Agents to save context. Cloudflare's reasoning is that most of this tool's commands are rarely touched by a person directly; what you actually do is have the Agent filter the results and report back in the format you want, so handing you a table you will never study closely makes no sense.

But some things do need a human's decision, such as searching for and buying a domain. Written as a long chain of named parameters, such a command is hard to compose, so cf breaks the API's requirements into a series of validated inputs that a person fills in step by step, like a form.

You can also just have an Agent do it for you; in the demo, adding --force makes the command skip confirmation and return the JSON result directly.

With 3,000 commands, how does an Agent find the one it needs

With this many commands, dumping the whole command list into an Agent would blow up its context. cf adds cf cli search: the Agent says in natural language what it wants to do, and a small search index returns matching commands based on each command's API description and parameters. The first time an Agent runs --help, cf automatically tells it this command exists, so you don't have to mention it in your prompt.

Config as TypeScript, so the editor catches the Agent's mistakes

Wrangler configuration is written in TOML or JSONC. Cloudflare's observation: TOML has no accessible schema, and JSONC can link to one but Agents rarely look at it. The new config file for cf is called cloudflare.config.ts and is written in TypeScript. The benefit is that an Agent using an LSP (Language Server Protocol, which lets editors offer completion and error checking) plugin, such as Claude Code or Codex, can read directly what each field is and what it accepts, and its edits are more accurate. Cloudflare says that even an Agent with no prior knowledge of the format can find and edit the config easily, including parts like env that share a name with Wrangler's but have changed substantially in meaning.

There is a side benefit: configuration can be generated by code. Some Wrangler config files inside Cloudflare were originally over 5,000 lines, with many custom environments copied for each developer; generating each environment from one shared base cut them by 40%. A multi-environment Worker only needs to switch between two sets of configuration based on Vite's built-in mode argument:

import { bindings, defineConfig } from "cf/config";
import * as entrypoint from "./index.js" with { type: "cf-worker" };

export default defineConfig(({ mode }) => ({
  worker: {
    name: "example-worker",
    entrypoint,
    compatibilityDate: "2026-09-27",
    env: {
      Environment: bindings.text(`This is ${mode} environment`),
    },
  },
}));

bindings is the single entry point for everything a Worker can connect to (environment variables, secrets, KV cache, D1 databases, R2 storage, queues, AI, vector indexes, another Worker). The editor can autocomplete and explain each item, which amounts to a directly searchable checklist for the Agent:

env: {
  API_URL: bindings.text(
    mode === "production" ? "https://example.com" : "https://staging.example.com",
  ),
  API_TOKEN: bindings.secret(),
  CACHE: bindings.kv({ id: mode === "production" ? "production-namespace-id" : "staging-namespace-id" }),
  DATABASE: bindings.d1({ name: `example-${mode}-database` }),
  UPLOADS: bindings.r2({ name: `example-${mode}-uploads` }),
  AI: bindings.ai(),
  // plus queue, vectorize, worker, and more
}

triggers gathers "what makes this Worker run" in one place: web requests, scheduled jobs, queue messages, incoming email. These used to be scattered across the config file; now they sit in a single block:

triggers: [
  triggers.fetch({ pattern: "example.com/*" }),
  triggers.scheduled({ schedule: "0 * * * *" }),
  triggers.queue({ name: "jobs", maxBatchSize: 10 }),
  triggers.email({ addresses: ["your-inbox-address"] }),
],

For now this config only supports Workers. The official plan is for it to manage all of Cloudflare: policies, zones, DNS and more will follow, all written in the same typed configuration.

Local development now defaults to Vite

When Wrangler was created, Vite did not exist, so it bundled with esbuild, and its local dev server (on port 8787 by default) was self-built, so changing anything meant digging into Miniflare (Cloudflare's local runtime). Now the Vite ecosystem is mature, with a large plugin catalog and a dev server with HMR (hot module replacement, where the page refreshes automatically after a code change), and bundling uses Rolldown, written in Rust, for tree-shaking (removing unused code). cf is built on Vite and the Cloudflare Vite plugin by default, together with the Vitest plugin for testing, giving a dev and test environment that matches the Workers runtime in production.

Cloudflare says most Workers can be migrated smoothly with an Agent's help. But not every project can move right away: JavaScript Workers that still depend on esbuild, as well as Workers written in Rust and Python, will keep having cf hand development and deployment to Wrangler.

Migrating from Wrangler

For an existing Worker, just run cf migrate: a Worker already built with Vite is converted to cloudflare.config.ts; one that still relies on Wrangler for esbuild keeps handing the build to Wrangler. For new projects, start with cf init; cf init and cf deploy install the Cloudflare Vite plugin and generate the config file for you. Static sites still don't need a config file; just run cf deploy in the project to deploy.

On timing: once the open beta ends, Cloudflare will release a final major version of Wrangler that points you and your Agent to cf, and then keep maintaining Wrangler for another 18 months to give everyone time to migrate. cf itself is open source, and issues can be reported to the cloudflare/cf repository on GitHub.

Why replace Wrangler instead of patching it

There is a counterintuitive point here. Years of documentation, blog posts and third-party tutorials on Wrangler have been absorbed into large models, so Agents already know it well; a new tool no Agent has seen sounds more error-prone. Cloudflare argues the opposite: making changes this big in the old tool would force the Agent to unlearn what it knows, for instance that env now means something different; a brand-new tool is cleaner, and the team can teach the Agent the new usage through design choices, context they can inject, and an AGENTS.md file they can append (instructions in a project written for the Agent). Cloudflare says only a few of these Agent-facing features ship so far, with more to come; among them, the way an Agent finds commands by itself is one it expects to become standard in more command-line tools.

How to read this

This is not just about Cloudflare gaining another command-line tool, but about a bigger shift: when a tool's main user changes from human to Agent, every product default gets flipped. Output format defaults to machines, finding commands relies on search rather than memory, configuration must be checkable by the editor, and old habits are dropped even at the cost of a break. If you are building tools or APIs for Agents, these four points are worth comparing against your own.

Two things to keep in mind: the 48% at the start is the Agent share of Wrangler usage as counted by Cloudflare, not of all developers; and cf is still an open beta, its config format currently supports only Workers, and configuration for the rest of the products, such as DNS and policies, is still planned.