Як не втрачати контекст у Claude Code: компакт, resume і handoff

Коротко (TL;DR)

Контекст у Claude Code — це ресурс, що має межу, і головна помилка — думати, ніби він «просто закінчується» на межі вікна. Насправді якість просідає задовго до цієї межі, а під час стиснення губиться не випадковий шум, а передбачувані речі: заперечення, точні числа, історія відхилених рішень.

Проблема існує на трьох рівнях, і для кожного — свій інструмент: – Усередині однієї сесії вікно переповнюється — рятує /compact (стиснення історії) і ручне правило «компактити близько 40%». – Між сесіями контекст обнуляється — повертає /resume, а сталі речі тримають CLAUDE.md і пам’ять. – Між агентами субагент губить нитку — вирішує handoff-документ: свідомо написана зведена інформація для наступного агента.

Ці три механіки постійно плутають. /compact продовжує ту саму сесію зі стиснутою історією; /resume повертає до старої сесії цілком; handoff — це не автоматика, а зведення, яке ви (або агент) пишете вручну. Нижче — точний контракт «що переживає компакт», готовий шаблон handoff-документа і докладний розбір того, що втрачається і чим це небезпечно.

Пороги та поведінка компакту змінюються між версіями — звіряйтеся з документацією; у волатильних цифр у тексті вказана своя дата.

Чому контекст закінчується раніше, ніж здається

У довгоживучого агента є три системні стіни: вікно має межу, між сесіями немає стану, а в моделі немає вбудованої самоперевірки — вона не знає напевно, що саме забула.

AMD купує собі місце в Anthropic: 2 гігавати MI450 в обмін на інвестицію до $5 млрд

Один агент чи кілька: як обрати мультиагентну архітектуру

П’ять патернів агентних систем: механіка, приклади та ціна кожного

Воркфлоу проти ШІ-агента: як обрати і не переплатити за автономність

Оркестрація агентів у Claude Code: як змусити їх працювати командою

Перша стіна — найпідступніша, бо діє поступово. Явище називають context rot: здатність моделі точно пригадувати потрібне знижується в міру заповнення вікна. Це градієнт, а не обрив — агент не «вимикається» на 100%, він поступово тупіє. Один інженер Anthropic (Tariq), у переказі стороннього блогу, зазначав помітну деградацію вже приблизно з 40% заповнення навіть на великих вікнах — це community-евристика, а не офіційний поріг. Звідси й практичне «правило 40%»: не чекати авто-стиснення, а компактити раніше, поки якість ще висока.

Наскільки раніше — питання цифр. Автоматичний компакт спрацьовує пізно: за замірами спільноти на липень 2026 року, близько 83,5% заповнення (раніше було 77–78%), з буфером порядку 33K токенів. Але це неофіційні виміри — в офіційній документації точного порогу немає, а інший незалежний гайд називає взагалі 95%. Висновок для практики: не покладайтеся на авто-тригер як на захист якості — він про захист від переповнення, а не про «поки все добре». Тримайте руку на /compact самі.

Усередині сесії: що переживає /compact

/compact стискає історію поточної сесії: модель зберігає суть і продовжує роботу в тому самому діалозі. Що саме вона зберігає, а що відкидає — не магія, а цілком конкретний контракт.

Під час стиснення модель утримує архітектурні рішення, невирішені баги, деталі реалізації та вміст приблизно п’яти останніх файлів; відкидає надлишкові результати викликів інструментів (ті самі простирадла логів). Окремо поводиться обв’язка сесії:

Не плутайте /compact з /clear. /compact — та сама сесія, стиснута історія, робота триває. /clear — нова розмова з чистого аркуша; стара при цьому нікуди не дівається, до неї можна повернутися через /resume. Компакт — «ущільнити», очищення — «почати заново».

Між сесіями: resume, CLAUDE.md і пам’ять

Кожна нова сесія Claude Code стартує з чистого вікна. З минулого автоматично переїжджають лише два канали: CLAUDE.md (те, що ви написали власноруч) і авто-пам’ять (те, що Claude записав сам) — обидва підвантажуються на початку кожної сесії.

Щоб повернутися до конкретної минулої сесії цілком, є /resume (псевдонім /continue). З версії v2.1.144 фонові сесії у списку вибору позначаються міткою bg, щоб не плутати їх з інтерактивними.

