--- title: context-rot desc: Чому довга сесія тупіє: з чого складається контекст, що з'їдає його насправді, що гине при компакції і чому /clear лікує краще за будь-яке формулювання. locked: true order: 7 --- # Чому довга сесія тупіє Відчуття знайоме: перші пів години агент влучний, потім починає забувати домовленості, повторювати вже виправлені помилки й «оптимізувати» те, що просили не чіпати. Це не деградація моделі. Це те, що з нею зробили з контекстом. --- ## З чого складається контекст | Складова | Хто її туди кладе | Чи можна впливати | |---|---|---| | Системний промпт | рантайм | ні | | Схеми інструментів (MCP, вбудовані) | конфіг | так — вимикати сервери, tool search | | Пам'ять / CLAUDE.md / правила | файли на диску | так — і це найдешевший важіль | | Однорядкові описи скілів | список активних скілів | так — вимикати невживані | | Історія повідомлень | сесія | так — `/clear`, `/compact` | | **Вивід інструментів** | сама робота | частково | | Вміст прочитаних файлів | сама робота | так — читати діапазони, не файли цілком | Розподіл у реальній агентній сесії — не той, який очікується. Проза моделі — одиниці відсотків. Основна маса це **вивід інструментів і вміст файлів**. Тому оптимізувати багатослівність відповідей — це шліфувати ту частину, якої майже нема. --- ## Що конкретно псує якість **1. Змішані теми.** Контекст, у якому одночасно лежать баг у вебхуках, налаштування nginx і суперечка про назву змінної — це контекст, у якому релевантне тоне серед нерелевантного. Модель не «забуває» — вона обирає з більшого стогу. **2. Спіраль виправлень.** Кожне «ні, не так» лишається в історії **разом із неправильною версією**. Після третьої ітерації в контексті три хибні варіанти й одна розмита вимога. Ймовірність влучити падає з кожним колом, а не зростає. **3. Простирадла виводу.** Один `cat` великого лог-файлу, один `npm test` із фулл-трейсом, одна відповідь MCP на 20k токенів — і половина вікна зайнята сміттям, яке більше ніколи не знадобиться. **4. Протухлі інструкції.** Правило, дописане пів року тому під задачу, якої вже нема, не нейтральне. Воно активно тягне модель у неправильний бік, і виглядає при цьому як авторитетне джерело. **5. Суперечності.** У CLAUDE.md написано одне, в чаті сказано інше, у скілі третє. Модель обере одне з трьох, і це буде не те, на яке розраховували. --- ## Що гине при компакції, а що ні Це найнеочевидніша частина, і саме на ній ламаються довгі сесії. | Переживає компакцію | Гине | |---|---| | Кореневий `CLAUDE.md` | Правила зі скоупом `paths:` | | Нескоуплені правила | Вкладені `CLAUDE.md` | | Авто-пам'ять (реінжектиться з диска) | Лістинг доступних скілів | | Тіла викликаних скілів (з лімітом) | Обмеження, сказані **тільки словами в чаті** | Останній рядок — джерело класичного інциденту. Сказано «не пушити в main», агент погодився, за годину відбулась компакція, ще за годину він запушив. Формально він не порушував — на момент дії такої інструкції в контексті вже не існувало. **Висновок:** усе, що мусить виконуватись гарантовано, живе в конфізі (`permissions.deny`, `PreToolUse`-хук), а не в тексті розмови. Текст розмови — це домовленість, а не механізм. --- ## Що з цим робити **Гігієна:** - Нова тема → `/clear`. Не «продовжимо тут, воно ж пов'язане». - `/compact <фокус>` руками перед новою великою фазою краще, ніж автокомпакція, яка вирішує сама. - `/context` — подивитись живий розподіл, а не здогадуватись. - Довгі побічні питання — через `/btw`: відповідь в оверлеї, в історію не потрапляє. **Структура роботи:** - Робочий стан — у файлах, не в історії чату. `SPEC.md`, `PLAN.md`, `NOTES.md` у репо переживають будь-яку компакцію й читаються за потреби. - Планування і виконання — різні сесії. Спека файлом, реалізація зі свіжого контексту. - Дослідження з великим виводом — у сабагента. Назад приїде підсумок, а не 40k токенів логів. **Інструменти:** - Читати діапазони рядків, а не файли цілком. - `grep`/`rg` замість «прочитай усі файли в теці». - Де є CLI — брати CLI замість MCP-сервера. - Вимкнути MCP-сервери, які зараз не потрібні. Не видалити — вимкнути. **Правило двох спроб:** дві невдалі корекції поспіль → `/clear` і переписати задачу з нуля, вже знаючи, де саме воно ламається. Третя спроба в отруєному контексті — найдорожча помилка з усіх, бо виглядає як прогрес. --- ## Симптоми, за якими видно, що пора стирати - Модель повертає помилку, яку вже виправляли в цій же сесії - Починає «заодно» правити те, що просили не чіпати - Переказує зроблене замість того, щоб робити наступне - Пропонує рішення, вже відкинуте двадцять повідомлень тому - Відповіді довшають, а конкретика зникає - Виправлення потребує третього уточнення Будь-які два з цього списку — досить. --- ## Чекліст - [ ] Одна сесія — одна тема - [ ] Стан роботи у файлах, а не тільки в історії - [ ] Тверді заборони — у `permissions.deny` / хуку, не в чаті - [ ] Великий вивід — через сабагента - [ ] Читання файлів діапазонами, не цілком - [ ] Невживані MCP-сервери вимкнені - [ ] Дві невдачі → `/clear`, а не третя спроба - [ ] `/context` перевірено, коли щось почало підозріло тупити {: .task }
P.S. — крива якості
```jd якість ▲ 100%│●───●───● │ ●──● 75%│ ●─● │ ●──● ← "дивно, вона ж 50%│ ●───● щойно нормально │ ●──● працювала" 25%│ ●───●───●───● │ 0%└────┬────┬────┬────┬────┬────┬────┬────┬────▶ 10 30 50 70 90 110 130 150 повідомлень ▲ отут треба було /clear (приблизно 120 повідомлень тому) ┌──────────────────────────────────────────────┐ │ людський підхід: ще одне уточнення │ │ правильний: Ctrl+A, Del, почати знову │ └──────────────────────────────────────────────┘ ```
Контекст працює як холодильник: чим більше туди напхано, тим менше шансів знайти те, по що прийшов. І щось там точно псується вже другий тиждень.