Cloudflare Workers AI: rejectIfBusy для быстрых отказов без очереди

17 сентября 2026 года Cloudflare добавила в Workers AI новую опцию rejectIfBusy. Она позволяет синхронному inference-запросу сразу завершиться ошибкой, если в этот момент нет свободной мощности, вместо ожидания в capacity queue.

На первый взгляд это небольшая настройка API. На практике она даёт разработчику важный выбор между двумя режимами поведения: ждать, пока появится доступная мощность, или быстро получить отказ и самостоятельно решить, что делать дальше.

Официальный источник: Cloudflare Workers AI Changelog, 17 сентября 2026.

Что меняет rejectIfBusy

Без специального режима синхронный запрос Workers AI может ожидать доступную capacity. Для некоторых задач это нормально: пользователь готов подождать, а дополнительная задержка предпочтительнее ошибки.

Но есть сценарии, где ожидание хуже быстрого отказа. Например, backend должен уложиться в жёсткий timeout, чат-бот может переключиться на другую модель, а API-шлюз умеет повторить запрос позже.

Именно для этого появился rejectIfBusy. Если capacity недоступна, запрос не остаётся ждать очередь, а возвращает ошибку сразу.

Как включить fail-fast через Workers binding

Для Workers AI binding опция передаётся третьим аргументом в env.AI.run().

const response = await env.AI.run(
  "@cf/google/gemma-4-26b-a4b-it",
  {
    messages: [
      { role: "user", content: "Проверь статус заказа" }
    ]
  },
  {
    rejectIfBusy: true
  }
);

Это не меняет модель и не ускоряет inference сам по себе. Настройка влияет именно на поведение при нехватке мощности.

Как использовать rejectIfBusy через REST API

В native REST API параметр передаётся внутри объекта options.

{
  "messages": [
    {
      "role": "user",
      "content": "Сформируй краткий ответ"
    }
  ],
  "options": {
    "rejectIfBusy": true
  }
}

Cloudflare отдельно документирует тот же режим для OpenAI-compatible интерфейса, поэтому его можно учитывать и в интеграциях, которые уже построены вокруг совместимого API-клиента.

Какую ошибку вернёт Workers AI

В документации Cloudflare ошибка нехватки мощности обозначена внутренним кодом 3040 и HTTP-кодом 429. Тот же ответ используется, когда запрос отклонён из-за rejectIfBusy.

Это важная деталь для backend-логики. Нельзя воспринимать любой 429 как одинаковую проблему и бесконечно повторять запрос. Нужно понимать, какой retry допустим, сколько попыток делать и есть ли более подходящий fallback.

Где быстрый отказ полезнее ожидания

• чат-бот должен ответить в ограниченное время;
• есть резервная модель или другой AI-провайдер;
• запрос можно безопасно повторить позже;
• frontend не должен держать долгое открытое соединение;
• операция некритична и пользователь может получить обычный ответ без AI;
• backend работает внутри короткого serverless timeout;
• очередь задач уже реализована на стороне приложения.

Пример с fallback на другую модель

Один из практичных сценариев — использовать основную модель, а при 429/3040 переключаться на резервную. Но fallback должен быть осознанным: другая модель может отличаться по стоимости, качеству, длине контекста и поддерживаемым инструментам.

Поэтому правильная схема обычно выглядит так: сначала выполняется основной запрос, затем проверяется конкретный тип ошибки, после этого выбирается fallback или контролируемый retry. Нельзя просто повторять запрос без лимита.

Retry тоже должен быть ограниченным

Если приложение решает повторить запрос, лучше использовать ограниченное число попыток и задержку между ними. Для внешних API я придерживаюсь того же принципа, который описывал в статье про webhook и API-интеграции без дублей: повтор должен быть управляемым и безопасным.

Для AI-запросов это особенно важно, потому что бесконтрольный retry может увеличить задержку, стоимость и нагрузку, но не устранить саму проблему capacity.

Когда rejectIfBusy лучше не включать

Fail-fast подходит не всегда. Если запрос критичен и пользователь готов подождать, обычная очередь может быть полезнее. Например, при генерации отчёта в фоновом процессе лишние несколько секунд могут быть несущественны.

Также не стоит включать быстрый отказ только ради более короткой средней задержки. Нужно заранее определить, что произойдёт после ошибки. Без fallback, retry или понятного ответа пользователю приложение просто начнёт чаще показывать сбой.

Что это даёт бизнес-приложению

Для бизнеса ценность не в самом параметре rejectIfBusy, а в возможности сделать поведение системы предсказуемым. Если AI временно перегружен, приложение заранее знает, какой сценарий использовать дальше.

Например, бот поддержки может вернуть заранее подготовленный ответ, CRM-интеграция может поставить задачу на повторную обработку, а внутренний помощник — переключиться на резервную модель.

Такой подход полезен в AI-автоматизации бизнеса, где важно проектировать не только успешный путь, но и контролируемое поведение при временных ошибках внешних сервисов.

Как это связано с Cloudflare Workers

Workers часто используются как промежуточный слой между сайтом, ботом, CRM и внешними API. Поэтому управление ошибками AI удобно делать именно там: Worker может проверить статус ответа, ограничить retry, выбрать fallback и вернуть клиенту единый формат результата.

При этом доступы такого Worker лучше ограничивать по принципу least privilege. Недавно я отдельно разбирал гранулярные роли Cloudflare Workers для AI-агентов и CI/CD.

Практическая схема обработки

Вывод

rejectIfBusy даёт разработчику простой способ выбрать fail-fast поведение для синхронных Workers AI запросов. Если capacity занята, приложение может сразу получить 429/3040 и перейти к собственному сценарию восстановления вместо неопределённого ожидания.

Это небольшая функция API, но хороший пример зрелой архитектуры: надёжность AI-интеграции определяется не только моделью, а тем, насколько хорошо система умеет обрабатывать перегрузку, timeout, retry и fallback.

Если нужно связать AI, сайт, CRM, API или Cloudflare Workers в устойчивый workflow, можно описать задачу A.S Groups. Сначала определим точки отказа и правила повторов, затем соберём интеграцию без лишнего дублирования и бесконтрольных retry.