Over the last year, agent use of Wrangler has skyrocketed. In March 2026, agents were responsible for a quarter of Wrangler use, up from single-digit percentages the year prior. Last week, agent usage reached 48%.
Agents are more prolific users, using almost twice as many distinct commands per day, and are almost four times as likely to use six or more commands. Agents love CLIs. But Wrangler only provides commands for around 280 operations, and Cloudflare offers thousands.
Earlier in the year we teased how we were planning to solve this and today, we’re enabling agents to use every Cloudflare product by introducing a new CLI: cf. cf is a CLI that is built for the next generation of software development: Agents can find the command they need to do anything they want to do with bespoke search and steering. JSON is the default interface, pretty printed for humans and condensed for agents for maximum context savings.
cloudflare. config. ts is the new configuration format for the whole of Cloudflare, starting with Workers, and bringing the safety and accuracy of TypeScript to you and your agent’s language server protocol (LSP) Vite becomes default, bringing with it the best local development server, and a plugin suite for developers and framework authors.
Install the open beta today globally and run it from anywhere: npm i -g cf Copy prompt Please update your global agent instructions, so you use Cloudflare's new cf CLI. Add the Markdown below to the user-level instructions file that you load in every project – not this repository's AGENTS. md or CLAUDE.
md. Use the file for the agent you are: Claude Code `~/. claude/CLAUDE.
md, Codex /. codex/AGENTS. md, OpenCode /.
config/opencode/AGENTS. md, Pi ~/. pi/agent/AGENTS.
md`. For any other agent, use its equivalent global rules file; if your global rules can only be set in a settings screen, tell me what to paste there instead. Create the file if it doesn't exist.
Keep everything already in it, but replace any existing instruction about Wrangler or the Cloudflare CLI instead of adding a conflicting one. If the same guidance is already there, leave the file as it is. When you're done, tell me the path of the file you changed.
```markdown ## Cloudflare CLI - cf - v20260928 cf is Cloudflare's current CLI and covers the whole Cloudflare platform. Prefer it over Wrangler: create projects with cf init, develop with cf dev, deploy with cf deploy, and manage account resources with cf <product> … (for example cf d1 list). Wrangler is only for projects that already use it – a `wrangler.
jsonc, wrangler. jsonorwrangler. toml` file – or when the user asks for it.
Keep using Wrangler in those projects unless asked to migrate, and use cf migrate in this case. cf commands differ from Wrangler's; check cf --help or cf cli search <what you want to do> instead of guessing. If a cf command fails in a project that doesn't use Wrangler, don't fall back to Wrangler (including npx wrangler) without offering to report it.
cf gives your agent access to the entire Cloudflare API What if your agent could do everything Cloudflare can do? That’s the question that sparked our interest earlier this year: agents were getting ever more powerful, but what they were able to do with Cloudflare’s CLI was still limited. Wrangler was hand-built with each product team contributing and taking their own approach to their command developer experience.
Enforcing patterns across teams was virtually impossible, even across our ~280 command paths. We had inconsistent terminology across d1 info , hyperdrive get , workflows describe as each team came up with their own practices at different times. Some teams built entirely custom experiences across thousands of lines of code that turned out to be used extremely rarely, and teams came up with different approaches to solve the same problems.
We wanted to both standardize what we had and make a massive expansion, all at once. Forge — Cloudflare’s new unified API generation pipeline — enabled us to do this, building on the idea of generating our CLI commands directly from the API schema that powers our API documentation and SDK generation. Everything we provide has an OpenAPI schema, and if we annotate this with just a little more information, we can use it as the source for Forge to make a CLI.
This enables us to expand cf from the ~280 functions that Wrangler had built up over time, to cover the entirety of the Cloudflare API surface of over 3,000 operations. Now it’s simple to give your agent cf and ask it to go set up a worker, deploy it, monitor and observe it, protect it with Cloudflare Access, buy a domain, and front it with Cloudflare WAF, all from a single tool.
Building for an agent that has never used cf cf is built for the trajectory of software engineering, where agentic development is drastically changing how software is built and deployed. This year we’ve been focused on providing tools to support this shift, culminating in cf. cf has been built from the ground up with agents in mind, and includes novel tools for agentic command discovery that we think will become standard in more CLIs in the near future.
Wrangler came with the advantage that years of documentation, blogs, and third-party guides have been absorbed into the training process of LLMs. It also came with the same disadvantage: changing how Wrangler works now goes against learned behavior, and significant change would be inevitable given the scale of improvement we want to make. Introducing a new CLI that agents have never seen sounds like a big disruptive change — but actually it’s the cleanest thing we can do.
Because of the design decisions we have made, the context injections we can make, and the AGENTS. md files we can append, making a switch in this way is actually less confusing than having an agent contextualize the major differences between two versions of a tool it is familiar with.
Originally published at blog.cloudflare.com
