От написания промптов к проектированию контекста. Или один очень обширный материал по Context Engineering

Прелюдия 1

Это длиннопост, после которого, я надеюсь, у вас сформируется устойчивый фундамент по работе с контекстом и современными агентными интерфейсами

Прелюдия 2

Если вы считаете, что я где то ошибся или хотите уточнить детали, то можете оставлять комменты. Все прочитаю и поправлю

Прелюдия 3

То, что написано ниже — достаточно тяжелый материал, если у вас нет понимания работы агентов и того, как работают LLM, то будет тяжело. Но не бесполезно)
Для начинающих у меня есть отичная статья Просто и подробно о том, как работают ChatGPT и другие GPT подобные модели. С картинками ^[1].

Прелюдия 4

Основные концепты я буду рассказывать на примере Claude Code, так как они являются двигателями моды в агентной разработке. Но остальные агенты работают примерно также

Прелюдия 5

Я много где использую английские термины и генерирую картинки через ChatGPT, не наказывайте строго 🥺

---

TL;DR. Промпт инжиниринг в том виде, в котором он был популярен в 2025 уже мёртв. В современных агентных инструментах, таких как Claude Code, Codex и упасибогCursor = ваш текст это ~0,03% контекста. Все остальное — это system prompt, CLAUDE.md ^[2], память ^[3], MCP, skills, история, tool results. И созданы они, чтобы съедать ваши лимиты и тратить ваши деньги 😈

Что внутри этого лонгрида

• Акт 1. Контекстное окно как поверхность внимания ^[4].
  Context rot + reasoning shift — как длинный контекст может резать рассуждения до 50% без предупреждения

• Акт 2. Про квадратичную сложность attention и почему «больше токенов» стоит O(n²)

• Акт 3. Про 7 слоев контекста — от pretrained весов и до редактируемых system prompt, CLAUDE.md ^[2], MEMORY.MD, Skills, MCP и файлов по вызову

• Акт 4. Про agent loop и harness. А еще про promt caching, spec-driven подход, subagents, agent teams и 4 типа токенов и их реальная цена

• Акт 5. Что отличает новичка от мастера и 6 action items на понедельник — что положить в проект сегодня вечером

Кому актуально: Всем, кто работает с Claude Code / Codex / Cursor и всем тем, кто внезапно стал упираться в лимиты

---

Акт 1. 0,03% и 99,97%

Так как эта статья про то, что именно сидит в этих 99,97%, то с этого и начнем

А еще начнем с моей любимой цитаты, вокруг которой и будет выстроено дальнейшее выступление

Good context engineering means finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome

Вокруг слов, выделенных жирным, и выстроена вся современная работа с LLM

System Prompt
CLAUDE.md / настройки проекта
Memory.md (файлы памяти из прошлых сессий)
Tool definitions (описания всех доступных инструментов)
Subagents + Skills + MCPs
Загруженные файлы / RAG-результаты
История диалога (всё, что вы написали раньше)
Результаты вызовов инструментов
ВАШ ПРОМПТ

Контекстное окно как поверхность внимания

О контекстном окне полезно думать как о рабочем столе, на котором лежит всё, что модель должна учитывать одновременно

Если на столе много мусора — тяжело понять, за что браться. Если только то, что относится к задаче — работать проще.

Внимание (attention) у модели — конечный ресурс: для каждого токена сумма весов softmax по всему контексту равна 1. Чем длиннее окно, тем меньше веса в среднем приходится на каждый отдельный токен — а на практике распределение ещё и неравномерное: первые токены и хвост получают непропорционально много (attention sinks), середина проваливается.

У длинного контекста есть две проблемки, и они работают одновременно

Первая и самая очевидная — Context rot. Когда внимание моделей размазывается

Чем больше случайных токенов в запросе к модели, тем сложнее ей отвечать релевантно

Это приводит к тому, что модели

• зацикливаются на уже обсуждённых точках

• забывают ^[5] детали из начала разговора

• противоречат ранее установленным ограничениям

• дают всё более размытые ответы

Вторая и менее очевидная — Reasoning shift

Есть немало наблюдений ^[6], что многие модели распределяют ресурсы между обработкой контекста и рассуждением — контекст растёт, рассуждения сокращаются.

На что это конкретно может влиять

• Меньше промежуточных рассуждений — модель сразу перескакивает к выводу

• Меньше самопроверки

