Assistants API офіційно вимкнено 26 серпня 2026 року, і він більше недоступний. Робочі застосунки мають перенести генерацію, стан діалогів, інструменти та потоки даних до Responses API. Безпечний шлях полягає в тому, щоб проінвентаризувати кожен Assistant, Thread, Run та інструмент, відтворити поведінку в конфігурації Responses, імпортувати історію, яку зберігає ваш застосунок, а потім перевірити відповіді й побічні дії до перемикання трафіку. Дату вимкнення та відповідність об’єктів підтверджує офіційний посібник OpenAI з міграції Assistants.
Що змінює вимкнення 26 серпня 2026 року
Це міграція кінцевих точок та об’єктів, а не перейменування моделі. Після вимкнення виклики старих ресурсів Assistants не є тимчасовим попередженням. Код, який створює або читає /v1/assistants, /v1/threads, /v1/threads/messages чи /v1/threads/runs, потребує нового шляху. Не починайте нову інтеграцію зі старим API й не створюйте fallback, що передбачає доступність старих об’єктів.
Поточна відповідність, опублікована OpenAI:
| Assistants API | Платформа Responses | Практичний зміст |
|---|---|---|
| Assistant | Prompt або конфігурація запиту | Зберігайте модель, інструкції, оголошення інструментів і правила виводу у версійному налаштуванні. Поточний посібник дозволяє створити Prompt з Assistant у панелі, але також попереджає про припинення підтримки багаторазових Prompt-об’єктів. |
| Thread | Conversation або історія застосунку | Conversation зберігає елементи, зокрема повідомлення, виклики інструментів і результати. Стан можна зберігати у власній базі та надсилати потрібні елементи. |
| Run | Response | Запит Responses отримує вхідні елементи й повертає вихідні. Окремий Run та цикл опитування більше не є головною абстракцією. |
| Run step | Item | Обробляйте типізовані елементи message, function_call, function_call_output і reasoning, а не вважайте кожен результат повідомленням. |
Прочитайте посібник міграції на Responses API разом із посібником про вимкнення. У ньому Responses названо рекомендованим API для нових проєктів і описано відмінності від Chat Completions та форми входу й виходу.
Нова модель роботи
Раніше Assistant був постійним серверним набором налаштувань. Thread зберігав повідомлення, а Run виконував Assistant щодо цього Thread. Responses розділяє ці обов’язки. Запит визначає модель, інструкції, вхідні дані та інструменти. Результат є типізованим Response, а output містить упорядкований список елементів.
Тепер застосунок явно відповідає за оркестрацію. Код визначає, як ідентифікувати користувача, скільки історії надсилати, які виклики дозволені, як перевіряти аргументи, як повторювати невдалі операції та коли потрібне людське підтвердження. OpenAI і далі надає варіанти стану, але це свідомий вибір, а не прихований життєвий цикл Assistant.
Є три практичні стратегії стану:
- Використовуйте запит без стану та надсилайте обмежений список вхідних елементів на кожному ході. Так ваша база контролює зберігання й обрізання історії.
- Поєднуйте ходи через previous_response_id. Цей підхід показано в документації про стан розмови. Він зручний для коротких сценаріїв, але попередні вхідні токени все одно тарифікуються, а зберігання має відповідати вашій політиці.
- Створіть об’єкт Conversations API та передавайте його ID у Responses. Conversation має сталий ідентифікатор і працює між сесіями, пристроями та завданнями. Елементи зберігаються до видалення, тому ID посилається на збережений стан, а не вмикає приватність.
Оберіть одну стратегію для кожного продуктового потоку. Не змішуйте локально відновлену стенограму, Conversation та ланцюжок previous_response_id без визначеного джерела істини. Дубльовані ходи можуть змінити поведінку моделі, збільшити витрати й ускладнити видалення.
Проінвентаризуйте залежності до зміни коду
Створіть запис міграції для кожного Assistant ID і кожного шляху виробничої сесії. Зафіксуйте модель, інструкції, параметри за замовчуванням, схеми інструментів, vector stores, файли, використання Code Interpreter, формат відповіді, метадані, вимоги до зберігання та код, який опитує стан Run. Шукайте не лише на сервері, а й у фонових задачах, адміністративних скриптах, панелях, тестах та аналітичних споживачах. Успішна текстова відповідь не доводить, що file search, структурований вивід, streaming чи функція з побічною дією працюють так само.
Відокремте поведінку від збережених даних. Інструкції та оголошення інструментів можна відтворити з конфігурації. Повідомлення Thread і завантажені файли є активами даних, для яких потрібен експорт або копія під контролем застосунку. Якщо система ніколи не зберігала повідомлення поза Threads, вирішіть, як обробити ці записи, перш ніж щось видаляти. Посібник після вимкнення зазначає, що отримання старих повідомлень Thread більше не працює, і радить використовувати повідомлення, які вже зберіг застосунок.
Відтворіть базовий запит
Для текстової взаємодії замініть послідовність beta Thread і Run одним викликом Responses. Поле input приймає рядок або список елементів, подібних до повідомлень. Використовуйте instructions для сталої системної поведінки, а текст користувача залишайте в input. Звичайний текст читайте через response.output_text, але перевіряйте response.output, якщо можливі інструменти або нетекстові елементи.
from openai import OpenAI
client = OpenAI()
response = client.responses.create(
model="gpt-5.6",
instructions="Відповідай чітко та цитуй надані записи.",
input=[{"role": "user", "content": "Підсумуй стан замовлення."}],
store=False,
)
print(response.output_text)
Нова кінцева точка — /v1/responses, а метод SDK — client.responses.create. Не переносіть без змін ключ messages, шлях choices[0].message.content або цикл опитування з Runs. Якщо Responses потрібно зберігати, прийміть це як окреме рішення. У документації про контроль даних зараз вказано, що стан Responses зберігається 30 днів за замовчуванням або коли store має значення true, з переліченими винятками.
Назва моделі у прикладі не є гарантією міграції. Перевірте модель і можливості в актуальному каталозі моделей, зафіксуйте snapshot, коли важлива відтворюваність, і проведіть власні тести якості та затримки.
Правильно збережіть історію
Якщо стенограма належить застосунку, нормалізуйте її до вхідних елементів Responses. Текст користувача стає input_text, текст асистента — output_text, а зображення — input_image із URL або посиланням на файл. Збережіть хронологічний порядок і пари виклику інструмента та його результату, потрібні для розуміння попереднього ходу.
Цей приклад створює постійну Conversation з історії застосунку, а потім надсилає новий хід:
from openai import OpenAI
client = OpenAI()
conversation = client.conversations.create(
items=[
{
"role": "user",
"content": [{"type": "input_text", "text": "Моє замовлення — 1842."}],
},
{
"role": "assistant",
"content": [{"type": "output_text", "text": "Я можу перевірити замовлення 1842."}],
},
]
)
response = client.responses.create(
model="gpt-5.6",
conversation=conversation.id,
input=[{"role": "user", "content": "Воно готове до відправлення?"}],
)
print(response.output_text)
Після вимкнення не намагайтеся мігрувати через threads.messages.list. Експортуйте, поки старий endpoint доступний, лише якщо працюєте в середовищі до вимкнення. У системі після вимкнення використовуйте записи, які зберіг ваш застосунок. До імпорту зіставте особу користувача, запити на видалення, регіональні правила, вкладення й часові мітки. Conversation ID від клієнта не можна приймати без перевірки належності автентифікованому користувачу.
Перенесіть інструменти та виклики функцій
Інструменти Responses оголошуються в запиті. Вбудовані web search, file search, computer use, Code Interpreter, генерація зображень і віддалений MCP описані в Using tools. Власні функції все одно реалізуються на боці застосунку. Модель може попросити викликати функцію, але не може самостійно авторизувати або виконати бізнес-операцію.
Цикл контролю тепер явний. Надішліть перший запит, перевірте response.output на елементи function_call, перевірте та виконайте кожну дозволену функцію, додайте вихідні елементи моделі й елементи function_call_output, а потім надішліть наступний запит. Для reasoning-моделей збережіть reasoning-елементи, що повернулися разом із викликом, як описано в посібнику з function calling.
import json
from openai import OpenAI
client = OpenAI()
tools = [
{
"type": "function",
"name": "lookup_order",
"description": "Повернути стан замовлення, що належить автентифікованому користувачу.",
"parameters": {
"type": "object",
"properties": {
"order_id": {"type": "string"},
},
"required": ["order_id"],
"additionalProperties": False,
},
"strict": True,
}
]
input_items = [{"role": "user", "content": "Де моє замовлення 1842?"}]
response = client.responses.create(
model="gpt-5.6",
tools=tools,
input=input_items,
)
input_items += response.output
for item in response.output:
if item.type == "function_call" and item.name == "lookup_order":
arguments = json.loads(item.arguments)
result = {"order_id": arguments["order_id"], "status": "packed"}
input_items.append(
{
"type": "function_call_output",
"call_id": item.call_id,
"output": json.dumps(result),
}
)
response = client.responses.create(
model="gpt-5.6",
tools=tools,
input=input_items,
)
print(response.output_text)
Суворий режим допомагає дотримуватися схеми, але не надає дозволів. У коді перевіряйте автентифікованого користувача, власника замовлення, діапазони, значення enum і стан операції. Для оплат, видалення, публікації або надсилання використовуйте ідемпотентність чи транзакцію. У разі помилки поверніть структуровану помилку інструмента, а не імітуйте успіх. Обмежте кількість ходів інструментів і записуйте виклики, результати та рішення про схвалення із прихованими чутливими значеннями.
Формат визначень функцій Responses відрізняється від старої оболонки функцій Chat Completions. Переносьте схему свідомо та тестуйте неправильні аргументи, невідомі функції, дубльовані й паралельні виклики, тайм-аути та результат інструмента з недовіреним текстом.
Збережіть структурований вивід
Якщо старий Assistant використовував JSON mode або схему відповіді, перенесіть її до конфігурації Responses text.format, а response_format не копіюйте без змін. Посібник зі структурованого виводу описує актуальну форму схеми й помічники SDK. Перевіряйте розібраний результат до запису в базу, показу в інтерфейсі або передачі іншому інструменту. Коректний JSON все одно може містити неправильний номер замовлення, небезпечну інструкцію чи неповне бізнес-рішення.
Тримайте схему малою та версіонуйте її разом із Prompt або конфігурацією запиту. Визначайте обов’язкові поля, встановлюйте additionalProperties=false там, де цього вимагає суворий режим, і тестуйте відмови, неповні відповіді та еволюцію схеми. Наявність JSON-об’єкта сама по собі не означає успіх операції.
Безпека й дані після міграції
Міграція змінює межу стану, тому перегляньте її як зміну архітектури безпеки. Зберігайте API-ключі на довіреному сервері, автентифікуйте кожну сесію й прив’язуйте Conversation або локальну стенограму до серверної особи користувача. Не розміщуйте секрети, токени авторизації чи необмежені запити до бази в інструкціях або описах інструментів.
Використовуйте найменший потрібний набір інструментів. Розділяйте функції читання й запису, вимагайте явного підтвердження важливих дій і виконуйте авторизацію незалежно від відповіді моделі. Вважайте отримані файли, вебсторінки та відповіді віддаленого MCP недовіреними даними. Віддалені MCP-сервери мають власні правила зберігання, а розміщені контейнери Code Interpreter можуть тимчасово зберігати стан під час роботи. Посібник з контролю даних перелічує ці обмеження.
Для кожного потоку вирішіть, чи потрібні store, Conversation або стенограма під контролем застосунку. Поточна документація говорить, що дані API не використовуються для навчання моделей OpenAI без явної згоди, але це не замінює перевірку зберігання, доступу, видалення, регіональної обробки та постачальників. store=false не є загальною політикою видалення і не робить Conversation тимчасовою.
Обмежуйте вхід і вихід, застосовуйте модерацію за потреби та організуйте людську перевірку рішень із високим впливом. Рекомендації OpenAI з безпеки радять adversarial-тестування проти prompt injection, модерацію та людський нагляд. Записуйте ID запитів і типи подій, але приховуйте текст користувача, облікові дані, аргументи функцій і результати інструментів відповідно до політики.
Типові помилки міграції
Старий endpoint повертає помилку
Після 26 серпня 2026 року запити до Assistants означають дефект міграції. Видаліть старий шлях клієнта, а не повторюйте його. Якщо фоновий worker ще опитує Run ID, розгорніть worker Responses і замініть thread_id та run_id на ідентифікатори сесії та Response.
Відповідь порожня або парсер падає
Вихід Responses є неоднорідним списком елементів. output_text зручний для звичайного тексту, але виклик інструмента, відмова чи неповна відповідь потребують перевірки статусу і типів елементів. Не беріть перший елемент за індексом, вважаючи його повідомленням.
Модель повторює контекст або витрати зростають
Оберіть стратегію стану та правило обрізання. previous_response_id не робить попередні вхідні токени безкоштовними, а копіювання тієї самої історії в Conversation і input дублює контекст. Вимірюйте вхідні та вихідні токени у staging на реалістичних довгих діалогах.
Функція виконується двічі
Повтори, паралельні виклики інструментів, мережеві тайм-аути й перепідключення можуть повторити виклик. Дайте кожній операції з побічною дією ідемпотентний ключ на основі call ID і автентифікованого користувача, а перед виконанням перевіряйте бізнес-транзакцію. Успішне повідомлення моделі не доводить одноразове виконання функції.
Старі файли або результати пошуку зникають
Інвентаризуйте vector stores, ID файлів, терміни дії та дозволи окремо від історії Thread. Відновіть підтримуваний шлях пошуку, перевірте доступ кожного орендаря та протестуйте цитати й порожні результати. Перетворення конфігурації Assistant не означає копіювання файлів.
Чекліст міграції
Виконайте кроки по порядку для кожного виробничого потоку:
- Запишіть залежності від старих Assistant, Thread, Run, файлів, vector stores, інструментів, Prompt і метаданих.
- Перенесіть інструкції для користувача та схеми інструментів у версійну конфігурацію.
- Виберіть модель Responses і підтвердьте її інструменти, мультимодальний ввід, структурований вивід та регіональну доступність.
- Виберіть одну стратегію стану: елементи без стану, previous_response_id або Conversations.
- Зіставте messages з input, choices з output, а читання тексту з output_text.
- Перепишіть визначення функцій і реалізуйте явний обмежений цикл інструментів.
- Окремо відновіть file search, Code Interpreter, web search, MCP, streaming і структурований вивід.
- Імпортуйте лише історію під контролем застосунку, зберігши порядок, особи, вкладення, виклики й семантику видалення.
- Додайте авторизацію, обмеження вводу, модерацію, ідемпотентність, приховані логи й схвалення побічних дій.
- Запустіть еталонні діалоги, adversarial-запити, помилки інструментів, повтори, відмови, довгий контекст і паралельні сесії.
- Порівняйте відповіді, цитати, ефекти інструментів, токени, затримку, помилки й поведінку зберігання.
- Випустіть зміни за feature flag, зупиніть старі workers, спостерігайте помилки Responses і збережіть відкат без вимкненого API.
- Видаляйте старий код Assistant і ключі лише після перевірки експорту, аудиту та процедур підтримки.
Про дизайн системи читайте в посібнику з production-архітектури AI-агента. Набори регресій і поведінкові перевірки описані в посібнику з evals AI-агентів.
Як зрозуміти, що міграцію завершено
Міграцію завершено, коли жоден виробничий шлях не залежить від ресурсів Assistants, для кожної сесії визначено власника стану, кожен виклик інструмента авторизований і захищений від повтору, а контракт виходу Responses покритий тестами. Зберігайте запис міграції зі snapshot моделей, версіями Prompt або конфігурації запиту, версіями схем, рішеннями щодо зберігання та відомими збоями. Переглядайте його, коли змінюються Responses API або модель, адже вимкнення старого fallback не скасовує постійного оцінювання.