Llega 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, frente a porcentajes de un solo dígito el año anterior. La semana pasada, el uso por parte de los agentes alcanzó el 48 %.

Los agentes son usuarios más activos: utilizan casi el doble de comandos distintos al día y son casi cuatro veces más propensos a 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 unas 280 operaciones, y Cloudflare ofrece miles.

A principios de año adelantamos cómo pensábamos resolver esto y hoy, permitimos a los agentes usar todos los productos de Cloudflare con la llegada de una nueva CLI: cf.

cf es una CLI diseñada para la próxima generación de desarrollo de software:

• Los agentes pueden encontrar el comando que necesitan para hacer cualquier cosa que quieran con una búsqueda y orientación personalizadas.
• JSON es la interfaz predeterminada, con formato legible para los humanos y condensado para los agentes, con el fin de ahorrar el máximo contexto.
• cloudflare.config.ts es el nuevo formato de configuración para todo Cloudflare, empezando por Workers, y te 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 potentes, pero lo que podían hacer con la CLI de Cloudflare seguía siendo limitado.

Wrangler se creó a mano con la colaboración de cada equipo de producto, y cada uno aplicaba su propio enfoque a la experiencia de desarrollo de comandos. Imponer patrones comunes entre los equipos era prácticamente imposible, incluso entre nuestras aproximadamente 280 rutas de comandos. Teníamos una terminología inconsistente en d1 info, hyperdrive get o workflows describe, ya que cada equipo había desarrollado sus propias prácticas en momentos diferentes. Algunos equipos crearon experiencias totalmente personalizadas con miles de líneas de código que al final se usaban muy de vez en cuando, y los equipos ideaban enfoques diferentes para resolver los mismos problemas.

Queríamos tanto estandarizar lo que teníamos como hacer una expansión a lo grande, todo a la vez. Forge — el nuevo proceso unificado de generación de API de Cloudflare — nos permitió hacerlo, basándonos en la idea de generar nuestros comandos de la CLI directamente a partir del esquema de la API que alimenta nuestra documentación de la API y la generación del SDK. Todo lo que ofrecemos tiene un esquema OpenAPI, y si lo anotamos con solo un poco más de información, podemos usarlo como fuente para que Forge cree una CLI.

Esto nos permite ampliar cf desde las 280 funciones que Wrangler había ido creando con el tiempo, hasta cubrir la totalidad de la superficie de la API de Cloudflare, con más de 3000 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 ha usado cf

cf está diseñado para la evolución de la ingeniería de software, donde el desarrollo agéntico está cambiando drásticamente la forma en que se crea y se implementa el software. Este año nos hemos centrado en ofrecer herramientas que apoyen este cambio, lo que ha culminado en cf. cf se ha creado desde cero pensando en los agentes e incluye herramientas novedosas para el descubrimiento de comandos agénticos que creemos que se convertirán en estándar en más CLI en un futuro próximo.

Wrangler traía la ventaja de que años de documentación, blogs y guías de terceros se han incorporado al proceso de entrenamiento de los modelos de lenguaje de gran tamaño (LLM). Pero también traía la misma desventaja: cambiar cómo funciona Wrangler ahora va en contra del comportamiento aprendido, y un cambio significativo sería inevitable dada la magnitud de las mejoras que queremos implementar.

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, a las inyecciones de contexto que podemos realizar y a los archivos AGENTS.md que podemos añadir, hacer el cambio de esta forma resulta, en realidad, menos confuso que hacer que un agente contextualice las principales diferencias entre dos versiones de una herramienta con la que está familiarizado. Lanzamos la herramienta con un par de estas funciones centradas en los agentes ya integradas, y pronto habrá más.

Los agentes necesitan filtrar JSON, no mirar tablas

Cuando los agentes usan Wrangler, añaden --json a cada comando que ejecutan y luego a menudo filtran 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 que los humanos vieran 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 valor por defecto. Para la gran mayoría de los comandos a los que los humanos rara vez accederán, esta es, obviamente, la decisión correcta.

Tú, como usuario humano de esta CLI, estás, en realidad, un paso alejado de usarla. Es preferible que los agentes puedan filtrar fácilmente sus resultados y luego devolverte esa lista filtrada en el formato que pidas, en lugar de proporcionarte tablas que probablemente nunca leerás directamente.

Pero, ¿y si quieres hacer algo que pueda requerir una intervenció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 y complicada, solo tienes que rellenar un formulario. Cf descompone los requisitos de la API en una serie de entradas validadas, por lo que comprar un dominio, incluso uno con requisitos complejos, es muy sencillo de seguir.

O, si lo prefieres, simplemente pídele a tu agente que lo haga.

Tu agente puede encontrar el comando correcto por sí mismo

Con 3000 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 hemos añadido cf cli search.

Este comando permite a tu agente preguntar en lenguaje natural qué necesita hacer, y un pequeño índice de búsqueda proporcionará 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 se basa en TypeScript, que es fácil de analizar tanto para las personas como para los agentes, y te permite escribir tu configuración mediante programación.

La configuración tipada es de gran ayuda 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.

Compáralo con TOML, que no tenía un esquema accesible, o con JSONC, cuyo esquema vinculado los agentes apenas utilizaban.

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

Esto se consigue definiendo programáticamente cada entorno a partir de la misma base universal, en lugar de copiar bloques env como solía hacerse en Wrangler. Un Worker sencillo con varios entornos solo tiene que activar el argumento mode nativo de Vite para cambiar de un conjunto de configuración a otro.

Una configuración sencilla que hace esto tiene ahora este aspecto:

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 te ofrecemos algunas funciones de ayuda para que crear tu Worker sea muy fácil.

bindings te ofrece un lugar sencillo para que tu agente descubra todo lo que la plataforma para desarrolladores tiene que ofrecer. Todo, desde las variables de entorno hasta el almacenamiento, la base de datos y las colas, puede autocompletarse y explicarse desde 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 una función de ayuda para los triggers, que es la nueva forma de definir rutas, colas, programaciones y triggers de correo electrónico para tu Worker. En lugar de tenerlos dispersos por tu archivo de configuración, ahora es muy fácil encontrar, en un único bloque, las acciones que podrían activar la ejecución de tu Worker.

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 principio. Nuestra intención con cloudflare.config.ts es que así sea como gestiones Cloudflare en su conjunto. Todos los productos que necesites, junto con su API, disponible para tu agente a través de cf, podrán expresarse mediante una configuración segura en cuanto a tipos. Pronto podrás configurar políticas completas, configurar zonas, configurar el DNS y mucho más, todo a través de este archivo de configuración.

La mejor experiencia de desarrollo de su clase

Cuando Wrangler empezó a crear JavaScript Workers, Vite aún no existía. En su lugar, usábamos esbuild en Wrangler para empaquetar tus Workers. El servidor de desarrollo que Wrangler ponía a tu disposición en el puerto :8787 era algo que había creado el equipo de Wrangler, y modificar cualquier parte de esto significaba meterte en el funcionamiento interno de herramientas locales específicas de Cloudflare, como Miniflare.

Vite supone una mejora enorme en este sentido y cuenta con un amplio ecosistema de plugins que puedes utilizar, además de ofrecer un servidor de desarrollo de primera clase con HMR (sustitución de módulos en caliente) y compilaciones que usan la biblioteca Rolldown, basada en Rust, para el “tree-shaking”. Todo lo que puedas hacer con Vite, lo puedes hacer con el plugin de Cloudflare para Vite.

El plugin de Cloudflare para Vite es la forma recomendada que te sugerimos para crear Workers, sea lo que sea lo que estés desarrollando: ya sea un proyecto centrado en el frontend o una API de backend. Junto con nuestro plugin Vitest, ofrece un entorno de desarrollo y pruebas cohesionado que se adapta al tiempo de ejecución de Workers y te da acceso directo a los bindings y a las API de la plataforma.

cf se basa en Vite de forma predeterminada. La mayoría de tus Workers migrarán fácilmente con los agentes. Otros pueden tardar más tiempo, por lo que cf seguirá recurriendo a Wrangler para el desarrollo y la implementación de los Workers de JavaScript que necesiten seguir utilizando esbuild, así como de los Workers de Rust y Python.

Migración desde Wrangler

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

cf migrate

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

Cuando termine la versión beta abierta, lanzaremos una versión final importante de Wrangler que os indicará a ti y a tu agente que utilicéis cf. Seguiremos ofreciendo soporte de mantenimiento para Wrangler durante 18 meses tras el fin de la versión beta, para que tengáis tiempo de migrar.

También puedes crear proyectos nuevos y configurarlos automáticamente para Cloudflare ejecutando cf init/deploy, lo que instalará el plugin de Cloudflare para Vite por ti y creará un archivo de configuración.

Los sitios estáticos siguen sin necesitar un archivo de configuración para ponerse en marcha, y desplegarlos es tan sencillo como ejecutar cf deploy en tu proyecto.

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

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