• Сокращение альтернативных ответов — одна гипотеза вместо трех

• Уверенные, но не факт что правильные ответы — они звучат увереннее, хотя обоснованы хуже

Получается, что вы хотите более точных ответов и подгружаете больше документов. Объём растёт → reasoning сокращается → ответ выглядит увереннее, но обоснован хуже. И вы не узнаёте — со стороны выглядит нормально

Контекст — один из главных рычагов управления inference compute

Чем меньше токенов — тем меньше вычислений, тем быстрее ответ, тем ниже стоимость и тем выше точность. Это не четыре независимых преимущества — это одно и то же.

Поэтому писать в один чат всё подряд про здоровье, работу, код и личное — плохая идея. Складывать в один проект кучу файлов и говорить «прочитай всё» тоже плохая идея

---

Акт 2. Почему всё так устроено

Attention Is All You Need

В июне 2017 года восемь исследователей Google выложили статью «Attention Is All You Need». В ней они предложили архитектуру Transformer — и именно она лежит в основе всех современных LLM: GPT, Claude, Gemini, Llama, DeepSeek. Буква T в GPT — это и есть Transformer.

Чтобы понять, почему это важно, нужно понять, как вообще работает LLM. Для этого нужно вернуться в 2017 год и посмотреть, как изменился фундаментальный принцип работы LLM.

Что было ДО 2017

Доминировали Recurrent Neural Networks. Они обрабатывали текст последовательно: слово за словом. И после каждого слова эта нейросеть обновляла «скрытое состояние» — компактный вектор, в который «сжималась» вся история.

Что предложил Transformer

Главная идея — self-attention. Каждое слово в предложении одновременно «смотрит» на все остальные слова и решает, насколько каждое из них релевантно. Никакой цепочки. Всё параллельно

Именно этот механизм позволил нам прийти к тому уровню развития нейросетей, на котором они сейчас. Но и он накладывает фундаментальное ограничение в размерах контекстного окна

Аttention в своем исходном виде — это O(n²) по длине последовательности. Каждый из N токенов смотрит на каждый из остальных, поэтому связей не N, а N×N.

На 1K токенов будет миллион операций, а на 1M уже целый триллион. Поэтому «давайте засунем больше файлов в модель» стоит не линейно, а квадратично — и прожектор внимания неизбежно размывается.

Современные оптимизации (Flash Attention, sliding window, sparse attention) бьются за экономию вычислений, но квадратичность как закон не отменяют

---

Акт 3. Из чего собирается контекст

Сначала про Pretrained Data — сильно туда погружаться не буду, у Карпаты есть 3-часовой разбор «Deep Dive into LLMs» ^[7], где разобраны основные понятия. По сути, это дистиллированное сжатие всего интернета с cutoff на конкретный момент времени, иногда Soul-документ, которым, например, дофайнтюнивают многие модели Claude

Именно веса определяют

• какие Q/K/V-проекции создаются (матрицы весов W_Q, W_K, W_V)

• как эти проекции трансформируются в FFN-блоках (Feed-Forward Networks)

На выходе последнего слоя получается вектор, который через матрицу unembedding (тоже веса) превращается в распределение вероятностей по всему словарю ~100+K токенов

И уже из этого распределения выбирается следующий токен (greedy / sampling / top-p)

Познавательная минутка
Один NVIDIA H100 — это 80 GB видеопамяти. Для модели в 1 триллион параметров (формат float16) нужно 25 GPU только чтобы веса поместились. Это не считая KV-cache для вашего контекста. Поэтому Claude Opus и GPT-4 физически не могут работать на вашем компьютере — они живут в дата-центрах. Локальные модели (Llama 3.1 70B на M3 Pro в int4-квантизации) — это другая категория моделей с другим характером и другой «конституцией». Когда речь о приватности или цене, выбор локальной модели = выбор другого Слоя 0

Веса — это образование, контекст — рабочий стол.

А если хотите лучше разобраться с принципом работы весов, то вот тут можете поиграться с GPT-2 моделью

На Pretrained секцию мы никак не влияем. Она запекается создателями модели в момент обучения. И всё, что мы делаем дальше — это работа поверх этого фундамента: веса поменять нельзя, зато второй блок — Context Window — мы уже можем формировать

