Модуль: Кеширование и токеномика для агентных систем

Курс для Лучиана. Тон: умный не-технарь с медицинским образованием. Каждая тема идёт тремя слоями: сначала по-человечески → как это называется по-настоящему → детали для любопытных (сворачиваемый блок). Все цифры сверены с caching-verify.md. Метки честности: [проверено] — подтверждено официальной документацией Anthropic; [осторожно] — цифра реальна, но неофициальная (реверс-инжиниринг сообщества), может отличаться по версии; [исправлено] — в сырье была ошибка, здесь дано верное значение.

Оглавление

1. Зачем это вообще: боль про «монстра за $1000 в минуту»
2. Как работает prompt caching (кеширование промптов)
3. Раздувание контекста и изоляция субагентов
4. Пять рычагов экономии (и где кеш их усиливает)
5. Практика для мега-проекта (мультиагентная ОС на Agent SDK)
6. Практика для мини-завода (10 каналов за копейки)
7. Мониторинг и стоп-краны
8. Чек-лист внедрения + расчёт экономии на живом примере

1. Зачем это вообще: боль про «монстра за $1000 в минуту»

По-человечески. Представь пациента с нарушенным метаболизмом: он ест нормально, но энергия сгорает впустую — тело тратит калории на бессмысленное перегревание, а не на работу. Твоя боль из практики — ровно это. На задаче в 12+ шагов контекст раздувался до ~1 миллиона токенов, и ты платил за перечитывание одного и того же снова и снова. Каждый новый шаг тащил за собой всю предыдущую историю, модель её перечитывала, и счётчик крутился. Страх «монстра, кушающего $1000 в минуту» — это страх системы с испорченным метаболизмом.

Хорошая новость: метаболизм лечится. И главное лекарство называется кеширование. Оно превращает повторное перечитывание из «полной цены» в «одну десятую цены». Всё остальное в этом модуле — как не давать организму раздуваться и как заставить каждый токен работать.

Как это называется по-настоящему. Токены (tokens) — это единицы «топлива»: кусочки текста (примерно 3–4 символа), которые модель читает и пишет. Всё, что модель видит за один вызов, — системный промпт, инструкции, история диалога, определения инструментов, результаты, твой вопрос — суммируется в контекстное окно (context window). За каждый токен на входе и выходе платят деньги. Раздувание контекста = линейный рост счёта плюс падение качества.

Почему мультиагенты особенно опасны. Простой чат тратит 1× токенов, обычная агентная система — около 4×, а мультиагентная — до 15× [проверено, Anthropic]. Причина — «компаундированные» издержки: каждый агент перечитывает накопленный контекст, каждый инструмент добавляет свою схему (10–60K токенов), при ошибке на шаге 15 система переобходит всё заново, и это стоит в 15 раз дороже, чем ошибка на шаге 1. Официальная дока Anthropic прямо называет множитель 7× токенов для «команд агентов» в plan-режиме против обычной сессии [проверено]. Вот откуда берётся монстр.

Разберём шесть механизмов, которые одновременно раздувают счёт (полезно понимать врагов в лицо): 1. Дубликат контекста — при параллельных агентах одна и та же информация хранится и передаётся столько раз, сколько агентов работает. 2. Издержки оркестрации — супервизор добавляет ~30% сверху: держит статус субагентов, переписывает координацию. 3. Налог на координацию — чем больше агентов, тем больше каналов связи между ними (10 агентов = до 45 каналов). 4. Циклы ретраев — ошибка на позднем шаге переобходит весь путь с полной историей. 5. Стек проверок — рефлексивные архитектуры (агент проверяет сам себя) точнее, но в ~2.3× дороже. 6. Долгие процессы — context rot: качество падает по мере роста окна, ошибки учащаются, ретраи удлиняются.

Каждый из шести лечится либо кешем, либо изоляцией, либо и тем и другим. Об этом — весь модуль.

2. Как работает prompt caching (кеширование промптов)

По-человечески. Это как анамнез пациента, который ты не переспрашиваешь на каждом приёме. Первый визит — ты записал всю историю болезни (это стоило времени). Каждый следующий визит — ты не расспрашиваешь заново, а достаёшь готовую карту почти мгновенно и бесплатно. Prompt caching делает то же самое: стабильную часть промпта сервер Anthropic запоминает, и повторные вызовы читают её за одну десятую цены.

Как это называется по-настоящему. Ты помечаешь блок контента флагом cache_control. Сервер считает хеш (отпечаток) всего, что идёт до этой точки — она называется точка разрыва кеша (cache breakpoint). При следующем вызове, если отпечаток совпал, этот кусок читается из кеша.

