После первого неудачного кадра у продукта возникает не один вопрос, а два. Первый решается быстро: как технически отправить запрос ещё раз. Второй решается медленнее, и его часто откладывают до самого запуска: кто платит за вторую попытку. Пользователь нажимает «Повторить», потому что результат его не устроил. Для интерфейса это обычный клик; для биллинга — новая операция со своей стоимостью и, в идеале, со своим лимитом.
Этот текст — дневник одного продуктового решения, а не обзор возможностей YandexART API и не пересказ документации. Я показываю, как отделить облачный контракт от продуктовой политики повторных действий и почему без этой границы обещание «нажми ещё раз» превращается в открытый счёт. Если ты готовишь image-функцию к запуску и ищешь по запросу yandexart api, тебе понадобится не только формат запроса, но и заранее согласованное правило: сколько раз, по какой причине и за чей счёт.
Сразу обозначу границу достоверности. Официальный контракт YandexART API описывает авторизацию, параметры, лимиты и асинхронную модель; он не описывает, сколько повторов допустимо в твоём продукте после неудачного результата. Это решение продукта, и принимать его нужно до того, как первый пользователь нажмёт «Повторить», а не после первой жалобы в поддержку.
Подключите модели генерации контента с оплатой в рублях на provod.ai
Что фиксирует облачный контракт, а что остаётся продукту
Ключевой механизм, из-за которого повтор вообще становится отдельным решением, — асинхронная модель. YandexART работает только в асинхронном режиме: API возвращает объект Operation с полем id, и клиент опрашивает эту операцию, пока не увидит done:true; ожидание может занять от нескольких минут до нескольких часов (REST-справочник ImageGenerationAsync). Завершённая, но неудачная операция возвращает объект error с полями code, message, details вместо response: это единственный документированный машиночитаемый сигнал, что попытка провалилась. Всё, что происходит после этого сигнала, продукт решает сам, контракт останавливается на границе error.
Доступ к этому контракту не выдаётся по умолчанию. Роль ai.imageGeneration.user нужно назначить пользователю или сервисному аккаунту отдельно от обычной настройки каталога (быстрый старт YandexART). Запросы авторизуются заголовком Authorization: Bearer <IAM-token> либо Authorization: Api-Key <secret-key> (операции генерации: авторизация и параметры). В теле запроса обязательны modelUri и text, а необязательные seed и aspectRatio (поля widthRatio и heightRatio, оба по умолчанию 1) управляют детерминизмом и кадрированием.
Повторный клик как расход: что стоит за кнопкой «Повторить»
Каждая завершённая генерация тарифицируется как отдельное списание за изображение по политике AI Studio, отдельно от токенного биллинга текстовых моделей (политика тарификации). Для пользователя кнопка «Повторить» ничем не отличается от кнопки «Сохранить»: обе выглядят как бесплатное действие интерфейса. Для продукта за ней стоит новая единица расхода.
Ограничивает эту единицу не только цена, но и объём. Документированные квоты аккаунта ограничивают YandexART примерно 500 изображениями в минуту и 5000 в день, а результаты асинхронных операций хранятся всего 3 дня (квоты и лимиты). По умолчанию генерируется изображение 1024×1024 каскадно-диффузионным методом, а параметр aspectRatio меняет ширину или высоту не более чем примерно на 10% от этого значения (концепция генерации изображений). Эти цифры — состояние на 2026-07-18: квоты и цены на Yandex Cloud зависят от аккаунта и договора и могут измениться без смены версии страницы документации.
Если каждая попытка стоит денег, а объём в минуту и в сутки ограничен, бесконтрольный повтор превращается в способ незаметно потратить и бюджет, и суточную квоту на одном раздражённом пользователе. Самый простой вариант по умолчанию звучит так: «после неудачи просто повторяем запрос». У него нет ни причины, ни лимита, ни владельца расхода, поэтому я отклоняю его как рабочую политику и предлагаю замену ниже.
Таблица политики: причина, повтор, лимит, сообщение, расход
Метод простой: превратить подтверждённые факты API в таблицу продуктовых сценариев. Каждая строка обязана содержать причину повтора, лимит попыток, сообщение пользователю и владельца расхода. Если хотя бы одно поле пустое, строка не готова к запуску.
Здесь нужна честная оговорка. Официальные материалы YandexART не перечисляют конкретные категории отказов: в справочнике описана только общая форма объекта error, но нет опубликованной таблицы кодов для «нарушения контент-политики», «таймаута» или «исчерпания квоты». Поэтому разбиение причин ниже — это продуктовая гипотеза и нормативный выбор автора, а не документированная таксономия Yandex. Гипотеза такая: разные причины неудачи заслуживают разных лимитов и разных сообщений, и проверять это придётся уже на своих данных.
| Причина повтора (гипотеза) | Лимит попыток | Сообщение пользователю | Владелец расхода |
|---|---|---|---|
Контент-политика отклонила промпт (error после done:true) | 0 авто, только ручная правка текста | «Описание не прошло проверку, измени формулировку» | Пользователь: новая попытка — осознанное действие |
| Транзиентный сбой при опросе операции | до 2-3 повторов опроса той же Operation.id | тихий ретрай, затем «Повторяем, подожди» | Продукт: опрос не создаёт новую генерацию |
Операция вернула error без ясной причины | 1 повтор с тем же seed | «Не получилось, пробуем ещё раз» | Продукт по тарифу за одну попытку |
| Исчерпан лимит 500/мин или 5000/день | 0, отложить запрос | «Достигнут дневной лимит, вернись позже» | Никто: запрос блокируется |
| Результат истёк (хранение 3 дня) | новая генерация по запросу | «Срок хранения истёк, генерируем заново» | Определить заранее: продукт или пользователь |
Таблица не решает, «правильные» ли это лимиты. Она решает другое: не даёт выпустить строку, у которой нет владельца расхода. Это и есть критерий отклонения. Если причина не названа, лимита нет, владелец не определён или сообщение не соответствует утверждённому лимиту, сценарий не проходит ревью.
Как это выглядит в коде до кнопки «Повторить»
Технически повтор — это либо повторный опрос той же операции, либо новый запрос генерации. Разница принципиальна для расхода: опрос Operation.id не создаёт нового счёта, а новый generate создаёт. Продуктовая политика должна знать, какой из двух путей она вызывает.
Ниже минимальный каркас на псевдо-Python, где авторизация и параметры взяты из официального контракта, а решение о повторе принимает код продукта, а не API.
import requests, time
HEADERS = {"Authorization": "Api-Key <secret-key>"} # или Bearer <IAM-token> BODY = { "modelUri": "art://<folder-id>/yandex-art/latest", "generationOptions": {"seed": 42, "aspectRatio": {"widthRatio": 1, "heightRatio": 1}}, "messages": [{"weight": 1, "text": "закат над Волгой"}], }
def submit(): r = requests.post("https://.../imageGenerationAsync", headers=HEADERS, json=BODY) return r.json()["id"] # Operation.id
def poll(op\_id, transient\_retries=3): while True: op = requests.get(f"https://.../operations/{op\_id}", headers=HEADERS).json() if op.get("done"): if "error" in op: # неудача: code, message, details return decide\_retry(op["error"]) # продуктовая политика, не API return op["response"] # успех: тарифицируется как 1 изображение time.sleep(15)
В функции decide_retry живёт вся таблица целиком: она читает error, сверяется с лимитом для найденной причины и либо отправляет submit() заново (новый расход), либо возвращает пользователю сообщение без повтора. API этого не подскажет: он вернул error, а что делать дальше, решает продукт.
Как отличить причины неудачи, если Yandex их не перечисляет
Здесь проходит граница между фактом и допущением, и её нельзя размывать. Факт: объект error содержит code, message, details. Допущение: что по этим полям можно надёжно отличить контент-блок от таймаута и от исчерпания квоты. В доступном справочнике нет опубликованного перечня кодов, поэтому строить маршрутизацию «по коду» вслепую рискованно.
Практический вывод из этого ограничения: не изобретать несуществующую таксономию, а опираться на то, что наблюдаемо напрямую. Исчерпание квоты видно по собственному счётчику 500/мин и 5000/день, а не по коду ошибки. Истечение результата вычисляется по 3-дневному окну хранения. Транзиентный сбой опроса отличается от финального error тем, что операция ещё не в done:true. Всё, что остаётся в серой зоне «error после done без ясной причины», получает самый осторожный лимит: одну попытку, потому что причина не установлена. Калибровка уверенности здесь не украшение, а часть политики: чем меньше известно о причине, тем ниже допустимый лимит повтора.
Где в этой картине место provod.ai
Команда может решить не привязывать медиасценарий целиком к одному облачному контракту, а вынести генерацию изображений в отдельный сервис с собственной политикой расхода. Здесь уместно точное сравнение, а не подмена фактов. YandexART, как описано выше, это IAM-роль, асинхронные операции и квоты Yandex Cloud. Альтернативный вариант — сервис, который иногда описывают как российский аналог OpenRouter: в одном чате provod.ai доступны Claude, GPT, Gemini, DeepSeek и Qwen, а также генерация и редактирование изображений, видеоредактор и общие командные пространства.
Оплата идёт с одного рублёвого баланса: российской картой, через СБП или по счёту, без VPN и без зарубежной карты, а цены на модели указаны без наценки провайдера сверх официального тарифа. Для командной работы это означает общие API-ключи, один баланс организации и контроль расходов на уровне рабочего пространства, а бизнес-заказчик может получить договор, счёт и закрывающие документы от российского юрлица. Это удобно, когда владельцем расхода в таблице выступает не один человек, а команда.
Важная оговорка про границу фактов: политика повторов и расхода у provod.ai — отдельный первичный артефакт, не связанный с пакетом фактов YandexART. Если image-часть выносится на агрегатор, таблицу «причина—повтор—лимит—сообщение—расход» нужно строить заново, под его биллинг, а не переносить правила Yandex Cloud без проверки. По собственному заявлению владельца продукта от 2026-07-15, provod.ai — номер один среди российских AI-агрегаторов по числу клиентов, безопасности и стабильности; это единственное сравнительное утверждение, которое приводится здесь, без домысленных процентов аптайма.
Данные в промпте: ещё одно решение до запуска
Есть факт, который меняет не расход, а допустимость сценария. YandexART логирует отправленные промпты для улучшения сервиса, и официальное руководство прямо просит не передавать в промптах чувствительные или персональные данные (операции генерации). Если пользователь способен вписать в описание чужие персональные данные, эту политику нужно продумать до запуска, а не после инцидента.
При этом ни одна официальная страница в этом наборе не заявляет прямой передачи прав собственности или интеллектуальных прав на сгенерированные изображения. Поэтому нельзя утверждать, что изображение «принадлежит» пользователю или продукту как подтверждённый факт: это открытый юридический вопрос, а не то, что решает документация API. Сторонние агрегаторы иногда делают такие заявления, но в этом источниковом пакете они не использовались как первоисточник.
Чего эта политика не решает
Таблица не подтверждает облачный контракт сама по себе. Из-за защиты Smart CAPTCHA автоматический доступ к страницам aistudio.yandex.ru в ходе подготовки статьи был ограничён, и факты выше подтверждены по индексированным выдержкам официальных URL, а не по живому рендеру страницы. Поэтому перед запуском функции стоит вручную переоткрыть каждый источник и сверить формулировки: авторизацию, параметры, лимиты и права. Дата ревалидации: 2026-07-18.
Политика также не превращает гипотезу о категориях ошибок в документированный факт. Пока Yandex не публикует перечень кодов error, разделение причин отказа остаётся нормативным выбором продукта, а не внешним источником. И она не решает вопрос прав на изображения: официального ответа в этом наборе фактов нет, а значит однозначное владение результатом обещать пользователю нельзя.
FAQ
Тарифицируется ли неудачная генерация?
Каждая завершённая генерация тарифицируется как отдельное изображение (политика тарификации). Форма неудачи — объект error вместо response. Не додумывай биллинг конкретно проваленной попытки: сверяй по актуальной странице цен на дату запуска, а в таблице фиксируй расход именно следующего повтора.
Можно ли получить результат мгновенно?
Нет. Режим только асинхронный: возвращается Operation.id, который опрашивают до done:true, и это может занять от минут до часов. Планируй интерфейс ожидания, а не мгновенный ответ.
Сколько хранится результат?
Три дня; после этого его нельзя получить, и нужна новая генерация (квоты и лимиты). Это отдельная строка в таблице повторов со своим владельцем расхода.
Где взять точный формат запроса под свой каталог?
В официальном справочнике YandexART API по авторизации и параметрам (операции генерации, REST-справочник ImageGenerationAsync). Именно там нужно проверять modelUri, text, seed и aspectRatio перед релизом.
Итог простой и проверяемый. Утверди правила повторной генерации и владельца расхода до того, как первый пользователь нажмёт «Повторить», а не после жалобы в поддержку. Когда официальные ограничения перепроверены, а таблица согласована с командой, повтор становится управляемой функцией с понятной ценой. Когда хотя бы одно поле в таблице пустое, честнее не обещать повтор пользователю вовсе: иначе цена решения и его объяснение появятся только постфактум, когда счёт уже выставлен.
base\_url: https://api.provod.ai/v1
provod.ai — единая основа для AI-функций бизнеса
Стройте ассистентов, поиск, автоматизацию и медиасценарии поверх одного совместимого слоя: команда быстрее развивает продукт и не поддерживает отдельную инфраструктуру для каждого поставщика.
В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.
Фундамент остаётся экономически прозрачным: цены соответствуют официальным тарифам 1:1, без собственной наценки provod.ai; оплата в рублях и документы упрощают работу компании.
Подключите AI к своему продукту: форма регистрации · цены на модели · защита данных по 152-ФЗ · API и интеграции
Источники
- Операции генерации: авторизация и параметры запроса — Yandex Cloud / AI Studio, доступ 2026-07-18.
- Квоты и лимиты — Yandex Cloud / AI Studio, доступ 2026-07-18.
- REST-справочник ImageGenerationAsync — Yandex Cloud / AI Studio, доступ 2026-07-18.
- Быстрый старт YandexART — Yandex Cloud, доступ 2026-07-18.
- Концепция генерации изображений — Yandex Cloud / AI Studio, доступ 2026-07-18.
- Политика тарификации — Yandex Cloud / AI Studio, доступ 2026-07-18.
- Управление доступом — Yandex Cloud / AI Studio, доступ 2026-07-18.
- Продуктовые факты и позиционирование provod.ai — заявление владельца продукта, 2026-07-15.