Как я сократил расход токенов в Claude Code на 75,5% с 17 локальными MCP — и почему byte saving недостаточно
RU-адаптация моей EN-статьи Two axes every LLM agent pays for (gregshevchenko.com, 2026-05-24). В этой версии добавлена секция cache-friendliness как второй первичной оси и измеренный directional finding, подтверждающий тезис на провайдере.
TL;DR
Local-first MCP-стек — это набор детерминированных prep-утилит, которые стоят между разработчиком и frontier-моделью (Claude, Codex, Cursor, Windsurf) и режут объём токенов на входе. Производственная стоимость этих токенов управляется не одной осью, а двумя.
- Byte saving — насколько компрессор уменьшает объём входного контекста.
- Cache-friendliness — насколько детерминированы байты на выходе. Если выход меняется между прогонами, prefix-cache провайдера не работает. Каждый ход платит за полный prefill заново — даже если byte saving у компрессора 99%.
Вторая ось «съедает» первую, если её игнорировать.
Контекст: за что платят разработчики Claude Code в 2026
Max-планы Anthropic — $100/мес (Max 5×) и $200/мес (Max 20×). Тяжёлое использование Codex или Claude Code без локальных prep-слоёв быстро упирается в session rate limits даже на $200 уровне.
Главная цена — не сама модель, а объём токенов, которые она читает перед каждым ответом. Большие, шумные prompts ведут к большему числу cache-misses, а значит к большим деньгам.
Локальные MCP как prep-слой
17 локальных MCP-серверов стоят перед frontier-моделью. Каждый — крошечная детерминированная утилита: ищет файлы, чистит логи, готовит структурный контекст, проверяет drift. Frontier-модель тратит токены на judgment, а не на raw search и не на noisy paste.
Headline measurement из EN-статьи: 75,5% сокращения токенов на объективном бенчмарке (25 заданий, paired none vs with-stack conditions).
Вторая первичная ось — cache-friendliness
Byte saving — необходимое, но не достаточное условие производственной экономии. Второе условие — byte-identical output между прогонами.
Идентичный output на одинаковом input запускает prefix-cache провайдера на downstream-ходах и превращает измеренное byte-saving в реальное сокращение цены. Недетерминированный output рушит кэш: каждый ход выглядит для провайдера как свежий prompt и платит полный prefill заново, часто съедая всё byte-saving в ноль.
Это framing из репозитория DenisSergeevitch/agents-best-practices — provider-neutral синтез OpenAI / Anthropic / MCP guidance. Базовое правило: stable prefix, dynamic suffix. Tool-definitions и static instructions идут первыми в детерминированном порядке. Dynamic state (текущий timestamp, request_id, свежие observations) идёт в конце. Любая volatile-вставка перед stable-блоком ломает кэш для каждого downstream-хода, который этот префикс шарит.
Локально-first компрессоры детерминированы по конструкции. Same input + same params → byte-identical output, каждый прогон. Это необходимое условие для downstream-кэширования, и оно не торгуется против byte-saving.
Реализации, которые удовлетворяют обе оси: parser-first text-compaction, regex-driven fact-extraction, extractive section selection — всё, что не ставит LLM в путь компрессии. Стохастические компрессоры, которые re-rank или re-summarise через модельный вызов, могут показать выше пиковое byte-saving на одном прогоне — но ломают вторую ось: их output варьируется и cache reuse падает до нуля.
Двенадцать анти-паттернов, которые рушат cache
Даже когда сам компрессор детерминирован, downstream-кэш можно убить архитектурой prompt-builder’а. Список из канона DSA:
- timestamp в stable description или response prefix
- request_id или correlation_id перед stable prefix
- рандомизированный порядок tool-definitions
- JSON serialization без стабильного порядка ключей
- live env injection перед static instructions
- секреты пользователя в stable description
- переписывание истории conversation на каждом turn
- re-summarising всей сессии каждый turn
- изменение schema formatting без versioning
- volatile retrieval-result перед stable instructions
- чрезмерно granular cache keys при low request volume
- отказ логировать cached_tokens (нечем измерить, что ломаешь)
Техническая ссылка: prompt-caching-and-cost.md.
Измеренный направленный результат
В benchmark-инфраструктуре есть 137 записей с полем cache_read_input_tokens из Anthropic usage block. Они покрывают и Claude Code agentic loops, и SWE-bench instances. Разрез — по двум условиям: с подключённым стеком против baseline без стека.
Результат структурный — даю только направление, без конкретных ratios (точные цифры остаются внутренними). С подключённым стеком downstream cache-reuse у провайдера выше и по среднему, и по суммарной доле, чем без стека. Эффект виден и на Claude Code agentic loops, и на SWE-bench.
Это эмпирическое подтверждение тезиса: детерминированные компрессоры — необходимое условие — действительно транслируются в более высокий downstream cache-reuse — достаточное условие.
Контр-пример из собственного стека
Не все компрессоры из коробки cache-friendly. В одной из сессий мы измерили один из MCP (retrieval-слой) на C2-бенчмарке (10 golden queries × N=3 runs) и нашли эффект, ради которого двух-осевая рамка вообще существует:
- Byte saving — на десятки порядков лучше любого text-summariser’а. Берёт мегабайты исходных файлов, возвращает килобайты ранжированных сниппетов.
- Cache-friendly score — около 30% (7 из 10 запросов давали разный md5 на одном и том же workspace). Источник: rg --files-with-matches не гарантирует стабильный порядок, и этот ордер протекал в Map-итерацию в findRelatedFiles.
Это ровно та ситуация, ради которой существует вторая ось: 99-percent-saver, который ломает cache-reuse, может производить хуже production-стоимость, чем 60-percent-saver с byte-identical output. Большое byte-saving на одной turn не компенсирует cache-miss на каждой subsequent turn.
Фикс шипнут — два surgical sorts в findRelatedFiles: sort rg output перед slice, sort Map-entries по path перед slice. После фикса cache-friendly score стал 100% на тех же 10 golden queries, byte saving не изменилось. Компрессор перешёл из «биггест saver, ниджест cache-friendly» в «биггест saver И полностью cache-friendly».
Что значит для маркетинговой и контент-команды
- Если ваш AI-stack использует custom prompt-builder или собственные MCP — прогоните 12-anti-pattern audit. Один зашитый timestamp в stable description убивает кэш на каждом client-side ходе.
- Не верьте byte-saving claims в одиночку. Просите second-axis cache-friendly proof: byte-identical output на одном input через N≥2 прогонов.
- Расчёт ROI должен включать обе оси. Prep-слой амортизирует затраты только если обе оси удовлетворены одновременно.
Дальнейшее чтение
- EN канон с полной методологией, источниками и сравнением vs Cursor / Cody / Continue / Aider / Firecrawl / LLMLingua / Martian / RouteLLM / Helicone / Langfuse: gregshevchenko.com/research/mcp-stack-token-economy. Секция cache-friendliness: cache-heading.
- DSA framework (источник cache-axis канона): github.com/DenisSergeevitch/agents-best-practices.
- Публичный local-first стек: github.com/g-shevchenko/mcp-token-savers.
- Формальная методология для peer-review-ready использования (формализация B/K/Q, cost-model theorem, Wilson 95% CIs на cache-friendly score, cluster-bootstrap CI на byte-saving, pre-registered протокол для N≥60 раунда, Gebru-style datasheet, Dockerfile для bytes-identical воспроизведения): mcp-token-savers/tree/main/methods. Нюанс честности: Wilson lower bound на κ при 15/15 даёт [0,796, 1,000] — корректная оценка population proportion для «100% cache-friendly» на маленьком N это ≥79,6%, а не 100%.
- Anthropic Code Execution with MCP (2026-11-04, primary source): anthropic.com/engineering/code-execution-with-mcp.
Если в вашем стеке прогон byte-identical через N≥2 запусков не пройдёт на одной из MCP — это не катастрофа, а measurement bug. Стоит он 1-2 surgical sorts и пары часов на 12-anti-pattern audit, а возвращает разницу между «76% byte saving которая платится reusable» и «99% byte saving которая платится prefill каждый turn».