Точные множители цены [проверено]

TTL (time-to-live, срок жизни кеша) — сколько кеш живёт без обращений: - 5 минут — по умолчанию, доплаты за запись нет сверх 1.25× [проверено]; - 1 час — расширенный, запись стоит 2.0× [проверено]. Любое чтение внутри срока обновляет таймер и стоит 0.1× при обеих TTL.

Когда кеш окупается [проверено]: - 5-минутный — после первого же повторного чтения. Пример на Opus 4.8: запись $6.25 + чтение $0.50 = $6.75 против двух полных входов 2×$5 = $10. Уже выгодно. - 1-часовой — после двух повторов: $10 запись + 2×$0.50 = $11 против 3×$5 = $15.

Что кешировать, а что нет

Кешируй стабильное (оно не меняется от вызова к вызову): - системный промпт и инструкции; - определения инструментов (tools) — они идут первыми и инвалидируют всё, если меняются; - CLAUDE.md проекта; - большая база знаний, примеры (few-shot), профиль/стиль.

НЕ клади в кешируемую часть изменчивое: - ID канала, тему видео, timestamp, номер запроса; - результаты предыдущего шага, которые каждый раз разные.

Золотое правило порядка: стабильное — сначала, изменчивое — потом. Точка разрыва ставится в конце стабильного префикса, а всё переменное идёт после неё, в user-сообщении.

# ПРАВИЛЬНО: разрыв на стабильном префиксе
system=[
    {"type": "text",
     "text": "Инструкции стадии + примеры (12K токенов, стабильно)",
     "cache_control": {"type": "ephemeral"}}   # ← точка разрыва здесь
]
messages=[
    {"role": "user",
     "content": f"Канал: {channel_id}\nТема: {topic}"}  # ← изменчивое, ПОСЛЕ разрыва
]

Если сделать наоборот — воткнуть timestamp или ID канала до разрыва — отпечаток будет разным каждый раз, и кеша не будет вообще. Это ошибка №1.

Минимальная длина для кеша [проверено / исправлено]

Кеш включается, только если префикс достаточно длинный:

[исправлено] В одном из исходников таблица была противоречивой (там 1024 ошибочно приписали Opus 4.6/4.5). Верно: 1024 — это Sonnet-семейство и Opus 4.8, а Opus 4.6/4.5 и Haiku 4.5 требуют 4096. Практически системные промпты стадий (3–14K токенов) всегда выше минимума, так что порог тебя не ограничит.

Предварительный прогрев кеша (cache warming)

Первый запрос всегда платит запись (1.25× или 2×) — это «штраф холодного старта». Если критична задержка первого ответа, кеш можно прогреть заранее: отправить пустой warm-up вызов, который только пишет системный промпт в кеш, ничего не генерируя. После этого все боевые запросы идут по горячему кешу. Для конвейера, который стартует по расписанию, прогрев за секунду до батча означает, что даже первый канал читает из кеша.

Как это ложится на твою биологию

Кеш — это как истории болезни в регистратуре. Первый приём пациента ты завёл карту (заплатил временем — это запись, 1.25×). Дальше карта лежит в регистратуре: любой врач достаёт её мгновенно (чтение, 0.1×). Но карта живёт не вечно — через 5 минут или час без обращений её убирают в архив (TTL истёк), и при следующем визите заводят заново. Смысл: обращайся к карте часто, пока она на руках — гоняй все повторные вызовы кучно, внутри окна TTL.

3. Раздувание контекста и изоляция субагентов

По-человечески. Если врач держит в голове всю историю всех пациентов за день, к вечеру он путается и упускает детали. Мозг человека и контекст модели ведут себя одинаково: чем больше набито, тем хуже внимание. Лекарство — не «помнить всё», а изолировать: каждой подзадаче — свой чистый стол, только нужные бумаги, а результат вернуть коротким выводом.

Почему многошаг раздувается. Без контрмер контекст растёт линейно: шаг 1 — 5K, шаг 3 — 12K, шаг 12 — 50K+ и дальше к миллиону. Каждый шаг тащит всю предыдущую историю. Это и есть твоя исходная боль. И раздувание бьёт дважды: сначала по кошельку (платишь за перечитывание), потом по качеству (модель начинает путаться). Это как перегруженный ординатор в конце суток: и медленнее, и ошибок больше.

