Кэширование промптов: оцените экономию в GetVibe

Агенты для программирования и ассистенты с несколькими ходами часто повторно отправляют один и тот же системный промпт, определения инструментов и начало диалога. Кэширование может сделать повторяющиеся входные токены дешевле, но только если модель, endpoint и структура запроса это поддерживают. Оно не снижает стоимость сгенерированного вывода, а повторения похожего текста недостаточно, если ключ кэша изменился. В этом руководстве отдельно рассматриваются автоматический механизм в стиле OpenAI и явное поведение с точками кэширования в Claude.

Что меняется в счёте?

Чтение из кэша оплачивается по тарифу для кэшированных входных данных вместо обычного тарифа для входных данных. В каталоге моделей GetVibe сведения о поддержке кэширования и его стоимости публикуются вместе с тарифами моделей. В снимке каталога, проверенном 3 октября 2026 года, среди примеров есть $0.0055 вход · $0.0274 выход за 1 млн токенов для GPT-6 Luna и $0.168 вход · $0.84 выход за 1 млн токенов для Claude Sonnet 5.5. Эти значения цен отображаются на основе актуальных страниц моделей. Также проверьте сведения о кэшировании на этих страницах; не предполагайте, что все модели используют один и тот же множитель или политику записи.

Простая оценка для повторяющегося префикса выглядит так: количество повторяющихся входных токенов умножается на обычный тариф для входных данных, а затем сравнивается с количеством повторяющихся входных токенов, умноженным на тариф чтения из кэша. Разница и есть потенциальная экономия на входных данных. Вычтите стоимость записи в кэш, если конкретная модель взимает такую плату. Чтобы превратить эту оценку в измеренный результат, нужны данные об использовании из ваших запросов.

Модели, совместимые с OpenAI: сохраняйте префикс неизменным

Для поддерживаемых маршрутов семейства OpenAI кэширование выполняется автоматически. В обычный запрос Chat Completions не нужно добавлять поле управления кэшем. Начало запроса должно оставаться неизменным. Размещайте системные инструкции, стабильные примеры и определения инструментов перед значениями, зависящими от пользователя. Не помещайте в начало временные метки, случайные идентификаторы или флаги функций, меняющиеся от запроса к запросу. Сохраняйте детерминированный порядок инструментов.

Если вы ожидаете совпадения того же префикса, не переписывайте предыдущие ходы диалога при продолжении сессии агента. Добавляйте новые ходы. Переключение моделей запускает отдельный кэш модели. Запрос может быть корректным и при этом не содержать кэшированных токенов в отчёте, если префикс короче порога кэширования модели или срок действия кэша истёк.

Claude: точки кэширования и endpoint Messages

В Claude кэширование использует точки управления кэшем. Интеграция GetVibe может вставить точку кэширования, если она отсутствует в поддерживаемых запросах Claude; если вы управляете точками самостоятельно, ознакомьтесь с актуальной документацией по кэшированию и размещайте маркер в стабильном разделе. Claude Code использует endpoint Anthropic Messages; в руководстве по интеграции Claude Code описаны его базовый URL и учётные данные.

curl https://getvibeapi.com/v1/messages \
  -H "x-api-key: $GETVIBE_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-5.5",
    "max_tokens": 300,
    "system": [{"type":"text","text":"Stable instructions shared by every request."}],
    "messages": [{"role":"user","content":"A request-specific question."}]
  }'

В этом примере показаны стабильный системный раздел и изменяющееся сообщение пользователя. Используйте актуальную документацию, чтобы узнать точное поле точки кэширования, поддерживаемое вашим клиентом и моделью.

Проверяйте попадание в кэш, а не предполагайте его

Дважды отправьте один и тот же длинный префикс, изменив только короткий суффикс. Изучите сведения об использовании в ответе. Ответы в формате OpenAI указывают кэшированные входные данные в поле prompt_tokens_details.cached_tokens; ответы в формате Anthropic содержат поля чтения из кэша и его создания. Информация о кэшировании также может отображаться на странице использования аккаунта. Если эти значения остаются равными нулю, проверьте равенство префиксов, минимальную кэшируемую длину, поддержку моделью и то, не изменился ли выбранный маршрут.

Используйте пример достаточного размера, чтобы превысить порог кэширования модели. Системный промпт из одного предложения может не дать заметной разницы. Сравните несколько повторных вызовов, поскольку срок жизни кэша и планирование запросов влияют на то, останется ли префикс доступным в кэше.

Практическая проверка экономии

1. Выберите один реальный промпт со значительным повторно используемым префиксом.
2. Зафиксируйте обычное использование входных данных и актуальные тарифы на странице модели.
3. Повторите запрос, изменив только суффикс пользователя.
4. Убедитесь, что в ответе указаны кэшированные входные данные.
5. Сравните стоимость повторных запросов в учётных данных.

Во время эксперимента сохраняйте примерно одинаковую длину вывода, чтобы затраты на вывод не скрывали изменения во входных данных. Не заявляйте об экономии только на основании множителя кэширования; проверьте количество попаданий в кэш и оплаченный объём использования.

Распространённые промахи кэша

• Перед стабильными инструкциями появляется временная метка или идентификатор запроса.
• Определения инструментов сериализуются в разном порядке в каждом запросе.
• Приложение по-разному изменяет пробелы или обрезает историю.
• Модель меняется между ходами.
• Префикс слишком короткий или окно кэширования завершилось.

Когда кэширование работает, оно может сделать длительные диалоги с агентом экономичнее, но это не повод отправлять ненужный контекст репозитория. Делайте промпты целенаправленными и оценивайте общую стоимость задачи. Более подробную информацию об endpoint можно найти в руководстве по реализации кэширования и на актуальной странице цен модели.