Слово «формировать» здесь точнее, чем «контролировать». Полного контроля у нас тоже нет: System Prompt и Tool definitions пишет харнесс (Claude Code в нашем случае). В Claude Code это несколько килобайт системного промпта от Anthropic плюс несколько десятков встроенных инструментов (Read, Write, Bash, Grep и далее по списку — точный перечень меняется от версии к версии, актуальный — в tools-reference ^[10]). Всё это занимает первые тысячи токенов окна ещё до того, как мы успеваем что-то сказать

Зато всё остальное — CLAUDE.md ^[2], память между сессиями, Skills, MCP-серверы, что и когда подгружается из файлов, как режется история диалога — это уже наша зона. И именно про неё дальше пойдёт разговор

Например, вот визуализация моего /context в Claude Code. Справа написано, сколько токенов и что занимает еще до отправки первого сообщения

Ну, поихали

CLAUDE.md 

CLAUDE.md ^[2] в корне репозитория — это первое, что Claude Code кладёт в контекст после системного промпта и до любого пользовательского сообщения. И главная ошибка ^[11] при работе с ним — превращать его в простыню «всё, что я хочу, чтобы агент знал»

Познавательная минутка
CLAUDE.md читает только Claude Code. Codex читает AGENTS.md, а Gemini читает GEMINI.md. Если вы хотите, чтобы все три агента правильно работали с вашим репозиторием, то у вас должны быть все 3 файла. И механизм их синхронизации между собой

# Проект: <одна строка>

## Архитектура — стек, ключевые директории
## Правила — конвенции коммитов, стиля, тестов
## Что НЕ делать — границы, типичные ошибки

Самый недооценённый блок это «что НЕ делать». Большинство ошибок агента идут от того, что вы не запретили что-то явно.

MEMORY.md для памяти между сессиями

Подгружается вместе с CLAUDE.md

Память в Claude Code — это не просто выжимка из разговора, как это было раньше. Теперь это аккуратный индекс с подписанными папками, где каждый файл имеет тип, имя и описание

Четыре типа памяти, разделённые по назначению:

• user — кто пользователь: роль, опыт ^[12], технические предпочтения.

• feedback — обратная связь после ошибок: «не делай X», «продолжай делать Y». Самое ценное, что можно положить в память.

• project — контекст проекта: дедлайны, архитектурные решения, ограничения.

• reference — ссылки на внешние системы: где Notion, какой репо с фикстурами.

MEMORY.md — индекс, грузится в каждую сессию целиком. Сами файлы — в .claude/memory/, подгружаются по description из фронтматтера.

У Memory есть механизм AutoDream

AutoDream — экспериментальный механизм фоновой консолидации памяти между сессиями, по принципу REM-сна: между сессиями читает все файлы памяти, находит дубли и противоречия, склеивает связанное в саммари. Запускается либо с вашей стороны либо автоматически раз в 24 часа или после 5-10 turns.

Ниже пример страницы Memory одного из моих проектов. Оранжевым показаны ссылки на файлы, где каждый из пунктов написан подробно

Skills — экспертиза on-demand, или «книга на полке»

Это механизм, созданный тоже антропиками, который позволяет по команде загружать в модель определенное поведение ^[13] или команду

Skill устроен как книга на полке. У книги есть корешок (имя + description, до 1 536 символов) — это и грузится в контекст всегда. Само содержимое (SKILL.md ^[14] — процесс, инструкции, шаги) подгружается только когда харнесс по описанию решает, что эта книга сейчас нужна. Ну или когда мы сами его вызываем

Anthropic рекомендует упаковывать в скиллы всё, что является процессом: TDD, code review, commit-style, deployment runbook, конкретный workflow вашей команды

MCP — очень прожорливый на токены формат

Если коротко, то это протокол для общения AI-модели с внешними сервисами

Про него у меня были отдельные статьи и выступления на публике, поэтому сильно на этом останавливаться не буду

1. Model Context Protocol. Смотрим на новый стандарт от Anthropic ^[15]

2. Как управлять Notion, GitHub и другими программами через Claude. Показываю свои примеры MCP серверов ^[16]

Subagents — изолированный источник контекста

Subagent — это отдельная сессия с собственным контекстным окном. Основной агент обращается к нему как к инструменту: «сходи проанализируй X», получает обратно только финальный текст. Внутренний контекст субагента (что он читал, чем рассуждал, какие 50 файлов открывал по пути) в основной контекст не попадает

• Subagent видит всё, что прочитал — может потратить 100K+ токенов на разбор длинного PR в собственном окне