Отдельно вредна нагрузка инструментов: определения tools могут занимать 60–80% всех токенов ещё до начала рассуждений, а каждый MCP-сервер добавляет 10–60K токенов схем на ход. Отсюда правило: не подключай все MCP везде. Супервизору — 1–2 нужных, а специфические инструменты раздай субагентам (research-субагенту — веб и ниши, gen-субагенту — FastGen и картинки). Каждый видит только свой набор — и контекст, и кеш чище.

Как это называется: lost-in-the-middle (потеря в середине) [проверено]. Модель хорошо помнит начало и конец контекста и хуже всего — середину. Это не баг конкретной модели, а свойство архитектуры трансформера. Вывод: даже при окне в 1M токенов нельзя рассчитывать, что модель одинаково внимательна ко всему. Нужен активный отбор 5–10 релевантных записей, а не «весь банк на всякий случай».

Автокомпакция ~167K [осторожно]. Claude Code при приближении к порогу автоматически сжимает историю: оставляет ~5 последних прочитанных файлов и сворачивает остальное в резюме. Цифра ~167 000 токенов реальна и широко цитируется, но официально Anthropic её не публиковал — разные версии называют от 150K до 187K, а для моделей с окном 1M порог другой (около 400K). Не закладывайся на неё как на точную константу; закладывайся на сам принцип: «история сожмётся сама, и что-то может молча пропасть».

Не путать. «LEARNING» — это стадия ⑨ твоего большого завода (выключена). «Компакция» — сжатие контекста. Разные вещи.

Три контрмеры

1. Минимальный контекст субагента. Субагент получает только явную декларацию задачи (1–2 абзаца) и свежее окно. Он не наследует историю родителя, его system-промпт и результаты инструментов. Единственный канал передачи — строка задачи. Результат он возвращает структурированной выжимкой (1–2K токенов), а не сырьём на 50K. Оркестратор передаёт выжимки, не сырьё.

2. Внешняя память вместо контекста. Промежуточные результаты пишутся в файлы (scratchpad, progress.json, profile.json, memory-bank), а агент читает только нужное. Это твой memory-bank в чистом виде — он и есть внешняя долговременная память организма.

3. Свежая сессия / компакция между этапами. Новый этап начинается с чистого оркестратора, который читает progress.json (сотни токенов), а не тащит всю историю. Это лечит «context anxiety» — состояние, когда переполненная модель начинает преждевременно объявлять задачу выполненной. Для ночной автономии это критично: агент на шаге 8 из 12 не должен «сдаться» из-за раздутого окна.

Числа, которые доказывают, что это работает

Замер на многошаговой задаче (GPT-5, expense itemization) [проверено как воспроизводимый результат исследования]:

Вывод парадоксальный, но железный: меньше контекста = дешевле И точнее. Стратегия «последние 5 + резюме» дала −63% токенов и одновременно подняла качество с 71% до 91.6%. Это ровно то, что тебе нужно для ночной автономии: не «помнить всё», а помнить правильное.

По замерам retrieval-подхода (Mem0): полный банк в контекст = 26 000 токенов на запрос; отбор релевантного (semantic + ключевые слова) = 6 900 токенов — −73% при росте точности. Это прямая инструкция для твоего memory-bank: не вываливай весь profile.json и весь лог в промпт, доставай 5–10 нужных записей.

Scratchpad как «вторая память» (git-подобный паттерн)

Долгоживущий проект удобно вести как git: main.md — глобальная карта (всегда в контексте, 2–3K), а полная сырая история (log.md, может быть 50K) лежит в файлах и подтягивается только если понадобится покопаться. Агент видит 3–4K актуального, но имеет доступ ко всему. Для ночной разработки это и защита от компакции (файл не сотрётся), и точка восстановления при сбое (run_id + stage).

4. Пять рычагов экономии (и где кеш их усиливает)

Пять рычагов, которые вместе снижают счёт в разы. Кеш — не отдельный шестой, он усиливает каждый из них.

Рычаг 1. Изоляция контекста. Дробим цепочку на фазы, каждый субагент видит минимум. → Кеш усиливает: у каждой изолированной стадии свой стабильный system-промпт, который кешируется и переиспользуется на всех каналах.

Рычаг 2. Внешняя память. Сырьё в файлы, в контекст — только выжимки (отбор 5–10 записей вместо всего банка экономит ~73% токенов по замерам Mem0). → Кеш усиливает: стабильную часть профиля канала можно держать в кешируемом блоке, а из памяти подтягивать только свежие изменения.

Рычаг 3. Компакция / свежая сессия. /compact между этапами, новый оркестратор на новую фазу. → Кеш усиливает: после компакции стабильный system остаётся кешируемым, переписывается только сжатое резюме.

