Как устроен контекст внутри: От 200K токенов к реальным 120K

Когда ты смотришь на документацию Claude, видишь число: 200K токенов. Звучит как много. Когда ты начинаешь писать код в Claude Code, до реальных задач доступно значительно меньше. В январе 2026 я тратил 3-4 часа в день на дебаг контекста при разработке серии статей про context engineering. Изучал logs, запускал /context после каждого запроса, чтобы понять, где теряется пространство - прежде чем осознал: контекстное окно - сложная система с невидимыми слоями, зарезервированными буферами, MCP-налогами и автоматическими триггерами сжатия. Если не понимаешь, как это всё работает, будешь постоянно удивляться, почему качество ответов падает именно тогда, когда оно нужно больше всего.

Три цифры, которые нужно запомнить

200K, 155K, 120K - три критических порога контекстного окна. Без этого понимания невозможно планировать сложные задачи.

Вот параметры контекстного окна на начало 2026 года:

Первый шок: между объявленными 200K и реально доступными токенами разница в 45K. Это context buffer - зарезервированный буфер для генерации ответа, extended thinking и tool calls. Он hardcoded, его нельзя переопределить.

Первый месяц я работал по логике 200K, думал у меня есть столько места. Через неделю делал review микросервисной архитектуры на Go (~5000 строк кода), которая обычно занимает 15 минут и даёт 8-10 замечаний. При 65-70% заполнении контекста та же работа начала занимать 20-22 минуты и давала только 5-6 замечаний. Запустил /context и оказалось, что контекст уже давно стал узким местом, заполнился на 65-70%. Видишь цифру 200K, а работаешь с 155K. Это как купить квартиру 100 квадратов, а потом узнать, что 22.5 квадрата - это несущие стены, которые не добавляют полезной площади.

Auto-compact срабатывает раньше. Реальный триггер: 119-120K токенов, а не заявленные 155K. Anthropic намеренно снижает триггер, чтобы сохранить качество ответов (об этом подробнее в разделе про деградацию).

Каждый подключённый MCP-сервер съедает 500-2000 токенов на определения инструментов. У меня было подключено 5 серверов: GitHub MCP, Slack, Database, Custom Files, Anthropic docs. Запустив /context на середине января 2026, я обнаружил неожиданное число: 9.7K токенов ушло на MCP-серверы. GitHub MCP съел 2.1K токенов, Slack почти столько же - 1.8K, Database вообще 2.3K, а Custom Files с Anthropic docs добавили по 2.1K и 1.4K. Ты не видишь эти токены в истории, но они занимают место.

Extended thinking - когда Claude использует adaptive thinking для сложных задач, он может занять часть буфера невидимо. Ты не видишь эти токены в истории, но они занимают место.

Тысяча токенов - примерно 750 слов в русском тексте или сорок строк Python/JavaScript. Возьми 155K доступных в начале: это 116 тысяч слов, целая книга. Но реально ты работаешь с 120K - это примерно 90 тысяч слов или пять тысяч строк кода.

120K - вот честный лимит для текущей сессии. Safe maximum - честный лимит, после которого лучше новая сессия. Это то, что я называю границей надёжной работы, после которой качество начинает деградировать.

Когда я впервые использовал /context и увидел breakdown по слоям, breakdown показал невидимые слои, которые я недооценил. System prompts + CLAUDE.md + MCP definitions - это ещё 10K, которые ты не видишь в conversation, но которые занимают место в окне.

Context engineering как парадигма требует понимания реальных цифр. Token Budgeting работает с реальными 120K, не объявленными 200K. Без знания этой разницы невозможно планировать сложные задачи.

Архитектура контекстного окна: четыре слоя

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

Слой 1: Core System Context (~3-5K токенов)

Это встроенные инструкции Claude Code - всё, что модель должна знать о том, как работать в этой среде. Определения всех команд (/cost, /context, /doctor), описание agentic loop, правила безопасности. Этот слой:

• Невидим для пользователя (не показывается в истории)
• Всегда в окне (не сжимается никогда)
• Занимает ~3-5K токенов постоянно

Ты его не видишь, но он всегда там. Он всегда активен и защищён - как ядро операционной системы.

Слой 2: Project Memory (~1-3K + 267 токенов)

Персистентная память проекта, которая загружается в каждую сессию. Видима частично: ты можешь прочитать CLAUDE.md, но не видишь его в conversation. Сжимается при compaction, но ключевая информация сохраняется с приоритетом. Занимает ~1-3K токенов в зависимости от размера проекта.

CLAUDE.md - файл с описанием иерархии проекта, который ты создаёшь вручную. Загружается при инициализации каждой сессии. Это детерминистический паттерн, который мы обсуждали в статье про context engineering - способ явно управлять тем, что модель знает о проекте.

