Доля попаданий в кэш Codex

Главное

• Норма: 96.0%, медиана в продолжающихся диалогах (38 пользователей); средняя половина 93.1%–97.2%
• Все запросы: 93.6%, включая смену аккаунта, истечение кэша и новые диалоги
• Главная причина промахов: новый контент в ходе диалога, 73% промахов
• Между вариантами клиента: разница 2.1 п., Настольное приложение, Терминальный интерфейс, codex exec (неинтерактивно)

Какая доля попаданий в кэш нормальна для каждого клиента

Неделя 2026-09-29 – 2026-10-05 (UTC)

• Доля попаданий в продолжающихся диалогах (медиана): 96.0%
• Средняя половина пользователей: 93.1%–97.2%
• Подходящие пользователи: 38 (не менее 20 продолжений диалога за неделю)
• Доля попаданий по всем запросам: 93.6%

Codex по вариантам

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

• Настольное приложение: 95.7% (27)
• Терминальный интерфейс: 96.0% (8)
• codex exec (неинтерактивно): 97.8% (6)

Codex по версиям

Если релиз меняет префикс запроса, его доля попаданий заметно ниже, чем у других версий, — уже в неделю выхода.

• 0.160.0: 96.2% (21)
• 0.159.2: 96.1% (9)
• 0.159.0-alpha.12.1: 95.7% (5)
• 0.158.0-alpha.2.1: 93.5% (7)

Почему у Codex низкая доля попаданий в кэш: причины промахов

6.4% входа за эту неделю не было прочитано из кэша. Ниже — по причинам и с тем, что можно сделать.

Новый контент и изменения префикса в идущем диалоге: 73% промахов, около 4.7% всего входа

Кэшу OpenAI нужен полностью совпадающий префикс. Смена reasoning effort, инструментов или формата вывода посреди сессии, а также сжатие истории в Codex меняют префикс. Это главный источник промахов кэша у Codex.

Новый диалог или простой больше часа: 11% промахов, около 0.7% всего входа

Первый запрос нового диалога или запрос после часа простоя вынужден записать кэш заново.

Запрос ушёл на другой вышестоящий аккаунт или эндпоинт: 10% промахов, около 0.6% всего входа

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

Пауза больше 5 минут, кэш истёк: 3% промахов, около 0.2% всего входа

На GPT-5.6 и новее кэш по умолчанию живёт 30 минут с последней записи или использования; старые модели обычно теряют его после 5–10 минут простоя.

Параллельный запрос (предыдущий ещё не завершён): 1% промахов, около 0.1% всего входа

Запрос, отправленный до завершения предыдущего (субагенты, параллельные вызовы инструментов), не может прочитать кэш, который предыдущий ещё записывает.

Смена модели: 1% промахов, около 0.1% всего входа

У каждой модели свой кэш, поэтому первый запрос после смены модели читает всю историю заново.

TTL кэша Codex: сколько он живёт и сколько стоит

• OpenAI кэширует префиксы промптов автоматически, без точек останова в клиенте; GPT-5.6 и новее кэшируют промпты от 1024 токенов.
• GPT-5.6 и новее хранят кэш 30 минут по умолчанию — с последней записи или использования. Старые модели держат записи в памяти около 5–10 минут простоя, максимум час; некоторые поддерживают хранение 24 часа.
• Вход из кэша обычно стоит 0,1× цены входа, на GPT-6.1 Sol — 0,05×; GPT-5.6 и новее берут 1,25× за запись в кэш.
• Codex передаёт ID сессии как prompt_cache_key (по исходному коду), поэтому запросы одной сессии направляются в один и тот же кэш.

Кэширование промптов OpenAI · Диагностика промахов кэша OpenAI · Исходный код Codex (prompt_cache_key) · Codex issue #35416: промахи при смене reasoning effort

Как проверить долю попаданий в кэш у Codex

• При выходе Codex CLI печатает расход токенов за сессию; часть «+ N cached» — это вход, прочитанный из кэша (так работает текущая версия, в документации не описано).
• Из API: usage.input_tokens_details.cached_tokens ÷ usage.input_tokens; GPT-5.6 и новее также сообщают о записи в кэш.
• Метрика OpenTelemetry turn.token_usage содержит тип cached_input.
• В Wokey в журнале запросов консоли у каждого запроса видны чтение и запись кэша.

Диагностика промахов кэша OpenAI

Почему через посредников (relay) доля попаданий ниже

• Смена аккаунта: кэш принадлежит вышестоящему аккаунту, поэтому запрос, отправленный на другой аккаунт, переписывает всё заново. Самая частая причина у посредников; при прямом подключении её нет.
• Конвертация формата: при переводе между форматами Anthropic и OpenAI может меняться префикс или теряться точка cache_control.
• Claude Code до v2.1.181 с собственным base URL добавлял в блок атрибуции в начале системного промпта токен, разный для каждого запроса, поэтому шлюзы, кэширующие по телу запроса, не попадали в кэш; обновитесь или задайте CLAUDE_CODE_ATTRIBUTION_HEADER=0.
• Самопроверка: отправьте два запроса с одинаковым префиксом длиннее минимальной длины кэша; у второго чтение из кэша должно быть близко к длине префикса.

Wokey по возможности направляет последующие запросы диалога на тот же вышестоящий аккаунт. С 2026-10-04 по 2026-10-10 обычные пользователи Wokey получили 92.8% попаданий на Claude Opus 5.5 по всем запросам, OpenRouter в целом — 87.8%.

Сравнить с долей попаданий в кэш у OpenRouter · Онлайн: публичный API доли попаданий в кэш Wokey (7 дней)

Как мы измеряем

• Реальные запросы пользователей через шлюз Wokey; каждый понедельник в 05:00 UTC считаем прошлую неделю (с понедельника по воскресенье).
• Клиент определяется по User-Agent запроса. Запросы из SDK, HTTP-библиотек и от посредников, где настоящий клиент неизвестен, не учитываются; корпоративные клиенты тоже.
• Продолжение диалога: та же модель и тот же вышестоящий аккаунт, что у предыдущего запроса диалога, и старт не позже 5 минут после его завершения. Доля пользователя = чтение из кэша ÷ вход по таким запросам (вход включает чтение и запись кэша); публикуем медиану по пользователям, у которых за неделю не меньше 20 таких запросов.
• Ячейка публикуется, если в ней не меньше 5 подходящих пользователей; изменение больше чем на 3 пункта к прошлой неделе сначала проверяется вручную.
• Известные смещения: только пользователи Wokey; привычки пользователей сильно различаются; доля по всем запросам включает собственные потери маршрутизации шлюза (причина «запрос ушёл на другой вышестоящий аккаунт»).

Частые вопросы