Рычаг 4. Лестница моделей (model routing). Haiku-класс на механику, Sonnet на код и тексты, Opus только на архитектуру. Твоё правило «Sonnet = Opus на чётких код-задачах, ×4 дешевле» — ровно это. Официальный паттерн Anthropic (Opus планирует, Sonnet исполняет) даёт около −43–50% [проверено]. → Кеш усиливает: множители кеша (1.25× / 0.1×) одинаковы для всех моделей, поэтому на дешёвой модели кеш даёт ту же 90% скидку в абсолютных копейках.

Рычаг 5. Mechanical-first. Если задача решается grep/скриптом — не зови LLM. Твой замер: LLM-аудит 10 тулок = ~4M токенов, grep = 0. → Кеш усиливает: тут наоборот — механика вообще убирает вызов, а кеш экономит на тех вызовах, что остались.

Бонусный слой: семантическое кеширование (semantic caching)

Prompt caching совпадает по точному тексту. Есть второй тип — семантический кеш: он ищет запросы, близкие по смыслу (через эмбеддинги, порог сходства ~0.85–0.95), и переиспользует готовый ответ. Это отдельный компонент (Redis/векторная база), не встроенный в API. На повторяющихся нагрузках hit rate 60–83%, экономия 40–80% [проверено как диапазон из исследований]. Для тебя это перспектива, не первый шаг: сначала выжми prompt caching (встроен, бесплатен в настройке), а семантический добавляй, когда пойдут тысячи однотипных запросов (например, массовая проверка описаний видёв). Аналогия: prompt caching — это карта конкретного пациента; семантический — «у нас уже был похожий случай, вот что помогло».

Реальные кейсы экономии (для ориентира)

• Advisor-Executor (Opus советует, Sonnet исполняет): −48% при том же качестве [проверено].
• Semantic caching на support-нагрузке: −71% ($3540/день сэкономлено на 100K запросов) [проверено].
• Смена стека на локальные/дешёвые модели: −87%, но с −4% качества и требованием локального инференса (у тебя RTX 3090 — вариант для механики) [проверено как кейс].

Мораль: рычаги складываются мультипликативно. Кеш −59%, поверх лестница моделей −43%, поверх batch −50% — и «монстр» худеет в разы.

⚠️ Важнейший нюанс для твоих claude -p вызовов [проверено на практике завода]. Каждый вызов claude -p несёт ~13K токенов создания кеша системного промпта самого Claude Code — независимо от модели. Поэтому Haiku на мелких QC-проверках не дешевле Opus: эти 13K доминируют над разницей в цене модели. Два вывода: (а) экономь число вызовов, а не модель; (б) для аргументированного вердикта (хорош ли скрипт, тайтл) бери модель поумнее — она почти не дороже, раз 13K всё равно платятся; (в) кешируй этот 13K системный промпт между вызовами в пределах TTL на одном аккаунте — это прямой рычаг экономии.

5. Практика для мега-проекта (мультиагентная ОС на Agent SDK)

Цель — универсальный ночной строитель и веер MVP на Agent SDK. Здесь кеш и изоляция решают, будет ли система дешёвой by design. Мысленная модель: оркестратор — это нервная система (передаёт команды и выжимки, а не всю кровь организма), субагенты — специализированные органы (каждый со своим чистым «рабочим столом»), memory-bank — долговременная память, а кеш — регистратура с историями болезни. Если нервная система начнёт гонять по телу полный анамнез каждого органа при каждом импульсе — организм сожжёт всю энергию на пересылку. Поэтому три правила: минимум контекста на орган, выжимки вместо сырья, кеш на всё стабильное.

5.1 Кешируй system prompt по субагентам

Каждый субагент в Agent SDK описывается через AgentDefinition с собственным prompt. Этот промпт стабилен между вызовами — идеальный кандидат в кеш.

from claude_agent_sdk import query, ClaudeAgentOptions, AgentDefinition

options = ClaudeAgentOptions(
    allowed_tools=["Read", "Grep", "Glob", "Agent"],
    agents={
        "planner":  AgentDefinition(description="Архитектор плана",
                    prompt=PLANNER_SYSTEM,   # стабильно → кешируется
                    model="opus"),
        "coder":    AgentDefinition(description="Пишет код по плану",
                    prompt=CODER_SYSTEM,     # стабильно → кешируется
                    tools=["Read","Edit","Bash"], model="sonnet"),
        "critic":   AgentDefinition(description="Критикует результат",
                    prompt=CRITIC_SYSTEM, model="sonnet"),
    },
)

