DR
Ценообразование для кэшируемого ввода может существенно снизить стоимость рабочих нагрузок, которые многократно пересылают большой, неизменный префикс промпта, но экономия зависит от правил чтения из кэша, записи в кэш, хранения, маршрутизации и удержания, специфичных для модели. Общей пометки «caching supported» недостаточно для оценки стоимости; используйте текущую цену, опубликованную для конкретной модели и маршрута.
TL;DR
- Для GPT-5.6 Terra опубликованы явные цены на чтение из кэша и запись в кэш у OpenAI, CometAPI и OpenRouter, хотя маршруты шлюза и уровни для длинного контекста могут менять объем.
- Google публикует ставку $0.15 за 1M токенов для кэширования контекста уровня Standard у Gemini 3.6 Flash плюс плату за хранение; CometAPI в настоящий момент указывает стандартные цены модели на ввод и вывод без отдельной строки для кэшируемого ввода.
- Важное сравнение — это не только стандартный ввод против чтения из кэша. Оно также включает первую запись в кэш, любую плату за хранение, срок жизни кэша, согласованность маршрутов и количество последующих попаданий в кэш.
Key messages
- Проверяйте цены на уровне конкретной модели и уровня сервиса, а не применяйте множитель на уровне всего шлюза.
- В расчете стоимости отдельно учитывайте чтение из кэша, запись в кэш, хранение и кэширование ответов.
- Подтверждайте фактическое использование кэша в метаданных ответа API, прежде чем прогнозировать экономию, исходя из опубликованной ставки.
Запрос, который повторяет большой, неизменный префикс — системный промпт, набор схем инструментов, длинный справочный документ — не обязательно должен тарифицироваться по полной ставке ввода при каждом вызове. Большинство моделей текущего поколения поддерживают некоторую форму ценообразования для кэшируемого ввода: пониженную ставку для части промпта, которую провайдер распознает как уже обработанную. Механизм, величина скидки и прозрачность публикации различаются по провайдерам и шлюзам, и эта вариативность требует конкретики, а не отношения к «поддержке кэширования» как к единой функции.
What cached input pricing is, and isn't
Ценообразование для кэшируемого ввода предоставляет скидку на токены ввода в запросе, которые совпадают с ранее отправленным префиксом. Оно не дает скидки на токены вывода и не является тем же самым, что дедупликация шлюзом двух полностью идентичных запросов с возвратом одного ответа бесплатно — это иной механизм, который некоторые шлюзы предлагают отдельно. Ценообразование кэшируемого ввода — это именно про меньшую оплату за ту часть промпта, которую провайдер модели уже недавно видел, а не про полное пропускание генерации.
Создание такого кэша тоже не является бесплатным. Примечания по ценообразованию GPT-5.6 от OpenAI указывают, что записи в кэш тарифицируются по 1,25 от не кэшированной ставки ввода, тогда как чтения из кэша получают 90%-ю скидку. Эта наценка на первую запись влияет на точку безубыточности и легко упускается, если сравнение показывает только льготную ставку чтения. Другие провайдеры могут использовать плату за хранение вместо той же модели записи, поэтому стоимость записи и хранения следует проверять отдельно.
На практике тарифицируемой единицей кэша обычно является многократно используемый префикс промпта, а не произвольный набор повторяющихся предложений. Провайдеры токенизируют и сопоставляют контент по порядку, поэтому повторно используемый материал должен идти перед запросо-специфичным «хвостом». Стабильные системные инструкции, определения инструментов, политики и справочные материалы следует располагать ближе к началу; изменяющиеся пользовательские сообщения, метки времени, идентификаторы запросов или извлеченные фрагменты — позже. Даже семантически безвредное изменение в начале может сместить токенизацию или нарушить совпадение для всего, что следует далее.
Правила применимости также специфичны для модели. Провайдер может требовать минимальную длину промпта, распознавать только документированные точки разделения или предоставлять явное поле управления кэшем. Запись кэша может истечь между вызовами, а шлюз может нуждаться в удержании связанных запросов на совместимом апстрим-маршруте. Это означает, что в разворачивании попадание в кэш следует рассматривать как наблюдаемый результат, а не как предположение на основе схожести промптов. Хорошо структурированный промпт повышает вероятность повторного использования, но именно метаданные ответа и счет определяют, была ли действительно применена льготная ставка.
What's actually published, by model and by gateway
Таблица ниже — снимок цен, проверенный 29 июля 2026 г. Цены указаны в долларах США за 1 миллион токенов, если не указано иное. Строки сравнивают текущую публичную информацию для GPT-5.6 Terra и Gemini 3.6 Flash у поставщика модели, в CometAPI и в OpenRouter; это не следует считать постоянным тарифом.
| Модель | Шлюз | Стандартный ввод | Кэшируемый ввод (чтение) | Запись в кэш | Скидка раскрыта? |
|---|---|---|---|---|---|
| GPT-5.6 Terra | Официальная ставка OpenAI | $2.50 / 1M | $0.25 / 1M | $3.13 / 1M | Да — 90% скидка, указана напрямую |
| GPT-5.6 Terra | CometAPI | $2.00 / 1M | $0.20 / 1M | $2.50 / 1M | Да — указано на странице цен CometAPI |
| GPT-5.6 Terra | OpenRouter | $2.50 / 1M | Не указано как отдельная ставка | Не указано | Нет — описано только как «на 60–80% дешевле» в совокупности, без покомодельной цифры |
| Gemini 3.6 Flash | Официальная ставка Google | $1.50 / 1M | $0.15 / 1M (согласно собственному анонсу Google) | Не раскрыто | Да, на запуске — через документацию модели Google |
| Gemini 3.6 Flash | CometAPI | $1.20 / 1M | Не указано как отдельная ставка | Не раскрыто | Нет — страница CometAPI помечает «Caching» как поддерживаемую функцию, но не публикует льготную ставку кэшируемого ввода для этой конкретной модели на момент написания |
| Gemini 3.6 Flash | OpenRouter | $1.50 / 1M | Не указано как отдельная ставка | Не раскрыто | Нет — собственная документация OpenRouter описывает множитель кэша Google в общем виде (0.25x от прайс-листа на ввод), не подтверждая ставку для этой модели |
Читайте таблицу как снимок на уровне модели и маршрута. Страница модели GPT-5.6 CometAPI детализирует GPT-5.6 Terra по $2.00 за стандартный ввод, $0.20 за кэшируемый ввод и $2.50 за запись в кэш за 1 миллион токенов. Ее страница модели Gemini 3.6 Flash в настоящий момент публикует $1.20 за ввод и $6.00 за вывод, но не показывает отдельную цену за кэшируемый ввод или хранение кэша. В ценах Gemini Developer API Google указывает для уровня Standard $1.50 за ввод, $0.15 за кэширование контекста и $1.00 за 1 миллион токенов в час за хранение. OpenRouter теперь публикует поля кэша на уровне модели через Models API: запись по умолчанию для GPT-5.6 Terra включает сниженные промо-цены и отдельный более высокий уровень для длинного контекста, а его запись для Gemini 3.6 Flash раскрывает различные значения для уровней Standard, Flex и Priority. Это точнее, чем применять один общий множитель кэша ко всем моделям.
Why gateway and provider prices can diverge
Цена шлюза не обязательно является наценкой к одному неизменному прайс-листу апстрима. Она может отражать согласованные мощности, временную промоакцию, другой уровень сервиса или коммерческое соглашение, специфичное для маршрута. Название модели также может соответствовать нескольким апстрим-вариантам, чьи цены меняются с длиной контекста или гарантиями по задержке. Например, запись OpenRouter для GPT-5.6 Terra публикует маршрут по умолчанию и более дорогую альтернативу после достижения порога длинного контекста по вводу. Google разделяет цены на уровни Standard, Batch, Flex и Priority для Gemini 3.6 Flash. Поэтому отдельная строка сравнения должна содержать дату, маршрут, уровень и допущения по контексту, чтобы оставаться значимой.
Обратное тоже важно: если на странице шлюза не публикуется отдельная строка чтения из кэша, это отсутствие не следует превращать ни в «кэширование недоступно», ни в «прямая скидка провайдера автоматически применяется». Шлюз может передавать апстрим-функцию без детальной расшифровки, предоставлять ее только на определенных маршрутах или тарифицировать запрос по своей обычной ставке ввода. Защищаемый подход — использовать актуальную страницу модели самого шлюза при планировании, а затем подтверждать фактическую ставку по данным использования или биллинга. Документация провайдера остается полезной для понимания механизма, но сама по себе не устанавливает коммерческие условия посредника.
Where the discount actually matters
Сценарий, в котором это значительно влияет на стоимость, — большой статичный префикс в паре с небольшим переменным запросом: системный промпт или набор схем инструментов, пересылаемые при каждом вызове в цикле агента, длинный справочный документ, к которому многократно обращаются с разными вопросами, или история диалога, пересылаемая на каждом шаге чат-бота. Для такой нагрузки разница между оплатой полной цены ввода за весь префикс каждый раз и оплатой наценки за первую запись плюс льготной ставки чтения далее растет с объемом вызовов. Это не дает ничего для нагрузок, которые не повторяют префикс — разовый запрос не имеет кэшируемого содержимого для скидки.
Практическая безубыточность сравнивает не кэшированную стоимость повторяющегося префикса по всем вызовам со стоимостью записи в кэш или хранения плюс льготные чтения из кэша в последующих вызовах. Результат зависит от размера префикса, числа успешных попаданий в кэш, срока действия кэша и того, удерживает ли шлюз запросы на совместимом маршруте провайдера. Если эти условия нестабильны, «заголовочная» скидка может переоценивать экономию, достигаемую в продакшене.
A simple cost model for a repeated prefix
Пусть P — количество токенов в стабильном префиксе, а N — число вызовов, которые его переиспользуют. Если U — цена не кэшированного ввода за токен, то префикс обходится в N × P × U без кэширования. Упрощенная оценка с кэшем: P × W + (N − 1) × P × R + S, где W — цена записи в кэш, R — цена чтения из кэша, а S — любая плата за хранение за период. Формула предполагает, что первый вызов создает кэш, а каждый последующий — успешное попадание. Она исключает переменный «хвост» каждого запроса, токены вывода, ретраи и любые изменения маршрута, приводящие к промаху.
Рассмотрим иллюстративный префикс в 100 000 токенов, переиспользуемый в 20 вызовах на официальной ставке GPT-5.6 Terra. При $2.50 за 1 миллион не кэшированных токенов ввода повторная обработка этого префикса стоила бы $5.00. Используя опубликованную ставку записи 1,25 от базовой и 90%-ю скидку на чтение, одна запись в 100 000 токенов обойдется примерно в $0.3125, а девятнадцать чтений — примерно в $0.475, суммарная стоимость префикса — около $0.7875. Разница составляет около $4.21 до учета переменного ввода и вывода. Это иллюстрация, а не оферта: она справедлива только если все девятнадцать последующих вызовов попадают в тот же действительный кэш и не применяется дополнительная плата за хранение или маршрутизацию.
Точка безубыточности следует напрямую из той же модели. Наценка на запись оправдана только тогда, когда до истечения срока хватает льготных чтений. Для нагрузки с короткими сессиями, частыми правками промптов или слабой привязкой к маршруту кэш может пересоздаваться чаще, чем ожидается. Для длительного агентного цикла или повторного анализа документа со стабильным префиксом число попаданий может быть гораздо выше. Поэтому в прогнозах следует использовать наблюдаемый диапазон hit-rate, а не предполагать идеальную последовательность после первого вызова.
Implementation patterns that improve cache reuse
Конструкция промпта оказывает большее влияние на долю попаданий, чем предполагают многие ценовые таблицы. Размещайте самый стабильный материал в начале и делайте его сериализацию детерминированной: системные инструкции, схемы инструментов, текст политик и общий справочный контекст должны сохранять один и тот же порядок, пробелы и представление полей в связанных вызовах. Изменяемый контент добавляйте после. Избегайте вставки меток времени, случайных идентификаторов, непрерывно изменяющихся счетчиков или результатов выборки, специфичных для запроса, в повторно используемый префикс, если это действительно не требуется.
Версионируйте стабильный материал намеренно. Если меняется схема инструмента или политика, последовательно назначайте новую версию вместо распространения множества почти идентичных вариантов. Для разговорных или агентных нагрузок переиспользуйте стабильный идентификатор сессии или ключ кэша, когда API это поддерживает, и избегайте смены провайдеров в рамках одной последовательности, зависящей от кэша. OpenRouter документирует привязку маршрутизации к провайдеру для кэширования промптов и предоставляет такие управляющие поля, как session_id и prompt_cache_key; они могут улучшить непрерывность, но не гарантируют попадание при холодном или истекшем апстрим-кэше.
Приложения также должны корректно деградировать при промахе. Кэширование — это оптимизация стоимости и задержки, а не зависимость корректности. Запрос все равно должен давать тот же правильный результат при недоступности кэша, а логика ретраев не должна слепо создавать повторные записи. Это разделение упрощает сравнение маршрутов: команды могут менять политику кэширования или конфигурацию шлюза без изменения семантики приложения.
How to verify cache economics in production
Начните с телеметрии на уровне запроса, а не с ежемесячного счета. Логируйте точный идентификатор модели, маршрут шлюза или провайдера, если он раскрыт, уровень сервиса, общее число токенов ввода, токены чтения из кэша, токены записи в кэш, токены вывода, задержку и тарифицированную стоимость. Объект использования OpenRouter включает поля cached_tokens и cache_write_tokens; другие провайдеры публикуют эквивалентные детали под разными именами полей. Сохраняйте «сырые» поля использования, чтобы последующие изменения цен не стерли доказательства, нужные для реконструкции стоимости.
Агрегируйте данные по версии промпта и типу нагрузки, а не только по модели. Полезные метрики включают долю пригодных запросов, попавших в кэш, долю токенов ввода, тарифицированных по ставке чтения, число записей на одно успешное чтение, время между записью и последним попаданием, и фактическую стоимость на запрос. Высокая доля попаданий на уровне запросов может давать малую пользу, если кэшируемый префикс мал, тогда как более низкая доля попаданий на очень большом префиксе может экономить больше. Сопоставляйте эти показатели с перцентилями задержки, поскольку более дешевый маршрут, который часто промахивается или перенацелен, может быть операционно хуже.
Наконец, анализируйте аномалии, а не сглаживайте их. Внезапное падение числа кэшированных токенов может указывать на выкатывание новой версии промпта, нестабильную сериализацию, истечение записей, границу уровня длинного контекста или смену маршрута шлюза. Сравните затронутые запросы с текущей страницей модели и документацией провайдера, затем проверьте тарифицированную ставку. Это закрывает разрыв между опубликованной скидкой и экономией, которую приложение действительно получает.
What to check before assuming a rate applies
Подтвердите пять пунктов, прежде чем закладывать опубликованную ставку в бюджет: точную модель и уровень сервиса, минимальный повторно используемый префикс или явные точки разделения кэша, плату за первую запись или хранение, срок жизни кэша и свидетельства того, что запросы действительно попадают в кэш. OpenAI в настоящий момент указывает минимальный срок жизни кэша 30 минут для GPT-5.6, но это не универсальное правило удержания. Google публикует разные ставки для уровней Standard, Batch, Flex и Priority. Шлюзы также могут маршрутизировать между провайдерами или уровнями, поэтому выбранный маршрут имеет значение. Документация OpenRouter по кэшированию промптов рекомендует проверять поля использования ответа, такие как cached_tokens и cache_write_tokens. Для любой производственной оценки сопоставляйте текущую страницу модели с фактическим биллингом и метаданными использования, а не полагайтесь только на общую пометку «caching supported».