previous_response_id позволяет продолжить диалог без ручной пересылки истории. В следующем запросе вы передаёте идентификатор предыдущего ответа и новое сообщение, а API использует связанный контекст.
История снова учитывается во входе: прежние входные токены цепочки не становятся бесплатными, прямо предупреждает документация OpenAI.
Что нужно передавать заново
Важное исключение касается instructions, верхнеуровневого поля с инструкциями для модели. Его содержимое из прошлого ответа через previous_response_id не переносится. Поэтому правила приложения, язык ответа и ограничения формата, размещённые именно в instructions, отправляйте в каждом запросе. OpenAI отдельно подчёркивает это в руководстве по переходу на Responses.
Не путайте историю разговора с настройками нового вызова. Храните актуальную конфигурацию приложения отдельно и явно собирайте следующий запрос. Так смена шаблона не зависит от предположения «сервер всё запомнил».
Не добавляйте полную копию старой переписки одновременно с previous_response_id без конкретной причины: вы сами усложняете контроль над контекстом.
Как контролировать расход и хранение
- Записывайте response.id (идентификатор ответа) и usage (данные о расходе) каждого завершённого вызова. Сравнивайте рост input_tokens (числа входных токенов) между ходами, а не только длину нового вопроса.
- Разделяйте независимые задачи на разные цепочки. Короткому вопросу о новом документе обычно не нужна вся предыдущая отладка.
- Если нужно удалять лишние сообщения или менять историю, самостоятельно управляйте входными Items, то есть элементами истории запроса. Это официально предусмотренная альтернатива цепочке ID.
- Не считайте ID бессрочным архивом. Обычные Response-объекты по умолчанию сохраняются на 30 дней; store: false отключает такое сохранение. Для долговременного объекта разговора предусмотрен Conversations API, у которого другое правило хранения.
Последние различия описаны в руководстве по состоянию разговора. Наличие сохранённого ответа, его участие в контексте и стоимость следующего запроса следует проверять отдельно.
Что проверить перед выпуском интеграции
- Выполните два связанных хода с одинаковыми instructions.
- Начните новую независимую цепочку.
- Сохраните фактический usage и убедитесь, что приложение не продублировало историю.
Это план проверки, а не обещание конкретной экономии.
Проверено 10 ноября 2026 года.
Последнее редактирование: