Why agents should (or shouldn’t) switch from Wrangler to Cloudflare’s new cf CLI

According to Cloudflare Blog, the company launched cf, a new command‑line interface built for the "next generation of software development" where AI agents are the primary users. The announcement matters because Cloudflare’s API surface runs into the thousands, and agents have already been hitting the limits of Wrangler’s roughly 280 commands.

The new cf CLI: features at a glance

• Full API coverage – cf generates commands directly from Cloudflare’s OpenAPI schemas, expanding the reachable operations from ~280 to over 3,000.
• JSON‑first output – every command returns JSON by default, eliminating the need for --json flags and downstream jq filtering.
• Typed configuration – cloudflare.config.ts replaces Wrangler’s wrangler.toml/jsonc with a TypeScript‑based file that can be type‑checked by language‑server plugins.
• Vite‑powered dev server – cf uses Vite (and the Rust‑based Rolldown) for hot‑module replacement and faster builds, instead of the older esbuild‑based pipeline.
• Natural‑language search – cf cli search <prompt> lets an agent ask in plain English for the right command, pulling from a small index of API descriptions.

These pieces are clearly aimed at reducing the token‑cost of prompting agents and at giving them a deterministic way to discover Cloudflare functionality.

How agents are using the CLI today

In the past twelve months Cloudflare measured a jump from single‑digit to 48 % of Wrangler invocations coming from agents. Agents tend to run more distinct commands per day (almost twice as many) and are four times more likely to execute six or more commands in a session. The data suggests agents are already comfortable with a CLI, but they have been hampered by two practical problems:

1. Missing commands – many API endpoints simply did not have a corresponding Wrangler command, forcing agents to fall back to raw HTTP calls.
2. Inconsistent output – only a subset of Wrangler commands supported --json; the rest printed Unicode tables, making automated parsing noisy and token‑expensive.

When the team gave a small internal team of agents access to the beta cf, the agents could discover a needed D1 database operation in under a minute using cf cli search d1 list. The JSON output arrived ready for a downstream jq filter, shaving roughly 150 tokens per call compared to the previous Wrangler workflow.

The hidden costs and trade‑offs

The table makes two things clear. First, cf offers a broader functional surface, which is the obvious win for agents that need to do more than the classic Worker lifecycle. Second, Wrangler benefits from a deep ecosystem of tutorials, community scripts, and LLM‑training data that will not instantly transfer to cf.

A practical downside of the switch is the learning curve for the new config format. Agents that have internal prompts tuned to edit wrangler.toml will need to be re‑trained to manipulate a TypeScript file. The blog notes a 40 % reduction in lines of config code after migration, but that reduction comes with a requirement that the agent understand TypeScript syntax, imports, and type annotations – a non‑trivial shift for a model that was never exposed to TS.

What the shift really means for your workflow

The trade‑off nobody spells out is context vs. capability. By feeding the entire Cloudflare API into the CLI, cf gives agents a lot of options, but each option adds to the prompt’s token budget when the agent tries to decide which command to run. The built‑in cf cli search mitigates this by providing a pre‑indexed shortlist, yet the index itself must be kept in sync with API changes. In practice, you may find the agent spending more time “searching” than executing, especially for rarely used services.

Another subtle change is human‑agent handoff. With Wrangler, a human could glance at a table of results and make an ad‑hoc decision. cf’s JSON‑only output pushes that decision downstream – the human must either request a formatted view (cf --pretty) or rely on a separate UI. For teams that still need occasional manual inspection, the default JSON could feel less friendly.

Finally, the ecosystem lag matters. Because cf is an open beta, most third‑party tutorials, GitHub actions, and CI templates still reference Wrangler. Until those are updated, you will spend extra effort maintaining a mixed‑tool environment or writing wrappers that translate between the two CLIs.

Quick steps to try cf tomorrow

1. Install the beta – run npm i -g @cloudflare/cf@beta (or the equivalent brew command). The installer will add the binary to your PATH.
2. Initialize a test project – cf init my‑test‑worker will create a cloudflare.config.ts with a minimal Worker skeleton.
3. Run a simple command – cf dev starts the Vite dev server; check that the local preview works on http://localhost:8787.
4. Compare JSON output – execute cf d1 list --output json and note the structure. Then run the same with Wrangler (wrangler d1 list --json) and count the tokens needed to parse the result in a prompt.
5. Search for a missing operation – try cf cli search workers kv list and see which command the CLI suggests. If the result is empty, you have identified a gap that still requires a raw API call.

If the test runs without errors and the JSON output feels clean, you can start replacing wrangler calls in your automation scripts with the equivalent cf commands. Keep the original wrangler binary around until you have verified that all your CI pipelines still succeed.

---

Sources

• Cloudflare Blog – Introducing cf: the agentic CLI for the entire Cloudflare API