Держи AgentDefinition.prompt стабильным, а задачу конкретного прогона передавай в строке вызова субагента (это единственный канал к нему) — тогда кеш system-части живёт, а меняется только задача.

5.2 Context editing (редактирование контекста)

Не давай сессии расти бесконтрольно. Между фазами — явные checkpoint'ы: результат фазы 1 пишем на диск, фазу 2 запускаем с чистым контекстом, читая файл.

# Фаза 1: анализ (ограничить!)
async for m in query(prompt="Проанализируй src/ на уязвимости",
        options=ClaudeAgentOptions(allowed_tools=["Read","Grep"], max_turns=3)):
    ...
open("/tmp/phase1.txt","w").write(results)          # checkpoint на диск

# Фаза 2: свежая сессия читает выжимку, а не сырую историю
async for m in query(prompt=f"На основе findings:\n{open('/tmp/phase1.txt').read()}\nСделай рефакторинг",
        options=ClaudeAgentOptions(allowed_tools=["Read","Edit","Bash"], max_turns=5)):
    ...

max_turns не даёт фазе раздуться; диск сохраняет результат от молчаливой компакции. Для длинных потоков предпочитай server-side compaction (context_management) — она сохраняет больше кеша, чем ручное сжатие на уровне SDK.

5.3 Memory tool (внешняя память)

Три уровня памяти = твоя биология: рабочая память (контекст, эфемерна) → индивидуальная долгая (progress.json, findings) → общая (правила, скиллы, memory-bank). Правило: в контекст идут выжимки и 5–10 релевантных записей, а не весь банк. Это твой memory-bank×3, эволюционировавший в дисциплину retrieval.

5.4 Кеш «по волнам»

Веер MVP = волна параллельных субагентов. Ключ к дешевизне: у всех генераторов волны общий стабильный system-префикс (общие правила, критерии, домен-контекст), помеченный cache_control, и разная задача после разрыва. Первый агент волны пишет кеш (1.25×), остальные читают (0.1×). При 8 генераторах общий контекст оплачивается один раз, а не восемь.

Для веера бери TTL 1 час: волна и турнир судей идут дольше 5 минут, а стабильный домен-контекст переиспользуется десятками вызовов — окупается со второго повтора.

5.5 Что наследует субагент (и что кешируется)

Полезно точно знать, что переходит субагенту, а что нет [проверено по докам SDK]:

Практический смысл: субагент дёшев by design, потому что стартует с чистым окном. Единственный канал передачи данных к нему — строка задачи в вызове Agent. Всё, что субагенту нужно, передавай явно и коротко — и не бойся, что он утащит в себя раздутую историю родителя: он её не видит.

5.6 Экономика волны в цифрах

Типичный веер MVP [проверено как расчёт из исходника]:

Волна 0 (Opus, план):      10K токенов  → $0.05
Волна 1 (8 × Haiku парал.): 8 × 5K       → $0.04
Волна 2 (Opus, синтез):    15K выход     → $0.075
Итого сложный анализ ≈ $0.165  вместо ~$1.25 на одном Opus со 100K контекста

Экономия ~87% и ускорение (агенты работают параллельно, а не по очереди). Кеш добавляет сверху: общий домен-контекст волны оплачивается записью один раз.

⚠️ Помни про множитель 7× для «команд агентов» в plan-режиме [проверено] и глубину вложенности 5 уровней [проверено]. Держи команды малыми (3–4 агента), выключай агента, когда его работа готова, и не строй башни субагентов глубже пяти этажей.

6. Практика для мини-завода (10 каналов за копейки)

Мини-завод запускается послезавтра, крутится нон-стоп на 5–10 каналах. Каждая стадия (title → script → visual_rules → … → render) имеет стабильный промпт и изменчивый вход (профиль канала + тема). Кеш здесь превращает 10 каналов в стоимость 2–3.

6.1 Кешируй промпт стадии + профиль канала

Схема на стадию: стабильное (инструкции стадии + few-shot примеры) → cache_control → изменчивое (профиль канала + тема) в user-сообщении.

STAGE_SYSTEM = [
    {"type": "text",
     "text": "# Стадия SCRIPT\nПравила + примеры (стабильно, ~10K токенов)",
     "cache_control": {"type": "ephemeral", "ttl": "1h"}}   # разрыв здесь
]
for channel in channels:          # 10 каналов
    r = client.messages.create(
        model="claude-sonnet-5", max_tokens=1024,
        system=STAGE_SYSTEM,      # канал 1 пишет кеш, каналы 2-10 читают 0.1×
        messages=[{"role":"user",
            "content": f"Ниша: {channel['niche']}\nТема: {topic}"}]  # изменчивое, после разрыва
    )

