Доля попаданий в кэш OpenCode на моделях Claude

Главное

• Норма: 96.5%, медиана в продолжающихся диалогах (7 пользователей); средняя половина 94.4%–97.5%
• Все запросы: 90.3%, включая смену аккаунта, истечение кэша и новые диалоги
• Главная причина промахов: смена аккаунта, 37% промахов

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

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

• Доля попаданий в продолжающихся диалогах (медиана): 96.5%
• Средняя половина пользователей: 94.4%–97.5%
• Подходящие пользователи: 7 (не менее 20 продолжений диалога за неделю)
• Доля попаданий по всем запросам: 90.3%

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пара пунктов доли попаданий — счёт в разы больше

По официальным ценам Claude Opus 5.5, промахи записываются в 5-минутный кэш; фактическая стоимость миллиона входных токенов:

• Медиана этой недели: 96.5%: $0.37 (×1.0)
• 90%: $0.68 (×1.9)
• 80%: $1.16 (×3.2)
• 50%: $2.60 (×7.1)

Посчитайте свой случай в калькуляторе стоимости Claude API

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

• Формат Anthropic: cache_read_input_tokens ÷ (input_tokens + cache_read_input_tokens + cache_creation_input_tokens).
• Формат OpenAI: cached_tokens (в prompt_tokens_details или input_tokens_details) ÷ prompt_tokens / input_tokens.
• В Wokey в журнале запросов консоли у каждого запроса видны чтение и запись кэша.

Почему через посредников (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; привычки пользователей сильно различаются; доля по всем запросам включает собственные потери маршрутизации шлюза (причина «запрос ушёл на другой вышестоящий аккаунт»).

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