# Когда prompt caching действительно снижает затраты coding-агента? > Prompt caching снижает стоимость, когда много запросов повторно используют большой побайтно стабильный префикс, а экономия cache read превышает затраты на запись, промахи и дополнительную сложность. Prompt caching полезен, когда агент многократно отправляет одно и то же большое начало, а не просто похожие для человека prompt. Timestamp, новый порядок инструментов, меняющееся summary workspace или request ID в начале могут разрушить повторное использование всего последующего текста. До переработки prompt исследуйте usage metadata реальных запросов. Определите число подходящих input tokens, сообщаемых cache read, частоту изменения префикса и наличие выгоды у выбранной модели и протокола. ## Смоделируйте базовую стоимость без cache Начните со стоимости ввода: caching не уменьшает output tokens и выполнение инструментов. ```text uncached_input_cost = requests * input_tokens_per_request * input_rate ``` Используйте единые размерности, обычно стоимость за миллион token. Не подставляйте скидку по памяти — берите текущий прайс и usage fields конкретной модели. | Компонент | Стабилен между запросами? | Размещение | |---|---|---| | Системная политика | Обычно | Первой | | Схемы инструментов | Обычно | В начале | | Правила repository | Часто | В начале | | Checkpoint задачи | Иногда | В середине | | Запрос пользователя | Редко | Ближе к концу | | Текущий вывод инструмента | Нет | Последним | ## Рассчитайте безубыточность символами Пусть `P` — token стабильного префикса, `R` — число запросов, `W` — ставка cache write, `H` — ставка cache read, `U` — обычная ставка ввода. ```text uncached = R * P * U cached = P * W + (R - 1) * P * H savings = uncached - cached ``` Идеальный случай предполагает hit после первого запроса. Для измеренной доли попаданий `h` замените последующий член взвешенной смесью `H` и `U`. Token вне префикса добавьте по обычной ставке с обеих сторон. Caching финансово полезен, только если экономия остаётся положительной после miss и инженерных затрат. ## Ставьте стабильный контент первым Стройте prompt от стабильного к изменчивому: * Системные инструкции и правила безопасности. * Определения инструментов в детерминированном порядке. * Правила repository и постоянные справочные материалы. * Компактный checkpoint задачи. * Текущий запрос пользователя. * Последний вывод инструмента. Сериализуйте схемы детерминированно. Избегайте случайного порядка, изменений whitespace, timestamp и комментариев конкретного запроса в префиксе. Версионируйте стабильные пакеты осознанно. ## Делайте префикс полезным, а не только большим Раздутый префикс может показать много cache read, одновременно увеличить общее число token и отвлечь модель. Удалите устаревшие инструменты, дублирующие правила и нерелевантные файлы. Измеряйте стоимость принятого изменения кода, а не только cache hit rate. Короткий prompt без cache может выиграть, если решает задачу за меньшее число ходов. ## Инструментируйте запросы и результаты Записывайте модель, протокол, версию префикса, общие input tokens, cached input tokens при наличии, output tokens, задержку, число tool call, retry и результат задачи. Отсутствующее поле помечайте unavailable, а не нулём. | Метрика | Зачем нужна | |---|---| | Доля кэшированных token | Подтверждает фактическое повторное использование | | Причина miss | Выявляет случайное изменение префикса | | Запросов на задачу | Показывает циклы, съедающие экономию | | Стоимость принятого изменения | Связывает token с полезным результатом | | Доля retry | Показывает издержки надёжности вне cache | Неделя репрезентативных задач полезнее, чем один синтетический prompt, повторённый сто раз. ## Учитывайте routing и границы сессий Поведение cache зависит от модели, провайдера, региона, retention window и routing. Gateway или fallback может отправить запрос на маршрут без того же прогретого префикса. Atlas Cloud предоставляет несколько LLM-форматов через один API, но не обещает единую скидку prompt cache. Проверяйте текущую модель и консоль. Используйте [LLM-протоколы](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=when-prompt-caching-reduces-coding-agent-costs) для формата и [каталог моделей](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=when-prompt-caching-reduces-coding-agent-costs) для актуальных деталей. ## Избегайте ложной экономии Низкая строка входной стоимости может скрывать дополнительные ходы, неудачные tool call или повторную реконструкцию context. Отличайте cache read от хранения на уровне приложения и retrieval — они решают разные задачи. Не помещайте секреты только потому, что контент можно кэшировать. Caching не заменяет контроль доступа и требования retention. ## Применяйте практический порог внедрения Внедряйте prompt caching, когда: * Стабильный префикс значим и часто повторяется. * Реальный usage показывает cache read. * Экономия сохраняется при наблюдаемой доле miss. * Версионирование префикса простое и детерминированное. * Качество задачи и число ходов не ухудшаются. Иначе сначала уменьшите prompt, извлекайте только релевантные файлы и сократите цикл агента. ## Итог Prompt caching уменьшает стоимость coding-агента, когда большой, полезный и побайтно стабильный префикс достаточно часто используется на маршруте с более дешёвым кэшированным вводом. Ставьте стабильный материал первым, считайте безубыточность по текущим ставкам и измеряйте стоимость принятого изменения. Высокий hit rate не помогает, если prompt избыточен или агенту нужно больше ходов. ## FAQ ### Какой контент лучше всего подходит для prompt caching? Стабильные системные инструкции, схемы инструментов, правила repository и редко меняющиеся справочные материалы подходят лучше live-логов и последнего сообщения пользователя. ### Почему переменный контент нужно ставить после стабильного префикса? Prefix cache обычно требует точного совпадения начала. Timestamp, request ID или меняющийся контекст в начале могут превратить весь последующий стабильный контент в miss. ### Всегда ли prompt caching уменьшает задержку? Нет. Эффект зависит от реализации провайдера, состояния cache, routing, модели, размера запроса и нагрузки. Измеряйте задержку отдельно от стоимости. ### Как рассчитать точку безубыточности? Сравните обычную стоимость ввода со стоимостью cache write и cache read при ожидаемом числе повторов, затем учтите инженерные затраты и долю miss. ### Можно ли кэшировать определения инструментов? Они могут быть частью повторяющегося префикса, если провайдер и протокол включают их в caching. Проверяйте usage metadata вместо предположений. ### Следует ли кэшировать весь coding-транскрипт? Обычно нет. Транскрипт меняется каждый ход. Сначала размещайте стабильные инструкции и схемы, затем короткий checkpoint и текущий запрос.