12-годинне кешування в OpenAI API: коли воно знижує вартість довгих запитів

Для агента, який звертається до API кілька разів протягом робочого дня, повторне передавання довгих інструкцій впливає на вартість. 20 жовтня 2026 року OpenAI додала до Responses API можливість вибрати 12-годинний строк кешування: спільні інструкції, інструменти й контекст можуть залишатися придатними для повторного використання між запитами, розділеними кількома годинами. OpenAI вказує ставку запису, що у 2,5 раза перевищує звичайну ціну вхідних токенів; це повна ставка запису, а не надбавка до неї. Економія залежить від повторного використання префікса й ціни читання кешованих токенів. Анонс у журналі змін OpenAI датовано 20 жовтня 2026 року.

Такий строк призначений для багатоетапних робочих процесів: наприклад, агент може аналізувати документи вранці, а пізніше продовжити завдання з тими самими інструкціями й інструментами. Вирішуючи, чи вмикати 12-годинний строк, важливо порівняти вартість запису з витратами на повторні читання й зважити, скільки запитів справді повторно використовують той самий префікс.

Що саме кешується

Кешування промптів повторно використовує однаковий початковий фрагмент запиту. Наступні запити мають зберігати його незмінним; змінні дані варто розміщувати після постійної частини. У посібнику OpenAI з кешування промптів зазначено, що для GPT‑5.6 і новіших моделей у Responses API можна задати TTL `30m` або `12h`. Дванадцять годин — це мінімальний строк, протягом якого запис має залишатися придатним для кешованого читання; це не обіцянка видалити його рівно через 12 годин. Доступність і параметри залежать від моделі.

У постійний префікс зручно поміщати системні інструкції, визначення інструментів і стабільні правила обробки. Поточне запитання, ідентифікатори завдання та свіжі дані краще додавати далі. Якщо змінювати ранні частини запиту, збігатиметься коротший префікс, а обсяг повторно використовуваних токенів може зменшитися.

Як оцінити окупність

Нехай стабільний префікс містить P токенів, його надсилають N разів, ціна звичайного вхідного токена дорівнює C, а ставка кешованого читання для вибраної моделі — R. За одного запису й влучання в кеш у всіх наступних запитах витрати на цей префікс становитимуть приблизно 2,5PC + (N−1)PR. Без кешу його передавання коштувало б NPC. Ця оцінка стосується лише стабільного префікса: змінну частину запиту, промахи кешу й додаткові записи враховуйте окремо. Ставка читання залежить від моделі; наприклад, документація вказує для GPT‑6.1 Sol значення 0,05 від звичайної ціни вхідного токена, а для GPT‑5.6 і новіших моделей — 0,1.

У цій спрощеній моделі кеш починає заощаджувати на повторно використовуваному префіксі, коли 2,5C + (N−1)R < NC. Реальна точка окупності залежить від фактичних влучань, повторних записів і конкретного тарифу. Якщо запити надходять рідко, інструкції часто змінюються або префікс щоразу унікальний, додаткові витрати на запис можуть перекрити економію на читанні.

Перевірка на робочому навантаженні

1. Зафіксуйте базовий сценарій. Візьміть типові запити, довжину стабільного префікса, інтервали між викликами й витрати без 12-годинного TTL.
2. Розділіть постійне та змінне. Залиште спільні інструкції й схеми інструментів на початку, а користувацькі дані та поточне завдання розмістіть після них.
3. Порівняйте зіставні запити. Порахуйте записи, обсяг кешованих вхідних токенів і загальні витрати для вибраної моделі та строку зберігання.
4. Оцініть повний робочий цикл. Враховуйте промахи, повторні записи після завершення строку й випадки, коли зміна префікса заважає його повторному використанню.

Метрики відповіді API допомагають перевірити фактичний обсяг кешованих вхідних токенів і записів; склад звітності залежить від моделі. Налаштовуваний 12-годинний строк підходить для стабільного великого префікса, який повторно використовують з інтервалами в кілька годин. Для коротких запитів або запитів, що рідко повторюються, спершу виміряйте записи, влучання й загальну вартість на власному трафіку.