Сontext-mode — это плагин для AI-агентов, который обещает экономить контекст.
Идея простая: не отправлять в модель весь вывод команд, а обрабатывать его отдельно и возвращать только короткий результат.
На первый взгляд звучит полезно. Но после использования я пришёл к выводу: context-mode решает правильную проблему неправильным способом.
Проблема экономии контекста есть.
Но решать её лучше не плагином, который встраивается в Claude Code, а нормальной архитектурой работы агентов.
В чём реальная проблема
Когда работаешь с Claude Code, быстро появляется типичная ситуация:
агент читает файлы
запускает grep
смотрит директории
ищет классы
открывает миграции
читает логи
собирает контекст
Всё это забивает context window.
Особенно неприятно, если основной агент дорогой: Opus, Sonnet или другая сильная модель. Она тратит дорогие токены не на мышление, а на рутину:
найди файлы
посмотри директории
проверь usages
собери список классов
покажи маршруты
Это плохое использование дорогой модели.
Дорогая модель должна думать.
Рутину должен делать дешёвый агент.
Как context-mode пытается решить проблему
context-mode предлагает другой подход:
большой вывод команды не отправляется в модель напрямую
плагин обрабатывает результат
часть данных сжимается
часть сохраняется
часть индексируется
агент получает короткий ответ
То есть плагин пытается экономить контекст технической прослойкой.
У него есть свои MCP-инструменты, hooks, SQLite/FTS5, session continuity и команды вроде:
ctx_execute
ctx_search
ctx_stats
ctx_doctor
ctx_purge
Формально задача понятная: меньше мусора в контексте.
Но проблема в том, что это не архитектурное разделение работы. Это дополнительный слой между агентом и проектом.
Почему это неправильный подход
Главная задача context-mode — экономия токенов.
Но токены можно экономить по-разному.
Плохой вариант:
дорогой агент делает всё сам
плагин пытается сжать последствия
Хороший вариант:
дешёвый subagent делает рутину
основной агент получает готовую выжимку
Разница принципиальная.
context-mode работает уже после того, как агент начал взаимодействовать с инструментами. Он пытается оптимизировать вывод, сжать данные, что-то сохранить и что-то вернуть обратно.
Subagent работает иначе: он сразу берёт на себя дешёвую рутинную задачу.
Например:
main agent:
Найди основные директории проекта и кратко опиши, за что они отвечают.
fast-explorer на Haiku:
- смотрит структуру проекта;
- находит app/, routes/, database/, config/, tests/;
- определяет ключевые модули;
- возвращает краткую выжимку.
main agent:
получает уже готовый результат и принимает решение.
В этой схеме дорогая модель не тратит токены на грязную разведку.
Что должен делать дешёвый subagent
Дешёвый subagent подходит для задач типа:
найти файлы
найти классы
найти usages
посмотреть routes
посмотреть migrations
найти config
собрать список сервисов
проверить структуру директорий
прочитать короткие фрагменты
сделать первичную выжимку
Например, для Laravel-проекта subagent может быстро собрать:
где лежат контроллеры
какие есть routes
какие модели участвуют в задаче
какие миграции связаны с таблицей
какие policies используются
где вызывается нужный сервис
какие тесты относятся к функционалу
И вернуть основному агенту короткий отчёт:
1. Основные файлы:
- app/Http/Controllers/ServiceController.php
- app/Models/Service.php
- app/Policies/ServicePolicy.php
- routes/web.php
2. Что важно:
- доступ проверяется через ServicePolicy
- route использует middleware auth
- в тестах есть проверка 403
- миграция создаёт поле is_active
3. Что смотреть дальше:
- ServicePolicy::viewAny()
- ServiceController::index()
Вот это нормальная экономия контекста.
Основной агент получает не сырой мусор, а результат разведки.
Почему subagent лучше context-mode
1. Роли разделены явно
С subagent понятно:
один агент ищет
другой агент думает
С context-mode непонятнее:
агент вызывает инструмент
плагин что-то перехватывает
что-то сжимает
что-то сохраняет
что-то достаёт из базы
что-то возвращает обратно
Чем больше скрытых действий, тем сложнее понять, почему агент ошибся.
2. Экономятся именно дорогие токены
Главный смысл — не просто уменьшить контекст.
Главный смысл — не тратить дорогую модель на дешёвую работу.
Если Haiku может найти файлы и собрать выжимку, зачем этим должен заниматься Opus?
context-mode экономит токены внутри одной схемы работы.
Subagent меняет саму схему работы.
Это более правильная оптимизация.
3. Результат можно проверить
Отчёт subagent можно прочитать:
что нашёл
какие файлы смотрел
что считает важным
что предлагает открыть дальше
Если отчёт плохой — это видно.
А если context-mode что-то сжал, не вернул или достал из своей базы, это менее прозрачно.
4. Не нужен скрытый слой памяти
Важная информация должна жить в проекте:
CLAUDE.md
AGENTS.md
docs/ai/
README
tests
git history
issues
А не во внутренней SQLite-базе плагина.
Если агенту нужно знать правила проекта — они должны быть явно записаны.
Если subagent собрал факты — он должен вернуть их в отчёте.
Не нужно, чтобы плагин сам решал, что запомнить и когда это снова подсунуть модели.
Что мне не понравилось в context-mode
Он сломался после обновлений
У меня context-mode в какой-то момент перестал нормально работать. Возможно, после обновления Claude Code или установки других плагинов.
Это уже проблема.
Инструмент, который встроен в hooks, MCP и работу с контекстом, не должен легко ломать среду.
После поломки непонятно, где искать причину:
Claude Code
MCP
hooks
plugin cache
settings.json
.mcp.json
statusLine
сам context-mode
Он тяжело удаляется
context-mode может оставлять следы в разных местах:
~/.claude/settings.json
~/.claude.json
.claude/settings.json
.claude/settings.local.json
.mcp.json
~/.claude/plugins/
plugin cache
hooks
statusLine
MCP servers
Если ставить его для нескольких агентов, чистить приходится ещё больше.
Для инструмента, который должен просто экономить контекст, это слишком большая цена владения.
Он делает работу агента менее прозрачной
Без context-mode цепочка простая:
агент прочитал файл
агент получил вывод
агент сделал вывод
агент изменил код
С context-mode появляется лишний слой:
tool call
hook
context-mode
executor
сжатие вывода
SQLite / FTS5
поиск данных
возврат короткого результата
Если агент ошибся, сложнее понять причину.
Он ошибся сам?
Плагин не вернул важный кусок?
Поиск достал не то?
В сессию попали старые данные?
Summary потерял важную деталь?
Для coding-agent это плохой обмен.
Когда context-mode может быть уместен
context-mode может быть полезен как отдельный инструмент для больших сырых данных:
большие логи
огромные JSON
CSV
дампы API
Playwright snapshots
длинные списки issue
Но это не значит, что его нужно ставить как постоянный слой для Claude Code.
Если задача — один раз обработать большой лог, такой инструмент может помочь.
Если задача — постоянно разрабатывать проект, лучше использовать subagents и явные инструкции.
Как я считаю правильным
Правильная архитектура такая:
main agent:
- думает;
- проектирует;
- принимает решения;
- пишет важный код;
- анализирует архитектуру.
cheap subagent:
- ищет файлы;
- grep-ает usages;
- смотрит директории;
- собирает факты;
- делает краткую выжимку.
Проектные правила должны лежать явно:
CLAUDE.md
AGENTS.md
docs/ai/
skills
commands
Контекст нужно не магически сжимать, а нормально организовывать.
Мой вывод
context-mode решает реальную проблему: контекст и токены надо экономить.
Но он делает это не тем способом.
Он добавляет:
hooks
MCP-инструменты
SQLite/FTS5
скрытое состояние
session continuity
сложную диагностику
сложное удаление
непрозрачную работу агента
При этом ту же задачу можно решить чище:
дешёвый subagent делает рутину
дорогой main agent получает выжимку
важные правила лежат в проектной документации
контекст контролируется явно
Поэтому я не хочу использовать context-mode как постоянный плагин для Claude Code.
Мой вывод короткий:
экономить токены нужно не скрытой прослойкой, а правильным разделением ролей между агентами.
Дорогая модель должна думать.
Дешёвая модель должна делать рутину.
А плагин, который лезет в hooks, MCP и внутреннюю память сессии, в этой схеме лишний.