Допустим, интернет-магазин в Караганде в середине октября перевёл маршрутизацию обращений на Decisions API. Разработчик сделал всё по уму: в начало запроса положил подробную инструкцию – девять отделов, описания, по паре примеров на каждый, около полутора тысяч токенов. Следом идёт сообщение клиента. Бот разводит обращения по очередям в CRM, счёт за месяц – копейки, все довольны.
Код с тех пор никто не трогал. Но 22 октября Decisions API вышел из беты, и правила оплаты поменялись без единой строки с вашей стороны. Если запрос собран неудачно, тот же поток обращений обойдётся примерно на четверть дороже. Если удачно – больше чем вдвое дешевле. Разница в одной отметке внутри запроса.
Откуда повод
22 октября 2026 года OpenAI объявила Decisions API общедоступным. Модель по-прежнему одна – gpt-6-luna. Добавились кэширование общей части запроса, картинки внутри отдельных вопросов, структурированные данные через input_json и до 400 вопросов в одном запросе вместо 200.
Что такое Decisions API и как строить на нём маршрутизацию с порогами уверенности, мы подробно разбирали в статье «Decisions API от OpenAI: маршрутизация обращений в CRM». Здесь – только то, что изменилось после беты, и что из этого нужно поправить у себя.
Главное за минуту
Запись в кэш платная
Общая часть запроса от 1 024 токенов кэшируется сама. Чтение стоит десятую часть входа, запись – в 1,25 раза дороже обычного входа.
Короткие запросы не задело
Если общая часть короче 1 024 токенов, кэша нет, и вы платите столько же, сколько в бете.
Карточка CRM как JSON
Статус клиента и открытые заказы можно передать объектом, без склейки в текст.
Фото по ссылке
Кроме base64 теперь принимаются ссылки, но только общедоступные. Вложения из мессенджеров под это обычно не подходят.
Что изменилось в Decisions API после беты
Изменения в одной таблице – с поправкой на бота, который разводит обращения по отделам.
| Было в бете | Стало с 22 октября | Что сделать |
|---|---|---|
| Кэш не оплачивался | Общая часть от 1 024 токенов кэшируется по умолчанию, запись платная | Проверить длину инструкции и поставить точку кэша вручную |
| До 200 вопросов в запросе | До 400 | Решить, нужно ли объединять проверки в один запрос |
| Только текст и картинки | Плюс input_json для структурированных данных |
Передавать карточку клиента из CRM объектом |
| Картинки только в base64 | Ещё и по общедоступной ссылке, а также внутри отдельного вопроса | Для вложений из мессенджеров оставить base64 |
| Отдельного отчёта по расходам не было | Отдельный отчёт GET /v1/organization/usage/decisions |
Подключить его к ежемесячной сверке затрат |
О несовместимых изменениях документация не сообщает. Но «работает как раньше» ещё не значит «стоит как раньше».
Кэш в Decisions API: где экономия, а где лишний платёж
Запрос к Decisions API состоит из общего входа (input) и списка вопросов. Кэшируется только общий вход. Вопросы, включая картинки внутри них, в кэш не попадают никогда и каждый раз оплачиваются как обычный вход.
По умолчанию OpenAI ставит точку кэша в конце общего входа. Для магазина из начала статьи это значит, что в кэш каждый раз пишется инструкция вместе с сообщением клиента. Сообщение в следующем запросе другое, а по правилам OpenAI префикс совпадает только целиком – значит, повторно записанное не прочитает никто. Платим за запись по повышенной ставке и ничего не получаем взамен.
Лечится это явной точкой. Отметка prompt_cache_breakpoint ставится в конце неизменной части – инструкции с описаниями отделов. Режим prompt_cache_options.mode переводится в "explicit", тогда кэш пишется только там, где вы отметили. Всё, что идёт после точки, оплачивается по обычной цене входа без надбавки за запись. Сама OpenAI в руководстве по кэшированию советует явный режим именно для запросов с меняющимся хвостом.
Отдельная ловушка – длинные вопросы. Хочется вынести описание каждого отдела в инструкцию к вопросу: так нагляднее. Но вопросы вне кэша, и полторы тысячи токенов описаний будут оплачиваться полностью в каждом запросе. Всё, что одинаково для всех обращений, держите в общем входе, а в вопросах – короткую формулировку.
Срок хранения в описании Decisions API не указан. По общему правилу OpenAI кэш живёт 30 минут и продлевается при каждом чтении. Для магазина, где обращения идут весь день, это почти всегда попадание. Ночью кэш истечёт, и утром первый запрос запишет его заново. Как работает 12-часовой кэш и когда за него стоит доплачивать, мы считали в статье «Кэш промптов OpenAI: 12 часов и плата за запись – как не переплатить». Применим ли он к Decisions API, документация не говорит.
Расчёт на 100 000 обращений в месяц
Возьмём условный запрос: инструкция с отделами и примерами – 1 500 токенов, карточка клиента и сообщение – 500, вопросы – 200. Цены gpt-6-luna: вход $0,10 за 1 млн токенов, чтение кэша $0,01, запись на 30 минут $0,125, выход не оплачивается. Курс – около 450 тенге за доллар.
| Вариант | Расчёт | В месяц |
|---|---|---|
| Как было в бете, без кэша | 220 млн токенов по $0,10 | $22, около 9 900 тенге |
| Точка по умолчанию, ни одного попадания | 200 млн токенов записи по $0,125 и 20 млн токенов вопросов по $0,10 | $27, около 12 150 тенге |
| Явная точка после инструкции | 150 млн токенов чтения по $0,01, 70 млн по $0,10, перезапись по утрам – меньше $0,50 | Около $9, около 4 000 тенге |
| Короткий запрос на 500 токенов, кэш не включается | 50 млн токенов по $0,10 | $5, около 2 250 тенге, как в бете |
Вторая строка – худший случай: мы предполагаем, что ни один запрос не прочитал кэш. На практике часть попаданий может случиться, но рассчитывать на это не стоит. Если включена обработка данных в выбранном регионе, ко всем строкам добавляется надбавка.
Суммы, честно говоря, смешные, и ради них никто не стал бы переписывать интеграцию. Но инструкции растут: через полгода в них двадцать отделов и тридцать примеров, а поток обращений вырос вдесятеро. Тогда та же ошибка стоит десятки тысяч тенге. Поставить точку сейчас – пять минут работы.
Карточка клиента из CRM через input_json
Самое полезное изменение для маршрутизации, на наш взгляд, не кэш, а input_json. «Где мой заказ?» от нового клиента и от клиента с двумя заказами в доставке – разные обращения. Раньше карточку склеивали в текст, теперь её можно передать объектом рядом с сообщением:
- статус клиента – новый, постоянный, оптовый;
- открытые заказы и их этапы – оплачен, передан в доставку, ожидает возврата;
- открытая жалоба за последние семь дней – да или нет;
- закреплённый менеджер, если обращение стоит вернуть ему, а не в общую очередь.
Есть два ограничения. input_json принимается только в сообщениях с ролью user. И ключи внутри объекта – просто данные: поле с названием role или image_url не превратится в отдельное сообщение и не заставит модель загружать картинку. Это скорее плюс: имя клиента из CRM не сможет выдать себя за инструкцию.
С персональными данными действует старое правило: в запрос уходит только то, что нужно для решения. Для выбора отдела не нужны ни телефон, ни ИИН, ни адрес. Этап заказа нужен, имя – нет. Региональная обработка у Decisions API по-прежнему доступна только в США и Европе.
Проверим, сколько стоит ваша маршрутизация
Пришлите пример запроса к Decisions API без персональных данных – посмотрим, где поставить точку кэша и какие поля карточки CRM стоит передавать.
400 вопросов в одном запросе: зачем столько
Для маршрутизации хватает трёх-пяти вопросов: отдел, срочность, отказ от рассылки. Лимит в 400 нужен для другой задачи – проверки по длинному списку. Например, переписку менеджера с клиентом можно прогнать по стандарту обслуживания: поздоровался ли, назвал ли срок доставки, предложил ли оплату в рассрочку, не пообещал ли того, чего нет в прайсе. Сорок пунктов – сорок вопросов-условий, один запрос, вероятность по каждому.
Помните про кэш: сорок подробных вопросов – это тысячи некэшируемых токенов, так что пояснения к стандарту держите в общем входе. И зависимые вопросы – «есть ли жалоба» и «на что именно жалуются» – по-прежнему лучше задавать отдельными запросами.
Для учёта расходов пригодится новый отчёт по Decisions API. Он требует ключ администратора с правом api.usage.read. Имейте в виду: поле num_model_requests считает запросы, а не вопросы, поэтому запрос с сорока проверками в нём одна единица. А в ответе на каждый запрос есть поля cached_tokens и cache_write_tokens – по ним за день видно, работает ли кэш или вы оплачиваете одни записи.
Фото по ссылке: удобно, но не для мессенджеров
В бете картинку можно было отправить только внутри запроса, в base64. Теперь подходит и ссылка – при условии, что она общедоступна. Для вложений из мессенджеров это условие обычно не выполняется. Ссылка на медиафайл в WhatsApp Cloud API открывается только с токеном доступа. А ссылка на файл в Telegram Bot API содержит токен самого бота, и отдавать её внешнему сервису – значит отдать ключ от бота.
Ссылки полезны там, где фото уже лежит в вашем хранилище: снимки брака, которые приёмщик загрузил в карточку возврата. Но и здесь не делайте файлы публичными навсегда. На накладной или чеке легко оказываются имя и адрес клиента, поэтому лучше выдавать ссылку, которая живёт несколько минут. Идентификаторы файлов, загруженных в OpenAI, этот адрес по-прежнему не принимает.
Чего после беты так и не появилось
Выход из беты обычно читают как «теперь можно в бой». Отчасти так и есть, но кое-что важное документация по-прежнему не закрывает:
- Выбора модели. Работает только
gpt-6-luna. - Описанных лимитов на частоту запросов и списка поддерживаемых языков. Качество на казахском и смешанной речи проверяйте на своих сообщениях.
- Политики версий. Как OpenAI будет менять интерфейс и предупреждать об этом, не сказано.
- Ясности со сроком кэша. Настройка 12-часового хранения в описании Decisions API не упоминается.
- Обработки в регионе ближе Европы. Казахстанского или соседнего варианта нет.
- Независимых замеров скорости. «В десять раз быстрее Responses API» – по-прежнему оценка самой OpenAI.
Мы бы не откладывали из-за этого запуск, но и ставить Decisions API единственной точкой отказа в маршрутизации не стали бы. Если API не ответил, обращение должно уйти в общую очередь, а не потеряться.
Что проверить на этой неделе
Если маршрутизация на Decisions API у вас уже работает, хватит одного короткого захода:
- Посчитать длину общего входа. Меньше 1 024 токенов – по кэшу ничего делать не нужно.
- Если больше – поставить явную точку после неизменной инструкции и перевести кэш в режим
explicit. - Вынести длинные пояснения из вопросов в общий вход.
- Записывать
cached_tokensиcache_write_tokensв лог и через день сравнить: чтений должно быть заметно больше, чем записей. - Решить, какие поля карточки CRM помогут выбрать отдел, и передавать только их через
input_json. - Для вложений из WhatsApp и Telegram оставить скачивание и base64.
- Подключить отчёт
/v1/organization/usage/decisionsк ежемесячной сверке расходов.
Связанные материалы
- Автоклассификация обращений: intent, entities и routing – как сделать и где ломается
- Новые правила сбора персональных данных: лиды, маскирование, ИИ
- AI-боты для входящих обращений
Настроим маршрутизацию обращений на Decisions API под вашу CRM
Соберём запрос с карточкой клиента и правильной точкой кэша, подберём пороги уверенности на ваших сообщениях и покажем расход на месяц вперёд. Первый прогон – за неделю.