Технічний контекст
Я подивився на context-mode не як на черговий «оптимізатор промптів», а як на інженерний шар між інструментом та моделлю. Проєкт свіжий, обговорення на Hacker News з'явилося зовсім недавно, а отже, я розглядаю його не як зрілий стандарт, а як ранній, але дуже показовий сигнал для AI-архітектури агентних систем.
Суть у нього практична: він бере багатослівний вивід MCP-інструментів, ріже його на чанки, індексує в SQLite через FTS5 і потім віддає в модель тільки релевантні фрагменти. Для ранжування використовуються BM25 та Porter stemming, тобто компресія досягається не генерацією через LLM, а детермінованим пошуком по індексу.
Саме це мені в ньому й подобається. Я не плачу додатковими токенами за «стиснення за допомогою іншої моделі», не додаю ще один нестабільний шар і не залежу від якості проміжного самарі.
Заявлений приклад виглядає сильно: 315 KB сирого MCP-виводу перетворюються приблизно на 5.4 KB. Це близько 98% економії, але я б не продавав бізнесу тільки цю цифру, тому що поки немає переконливих незалежних бенчмарків щодо якості виконання завдань end-to-end.
Інтеграція теж досить приземлена: npm, Claude Code, Codex CLI, VS Code Copilot. Тобто це не дослідницька іграшка у вакуумі, а інструмент, який вже можна вбудувати в контур розробки та тестувати на реальних агентних сценаріях.
Вплив на бізнес та автоматизацію
Я бачу тут не просто економію токенів, а зміну вартості всього ланцюжка. Коли агент читає логи, результати CLI, великі відповіді від MCP-серверів та діагностичні дампи, бюджет найчастіше згоряє не на «розумі моделі», а на смітті, яким її нагодували.
Якщо я прибираю це сміття до потрапляння в контекст, я отримую три ефекти відразу: нижча вартість, вища стабільність відповіді та менша деградація на довгих сесіях. Для команд, які будують ШІ рішення для бізнесу на базі Copilot, Claude Code або власних coding-agent пайплайнів, це вже не дрібна оптимізація, а цілком відчутна стаття ефективності.
Виграють ті, хто масово ганяє інструментальні пайплайни: розробка, DevOps, сапорт-інженерія, внутрішні асистенти для аналізу логів та інцидентів. Програють, як завжди, ті, хто думає, що впровадження штучного інтелекту зводиться до вибору «найрозумнішої моделі» без контролю контексту, маршрутизації та вартості inference.
З мого досвіду в Nahornyi AI Lab, саме контекстний шум ламає ШІ автоматизацію раніше, ніж ліміт токенів як такий. Я багато разів бачив, як проєкту не потрібен перехід на дорожчу модель — йому потрібна нормальна архітектура ШІ-рішень з фільтрацією, retrieval-шаром та дисципліною навколо tool output.
Стратегічний погляд та глибокий розбір
Мій головний висновок такий: context-mode цікавий не як окремий репозиторій, а як маркер зрілості ринку. Ми рухаємося до архітектури, де контекст стає керованим ресурсом, а не бездонним буфером, в який складають усе підряд.
Я очікую, що в найближчий цикл розвитку MCP-екосистеми переможуть не ті, хто дасть моделі вікно на 1 мільйон токенів, а ті, хто навчиться подавати в це вікно тільки те, що потрібно. У ряді завдань маленька модель із чистим контекстом дійсно може виявитися вигіднішою і навіть точнішою за велику модель із захаращеною історією.
Але є й обмеження, яке я б відразу озвучив клієнту. Детерміноване пакування добре працює, поки завдання залежить від пошуку релевантних фрагментів; якщо критичні приховані зв'язки, рідкісні винятки або розподілений зміст по всьому логу, без акуратного налаштування retrieval можна втратити важливий сигнал.
Тому я б впроваджував такі інструменти тільки як частину повної ШІ інтеграції: з трасуванням, метриками якості, A/B-порівнянням проти raw-context режиму і контролем помилок за типами завдань. Так працює професійна розробка ШІ рішень, а не GitHub-ентузіазм заради гарної цифри економії.
Цей розбір підготував Вадим Нагорний — ключовий експерт Nahornyi AI Lab з AI-архітектури, впровадження ШІ та AI automation у реальному бізнесі. Якщо ви хочете зробити ШІ автоматизацію дешевшою, стійкішою і точнішою на ваших агентах, я пропоную обговорити ваш проєкт зі мною та командою Nahornyi AI Lab. Я допоможу спроєктувати архітектуру, перевірити гіпотези на ваших даних і впровадити рішення без зайвих витрат на токени та інфраструктуру.