Різниця між трьома каналами сталості важлива на практиці. /resume повертає всю історію конкретної сесії — це дорого за контекстом, але повно: підходить, коли потрібно продовжити рівно з того місця. CLAUDE.md — це те, що ви вирішили тримати завжди (правила проєкту, домовленості, важливі шляхи); він переінжектується в кожну нову сесію і в цьому сенсі «безкоштовно» переживає і компакт, і зміну сесії. Авто-пам’ять — проміжний канал: Claude сам записує те, що вважав вартим запам’ятовування, і це також переїжджає між сесіями. Практичний висновок: разовий живий стан передавайте через /resume або handoff, а те, що має жити вічно, кладіть у CLAUDE.md — не розраховуйте, що важливе правило «само переживе» історію діалогу.

Тут важлива межа: CLAUDE.md і авто-пам’ять — це про довгу пам’ять проєкту (те, що пам’ятається завжди), і це окрема велика тема. У цій статті нас цікавить механіка передачі — як перенести живий стан роботи, а не що запам’ятати назавжди. Якщо вам потрібна саме постійна пам’ять, її логіку ми розбираємо окремо; тонкощі версії моделі (розмір вікна, пороги) теж впливають на те, як часто ви впираєтеся в компакт — це видно з розбору можливостей Claude Sonnet 5 з його великим контекстним вікном.

Між агентами: субагент віддає summary, а не все вікно

Коли роботу виконує субагент, він працює у своєму окремому контекстному вікні й повертає батьківському агенту не все, що прочитав, а стиснуте зведення — зазвичай порядку 1000–2000 токенів. Це і є передача контексту між агентами в чистому вигляді: сто прочитаних файлів згортаються в абзац виводу.

Той самий принцип працює як прийом проєктування — progressive disclosure (поступове розкриття): не завантажувати в агента все заздалегідь, а давати інформацію в міру потреби, посиланнями замість повного тексту. Вигода подвійна: контекст оркестратора лишається чистим, а субагент не відволікається на зайве й працює точніше у своєму вузькому завданні. У Dynamic Workflows ідею доведено до межі — план і розгалуження живуть у змінних скрипта, а в контекст моделі потрапляє лише фінальний результат кроку, тому такий воркфлоу й тягне десятки кроків без переповнення.

Окремо варто розрізняти context reset і компакцію — їх часто вважають синонімами, а це різні речі. Компакція зберігає безперервність діалогу, але не лікує «context anxiety» — ефект, коли модель занижує свою залишкову спроможність і починає поспішати закінчити. Reset дає чистий аркуш (тривога зникає), але ціною того, що все важливе потрібно вручну перекласти в handoff-документ. Саме до нього й переходимо.

Шаблон handoff-документа: збираємо покроково

Handoff-документ — це свідомо написане зведення стану для наступного агента чи сесії. Не автоматика: ви або агент пишете його навмисно, коли наближається межа контексту або завдання передається далі.

Гарна новина — структура давно усталена. Зведемо дві незалежні схеми (aipatternbook.com і agentpatterns.ai) в один шаблон із п’яти полів:

# Handoff

## 1. Мета (Objective)
Що ми взагалі робимо і який результат вважається готовим.

## 2. Обмеження (Constraints)
Жорсткі рамки: чого робити НЕ МОЖНА, які вимоги обов'язкові.
(Це поле критичне — саме обмеження втрачаються першими, див. ризики.)

## 3. Ухвалені рішення (Prior decisions)
Що вже вирішено і ЧОМУ; які варіанти відхилено і чому —
щоб отримувач не ганявся за вже закритими гіпотезами.

## 4. Поточний стан (Current state)
Де ми зараз: що зроблено, що в роботі, посилання на файли/гілки.

## 5. Наступні кроки (Next steps)
Що робити далі, по пунктах.

Головне правило, яке суперечить інстинкту, — не дублюй. Коли контекст губиться, хочеться записати в handoff геть усе, але найчастіший провал — не «мало», а забагато: повний ланцюг міркувань змушує отримувача перебирати вже відхилені ходи («context dump fallacy»). Не копіюйте в handoff те, що вже існує в проєкті (PRD, ADR, коміти) — посилайтеся на них за шляхом. У документ пишіть лише те, що живе виключно в розмові і інакше зникне.

