Какая доля попаданий в кэш нормальна? Замеры AI-клиентов для кода
За неделю с 2026-09-29 популярные AI-клиенты для кода на моделях Claude достигали 88%–97% попаданий в кэш в продолжающихся диалогах, Codex на GPT — около 96%. Клиенты различаются мало; если у вас заметно ниже, причина обычно в смене аккаунта, паузах дольше 5 минут или новых диалогах.
Неделя 2026-09-29 – 2026-10-05 (UTC)
Главное
- Норма на моделях Claude: 88%–97%, медиана в продолжающихся диалогах, клиентов: 7
- Codex на GPT: 96.0%, медиана, 38 пользователей
- Самая частая причина промахов: смена аккаунта, 37% промахов Claude Code × Claude
- Опубликовано сочетаний: 10, клиент × модель, в каждом от 5 подходящих пользователей
Какая доля попаданий в кэш нормальна для каждого клиента
Доля попаданий в продолжающихся диалогах учитывает только запросы в том же диалоге, на той же модели и том же вышестоящем аккаунте, отправленные не позже 5 минут после завершения предыдущего: это то, чего добивается сам клиент. Доля по всем запросам включает ещё смену аккаунта, истечение кэша и новые диалоги и ближе к тому, что вы видите в счёте.
| Клиент × модель | Продолжающиеся диалоги | Все запросы | Пользователи |
|---|---|---|---|
| Codex × Claude | 97.1% (93.3%–99.4%) | 92.8% | 7 |
| Claude Code × Claude | 96.8% (94.9%–98.1%) | 90.9% | 120 |
| Codex × Doubao | 96.6% (95.0%–96.8%) | 95.3% | 16 |
| OpenCode × Claude | 96.5% (94.4%–97.5%) | 90.3% | 7 |
| Magpie × Claude | 96.5% (72.3%–98.4%) | 61.6% | 8 |
| Codex × GPT | 96.0% (93.1%–97.2%) | 93.6% | 38 |
| DeepSeek Harness × Claude | 95.6% (93.2%–96.8%) | 87.7% | 7 |
| pi × Claude | 95.1% (93.1%–98.5%) | 82.0% | 9 |
| Z Code × Claude | 88.3% (31.7%–92.0%) | 77.2% | 5 |
| pi × GPT | 68.3% (55.5%–78.5%) | 68.3% | 7 |
Идёт сбор данных
- Claude Code × DeepSeek: Идёт сбор: 4 из 5 подходящих пользователей (всего за неделю: 6)
- WorkBuddy × Claude: Идёт сбор: 4 из 5 подходящих пользователей (всего за неделю: 5)
- Z Code × GPT: Идёт сбор: 4 из 5 подходящих пользователей (всего за неделю: 4)
- Claude Code × GPT: Идёт сбор: 3 из 5 подходящих пользователей (всего за неделю: 8)
- Codex × DeepSeek: Идёт сбор: 3 из 5 подходящих пользователей (всего за неделю: 5)
- pi × DeepSeek: Идёт сбор: 3 из 5 подходящих пользователей (всего за неделю: 5)
- DeepSeek Harness × GPT: Идёт сбор: 2 из 5 подходящих пользователей (всего за неделю: 5)
- OpenCode × GPT: Идёт сбор: 1 из 5 подходящих пользователей (всего за неделю: 4)
Почему доля попаданий в кэш низкая: причины промахов по клиентам
- Claude Code × Claude: Запрос ушёл на другой вышестоящий аккаунт или эндпоинт 37%, Новый контент и изменения префикса в идущем диалоге 22%, Параллельный запрос (предыдущий ещё не завершён) 15%
- Codex × GPT: Новый контент и изменения префикса в идущем диалоге 73%, Новый диалог или простой больше часа 11%, Запрос ушёл на другой вышестоящий аккаунт или эндпоинт 10%
- Codex × Doubao: Новый контент и изменения префикса в идущем диалоге 69%, Параллельный запрос (предыдущий ещё не завершён) 10%, Запрос ушёл на другой вышестоящий аккаунт или эндпоинт 10%
- pi × Claude: Новый контент и изменения префикса в идущем диалоге 37%, Пауза больше 5 минут, кэш истёк 26%, Запрос ушёл на другой вышестоящий аккаунт или эндпоинт 18%
Почему через посредников (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; привычки пользователей сильно различаются; доля по всем запросам включает собственные потери маршрутизации шлюза (причина «запрос ушёл на другой вышестоящий аккаунт»).
Частые вопросы
Какая доля попаданий в кэш считается нормальной?
В продолжающихся диалогах на моделях Claude медиана пользователей популярных клиентов — 88%–97%; по всем запросам, включая смену аккаунта, истечение кэша и новые диалоги, обычно на несколько пунктов ниже. Ниже 90% причина редко в самом клиенте.
Что значат попадание и промах кэша?
Кэш промптов хранит неизменное начало запроса: системный промпт, описания инструментов, прошлые реплики. Если следующий запрос начинается так же, эта часть читается из кэша (попадание) и стоит долю цены входа; если начало другое или кэш истёк, запрос обрабатывается целиком (промах) и обычно заново записывается в кэш.
Высокая доля попаданий в кэш — это хорошо?
Да, чем выше, тем лучше. Вход из кэша тарифицируется примерно по 0,1× цены входа (у части новых моделей дешевле), а первый токен приходит быстрее; в подписках Claude чтение из кэша почти не расходует лимит.
Почему у меня такая низкая доля попаданий в кэш?
Обычные причины: запрос ушёл на другой вышестоящий аккаунт (часто у посредников), паузы дольше 5 минут, из-за которых кэш истекает, параллельные запросы вроде субагентов, смена модели и новые диалоги. На странице каждого клиента они перечислены по измеренной доле, с тем, что можно сделать.
Сильно ли различаются клиенты по доле попаданий?
Не сильно. На одной модели Claude Code, pi, OpenCode и другие различаются на несколько пунктов в продолжающихся диалогах. Важнее вендор: кэшу OpenAI нужен полностью совпадающий префикс, поэтому Codex на GPT на несколько пунктов ниже клиентов Claude.
Почему у посредников (relay) доля попаданий ниже?
Кэш принадлежит вышестоящему аккаунту. Посредник, который раскидывает диалог по нескольким аккаунтам или меняет префикс при конвертации формата, снова и снова переписывает кэш. Проверьте: отправьте два запроса с одинаковым префиксом — второй должен прочитать из кэша примерно длину префикса.
Низкая доля попаданий быстрее съедает лимит подписки Claude?
Да. По нашим замерам лимитов Claude чтение из кэша почти не расходует лимит, а запись в кэш считается примерно как некэшированный вход. Закэшированный контекст почти ничего не стоит, а при промахе засчитывается целиком. Лимиты по тарифам — на странице замеров лимитов Claude (/claude-usage-limits).
Как считается доля попаданий в кэш?
Токены, прочитанные из кэша, ÷ входные токены, где вход включает некэшированный вход, запись и чтение кэша. В формате Anthropic это cache_read_input_tokens, в формате OpenAI — cached_tokens.
Почему в таблице нет Cline, Roo Code или Cursor?
Ячейке нужно не меньше 5 пользователей с достаточным числом продолжений диалога за неделю. Запросы Cursor со своим ключом идут с серверов Cursor, поэтому шлюз не видит клиента; запросы через SDK и посредников тоже нельзя отнести к клиенту.