cf — CLI от Cloudflare, который открывает агенту весь API

Cloudflare выпустил новый CLI под назвалом cf. Он открывает агенту весь API Cloudflare — больше 3000 операций вместо примерно 280 у Wrangler, — отдаёт JSON по умолчанию и переводит конфигурацию Workers на TypeScript с проверкой типов. Установка — одна команда:

npm i -g cf

Начнём с цифр, которые объясняют, зачем это понадобилось. В марте 2026 года на агенты приходилась четверть всех запусков Wrangler, а годом раньше доля была однозначной. На неделе анонса — уже 48%. Агенты выполняют примерно вдвое больше разных команд за день и почти в четыре раза чаще запускают шесть команд и больше.

При этом агенты умеют работать с CLI хорошо, но Wrangler покрывал только около 280 операций, тогда как у Cloudflare их тысячи. Раньше каждую команду писали вручную внутри команды, отвечавшей за продукт, и единый стиль во всём этом просто не поддерживался. Названия в d1 info, hyperdrive get и workflows describe отличались друг от друга, потому что команды появлялись в разное время. Какие-то команды пришлось писать тысячами строк, а пользовались ими единицы.

Откуда взялись 3000 команд

Cloudflare решил задачу с другой стороны. У компании есть внутренний конвейер под названием Forge, который собирает CLI и SDK прямо из схемы API. Всё, что Cloudflare отдаёт наружу, описано схемой OpenAPI. Если в неё добавить немного метаданных, из неё можно сгенерировать CLI.

Благодаря этому cf покрывает не 280 операций, как Wrangler, а весь API Cloudflare — свыше 3000. Теперь агенту можно дать cf и поручить длинную цепочку дел: поставить Worker, задеплоить его, включить наблюдение, закрыть доступ через Cloudflare Access, купить домен и поставить перед ним Cloudflare WAF. Всё это — из одного инструмента.

Почему не доработали Wrangler

Звучит странно: у Cloudflare был Wrangler, о котором модели уже много знают, и вместо него они выпустили новый инструмент с нуля.

Причина в том, как устроены языковые модели. Документация, статьи и чужие руководства по Wrangler давно попали в обучающие данные. Это плюс: модель сразу понимает, как с ним работать. И это же минус: любое изменение поведения Wrangler идёт против того, чему модель научилась. А масштаб нужных улучшений таков, что серьёзных изменений не избежать.

С новым CLI, которого агент никогда не видел, получается чище. Когда в начале работы агент получает подсказки о том, как пользоваться инструментом, и дополнительные файлы AGENTS.md с описанием команд, переход на новый инструмент путает меньше, чем попытка объяснить агенту все различия между двумя версиями знакомого ему Wrangler.

JSON по умолчанию, а не таблицы

Когда агент работает с Wrangler, он дописывает к каждой команде --json, а потом часто прогоняет вывод через jq, чтобы вытащить нужные поля. Но --json поддерживали только часть команд — остальные отдавали таблицы, нарисованные символами Unicode, для человека в терминале. Агент в состоянии разобраться, но платит за это дополнительным временем и токенами.

В cf решение обратное. JSON стоит по умолчанию: для человека он печатается с отступами, для агента — слитно, чтобы экономить контекст. Если главный пользователь инструмента — агент, то JSON и должен быть значением по умолчанию. Агенту проще отфильтировать результат и вернуть вам только нужное в том виде, в котором вы попросили. Таблицы вы всё равно почти не читали бы.

Исключение — команды, где нужно ваше личное решение. Например, покупка домена. Для таких случаев CLI показывает форму: cf раскладывает требования API на отдельные проверяемые поля, и заполнить их проще, чем передавать агенту длинную цепочку параметров. Если не хочется — попросите агента сделать это за вас.

Агент сам найдёт нужную команду

Три тысячи маршрутов — это много, и агенту нужно найти нужный быстро, не раздувая контекст. Для этого в cf есть отдельная команда cf cli search.

Агент описывает задачу обычным текстом, а небольшой поисковый индекс подбирает подходящие команды по их описаниям в API и по параметрам. Когда агент впервые запускает cf --help, cf сам рассказывает ему про эту команду.

Конфигурация на TypeScript, которую проверит редактор

Новый формат конфигурации — cloudflare.config.ts. TypeScript удобен и человеку, и агенту: файл можно не только прочитать, но и править программно. Агенту не нужен предварительный разбор формата — он сам находит нужное место в файле и вносит правку, даже если структура заметно отличается от того, что он видел раньше.

Отдельно полезны агенты с подключением к LSP — например Claude Code и Codex. Они получают больше сведений о формате файла и потому дают заметно более точные подсказки. Для сравнения: у TOML не было доступной схемы, а у JSONC схема была, но агенты её почти не открывали.

Внутри Cloudflare это дало заметный эффект. Некоторые файлы конфигурации Wrangler сократились на 40%: вместо 5000 с лишним строк с кучей блоков env у каждого разработчика появились компактные файлы, которые собирают конфигурацию программно. Каждое окружение описывается из одного общего шаблона, а не копируется. Простой Worker с несколькими окружениями переключается аргументом mode, который пришёл из Vite:

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

Миграция с прежнего формата выполняется одной командой cf migrate.

bindings: список всех возможностей платформы

Чтобы агенту было легко разобраться, что платформа вообще умеет, добавлена группа помощников bindings. Через неё в одном месте собираются переменные окружения, хранилища, базы данных и очереди. Редактор подставляет названия и показывает описания сам:

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

triggers: что запускает Worker

Отдельный помощник triggers собирает в один блок всё, что может запустить 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 — только начало. Замысел в том, чтобы cloudflare.config.ts управлял всей Cloudflare: политики, зоны, DNS и остальное тоже должны описываться в этом файле с проверкой типов. Сейчас это ещё впереди.

Vite становится умолчанием

Когда Cloudflare только делала Workers на JavaScript, Vite ещё не существовал: сборка шла на esbuild, а сервер разработки на порту 8787 писали внутри Cloudflare, поверх Miniflare. Любая правка означала ковыряние во внутренностях.

Теперь Vite — значение по умолчанию. Это готовый сервер разработки с горячей перезагрузкой модулей (HMR), сборка на основе библиотеки Rolldown, которая удаляет неиспользуемый код, и большая экосистема плагинов. Cloudflare предлагает свой плагин для Vite как основной способ собирать Workers — независимо от того, что вы пишете: фронтенд или серверный API. Вместе с плагином для Vitest он даёт среду разработки и тестирования, которая ведёт себя так же, как настоящая среда выполнения Workers, и даёт прямой доступ к bindings и API платформы.

Часть проектов продолжит сборку через Wrangler: Worker на esbuild, а также Worker на Rust и Python.

Переход с Wrangler

cf migrate

Если Worker уже собирается через Vite, конфигурация будет переведена на cloudflare.config.ts автоматически. А тем, кому нужна сборка на esbuild, cf продолжит передавать её Wrangler.

После завершения открытого бета-релиза выйдет финальная мажорная версия Wrangler, которая будет отправлять вас и вашего агента в cf. Поддержку Wrangler будут вести ещё 18 месяцев после закрытия беты.

Новый проект можно настроить автоматически: cf init/deploy поставит плагин Cloudflare для Vite и создаст файл конфигурации. Статические сайты вообще не требуют файла конфигурации — достаточно запустить cf deploy в папке проекта. Для стандартного Hello World достаточно cf init.

cf — открытый проект, исходный код лежит на GitHub, там же принимают сообщения об ошибках.