Профиль канала (profile.json: ниша/маскот/стиль/scene-mix/voice_id/peak-hours) для повторных прогонов одного канала можно поднять в кешируемый блок вторым сегментом system — тогда повторные видео этого канала читают и правила стадии, и профиль из кеша.

6.1a Где в твоём конвейере кеш даёт больше всего

Из карты стадий (STAGE_MAP): мозг тратится в 3–4 местах — script (1 Opus + веб-ресёрч + extended thinking, самый тяжёлый единичный вызов), visual_rules (ceil(сцены/75) Opus-вызовов, на длинном лонге дороже script), derive shorts+reels (2 Opus), и скрытый пожиратель — vision-QC картинок (до сцены×3 haiku-вызовов, >1000 на длинном лонге). Приоритеты кеша:

• script / visual_rules: стабильные инструкции стадии и правила стиля канала — в кешируемый префикс. Ресёрч (изменчивый) идёт после разрыва. На 10 каналах правила стиля пишутся раз, читаются девять.
• vision-QC (скрытый пожиратель): здесь главный рычаг — не кеш, а батчить (несколько кадров в один вызов) и/или проверять только сэмпл. Помни: 13K системного промпта Claude Code на каждый claude -p доминирует, поэтому 1000 мелких вызовов — это 1000×13K впустую. Сократи число вызовов в разы — и кеши общий префикс между оставшимися.
• derive shorts/reels: в мини переписать компактно (в боевом гварде — взаимоблокировки и выброс дорогого Opus-плана целиком). Стабильную часть плана — в кеш.

6.1b Механическое где можно (0 токенов)

Твой принцип «мини-QC на каждой стадии» держится на разделении: длина тайтла, наличие полей, формат — скрипт, 0 токенов (mechanical-first, grep вместо LLM); визуальное описание кадра — Haiku (vision); аргументированный вердикт о качестве скрипта/тайтла — модель поумнее (Sonnet-класс) через brain-router. Кеш экономит только на тех вызовах, что реально нужны; механику он не заменяет и не должен — там вызова просто нет.

6.2 Повторные вызовы по 10 каналам — копеечные

Break-even на стадии Idea Generation (system 11K, вход 500 токенов/канал), TTL 1 час: - канал 1: запись 11K ($0.044 на Sonnet) + вход; - каналы 2–10: чтение 11K ($0.002 каждый) + вход. Итог по стадии ~$0.222 против ~$0.39 без кеша — −43%. По всем 4 стадиям на 10 каналов: ~$0.50 против ~$1.2 — −59%. С batch API поверх кеша — до −70–80% [проверено, расчёты из pipeline-исходника].

6.3 ⚠️ Мульти-аккаунтный claude -p: разные аккаунты = разный кеш

Это критично для твоего brain-router (Claude acct1 → acct2 → AnyModel). Кеш изолирован на уровне workspace/аккаунта [проверено]. Аккаунт 2 не видит кеш аккаунта 1. Последствия:

• При failover на второй аккаунт кеш начинается с нуля — платишь запись заново. Заложи в бюджет failover × ~1.2.
• Не гоняй один и тот же батч каналов по разным аккаунтам «для балансировки» — так ты платишь запись N раз вместо одного. Держи один батч на одном аккаунте, пока он жив; переключайся только при реальном падении.
• Помни про 13K системного промпта Claude Code на каждый claude -p: чтобы он кешировался, серия вызовов должна идти на одном аккаунте в пределах TTL. Failover эту экономию обнуляет — это цена надёжности, задокументируй её.

Практический вывод для мини-завода: предпочитай прогонять всю стадию по всем 10 каналам подряд, на одном аккаунте, внутри окна TTL — так стабильный префикс пишется один раз и читается девять. Fallback на acct2/AnyModel — только когда стадия реально застряла (защита от Loop of Death), с осознанием, что кеш там холодный.

6.4 Порядок обработки батча имеет значение

Одна и та же работа стоит по-разному в зависимости от порядка. Плохой порядок — «канал A: все стадии, канал B: все стадии...»: тогда между двумя обращениями к промпту стадии script проходит весь конвейер канала A, и 5-минутный TTL успевает истечь — кеш холодный на каждом канале. Хороший порядок — по стадиям: «стадия script: A, B, C … J подряд», потом «стадия visual_rules: A…J». Тогда промпт стадии пишется один раз и читается девять раз кучно, внутри TTL. Это бесплатная оптимизация — просто переставь циклы местами (внешний цикл — стадия, внутренний — канал), и hit rate прыгнет к 90%.