• Основной агент видит только итоговый абзац — обычно ~100–500 токенов вместо PR на 3000 строк

Внешне для основного агента это похоже на Read файла, который вернул заранее подготовленную выжимку. Только «выжимку» делал не редактор, а другая модель в другой сессии — и стоило это работы реального компьюта в её окне.

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

Какой механизм выбрать

• Skill — когда нужно переключить экспертизу или процесс. Формулировка: «следуй процессу Y».

• MCP — когда нужен хорошо описанный новый канал в мир (внешний API, БД, чужой сервис).

• Subagent — когда нужно изолировать контекст под исследование.

Файлы и RAG — что подгружается прицельно

В отличие от MCP и Skills, файлы и результаты поиска по коду — это динамическая часть контекста, которая формируется во время работы. Каждый Read и Grep добавляет в контекст ровно тот кусок, который вы или модель попросили прочитать

И да, «давайте на всякий случай скормим модели весь репозиторий» — это антипаттерн

Что работает:

• Нормальные харнессы по типу Claude Code умеют делать прицельный Grep вместо «дай весь файл» — модель просит конкретный паттерн, харнесс возвращает 5 строк контекста, не 500

• Subagent под исследование длинных документов — он прочитает PR на 3000 строк, вернёт абзац выводов в основной контекст (об этом дальше в практике)

• Правильная индексация на вспомогательные файлы внутри CLAUDE.md и MEMORY.md

Каждый Read и Grep это решение, сколько внимания вы отдаёте этому куску ценой отвлечения от всего остального

Compaction — как харнесс режет историю

История диалога не растёт бесконечно — даже на 1KK окне у вас рано или поздно срабатывает compaction. Это хук (не модель решает — харнесс автоматически), который вызывается при достижении порога контекста

На той же картинке ниже видно Autocompact buffer, который резервирует часть контекстного окна и запустит /compact, когда вы подберетесь к его границе. Autocompact buffer можно отключить в /config

Что происходит при autocompact или /compact

1. Харнесс отправляет в модель промпт «суммируй текущую сессию, сохрани решения и важные tool_result, выкини рутину»

2. Модель возвращает компактный пересказ

3. И начинается новая сессия с предзагруженным пересказом вместо полной истории

Минус: модель сама решает, что важно — и иногда выкидывает то, что вы как раз хотели сохранить.

Чтобы избежать потери нужной вам информации при /compact, то вот вам лайфхак. Команда /compact в Claude Code принимает свободный текст

/compact оставь подробно последние 20 сообщений про авторизацию,
остальное сожми до решений и архитектурных правил

Так вы превращаете дефолтный compact в кастомный — под задачу, а не общий. Этим часто пренебрегают, а зря. Разница между «модель сократила историю наугад» и «модель сократила историю по вашим правилам» — порядок качества дальнейшей работы.

Альтернатива compact это /clear — новая сессия с чистого листа. Стоит чаще, чем кажется: если задача поменялась, лучше открыть новый контекст и притащить туда нужное явно через CLAUDE.md ^[2], memory, конкретный Read), чем тащить шлейф прошлого.

---

Акт 4. Как управлять контекстом

Agentic Loop: почему агент дороже чата

Потому что он решает задачу до того момента, пока не посчитает эту задачу решенной. Следовательно, вместо простого “Вопрос” => “Ответ”, как в чатах. Агенты пытаются решить поставленную задачу и ради одного ответа могут дернуть модель и 5 и 10 и 15 раз

Есть очень классный сайт, на котором хорошо показан Claude Code Agent Loop

Как работает Agent Loop: 4 вызова модели за 1 ответ

Например, вы написали

Проверь, почему упал последний деплой prod?

И агент за это сделает 3 tool uses — для пользователя это выглядит как один ответ, “Claude подумал и ответил”. На самом деле там 4 раздельных HTTP-запроса к /v1/messages, между которыми harness (Claude Code) зовет разные инструменты

Действующие лица

USER     ──▸  человек, прислал текст
HARNESS  ──▸  процесс на твоей стороне (Claude Code, SDK, кастомный код).
              Делает HTTP-запросы к Anthropic, выполняет тулы, рендерит ответ.
MODEL    ──▸  серверная сторона Anthropic. Stateless: ничего не помнит между вызовами.
TOOLS    ──▸  реальные функции (read_file, bash, get_logs, ...). Живут в harness.

