Чому довга сесія тупіє

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

З чого складається контекст

Розподіл у реальній агентній сесії — не той, який очікується. Проза моделі — одиниці відсотків. Основна маса це вивід інструментів і вміст файлів. Тому оптимізувати багатослівність відповідей — це шліфувати ту частину, якої майже нема.

Що конкретно псує якість

1. Змішані теми. Контекст, у якому одночасно лежать баг у вебхуках, налаштування nginx і суперечка про назву змінної — це контекст, у якому релевантне тоне серед нерелевантного. Модель не «забуває» — вона обирає з більшого стогу.

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

3. Простирадла виводу. Один cat великого лог-файлу, один npm test із фулл-трейсом, одна відповідь MCP на 20k токенів — і половина вікна зайнята сміттям, яке більше ніколи не знадобиться.

4. Протухлі інструкції. Правило, дописане пів року тому під задачу, якої вже нема, не нейтральне. Воно активно тягне модель у неправильний бік, і виглядає при цьому як авторитетне джерело.

5. Суперечності. У 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 перевірено, коли щось почало підозріло тупити

  якість
    ▲
100%│●───●───●
    │           ●──●
 75%│                ●─●
    │                    ●──●         ← "дивно, вона ж
 50%│                        ●───●       щойно нормально
    │                             ●──●   працювала"
 25%│                                 ●───●───●───●
    │
  0%└────┬────┬────┬────┬────┬────┬────┬────┬────▶
         10   30   50   70   90  110  130  150   повідомлень
                                  ▲
                          отут треба було /clear
                          (приблизно 120 повідомлень тому)


  ┌──────────────────────────────────────────────┐
  │  людський підхід:  ще одне уточнення         │
  │  правильний:       Ctrl+A, Del, почати знову │
  └──────────────────────────────────────────────┘