OpenAI 22 сентября 2026 года опубликовала материал Better prompt caching for GPT-6 и обновила документацию по работе с кэшем в API. Это не новая модель и не корпоративный кейс, а практичный релиз для разработчиков: GPT-6 должен лучше переиспользовать длинные стабильные части запроса, показывать, почему кэш не сработал, и давать больше контроля над границами кэширования.
Если коротко, prompt caching становится не скрытой оптимизацией, а нормальной частью архитектуры агентного приложения. Для короткого чат-бота разница может быть незаметной. Но если продукт каждый раз отправляет системные правила, инструкции инструментов, справочники, историю рабочего процесса и длинный контекст клиента, кэш решает сразу две задачи: снижает задержку и уменьшает стоимость повторяющихся входных токенов.
Что именно изменилось
OpenAI описывает релиз как улучшение prompt caching для GPT-6: выше cache hit rate, новая диагностика, explicit breakpoints и настройки, которые помогают снижать latency и расходы. В документации по GPT-6 отдельно сказано, что при миграции со старых моделей нужно заменить prompt_cache_retention на prompt_cache_options.ttl со значением вроде 30m, а также пересмотреть новые правила границ кэша и billing для cache writes.
Главная мысль простая: стабильная часть запроса должна оставаться стабильной. Если в начале промпта лежат правила агента, описание инструментов, политика безопасности, примеры и общий контекст, а в конец добавляется свежий пользовательский вопрос, система может переиспользовать уже обработанный prefix. Если приложение каждый раз переставляет блоки местами, меняет tool definitions или переписывает старую историю, кэш будет промахиваться.
Для GPT-5.6 и более новых семейств OpenAI уже описывает explicit prompt caching controls. Разработчик может поставить prompt_cache_breakpoint на границе, где заканчивается переиспользуемая часть и начинается динамический хвост. Можно выбрать явный режим, если приложение хочет опираться только на указанные breakpoints, а не на автоматический выбор. В GPT-6 эта логика становится особенно важной, потому что семейство рассчитано на длинные агентные workflow, tool calling и продолжительные рабочие сессии.
Почему это важно для агентных продуктов
У классического чат-бота промпт обычно небольшой: роль, стиль, несколько правил и последнее сообщение пользователя. У агента всё тяжелее. В запрос могут входить инструкции из файлов, схема инструментов, правила доступа, состояние задачи, результаты прошлых tool calls, выдержки из базы знаний, внутренние ограничения продукта и куски истории. На таком фоне повторно оплачивать и заново обрабатывать одинаковые первые десятки тысяч токенов просто жалко.
Prompt caching помогает только при дисциплине. Стабильный prefix должен идти первым. Динамические данные лучше добавлять позже. Tool definitions нужно держать в одном порядке. Если есть большая политика или справочник, который меняется редко, его стоит отделить от свежего пользовательского ввода. Тогда несколько запросов внутри одной задачи получают шанс попадать в кэш, а не стартовать с нуля.
Это особенно заметно в поддержке, внутренних операционных агентах, IDE-помощниках, аналитических ассистентах и длинных research-сессиях. Один и тот же агент может обрабатывать десятки похожих запросов: смотреть тикеты одного клиента, проверять набор файлов, вести пользователя через onboarding или выполнять несколько шагов в панели. Чем больше общего контекста между шагами, тем важнее правильная структура запроса.
Диагностика промахов становится отдельным инструментом
Отдельная хорошая новость — диагностика prompt cache. В чейнджлоге OpenAI 8 сентября 2026 года указала, что Prompt Cache Diagnostics стала generally available в Responses API для GPT-5.6 и более новых поддерживаемых моделей. Она позволяет сравнивать reuse с предыдущим response, искать причины cache misses и получать рекомендации по устранению проблем.
Раньше кэш часто был похож на чёрный ящик. Разработчик видел cached_tokens в usage и мог догадываться, почему в одном сценарии всё хорошо, а в другом hit rate падает. Теперь появляется более нормальный цикл: запустил типовой workflow, посмотрел cache reads, cache writes, miss reasons, поправил границу или порядок блоков, повторил тест.
Это важно ещё и потому, что кэширование нельзя оценивать по одному удачному запросу. Если приложение записывает большой prefix в кэш, а потом почти не использует его повторно, экономия может оказаться слабой. В документации OpenAI отдельно советует логировать cached_tokens и cache_write_tokens, а затем сравнивать объём записей с последующими чтениями. Иначе можно оптимизировать красивый график, а не реальные деньги.
Что меняется в стоимости
Кэш не означает «всё бесплатно». Для GPT-5.6 и более новых моделей OpenAI описывает отдельную экономику cache writes: запись в кэш стоит дороже обычного uncached input, зато последующие cache reads дешевле. Поэтому схема выгодна, когда один и тот же prefix действительно переиспользуется.
В практическом продукте это заставляет думать не только о промпте, но и о потоке запросов. Например, если пользователь открывает задачу и делает пять последовательных действий с одним и тем же контекстом, кэш может окупиться. Если запросы каждый раз уникальны и prefix почти не повторяется, cache write может не дать заметной пользы.
Для multi-tenant сервисов появляется ещё одна деталь: cache accounting. OpenAI пишет, что на GPT-5.6 и позже prompt_cache_key уже не обязателен для оптимального hit rate, но его можно использовать для раздельного учёта по клиентам, пользователям или рабочим пространствам. Это помогает объяснять cached token usage внутри продукта и снижает риск cache-hit probing между клиентами.
Explicit breakpoints: где провести границу
Самый понятный практический приём — поставить breakpoint после стабильного блока. Например, сначала идут системные инструкции, политика компании, список инструментов и несколько неизменных примеров. Затем ставится граница кэша. После неё приложение добавляет свежий тикет, вопрос пользователя, актуальный фрагмент базы или результаты последнего шага.
Если границу поставить слишком рано, в кэш попадёт мало полезного. Если слишком поздно, в переиспользуемую часть начнут попадать данные, которые меняются каждый раз, и hit rate ухудшится. Поэтому breakpoint лучше выбирать на реальных сценариях, а не на ощущениях. Берём несколько типовых задач, смотрим, какие блоки повторяются, какие постоянно меняются, и только потом фиксируем структуру.
Для агентных систем я бы отдельно проверял tool definitions. Частая ошибка — собирать список инструментов из словаря без стабильной сортировки или добавлять в описания динамические значения. Внешне это тот же набор инструментов, но для кэша prefix уже другой. То же касается дат, случайных идентификаторов, debug-полей и временных комментариев в начале промпта.
GPT-6 и смена reasoning effort без поломки prefix
В документации по GPT-6 есть связанная возможность: change reasoning mid-conversation while preserving cache. Для стандартных single-agent requests можно добавить configuration_update, чтобы повысить или снизить reasoning effort между ответами, не переписывая исходный request-level prefix. Обновлённый effort действует до следующего изменения.
Это звучит как мелочь, но для длинных workflow полезно. Агент может большую часть времени работать в более дешёвом режиме, а на сложном шаге временно поднять reasoning. Если при этом стабильный prefix сохраняется, приложение не ломает кэш только ради смены режима мышления. В обычной инженерной логике это похоже на переключение передачи: не нужно пересобирать весь автомобиль, чтобы проехать сложный участок.
У этой функции есть ограничения. OpenAI указывает, что configuration updates нельзя смешивать с automatic compaction или truncation, а /responses/compact отклоняет histories, где они есть. Значит, если продукт активно использует compaction, схему нужно проектировать аккуратно: когда компактировать историю, когда заново добавлять configuration update, где проходит кэшируемая граница.
Как я бы внедрял это в продукте
Первый шаг — нарисовать карту запроса. Не в смысле красивой схемы, а буквально разложить request на блоки: инструкции агента, правила безопасности, tools, справочник, контекст пользователя, история, текущий вопрос, результаты инструментов. После этого отметить, что стабильно, что меняется редко, а что уникально в каждом запросе.
Второй шаг — стабилизировать порядок. Все статические правила идут первыми. Tool definitions сортируются одинаково. Динамические даты и debug-информация не попадают в начало. Если есть большой документ, который меняется раз в день, его лучше отделить от данных, которые меняются каждую минуту.
Третий шаг — поставить breakpoint и включить диагностику. На тестовом наборе нужно смотреть не только latency, но и cached tokens, cache write tokens, cache reads per write и причины промахов. Если кэш записывается часто, а читается мало, граница выбрана плохо или сам сценарий не подходит.
Четвёртый шаг — не забыть про безопасность. Если используется prompt_cache_key для учёта по клиентам, ключ должен быть стабильным, но не раскрывать лишние данные. Если продукт multi-tenant, нельзя смешивать контекст разных клиентов ради красивого hit rate. Экономия на токенах не стоит риска перепутать данные.
Где будет самый большой эффект
Больше всего выиграют продукты с повторяющимся длинным контекстом. Например, внутренний агент поддержки, который работает по одной политике и одному набору инструментов; кодовый агент, который несколько шагов держит правила репозитория и tool schema; аналитический ассистент, который обрабатывает серию вопросов по одному набору документов; B2B-бот, где у каждого клиента есть большой, но стабильный слой инструкций.
Меньше эффекта будет там, где запросы короткие или полностью уникальные. Если приложение отправляет один абзац и получает короткий ответ, кэш не станет главным рычагом. Если каждый запрос собирается заново из хаотичных кусочков, сначала придётся чинить архитектуру промпта.
Есть и продуктовый нюанс: кэширование не улучшает качество ответа само по себе. Оно не делает модель умнее и не заменяет eval. Оно делает повторяющуюся работу быстрее и дешевле. Поэтому правильный KPI здесь не «мы включили prompt caching», а «типовой workflow стал дешевле, latency снизилась, качество не просело, а miss reasons понятны».
Почему релиз важен
Улучшенный prompt caching для GPT-6 показывает, что API для больших моделей взрослеет вокруг production-деталей. Раньше многие обсуждали только качество модели: как она рассуждает, пишет код, вызывает инструменты. Но в реальном продукте не менее важны стоимость длинного контекста, задержка, предсказуемость workflow и возможность объяснить, почему система внезапно стала дороже.
OpenAI двигает кэширование в сторону управляемой инженерной практики: explicit breakpoints, ttl, диагностика, отдельная стоимость cache writes, рекомендации по stable prefix и совместимость с настройками GPT-6. Это не самая громкая новость недели, зато очень полезная для тех, кто строит не демо, а сервис с ежедневным трафиком.
Мой вывод простой: если у вас уже есть агент на Responses API или длинные GPT-6 запросы, prompt caching теперь стоит вынести в отдельный пункт технического аудита. Проверить структуру промпта, измерить hit rate, найти промахи, закрепить стабильные блоки и посчитать экономику. Это скучная работа, но именно она отличает игрушечный агент от продукта, который можно масштабировать.
Источник
Официальный материал OpenAI: Better prompt caching for GPT-6.
Дополнительные официальные материалы: Model guidance для GPT-6, API deployment checklist, OpenAI API changelog.