MEMORY.md - автоматическая память, которую накапливает Claude Code во время работы. Первые 200 строк (~267 токенов) загружаются в каждую сессию - примерно 200 строк, что на текущей версии Claude Code составляет ~267 токенов, хотя может варьироваться в зависимости от длины строк.

При auto-compact этот слой сохраняется с приоритетом. Anthropic приоритизирует project memory: архитектура проекта важнее истории сообщений.

Слой 3: Active Conversation (~45K в начале сессии)

Твои сообщения, ответы Claude, outputs инструментов (Read, Bash, Edit), история ошибок и неудачных попыток - полностью видимо в истории, сжимается первым и агрессивнее всего при auto-compact, растёт быстрее всего во время работы.

Я несколько дней не понимал, почему review архитектуры вдруг стал медленным и неточным. Причина была проста: conversation layer вырос до 80-90K токенов, и модель потеряла способность одновременно обрабатывать связи между модулями. Старые сообщения были там, но уже не использовались эффективно - модель начала забывать детали, которые я показывал в начале сессии.

Как работает Слой 4: MCP Context?

Определения инструментов MCP-серверов, которые ты подключил к Claude Code. Загружаются на лету, только когда требуется - не все сразу. Но когда загружаются, занимают место. Вот что происходит под капотом:

• Невидимы в conversation (ты их не видишь в истории)
• Lazy loaded (загружаются только когда инструмент нужен)
• Скрытое потребление контекста (“token tax”)

Запустив /context на середине января 2026, я обнаружил неожиданное число: 9.7K токенов ушло на MCP-серверы. Я подключил 5 серверов (GitHub, Slack, Database, Files, Custom) и не понимал, где делись 10K токенов. /context показывал:

System context: 4.5K tokens
Project memory (CLAUDE.md): 2.1K tokens
Active conversation: 45.3K tokens
MCP tools (loaded): 9.7K tokens

9.7K токенов - почти 10% от доступного контекста. С тех пор я начал выключать неиспользуемые MCP-серверы в начале сессии.

Порядок деградации при заполнении

Code review с пониманием архитектуры - модель перестаёт видеть связи между модулями. При review системы кэширования из 4 модулей, когда контекст заполнялся выше 70%, Claude забывал зависимости между Cache Manager и Storage Layer, которые я показал в начале сессии.

Дебаг сложных взаимодействий забывает детали из нескольких файлов. Рефакторинг с переименованием может пропустить файлы или не понять зависимости. Запросы “переделай это лучше” теряют контекст предыдущих версий.

Isolated задачи (написание функций, форматирование, синтаксис) остаются надёжными до последнего. Они не требуют держать в голове весь проект, поэтому работают даже при высоком заполнении.

Понимание этой архитектуры - основа для Tool Management (пятый столп из Six Pillars Framework). Когда знаешь про MCP token tax и lazy loading, можешь оптимизировать подключение инструментов и не тратить контекст впустую.

Контекст деградирует неравномерно

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

Вот как деградирует качество:

При 0-30% заполнения - идеальное качество. Claude помнит всё, что ты ему показал. Сложные задачи - code review, дебаг, архитектурные решения - работают отлично.

30-50% заполнения - хорошее качество, но review начинает быть медленнее. Это первый незаметный сигнал. Модель всё ещё держит в голове архитектуру, но уже приходится чуть больше времени на recall деталей из начала сессии.

Вот что это значит на практике: при 50-70% заполнения происходит первый cliff point - модель начинает забывать детали из начала сессии. Я делал review какого-то модуля, потом просил переделать несколько классов, и заметил, что Claude предлагал рефакторинг, противоречащий деталям, которые я показал ранее. При ~65% заполнения контекста, когда я делал review системы аутентификации на проекте платежной системы на Node.js, Claude предложил перемещение методов в Base класс. У нас было 3 OAuth провайдера (Google, GitHub, Microsoft), и этот рефакторинг сломал бы имеющиеся OAuth интеграции в соседнем модуле. Я заметил эту ошибку при ревью, но на живой системе она привела бы к 2-часовому downtime. Потребовалось 4 итерации, чтобы Claude понял контекст после повторения деталей про OAuth.

70-80% заполнения - второй cliff point, более резкий. Дебаг становится ненадёжным. Когда я дебажил новую фичу (социальная авторизация через несколько провайдеров) при 72% заполнении контекста, вместо обычных 4-5 итераций потребовалось 10-12. Ошибка была в CORS-обработке. Первые 4-5 итераций я просил Claude “пошагово отследить запрос” - нужно было ~2 часа вместо обычных 25 минут. После явного повтора про CORS в начале решилось за 3 итерации, потому что Claude постоянно забывал про обработку CORS-ошибок, которые я ему показал в начале сессии.