7. Мониторинг и стоп-краны

По-человечески. Это приборы у постели пациента: пульс, давление, тревога при выходе за норму. Без них ты узнаешь о проблеме по счёту в конце месяца — поздно. Мониторинг — это не бюрократия, а иммунная система: он ловит «воспаление» (аномальный расход) до того, как оно станет сепсисом ($1000/мин).

Ещё один прибор — лимит скорости (TPM, tokens per minute). Для соло-оператора Anthropic рекомендует 200–300K TPM (это ~12M токенов в час) [проверено]. Выставь его как потолок: он не даёт одному сбойному циклу выжрать всё за минуту. Это верхняя граница «сердечного ритма» системы.

Что мерить

• Cache hit rate = cache_read / (cache_read + cache_write). Цель для стабильного конвейера — 90%+. Ниже 40% — красный флаг: кеш сломан (изменчивое до разрыва / короткий промпт / TTL истёк / разные аккаунты).
• $/задача — стоимость одного прогона (одно видео, один MVP). Твоё правило: >250K cache-read или >$0.50 на задачу → стоп и пересборка.
• $/день и $/месяц — против бюджета $500–2000.
• Распределение по моделям — Haiku < Sonnet < Opus по объёму. Если Opus жрёт больше всех — лестница моделей нарушена.

Инструменты

/context     # разбивка контекста: system / CLAUDE.md / история / файлы / свободно
/usage       # бухгалтерия сессии: cache write/read, свежий вход, output, стоимость
/model sonnet   # переключить модель на лету

В Agent SDK каждая ResultMessage несёт cache_creation_input_tokens, cache_read_input_tokens, input_tokens, output_tokens — собирай их в свою веб-панель для $/задача и $/день.

Как читать /context (пример)

System prompt         4.2K   2%
CLAUDE.md (project)   8.5K   4%
Conversation history 87.3K  43%   ← если это растёт неограниченно — тревога
File reads (recent 5) 25.4K 13%
Tool results (cached) 12.1K  6%
Free space           61.3K  31%
Pressure: 69% / 200K

Правило: давление > 80% → /compact перед продолжением, иначе близко к автокомпакции, которая молча что-то сотрёт. Если Conversation history — самый жирный кусок, значит нарушены изоляция и внешняя память (история должна жить в файлах, не в окне).

Целевые пороги (шпаргалка)

Стоп-краны (единственная красная линия — деньги)

1. Governor / per-task cap (у тебя уже есть, fail-open): перед FastGen-вызовом — if credits_used + estimate > budget: DENY. Пороги: daily $50 (мягкое предупреждение $40), per-task $10, cache-write $0.50.
2. Лимит ходов (max_turns) на фазу — против бесконечных циклов.
3. Потолок ретраев QC — max 2–3 цикла на этап, потом скип видео + алерт в Telegram.
4. Spend limit на уровне workspace/плана (жёсткая остановка на лимите).
5. Алерты по red flags: расходы ×2–3 внезапно (кеш отвалился или контекст раздулся); hit rate < 40%; одна задача > 10M токенов (нужен windowing).

8. Чек-лист внедрения + расчёт экономии на живом примере

Чек-лист (по шагам)

День 1 — разметка. - [ ] Разбить конвейер на стадии; для каждой выделить стабильное (промпт + примеры) и изменчивое (профиль + тема). - [ ] Убедиться, что стабильный префикс ≥ минимума (обычно ОК для 3K+). - [ ] Выбрать TTL: 5 мин для sync-прогона <5 мин; 1 час для batch/пауз.

День 2 — конфигурация. - [ ] Поставить cache_control на конец стабильного префикса каждой стадии. - [ ] Перенести всё изменчивое в user-сообщение после разрыва. - [ ] Зафиксировать модель и speed на стадии (смена сбрасывает кеш). - [ ] Включить сбор usage.cache_* в панель.

День 3 — валидация. - [ ] Прогнать 3–5 каналов, проверить hit rate (ждём 90%+). - [ ] Сравнить $/задача с baseline без кеша. - [ ] Проверить, что failover-аккаунты не гоняют один батч (двойная запись).

Неделя 2 — масштаб. - [ ] Перейти на batch API там, где ожидание >5 мин. - [ ] Добавить server-side compaction, если контекст стадии >80K. - [ ] Настроить стоп-краны (governor, max_turns, потолок ретраев, spend limit). - [ ] Подтвердить лестницу моделей и mechanical-first на механических проверках.