Як це виглядає на практиці. Поганий handoff — це простирадло: «я спробував варіант A, потім подумав про B, але згадав про C, подивився файл X, там було…» — отримувач тоне і повторює ваш шлях. Добрий — короткий і адресний: «Мета: полагодити експорт у CSV. Обмеження: не чіпати схему БД. Вирішено використати стрімінг замість завантаження в пам’ять (варіант із буфером відхилено — падав на файлах >1 ГБ). Зараз: готовий парсер, не дописано вивід заголовків. Далі: доробити заголовки, додати тест на порожній файл». П’ять рядків замість сторінки — і наступний агент одразу в контексті, без розкопок.

Зверніть увагу, чому поле «Ухвалені рішення» зберігає й відхилені варіанти з причиною: без цього отримувач з високою ймовірністю знову запропонує буфер у пам’яті — той самий, що вже провалився. Заперечення та історія відмов втрачаються під час стиснення першими (про це нижче), тому саме їх важливо зафіксувати явно.

Parallel-safe рецепт. Якщо ви ганяєте кілька терміналів паралельно, один спільний handoff-файл перетворюється на гонку записів (last-write-wins, хтось перетре чуже). Рішення просте: timestamped-файли — кожен агент пише свій handoff-<час>.md, а не спільний один. Race condition зникає.

Те, що це не «фіча одного вендора», добре видно з індустрії: той самий патерн під тією самою назвою реалізовано в OpenAI Agents SDK (transfer_to_<agent>) і Microsoft Agent Framework. А живий робочий приклад — кейс з Хабра: зв’язка агента-ініціалізатора й агента-кодера спілкується через init.sh плюс claude-progress.txt плюс JSON-чекліст фіч із полем passes, причому готовність перевіряється не самооцінкою агента, а прогоном через браузер (Puppeteer MCP). Це той самий handoff, тільки формалізований до машинозчитуваного файлу — і, що показово, до ідеї машинозчитуваного прогрес-файлу незалежно дійшли в різних місцях (JSON-чекліст Anthropic; формати progress.json і record_note у практиків). Сходження до однієї ідеї зазвичай свідчить про реальну потребу, а не про моду.

Скільки це коштує

Handoff і context-reset — це праця й токени, і питання «а чи варто» цілком законне. Орієнтири такі:

Наочний приклад від Anthropic: той самий довгий прогон у варіанті «соло» коштував близько $9 за 20 хвилин і ламався, а з повноцінним harness’ом (context reset плюс handoff між стадіями) — близько $200 за 6 годин і працював. Це конкретний експеримент (одне завдання-генератор ігор, одна модель), а не універсальне співвідношення цін — але ілюструє принцип: переплата не за «магію», а за те, що система не розсипається на довгій дистанції. Для орієнтиру: середня вартість Claude Code на підприємствах — порядку $13 на розробника в день ($150–250 на місяць).

Якщо завдання — не разовий прогон, а постійний автономний агент зі своєю економікою, це вже інший клас інструментів; собівартість такого ми рахували на прикладі персонального ШІ-агента OpenClaw.

Де ламається і що втрачається першим

Стиснення не безкоштовне для якості, і втрати не випадкові. Під час компакції першими під ніж ідуть передбачувані категорії: заперечення й заборони, точні числа, порядок кроків, атрибуція результатів інструментів та історія відхилених рішень. Це готовий чекліст «що закріплювати вручну».

Наскільки глибокі втрати — показують два незалежні препринти 2026 року (обидва ще не рецензовані, але якісно узгоджуються): – За одним, уже 5% компакції коштують близько −7 процентних пунктів recall, а за 50% стиснення настає майже «мертва зона» (0–7% точності відтворення). – За іншим, після компакції частка порушень заборонених дій підскакує з 0% до 30–59% — тобто агент починає робити те, що йому забороняли, просто тому що заборона «випала» з контексту. Прийом під назвою Constraint Pinning (примусове закріплення обмеження поза стисненням) повертає порушення до нуля.

Другий провал — «зіпсований телефон» під час передачі summary: якщо зведення неточне або, навпаки, перевантажене, отримувач іде не туди. Звідси й no-duplication rule вище: коротке точне зведення надійніше за довге. Особливо підступно це в ланцюжку з кількох передач — кожне наступне зведення будується на попередньому, і дрібне спотворення на першому кроці до третього агента розростається в неправильну картину.

Для порівняння, агент, який веде структуровану базу знань, вирішує проблему пам’яті інакше — не передачею контексту, а зовнішнім сховищем; це інший інженерний компроміс.

