Presentamos cf: la CLI agéntica para toda la API de Cloudflare

Durante el último año, el uso de Wrangler por parte de los agentes se ha disparado.

En marzo de 2026, los agentes fueron responsables de una cuarta parte del uso de Wrangler, comparado con porcentajes de un solo dígito el año anterior. La semana pasada, el uso por parte de agentes alcanzó el 48 %.

Los agentes son usuarios más prolíficos: utilizan casi el doble de comandos distintos por día y tienen casi cuatro veces más probabilidades de usar seis o más comandos.

A los agentes les encantan las interfaces de líneas de comando (CLI). Pero Wrangler solo ofrece comandos para alrededor de 280 operaciones, y Cloudflare ofrece miles.

A principios de año adelantamos cómo planeábamos resolver esto y hoy, habilitamos a los agentes para usar todos los productos de Cloudflare presentando una nueva CLI: cf.

cf es una CLI desarrollada para la generación futura del desarrollo de software:

• Los agentes pueden encontrar el comando que necesitan para hacer cualquier cosa que deseen, con búsqueda y orientación a medida.
• JSON es la interfaz predeterminada, con formato legible para humanos y condensado para agentes para maximizar el ahorro de contexto.
• cloudflare.config.ts es el nuevo formato de configuración para todo Cloudflare, comenzando con Workers, y aporta la seguridad y precisión de TypeScript a ti y al protocolo de servidor de lenguaje (LSP) de tu agente.
• Vite se convierte en la opción por defecto, trayendo consigo el mejor servidor de desarrollo local y un conjunto de plugins para desarrolladores y autores de marcos de trabajo.

Instala hoy mismo la versión beta abierta a nivel global y ejecútala desde cualquier lugar:

npm i -g cf

cf le da a tu agente acceso a toda la API de Cloudflare

¿Y si tu agente pudiera hacer todo lo que Cloudflare puede hacer? Esa fue la pregunta que despertó nuestro interés a principios de este año: los agentes eran cada vez más poderosos, pero lo que podían hacer con el CLI de Cloudflare seguía siendo limitado.

Wrangler fue construido de forma manual, con cada equipo de producto aportando y adoptando su propio enfoque para la experiencia del desarrollador en sus comandos. Imponer patrones entre equipos era prácticamente imposible, incluso entre nuestras casi 280 rutas de comandos. Teníamos una terminología inconsistente entre d1 info, hyperdrive get y workflows describe, ya que cada equipo estableció sus propias prácticas en momentos distintos. Algunos equipos construyeron experiencias completamente personalizadas con miles de líneas de código que resultaron usarse de forma extremadamente infrecuente, y los equipos desarrollaron enfoques diferentes para resolver los mismos problemas.

Queríamos tanto estandarizar lo que teníamos como hacer una expansión masiva, todo al mismo tiempo. Forge, el nuevo proceso de generación de API unificado de Cloudflare, nos lo hizo posible, partiendo de la idea de generar nuestros comandos CLI directamente desde el esquema API que impulsa nuestra documentación de API y la generación de SDK. Todo lo que proveemos tiene un esquema OpenAPI, y si lo anotamos con un poco más de información, podemos usarlo como fuente para que Forge genere una CLI.

Esto nos permite ampliar cf desde las 280 funciones que Wrangler había acumulado con el tiempo, para cubrir toda la superficie de la API de Cloudflare con más de 3.000 operaciones.

Ahora es muy sencillo darle a tu agente cf y pedirle que configure un worker, lo implemente, lo supervise y observe, lo proteja con Cloudflare Access, compre un dominio y lo proteja con Cloudflare WAF, todo desde una sola herramienta.

Desarrollado para un agente que nunca utilizó cf

cf está construido para la trayectoria de la ingeniería de software, donde el desarrollo agéntico está cambiando drásticamente cómo se crea e implementa el software. Este año nos hemos enfocado en proveer herramientas para apoyar este cambio, culminando en cf. cf se desarrolló desde cero pensando en los agentes e incluye herramientas novedosas para la detección agéntica de comandos que creemos se convertirán en estándar en más CLI en un futuro cercano.

Wrangler contaba con la ventaja de que años de documentación, blogs y guías de terceros habían sido incorporados en el proceso de entrenamiento de los LLM. Pero también tenía el mismo inconveniente: cambiar cómo funciona Wrangler ahora va en contra del comportamiento aprendido, y un cambio significativo era inevitable dado el alcance de las mejoras que queremos realizar.