Расчёт: кешированный vs некешированный прогон

Живой пример — стадия Idea Generation мини-завода на 10 каналов, Sonnet 5 (цены до 31.08.2026: вход $2, кеш-запись 1h $4, кеш-чтение $0.20, выход $10) [проверено]. System-промпт 11K токенов, вход 0.5K/канал, выход 1.5K/канал.

Без кеша: каждый из 10 каналов платит полные 11K входа.

10 × (11 000 вход + 500 вход + 1 500 выход)
= 10 × (11 500 × $2/MTok + 1 500 × $10/MTok)
= 10 × ($0.023 + $0.015) = 10 × $0.038 ≈ $0.39

С кешем (1 час):

Канал 1 (запись): 11K × $4/MTok = $0.044  + вход $0.001 + выход $0.015 = $0.060
Каналы 2-10 (чтение, ×9): (11K × $0.20/MTok = $0.0022 + $0.001 + $0.015) × 9 ≈ $0.164
Итого ≈ $0.224

Экономия ≈ 43% на одной стадии. По всем 4 стадиям — −59% (~$0.50 против ~$1.2). Добавь batch API поверх — −70–80%.

Теперь маштаб: 10 каналов × 1 лонг/день × 30 дней = 300 прогонов конвейера в месяц. Разница «−59%» превращает, условно, $360/мес в ~$150/мес только на этой оптимизации — и это без учёта лестницы моделей и mechanical-first, которые срезают ещё. Вот как «монстр за $1000/мин» становится дешёвой by design системой.

План на первую неделю (конкретика)

• Пн: на одной стадии мини-завода (script) вынести стабильные инструкции в отдельный блок и поставить cache_control; всё изменчивое (ниша, тема, ресёрч) — после разрыва. Прогнать 1 канал, посмотреть usage.cache_*.
• Вт: прогнать эту стадию по 5 каналам подряд, на одном аккаунте. Проверить hit rate (ждём ~90% на каналах 2–5). Если 0% — искать изменчивое, залезшее до разрыва.
• Ср: повторить разметку на visual_rules и derive shorts/reels. Зафиксировать модель/speed на стадию.
• Чт: включить сбор cache_creation/read/input/output в панель, вывести $/задача и $/день.
• Пт: поставить стоп-краны: per-task cap $10, cache-write порог $0.50, потолок ретраев QC 2–3, spend-limit на аккаунт. Задокументировать failover × 1.2 в бюджете.
• Выходные: сравнить недельный счёт с baseline без кеша; решить, где включать batch API (там, где ожидание >5 мин).

Дальше — тот же протокол на остальные стадии и на мега-проект (Agent SDK): кеш AgentDefinition.prompt, context editing между фазами, memory tool для выжимок, кеш общего префикса по волнам.

Пять главных выводов

1. Кеш — это лекарство от твоей боли «$1000/мин». Стабильный префикс (промпт стадии + инструменты + CLAUDE.md + профиль) читается из кеша за 0.1× цены — скидка 90% [проверено], и окупается уже после первого повтора. Раздувание контекста лечится тем, что повторное перечитывание перестаёт стоить полную цену.

2. Золотое правило порядка решает всё: стабильное — сначала, изменчивое — потом. Точка разрыва (cache_control) ставится в конце неизменной части; ID канала, тема, timestamp идут строго после неё. Нарушил порядок — кеша нет вообще (ошибка №1, hit rate падает в ноль).

3. Экономь ЧИСЛО вызовов, а не только модель. Каждый claude -p несёт ~13K токенов системного промпта Claude Code независимо от модели — поэтому Haiku на мелких QC не дешевле Opus, а умную модель для вердикта брать почти не дороже. Кешируй этот 13K на одном аккаунте в пределах TTL.

4. Разные аккаунты = разный кеш. Кеш изолирован по workspace/аккаунту [проверено]. Failover Claude acct1 → acct2 обнуляет кеш — заложи failover × ~1.2 в бюджет и гоняй один батч каналов подряд на одном аккаунте внутри TTL, а не размазывай по аккаунтам «для балансировки».

5. Кеш усиливает все пять рычагов, но не заменяет их. Изоляция субагентов (минимальный контекст), внешняя память (memory-bank, выжимки вместо сырья), компакция/свежая сессия между этапами, лестница моделей и mechanical-first — вместе с кешем дают −59% на конвейере и −70–80% с batch. Плюс стоп-краны (governor, max_turns, потолок ретраев, spend limit) — чтобы система была дешёвой by design, а не по обещанию. ```