Ризики: коли втрачене обмеження небезпечне

Для технічної теми це і є YMYL-блок. Поки агент пише код у пісочниці, втрата обмеження під час компакції — прикрість. Але якщо агенту довірено незворотні дії — git push, надсилання листів, платежі, — зникнення safety-обмеження з контексту стає реальним ризиком: агент може виконати те, що ви явно забороняли на початку сесії, бо заборона не пережила стиснення (див. цифри про governance decay вище).

Практична рекомендація проста й структурна: критичні обмеження тримайте поза зоною компакта — у CLAUDE.md (він переінжектується), у закріпленому вигляді (Constraint Pinning) або на початку handoff-документа окремим полем «Обмеження». Не розраховуйте, що модель «сама згадає» заборону з історії — на довгій дистанції вона втрачає її передбачувано.

Альтернативи: формати прогрес-файлу і коли handoff не потрібен

Повноцінний handoff-документ — не єдиний інструмент, і не завжди він взагалі потрібен.

• Легкі чекпоінти замість повного handoff. Для повторюваних завдань зручні компактні формати: record_note (короткий запис-позначка про прогрес) або progress.json (структурований статус за пунктами). Це той самий принцип, але без розгорнутого зведення — коли втрачати особливо нічого, вистачає позначки «зроблено/не зроблено».
• Готові community-інструменти. Під завдання «міст контексту між сесіями» вже з’явилися сторонні утиліти (handoff-skill і подібні) — їх можна взяти, а не вигадувати формат з нуля. Перевіряйте лише, що інструмент не тягне в контекст зайвого.
• Коли handoff не потрібен узагалі. Коротке завдання в межах однієї сесії не потребує ні handoff, ні навіть ручного компакта — доробили і закрили. Городити прогрес-файл заради півгодини роботи — той самий оверінжиніринг, якого варто уникати.

Правило просте: масштаб інструменту — під масштаб завдання. Багатоденний автономний прогон потребує harness із context reset і структурованим handoff; правка на півгодини — нічого з цього.

FAQ

Що втрачається під час /compact, а що зберігається? Зберігаються архітектурні рішення, невирішені баги, деталі реалізації та приблизно п’ять останніх файлів; кореневий CLAUDE.md і авто-пам’ять переінжектуються з диска, а системний промпт і так не є частиною історії повідомлень. Відкидаються в першу чергу надлишкові результати викликів інструментів, а також передбачувано страждають заперечення, точні числа й історія відхилених рішень. Path-scoped правила та вкладені CLAUDE.md випадають, доки агент знову не прочитає файл.

Коли компактити — чекати авто-тригер чи вручну? Вручну, раніше за авто-тригер. Автоматичний компакт спрацьовує пізно (за замірами спільноти — близько 83% заповнення, але точного офіційного порогу немає), а якість просідає вже приблизно з 40%. Правило 40% — про те, щоб стиснути, поки агент ще «розумний», а не коли він уже почав тупіти.

Чим /compact відрізняється від /resume і /clear? /compact стискає історію тієї самої сесії й продовжує роботу. /clear починає нову розмову з чистого аркуша (стара доступна через /resume). /resume (псевдонім /continue) повертає до конкретної минулої сесії цілком. Три різні операції під три різні завдання.

Як виглядає добрий handoff-документ? П’ять полів: мета, обмеження, ухвалені рішення (з причинами й відхиленими варіантами), поточний стан, наступні кроки. Головне правило — не дублювати те, що вже є в проєкті (PRD, коміти, ADR): посилайтеся за шляхом, а в handoff пишіть лише те, що живе тільки в розмові. Найчастіша помилка — напхати забагато.

Як передавати контекст, якщо запускаю кілька агентів паралельно? Не використовуйте один спільний handoff-файл — буде гонка записів, хтось перетре чуже. Давайте кожному агенту свій файл з міткою часу (handoff-<час>.md). Це усуває race condition і дозволяє потім зібрати стан з усіх файлів.

Чи правда, що агент може «забути» заборону після стиснення? Так, і це вимірювано: після компакції частка порушень раніше заборонених дій зростає з нуля до десятків відсотків, бо обмеження випадає з контексту. Тому критичні заборони тримають поза зоною стиснення — у CLAUDE.md або закріпленими окремо, а не покладаються на історію діалогу.