Presentar una nueva CLI que los agentes nunca han visto suena como un gran cambio disruptivo, pero en realidad es lo más sencillo que podemos hacer.. Gracias a las decisiones de diseño que hemos tomado, las inyecciones de contexto que podemos realizar y los archivos AGENTS.md que podemos agregar, hacer un cambio de esta manera es en realidad menos confuso que pedirle a un agente que contextualice las diferencias principales entre dos versiones de una herramienta que conoce. Lanzamos con un par de estas funcionalidades orientadas a agentes integradas, con más por venir.

Los agentes necesitan filtrar JSON, no mirar tablas

Cuando los agentes usan Wrangler, agregan --json a cada comando que ejecutan y luego suelen filtrar la salida con jq para extraer un subconjunto de campos. Pero solo algunos comandos de Wrangler admitían --json; muchos devolvían tablas unicode diseñadas para humanos que miran la salida en su terminal. Los agentes pueden descifrarlas, pero les cuesta más tiempo y tokens que un filtro jq.

En cf adoptamos la postura contraria: los agentes simplemente necesitan JSON, y si los agentes son el futuro usuario principal de esta herramienta, debería ser el estándar. Para la gran mayoría de comandos a los que los humanos rara vez accederán, es evidentemente la decisión correcta.

Tú, como cliente humano de esta CLI, estás en realidad a un paso de usarlo directamente. Es preferible que los agentes puedan filtrar fácilmente sus resultados y devolver esa lista filtrada en el formato que solicites, antes que recibir tablas que probablemente nunca vas a leer directamente.

¿Pero qué pasa si quieres hacer algo que podría requerir una aportación personal real, como buscar un dominio para comprar?

Para los comandos a los que tu agente puede acceder encadenando parámetros con nombre en una secuencia larga e incómoda, puedes simplemente completar un formulario. Cf divide los requisitos de la API en una serie de entradas validadas, por lo que comprar un dominio, incluso uno con requisitos complejos, es sencillo de seguir.

O, si preferís, simplemente pedile a tu agente que lo haga.

Tu agente puede encontrar el comando correcto por sí mismo

Con 3.000 rutas posibles a través de una CLI, ¿cómo puede tu agente encontrar rápidamente la operación que necesita sin saturar tu contexto? Por eso también añadimos cf cli search.

Este comando le permite a tu agente preguntar en lenguaje natural qué necesita hacer, y un pequeño índice de búsqueda proveerá una lista de comandos apropiados, basados en su descripción de API y sus parámetros. Informamos automáticamente a tu agente sobre este comando cuando ejecuta --help por primera vez.

Configuración que comprueba los tipos de tu agente

Nuestro nuevo formato de configuración está basado en TypeScript, que es fácil de interpretar para humanos y agentes, y te permite escribir tu configuración de forma programática.

La configuración tipada es enormemente útil para los agentes. Hemos comprobado que incluso sin contexto previo del formato de configuración programática, los agentes son capaces de identificar y editar fácilmente la configuración bajo demanda, incluso en elementos como env que han cambiado drásticamente respecto a la misma función en Wrangler. Todos los agentes que usan plugins LSP, como Claude Code y Codex, se benefician de poder interpretar más sobre el formato del archivo de configuración en contexto y hacen sugerencias mucho más precisas como resultado.

Compará esto con TOML, que no tenía un esquema accesible, o JSONC, que tenía un esquema vinculado que los agentes raramente usaban.

Algunos archivos de configuración de Wrangler dentro de Cloudflare se han reducido un 40 % desde más de 5.000 líneas, con muchos entornos personalizados por desarrollador, a archivos predeterminados que construyen la configuración de cada desarrollador de forma más eficiente.

Esto se logra definiendo programáticamente cada entorno desde la misma base universal, en lugar de copiar bloques env como era habitual en Wrangler. Un Worker sencillo con múltiples entornos simplemente cambia con el argumento de modo nativo de Vite para pasar de un conjunto de configuración a otro.