80-90% заполнения (перед auto-compact) - очень плохо. Работают только isolated задачи. Code review неточный, сложные анализы ненадёжны. Модель находится в режиме выживания - держит только самый свежий контекст, всё остальное сжато до минимума.

После compaction модель восстанавливает ~40-50% качества, но с 10-20% штрафом на rehydration. Об этом подробнее в следующем разделе.

Гипотеза Matsuoka: почему триггер срабатывает раньше

Сообщество Claude Code обсуждает наблюдение: Anthropic намеренно снизил триггер auto-compact с теоретических 100% до ~77-78%, чтобы сохранить качество обработки. Хотя это не подтверждённый факт от Anthropic, паттерн воспроизводится в практике множества пользователей.

Вот данные:

• Реальный триггер compaction: ~77-78% от объявленного
• Gap: ~35K скрытого резерва (~23% от 155K) в дополнение к 45K buffer
• Reported actual usage перед compaction: ~40-45% от полного окна

Better safe than sorry - потеря части контекста лучше, чем работать с деградацией. Extended thinking может занять 20-30% буфера на следующие 2-3 запроса. Quality degradation при >70% заполнения резкая (мы только что это обсудили).

Для практики это означает: не стоит полагаться на 155K как “реально доступный”. Хороший limit для планирования - 100-120K токенов. Это то, что я теперь использую для Token Budgeting в начале каждой сессии.

Auto-compact в деталях: когда и почему срабатывает

Вот как это работает при ~77-78% от 155K доступных токенов (около 120K) для Sonnet. Немного раньше объявленного “полного заполнения”, чтобы оставить margin для качества.

В конце одной долгой сессии контекст достиг 77-78%, и я заметил небольшое замедление ответов. Потом /context показал, что произошла auto-compaction, и среднее время ответа выросло на 20-30%. Я осознал, что compaction имеет измеримую стоимость.

Что происходит при сжатии

Сжатие старых сообщений (Micro-compaction) работает через summarization - длинные ответы превращаются в краткие выжимки ключевых фактов, без потери информации.

Есть ещё агрессивное сжатие conversation layer (Auto-compaction), которое сжимает старые сообщения сильнее и переносит ключевые факты в MEMORY.md. Это тот самый триггер, который срабатывает при 77-78%.

Наконец, Manual compaction - явное вызывание сжатия, когда ты знаешь, что происходит. Об этом будет отдельная статья (Compaction Strategy).

Что сжимается в первую очередь

Conversation layer сжимается агрессивно, system prompts почти не сжимаются. Active conversation (старые сообщения) обрабатываются первыми. MCP definitions выгружаются из контекста, если их давно не использовали. System prompts и CLAUDE.md почти не сжимаются - Anthropic приоритизирует их сохранение.

Из этого следует практический вывод: после compaction isolated задачи остаются надёжными (system prompts на месте), но сложные review требуют повторений (старые детали сжаты).

Rehydration: восстановление после сжатия

После compaction модель восстанавливает контекст из сжатых представлений через процесс, называемый rehydration.

Rehydration имеет издержку: штраф 10-20% на скорость и качество. Модель тратит дополнительное время и вычислительные ресурсы на распаковку сжатой информации.

Я заметил rehydration penalty, когда после compaction сразу просил сложный анализ архитектуры. Я просил анализ зависимостей между 8 модулями микросервисной архитектуры платежной системы: API Gateway, Service Registry, Cache Manager, Database Layer, Authentication Service, Payment Processor, Notification Service, Audit Logger. Первый ответ был поверхностный и пропустил 3 критических зависимости между (API Gateway → Service Registry), (Payment Processor → Database Layer), (Authentication Service → Service Registry). Когда я повторил про API Gateway и Service Registry явно, качество улучшилось на ~70%. Восстановление контекста требует дополнительных ресурсов. Лучше помочь ей, явно повторив важные факты.

Как это влияет на работу

Время ответа может увеличиться на 20-30%. Качество code review падает (нужны повторения ключевых деталей). Isolated задачи проходят нормально (не требуют старого контекста). Следующие 2-3 запроса медленнее обычного (пока rehydration не завершится).

Compaction Strategy (третий столп из Six Pillars Framework) основан на понимании триггеров, rehydration и качества после сжатия. В следующей статье серии (планируется на 20-25 февраля) мы поговорим об оптимальной стратегии сжатия - когда компактить вручную, как подготавливать контекст к auto-compact, когда лучше начать новую сессию.

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