Полная последовательность (9 шагов)

╭────────────────────────────────────────────────────────────────────────────────╮
│ [ 1. USER -> HARNESS  (Claude Code / API client) ]                             │
│                                                                                │
│ Текст: "Почему упал последний деплой prod?"                                    │
│                                                                                │
│ Harness формирует запрос к /v1/messages со списком tools.                      │
│ В payload идёт: system prompt, tool definitions, user message.                 │
╰────────────────────────────────────────────────────────────────────────────────╯
                                         │
                                         ▾
╭────────────────────────────────────────────────────────────────────────────────╮
│ [ 2. HARNESS -> MODEL  (call #1, prefill, then decode) ]                       │
│                                                                                │
│ Input tokens:  system ~3500, tools ~2000, user ~20  -> ~5520                   │
│ Prefill: один forward pass, заполняет KV-cache на 5520 токенов                 │
│ Decode:  "Проверю статус деплоя." затем tool_use(get_deploy_status)            │
│                                                                                │
│ stop_reason = "tool_use"   <- модель сама остановилась                         │
│ usage: input=5520, output=22                                                   │
╰────────────────────────────────────────────────────────────────────────────────╯
                                         │
                                         ▾
╭────────────────────────────────────────────────────────────────────────────────╮
│ [ 3. HARNESS executes TOOL #1  (get_deploy_status) ]                           │
│                                                                                │
│ Harness видит stop_reason="tool_use", парсит tool_use block,                   │
│ вызывает реальный код или API. Модель в этот момент не работает.               │
│                                                                                │
│ Tool returns: {"id":"deploy-7af2","status":"failed",                           │
│                "started":"2026-04-26T09:15Z","duration":"42s"}                 │
╰────────────────────────────────────────────────────────────────────────────────╯
                                         │
                                         ▾
╭────────────────────────────────────────────────────────────────────────────────╮
│ [ 4. HARNESS -> MODEL  (call #2, prefill_diff, then decode) ]                  │
│                                                                                │
│ Harness отправляет ВСЮ историю заново, добавив:                                │
│   - предыдущий assistant message (текст и tool_use_1)                          │
│   - tool_result_1                                                              │
│                                                                                │
│ Input tokens:  5520 (старое), 22 (asst), 60 (result)  -> ~5602                 │
│ С prompt caching: prefill считается только для дельты ~82 токенов              │
│ Decode: "Деплой упал. Посмотрю логи." затем tool_use(get_logs)                 │
│                                                                                │
│ stop_reason = "tool_use"                                                       │
╰────────────────────────────────────────────────────────────────────────────────╯
                                         │
                                         ▾
╭────────────────────────────────────────────────────────────────────────────────╮
│ [ 5. HARNESS executes TOOL #2  (get_logs) ]                                    │
│                                                                                │
│ Tool returns 800 токенов лога:                                                 │
│   "ERROR: failed to bind :8080, address in use"                                │
│   "ERROR: container stopped after 3 restart attempts"                          │
│   ...                                                                          │
╰────────────────────────────────────────────────────────────────────────────────╯
                                         │
                                         ▾
╭────────────────────────────────────────────────────────────────────────────────╮
│ [ 6. HARNESS -> MODEL  (call #3, prefill_diff, then decode) ]                  │
│                                                                                │
│ Input tokens:  5602, 24 (asst), 800 (result)  -> ~6426                         │
│ С prompt caching: дельта ~824 токена                                           │
│ Decode: "Похоже, порт занят. Проверю последний коммит."                        │
│         затем tool_use(git_log)                                                │
│                                                                                │
│ stop_reason = "tool_use"                                                       │
╰────────────────────────────────────────────────────────────────────────────────╯
                                         │
                                         ▾
╭────────────────────────────────────────────────────────────────────────────────╮
│ [ 7. HARNESS executes TOOL #3  (git_log) ]                                     │
│                                                                                │
│ Tool returns:                                                                  │
│   "abc123 chore, add nginx sidecar  (Igor, 2h ago)"                            │
╰────────────────────────────────────────────────────────────────────────────────╯
                                         │
                                         ▾
╭────────────────────────────────────────────────────────────────────────────────╮
│ [ 8. HARNESS -> MODEL  (call #4, prefill_diff, then decode) ]                  │
│                                                                                │
│ Input tokens:  6426, 28 (asst), 40 (result)  -> ~6494                          │
│ Decode: "Деплой упал из-за nginx-sidecar коммита abc123,                       │
│          он биндит тот же порт 8080. Откатить или сменить порт."               │
│                                                                                │
│ stop_reason = "end_turn"   <- модель решила, что закончила                     │
╰────────────────────────────────────────────────────────────────────────────────╯
                                         │
                                         ▾
╭────────────────────────────────────────────────────────────────────────────────╮
│ [ 9. HARNESS -> USER ]                                                         │
│                                                                                │
│ Финальный ответ модели передаётся пользователю.                                │
│ Всего: 4 вызова модели, 3 tool execution, 1 пользовательское сообщение.        │
╰────────────────────────────────────────────────────────────────────────────────╯

Что важно понимать про этот цикл

1. Тулы исполняет харнесс, не модель. Модель только генерирует JSON-блок с именем тулa и аргументами. Реальный bash, read_file, HTTP-запрос — это код в харнессе. Между этими двумя мирами модель ничего не видит, кроме того, что харнесс потом вернёт как tool_result.

2. История сообщений растёт. Round 1 = 5520 токенов. Round 4 = 6494. И харнесс заливает в модель все 4 раза полный диалог, а не только дельту. Т.е. это около 22 000 токенов за 4 прохода. Учитывая, что для нас это выглядит как одна операция

3. Tool definitions сидят в каждом запросе. Если у тебя 10 MCP-тулов на ~15K токенов описаний, то эти 15K включаются в каждый из 4 вызовов = около 60 тысяч токенов потрачено на описания тулов, из которых реально вызвано 3 штуки.

Состояние контекста по вызовам

Давайте посмотрим, как в деталях выглядят наши запросы к модели в этой ситуации.

Вызовы 1 и 2 покажу детально, остальные в таблице

╭────────────────────────────────────────────────────────────────────────────────╮
│ ROUND 1                                                                        │
│                                                                                │
│ total = 5520 tokens   |   cacheable prefix = первые 3 сегментов                │
│ дельта этого раунда = 5520 токенов                                             │
│                                                                                │
│ SYS                             TOOLS             USR                          │
│ [##############################][################][#]                          │
│ 3500                            2000              20                           │
│                                                                                │
│ #  = в кеше предыдущего раунда (cache_control hit, 10% от базовой цены)        │
│ *  = новые токены раунда:                                                      │
│        100% если просто добавлены без cache_control                            │
│        125% (5-min TTL) или 200% (1-hour TTL) если помечены cache_control      │
│        (тогда становятся cached prefix для следующих раундов)                  │
╰────────────────────────────────────────────────────────────────────────────────╯
                                         │
                                         ▾
╭────────────────────────────────────────────────────────────────────────────────╮
│ ROUND 2                                                                        │
│                                                                                │
│ total = 5602 tokens   |   cacheable prefix = первые 3 сегментов                │
│ дельта этого раунда = 82 токенов                                               │
│                                                                                │
│ SYS                             TOOLS             USRA1 T1                     │
│ [##############################][################][#][*][*]                    │
│ 3500                            2000              20 22 60                     │
│                                                                                │
│ #  = в кеше предыдущего раунда (cache_control hit, 10% от базовой цены)        │
│ *  = новые токены раунда:                                                      │
│        100% если просто добавлены без cache_control                            │
│        125% (5-min TTL) или 200% (1-hour TTL) если помечены cache_control      │
│        (тогда становятся cached prefix для следующих раундов)                  │
╰────────────────────────────────────────────────────────────────────────────────╯

Подробная разбивка по каждому вызову

Все это выше лишь подводка к тому, что без caching агентные циклы экономически нерентабельны. В типичном агентном loop 95–96% всех input-токенов — это cache reads

Вот математика ^[18] того, во что это превращается со включённым кешем:

╭────────────────────────────────────────────────────────────────────────────────╮
│ COST ARITHMETIC (write = 125% от базового input)                               │
│                                                                                │
│ Сравнение стоимости ввода (4 вызова модели), в "эффективных токенах":          │
│                                                                                │
│                   без cache     с prompt cache (write 125%, read 10%)          │
│  Round 1  write    5520         5520 x 1.25 = 6900   (полный cache write)      │
│  Round 2           5602         552 read , 103 write (82 x 1.25)  = ~655       │
│  Round 3           6426         560 read , 1030 write (824 x 1.25) = ~1590     │
│  Round 4           6494         643 read , 85 write (68 x 1.25)   = ~728       │
│  ИТОГО            24042        ~9873   (экономия ~2.4x)                        │
│                                                                                │
│ Cache write дороже обычного ввода (125%), но READ потом стоит 10%.             │
│ Окупается, если префикс реально переиспользуется >= 2 раз.                     │
│ На длинных диалогах (10-20 раундов) экономия достигает 5-10x.                  │
╰────────────────────────────────────────────────────────────────────────────────╯

Вот моя статистика по токенам.

Видно, какая колоссальная разница между Cache Read и Input tokens

У клода есть два типа кеша на 5 минут и на 1 час

Запись в 5 минутный кеш стоит 125% от цены обычного input токена

А запись в 1 часовой кеш стоит уже 200% от цены обычного токена. Не важно, платите ли вы за API или у вас подписка

На 5m TTL:  каждая пауза > 5 мин → cache miss → re-write
            10 × (1M × 125%) = 12.5M write tokens

На 1h TTL:  пауза < 60 мин → кеш жив → read
            1 × (1M × 200%) + 9 × (1M × 10%) = 11M эффективных токенов
            НО: 1M токенов лежат в hot-storage все 60 минут подряд

Anthropic’ам приходится физически держать ваш 1M-префикс в KV-cache на GPU, готовым к чтению, весь час. Миллион таких пользователей могут занять десятки петабайт RAM на горячем хранении одновременно. Поэтому они и режут доступы к своим дата центрам как могут

Например, если у вас в окне 900K токенов, потом вы ушли на час, потом прислали сообщение — это >900K токенов write по полной, что съест значительный % rate-limit». Цена для пользователя — каждая пауза >5 минут превращает следующий запрос в полный re-write всего префикса.

Например вот, для пользователей с подписками Антропики с конца марта переключили default кеш с 1h на 5m

Типы токенов и сколько каждый стоит

В Anthropic API не один тип токенов — четыре, и каждый имеет свою цену. Это знание прямо влияет на счёт:

Итого несколько инсайтов, которые для меня когда-то удивлением

---

Акт 5. Как итог

Новичок vs Мастер контекстного дела

Как работает новичок

Открывает Claude Code, набирает в командной строке что то типо такого и ждет ответа

> Напиши мне REST API для моей задачи (текст задачи)

У него

• Один промпт — один ответ

• Никакого контекста проекта (нет CLAUDE.md ^[2], нет архитектурных правил)

• Никакой памяти между сессиями (вчерашние решения забыты)

• Ручное копирование ошибок и исправлений из чата в чат

• Каждый новый чат начинается с нуля

• MCP, скиллы и куча субагентов «на всякий случай» висят в каждом запросе

В результате модель каждый раз переизобретает колесо. Ответы выглядят уверенно, но требуют ручной проверки и переделки. Через неделю агент «по тому же проекту» отвечает противоречиво — потому что для модели каждая сессия и есть «новый проект».

Как работает мастер

Подготавливает среду один раз:

├── CLAUDE.md             — архитектура, стек, правила, «что НЕ делать»
├── ~/.claude/memory/     — user/feedback/project/reference, формат Why+How
├── .claude/skills/       — рабочие процессы (TDD, debugging, review)
├── .claude/agents/       — субагенты для тяжёлого ресерча
├── .mcp.json             — только нужные MCP, остальное отключено
└── .claude/settings.json — хуки, permissions, статус-лайн

В каждой сессии при этом происходит уже не разговор, а работа системы по контракту:

• Claude Code читает CLAUDE.md ^[2] и понимает проект без объяснений

• Claude Code подгружает релевантную память

• Знает свои скиллы и субагентов — выбирает нужные под задачу

• Делегирует тяжёлый ресерч субагентам, чтобы не засорять основной контекст

• Знает 5m / 1h prompt cache тайминги и учитывает это в своей работе

• Постоянно пользуется командами/context, /compact, /clear

Что получает в результате: стабильный, воспроизводимый результат. Тот же проект через неделю — те же правила. Новый человек в команде получает работающего агента сразу, без устной передачи знаний. Счёт за токены и расход квоты не растут пропорционально объёму работы — растут пропорционально новизне

Короткое сравнение

Мастер не пишет лучших промптов. Мастер проектирует среду, в которой модель стабильно выдаёт нужный результат

Или