Una configuración simple que hace esto, ahora se ve así:

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`),
      },
    },
}));

Puedes migrar tu Cloudflare Worker a este nuevo formato mediante cf migrate.

También proporcionamos algunas funciones auxiliares para facilitar la creación de tu Worker.

bindings ofrece a tu agente un lugar sencillo para descubrir todo lo que la plataforma de desarrolladores tiene para ofrecer. Todo, desde variables de entorno hasta almacenamiento, bases de datos y colas, puede ser autocompletado y explicado por tu editor.

import { bindings, defineConfig } from "cf/config";

export default defineConfig(({ mode }) => ({
  worker: {
    // ...
    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` }),
      JOBS: bindings.queue < { userId: string } > ({
        name: `example-${mode}-jobs`,
      }),
      AI: bindings.ai(),
      SEARCH_INDEX: bindings.vectorize({
        name: `example-${mode}-search`,
      }),
      API: bindings.worker({ worker: `example-${mode}-api` }),
    },
  },
}));

Del mismo modo, hemos incluido un asistente para triggers, que es la nueva forma de definir rutas, colas, horarios y disparadores de correo electrónico para tu Worker. En lugar de tenerlos dispersos en tu archivo de configuración, ahora es sencillo encontrar, en un solo bloque, las acciones que podrían permitir que tu Worker se ejecute.

import { defineConfig, triggers } from "cf/config";

export default defineConfig({
  worker: {
    // ...
    triggers: [
      triggers.fetch({ pattern: "example.com/*" }),
      triggers.scheduled({ schedule: "0 * * * *" }),
      triggers.queue({ name: "jobs", maxBatchSize: 10 }),
      triggers.email({ addresses: ["support@example.com"] }),
    ],
  },
});

defineConfig.worker es solo el comienzo. Nuestra intención con cloudflare.config.ts es que así sea como gestionas Cloudflare en su totalidad. Cada producto que necesitas, junto con su API disponible para tu agente a través de cf, podrá expresarse mediante una configuración con seguridad de tipos. Pronto podrás configurar políticas completas, establecer zonas, configurar DNS y más, todo a través de este archivo de configuración.

La mejor experiencia de desarrollo

Cuando Wrangler empezó a construir JavaScript Workers, Vite no existía. En su lugar, usábamos esbuild en Wrangler para empaquetar tus Workers. El servidor de desarrollo que Wrangler ponía disponible en :8787 fue algo que el equipo de Wrangler construyó, y modificar cualquier cosa de esto implicaba adentrarse en el proceso interno de herramientas locales específicas de Cloudflare como Miniflare.

Vite supone una enorme mejora al respecto, y viene con un gran ecosistema de plugins, un servidor de desarrollo de primer nivel con HMR (hot module replacement) y compilaciones que usan la biblioteca basada en Rust Rolldown para el tree-shaking. Todo lo que podés hacer con Vite, podés hacerlo con el Cloudflare Vite Plugin.

El Cloudflare Vite Plugin es la forma recomendada de construir Workers, sea lo que sea que estés desarrollando: ya sea un proyecto orientado al frontend o una API de backend. Junto con nuestro plugin de Vitest, proporciona un entorno de desarrollo y pruebas consistente  que se adapta al tiempo de ejecución de Workers y te brinda acceso directo a bindings y a la API de la paltaforma.

cf está construido sobre Vite de forma predeterminada. La mayoría de tus Workers migrarán fácilmente con agentes. Otros pueden necesitar más tiempo, por lo que cf seguirá delegando en Wrangler para el desarrollo y despliegue de JavaScript Workers que necesiten continuar usando esbuild, y también para Rust y Python Workers.

Migración desde Wrangler

Migrar un Worker desde Wrangler es tan sencillo como ejecutar cf migrate.

cf migrate

Los Workers que ya se construyen con Vite se convertirán a cloudflare.config.ts automáticamente. Si tu Worker depende de Wrangler para esbuild, cf seguirá delegando las compilaciones en Wrangler.

Cuando finalice la beta abierta, publicaremos una versión mayor final de Wrangler que te dirigirá a vos y a tu agente a usar cf. Seguiremos ofreciendo soporte de mantenimiento para Wrangler durante 18 meses tras el fin de la beta, para darte tiempo a migrar.

También podés tomar nuevos proyectos y configurarlos automáticamente para Cloudflare ejecutando cf init/deploy, que instalará el Cloudflare Vite Plugin por vos y creará un archivo de configuración.

Los sitios estáticos aún no requieren un archivo de configuración para comenzar, y su implementación es tan sencilla como ejecutar cf deploy en tu proyecto.

Para iniciar un nuevo proyecto Hello World con cf, usá cf init.

cf es de código abierto y los problemas pueden ser reportados en nuestro repositorio de GitHub.