Три встроенные команды помогают понять, что происходит.

Встроенные команды

Практический пример интерпретации

Реальный пример из моей сессии от 15 января 2026 при работе с проектом платежной системы:

System context: 4.5K tokens
Project memory (CLAUDE.md): 2.1K tokens
Auto-memory (MEMORY.md): 267 tokens
Active conversation: 45.3K tokens
MCP tools (loaded): 3.2K tokens
Extended thinking (reserved): 8.1K tokens
---
Total used: 63.4K / 155K available (40.9%)
Auto-compact trigger: 77-78% of 155K = ~119-120K

Что это значит:

• До триггера остаётся ~56K токенов - ещё есть место для работы
• Память проекта в норме (CLAUDE.md не раздулся до неразумных размеров)
• Conversation history начинает быть заметной (~45K) - скоро нужно будет подумать о сжатии
• MCP tax небольшой (3.2K) - только один-два сервера загружены
• Extended thinking занял 8.1K - это означает, что модель использовала adaptive thinking для этой сессии, вероятно, из-за сложных задач

Когда начинать волноваться

/context показывает больше 100K? Переходи на isolated задачи. Code review и дебаг уже ненадёжны. Лучше сделать то, что не требует памяти всего проекта.

Если MCP tools показывают больше 5K, проверь, какие серверы загружены - возможно, есть неиспользуемые, которые можно выключить через настройки?

Extended thinking больше 15K означает, что модель решает очень сложную задачу. Adaptive thinking активен и жрёт буфер, ей нужно больше места для рассуждений.

Что делать, если Status bar меньше 20%? Готовься к compaction в следующих 2-3 запросах. Либо начни новую сессию, либо переключись на isolated задачи.

За 35 сессий в январе-феврале 2026 я заметил стабильные паттерны. Conversation растёт на 1-1.5K при каждом Read/Edit - это предсказуемо. MCP tax прирастает медленнее, примерно на 0.5K при подключении нового сервера. Но Extended thinking - самый непредсказуемый, может занять 20-30% буфера на следующие 2-3 запроса после сложного запроса, и ты это не видишь в breakdown.

Context Awareness (второй столп из Six Pillars Framework) опирается на понимание реальных цифр, не объявленных лимитов. Умение интерпретировать /context и /doctor outputs - это не просто мониторинг, это понимание того, что происходит под капотом. Без этого невозможно оптимизировать работу.

Заключение

Контекстное окно - сложная система с невидимыми слоями, резервами, налогами и триггерами.

Ключевая прогрессия: 200K → 155K → 120K. От объявленного окна к реально доступному, от доступного к честному лимиту для работы. Без этого понимания нельзя оптимизировать контекст - будешь постоянно удивляться, почему качество падает, когда контекст вроде бы ещё не заполнен.

Context engineering как парадигма - это управление всеми токенами, которые модель видит при генерации. Все Six Pillars Framework опираются на знание из этой статьи. Token Budgeting работает благодаря тому, что ты знаешь реальные цифры (120K, не 200K). Context Awareness - это понимание слоёв и невидимых потребителей контекста. Compaction Strategy основана на знании cliff points и rehydration penalty. А что с Memory Optimization? Это знание про CLAUDE.md и MEMORY.md architecture. Tool Management опирается на понимание MCP token tax. Наконец, Rehydration - это знание стоимости восстановления после сжатия.

Context engineering без знания механики - это как управлять машиной без понимания, как работает двигатель. Можешь ездить, но не можешь оптимизировать расход топлива, не понимаешь, почему иногда машина тормозит, не знаешь, когда нужно обслуживание.

Практические выводы

Запускай /context каждые 10-15 запросов, чтобы предугадать проблемы до того, как качество упадёт.

Используй 100-120K как честный лимит, не 200K. Планируй сессии с логикой 100-120K доступного контекста. Это честный лимит для текущей сессии, после которого качество начинает деградировать.

Когда контекст превышает 100K, лучше переходи на isolated задачи - code review уже ненадёжен. Лучше сделать что-то, что не требует памяти всего проекта.

Невидимые слои (system, MCP, thinking) не менее важны, чем видимые. MCP tax может съесть 10K токенов незаметно - проверяй /doctor в начале сессии.

В следующей статье серии поговорим про Compaction Strategy - когда компактить вручную, как подготавливать контекст к auto-compact, когда лучше начать новую сессию. Вся серия - это путь: механика (эта статья) → стратегия (статья 3) → тактика (статья 4+).

Я потратил месяц на слепой дебаг контекста, потому что не знал механики. Надеюсь, что эта статья сэкономит тебе время и нервы. Теперь, когда ты знаешь, как устроено, ты можешь это оптимизировать.