---
read_when:
    - Вам потрібно налагодити ідентифікатори сеансів, JSONL транскриптів або поля sessions.json
    - Ви змінюєте поведінку авто-Compaction або додаєте службове впорядкування перед Compaction
    - Ви хочете реалізувати очищення памʼяті або тихі системні ходи
summary: 'Глибокий розбір: сховище сесій і транскрипти, життєвий цикл та внутрішня реалізація (авто)Compaction'
title: Глибокий огляд керування сеансами
x-i18n:
    generated_at: "2026-07-04T20:43:33Z"
    model: gpt-5.5
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: c97994f674e14ec01b2eaadc10a61e524f5071f95b2ef84957d71abacbdc719b
    source_path: reference/session-management-compaction.md
    workflow: 16
---

OpenClaw керує сеансами наскрізно в таких сферах:

- **Маршрутизація сеансів** (як вхідні повідомлення зіставляються з `sessionKey`)
- **Сховище сеансів** (`sessions.json`) і що воно відстежує
- **Збереження транскриптів** (`*.jsonl`) і їхня структура
- **Гігієна транскриптів** (провайдер-специфічні виправлення перед запусками)
- **Обмеження контексту** (контекстне вікно проти відстежуваних токенів)
- **Compaction** (ручна й автоматична Compaction) і де під’єднувати роботу перед Compaction
- **Тихе обслуговування** (записи пам’яті, які не мають створювати видимого для користувача виводу)

Якщо спершу потрібен огляд вищого рівня, почніть із:

- [Керування сеансами](/uk/concepts/session)
- [Compaction](/uk/concepts/compaction)
- [Огляд пам’яті](/uk/concepts/memory)
- [Пошук у пам’яті](/uk/concepts/memory-search)
- [Обрізання сеансів](/uk/concepts/session-pruning)
- [Гігієна транскриптів](/uk/reference/transcript-hygiene)

---

## Джерело істини: Gateway

OpenClaw спроєктовано навколо єдиного **процесу Gateway**, який володіє станом сеансів.

- Інтерфейси (застосунок macOS, веб Control UI, TUI) мають запитувати в Gateway списки сеансів і підрахунки токенів.
- У віддаленому режимі файли сеансів розміщені на віддаленому хості; «перевірка локальних файлів Mac» не відображатиме те, що використовує Gateway.

---

## Два шари збереження

OpenClaw зберігає сеанси у двох шарах:

1. **Сховище сеансів (`sessions.json`)**
   - Карта ключ/значення: `sessionKey -> SessionEntry`
   - Невелике, змінюване, безпечне для редагування (або видалення записів)
   - Відстежує метадані сеансу (поточний ідентифікатор сеансу, останню активність, перемикачі, лічильники токенів тощо)

2. **Транскрипт (`<sessionId>.jsonl`)**
   - Транскрипт лише для дописування з деревоподібною структурою (записи мають `id` + `parentId`)
   - Зберігає фактичну розмову + виклики інструментів + підсумки Compaction
   - Використовується для повторної побудови контексту моделі для майбутніх ходів
   - Контрольні точки Compaction є метаданими над ущільненим наступним транскриптом. Нові Compaction не записують другу копію `.checkpoint.*.jsonl`.

Зчитувачам історії Gateway слід уникати матеріалізації всього транскрипту, якщо поверхні явно не потрібен довільний історичний доступ. Історія першої сторінки, вбудована історія чату, відновлення після перезапуску та перевірки токенів/використання застосовують обмежені читання хвоста. Повні сканування транскриптів проходять через асинхронний індекс транскриптів, який кешується за шляхом файлу разом із `mtimeMs`/`size` і спільно використовується конкурентними зчитувачами.

---

## Розташування на диску

Для кожного агента, на хості Gateway:

- Сховище: `~/.openclaw/agents/<agentId>/sessions/sessions.json`
- Транскрипти: `~/.openclaw/agents/<agentId>/sessions/<sessionId>.jsonl`
  - Сеанси тем Telegram: `.../<sessionId>-topic-<threadId>.jsonl`

OpenClaw визначає ці шляхи через `src/config/sessions.ts`.

---

## Обслуговування сховища та керування диском

Збереження сеансів має автоматичні засоби обслуговування (`session.maintenance`) для `sessions.json`, артефактів транскриптів і допоміжних файлів траєкторій:

- `mode`: `enforce` (типово) або `warn`
- `pruneAfter`: граничний вік застарілих записів (типово `30d`)
- `maxEntries`: обмеження кількості записів у `sessions.json` (типово `500`)
- Утримання короткоживучих проб запуску моделі Gateway фіксоване на `24h`, але воно спрацьовує лише під тиском: воно видаляє застарілі рядки строгих проб лише тоді, коли досягнуто тиску обслуговування/ліміту записів сеансів. Це стосується лише строгих явних ключів проб, що відповідають `agent:*:explicit:model-run-<uuid>`, і виконується перед глобальним очищенням/обмеженням застарілих записів, коли воно запускається.
- `resetArchiveRetention`: утримання архівів транскриптів `*.reset.<timestamp>` (типово: те саме, що `pruneAfter`; `false` вимикає очищення)
- `maxDiskBytes`: необов’язковий бюджет каталогу сеансів
- `highWaterBytes`: необов’язкова ціль після очищення (типово `80%` від `maxDiskBytes`)

Звичайні записи Gateway проходять через окремий для сховища записувач сеансів, який серіалізує внутрішньопроцесні мутації без взяття файлового блокування під час виконання. Допоміжні функції виправлень на гарячому шляху позичають перевірений змінюваний кеш, доки утримують цей слот записувача, тож великі файли `sessions.json` не клонуються й не перечитуються для кожного оновлення метаданих. Код виконання має надавати перевагу `updateSessionStore(...)` або `updateSessionStoreEntry(...)`; прямі збереження всього сховища є інструментами сумісності та офлайн-обслуговування. Коли Gateway доступний, недемонстраційні `openclaw sessions cleanup` і `openclaw agents delete` делегують мутації сховища Gateway, щоб очищення долучалося до тієї самої черги записувача; `--store <path>` є явним офлайн-шляхом відновлення для прямого обслуговування файлів. Очищення `maxEntries` усе ще пакетне для лімітів виробничого розміру, тому сховище може ненадовго перевищувати налаштований ліміт, перш ніж наступне очищення верхньої межі знову зменшить його. Читання сховища сеансів не обрізають і не обмежують записи під час запуску Gateway; для очищення використовуйте записи або `openclaw sessions cleanup --enforce`. `openclaw sessions cleanup --enforce` усе ще негайно застосовує налаштований ліміт і обрізає старі непосилані артефакти транскриптів, контрольних точок і траєкторій, навіть коли дисковий бюджет не налаштовано.

Обслуговування зберігає довговічні зовнішні вказівники розмов, як-от групові сеанси та сеанси чатів у межах гілок, але синтетичні записи виконання для cron, хуків, heartbeat, ACP і субагентів усе одно можуть бути вилучені, коли вони перевищують налаштований вік, кількість або дисковий бюджет. Сеанси проб запуску моделі Gateway використовують окреме утримання запуску моделі `24h` лише тоді, коли їхній ключ точно відповідає `agent:*:explicit:model-run-<uuid>`; інші явні сеанси не належать до цього утримання. Очищення запусків моделі застосовується лише під тиском ліміту записів сеансів. Ізольовані запуски cron зберігають власний контроль `cron.sessionRetention`, незалежний від утримання проб запуску моделі.

OpenClaw більше не створює автоматичні ротаційні резервні копії `sessions.json.bak.*` під час записів Gateway. Застарілий ключ `session.maintenance.rotateBytes` ігнорується, а `openclaw doctor --fix` видаляє його зі старіших конфігурацій.

Мутації транскриптів використовують блокування запису сеансу на файлі транскрипту. Отримання блокування очікує до `session.writeLock.acquireTimeoutMs`, перш ніж показати помилку зайнятого сеансу; типове значення — `60000` мс. Підвищуйте це лише тоді, коли легітимна підготовка, очищення, Compaction або дзеркалювання транскрипту довше конкурують на повільних машинах. `session.writeLock.staleMs` керує тим, коли наявне блокування можна повернути як застаріле; типове значення — `1800000` мс. `session.writeLock.maxHoldMs` керує порогом внутрішньопроцесного сторожового звільнення; типове значення — `300000` мс. Аварійні перевизначення середовища: `OPENCLAW_SESSION_WRITE_LOCK_ACQUIRE_TIMEOUT_MS`, `OPENCLAW_SESSION_WRITE_LOCK_STALE_MS` і `OPENCLAW_SESSION_WRITE_LOCK_MAX_HOLD_MS`.

Порядок застосування очищення дискового бюджету (`mode: "enforce"`):

1. Спочатку видалити найстаріші архівовані, осиротілі артефакти транскриптів або осиротілі артефакти траєкторій.
2. Якщо все ще вище цілі, витіснити найстаріші записи сеансів і їхні файли транскриптів/траєкторій.
3. Продовжувати, доки використання не буде на рівні або нижче `highWaterBytes`.

У `mode: "warn"` OpenClaw повідомляє про потенційні витіснення, але не змінює сховище/файли.

Запустіть обслуговування на вимогу:

```bash
openclaw sessions cleanup --dry-run
openclaw sessions cleanup --enforce
```

---

## Сеанси cron і журнали запусків

Ізольовані запуски cron також створюють записи сеансів/транскрипти та мають спеціальні засоби керування утриманням:

- `cron.sessionRetention` (типово `24h`) обрізає старі сеанси ізольованих запусків cron зі сховища сеансів (`false` вимикає).
- `cron.runLog.keepLines` обрізає збережені рядки історії запусків SQLite для кожного завдання cron (типово: `2000`). `cron.runLog.maxBytes` лишається прийнятним для старіших файлових журналів запусків.

Коли cron примусово створює новий ізольований сеанс запуску, він санітизує попередній запис сеансу `cron:<jobId>` перед записом нового рядка. Він переносить безпечні параметри, як-от налаштування thinking/fast/verbose, мітки та явні вибрані користувачем перевизначення моделі/автентифікації. Він відкидає навколишній контекст розмови, як-от маршрутизацію каналу/групи, політику надсилання або черги, підвищення прав, походження та прив’язку виконання ACP, щоб свіжий ізольований запуск не міг успадкувати застарілу доставку або повноваження виконання від старішого запуску.

---

## Ключі сеансів (`sessionKey`)

`sessionKey` визначає, _у якому контейнері розмови_ ви перебуваєте (маршрутизація + ізоляція).

Поширені шаблони:

- Основний/прямий чат (для агента): `agent:<agentId>:<mainKey>` (типово `main`)
- Група: `agent:<agentId>:<channel>:group:<id>`
- Кімната/канал (Discord/Slack): `agent:<agentId>:<channel>:channel:<id>` або `...:room:<id>`
- Cron: `cron:<job.id>`
- Webhook: `hook:<uuid>` (якщо не перевизначено)

Канонічні правила задокументовано на [/concepts/session](/uk/concepts/session).

---

## Ідентифікатори сеансів (`sessionId`)

Кожен `sessionKey` вказує на поточний `sessionId` (файл транскрипту, який продовжує розмову).

Практичні правила:

- **Скидання** (`/new`, `/reset`) створює новий `sessionId` для цього `sessionKey`.
- **Щоденне скидання** (типово о 4:00 AM за місцевим часом на хості gateway) створює новий `sessionId` у наступному повідомленні після межі скидання.
- **Завершення через неактивність** (`session.reset.idleMinutes` або застарілий `session.idleMinutes`) створює новий `sessionId`, коли повідомлення надходить після вікна неактивності. Коли налаштовано і щоденне, і за неактивністю, перемагає те, що спливає першим.
- **Відновлення після повторного підключення Control UI** може зберегти поточний видимий сеанс для одного надсилання після повторного підключення, коли Gateway отримує відповідний `sessionId` від клієнта операторського інтерфейсу. Звичайні застарілі надсилання все одно створюють новий `sessionId`.
- **Системні події** (heartbeat, пробудження cron, сповіщення exec, облік gateway) можуть змінювати рядок сеансу, але не подовжують свіжість щоденного/неактивного скидання. Перехід скидання відкидає поставлені в чергу повідомлення системних подій для попереднього сеансу до побудови свіжого запиту.
- **Політика форку батьківського елемента** використовує активну гілку OpenClaw під час створення гілки або форку субагента. Якщо ця гілка завелика, OpenClaw запускає дочірній елемент з ізольованим контекстом замість збою або успадкування непридатної історії. Політика визначення розміру автоматична; застарілу конфігурацію `session.parentForkMaxTokens` видаляє `openclaw doctor --fix`.

Деталь реалізації: рішення ухвалюється в `initSessionState()` у `src/auto-reply/reply/session.ts`.

---

## Схема сховища сеансів (`sessions.json`)

Тип значення сховища — `SessionEntry` у `src/config/sessions.ts`.

Ключові поля (не вичерпно):

- `sessionId`: поточний ідентифікатор транскрипту (ім’я файлу виводиться з нього, якщо не задано `sessionFile`)
- `sessionStartedAt`: часова мітка початку для поточного `sessionId`; щоденне скидання
  актуальності використовує її. Застарілі рядки можуть виводити її з заголовка сеансу JSONL.
- `lastInteractionAt`: часова мітка останньої реальної взаємодії користувача/каналу; скидання
  актуальності під час простою використовує її, щоб події heartbeat, cron і exec не підтримували сеанси
  активними. Застарілі рядки без цього поля повертаються до відновленого часу початку сеансу
  для актуальності простою.
- `updatedAt`: часова мітка останньої зміни рядка сховища, використовується для списків, очищення та
  обліку. Вона не є джерелом істини для актуальності щоденного/простою скидання.
- `archivedAt`: необов’язкова часова мітка архівування. Архівовані сеанси залишаються в сховищі
  з незмінним транскриптом і виключаються зі звичайних списків активних сеансів.
- `pinnedAt`: необов’язкова часова мітка закріплення. Активні закріплені сеанси сортуються перед
  незакріпленими; архівування сеансу очищає його закріплення.
- Взаємодія з потоками Codex: обидва поля відповідають формі керування потоками Codex —
  булеві значення `archived`/`pinned` у передаванні завжди виводяться з
  часової мітки та проставляються на серверному боці, відповідно до семантики Codex `threads.archived_at`
  і серіалізації camelCase. Часові мітки OpenClaw — це мілісекунди епохи,
  тоді як Codex використовує секунди епохи, тому мости конвертують їх на межі
  plugin codex. Codex ще не має API закріплення (лише `thread/archive`/`thread/unarchive`);
  стан закріплення залишається на боці OpenClaw, доки такий API не з’явиться; тоді
  відповідна форма дасть змогу прив’язаним сеансам механічно виконувати round-trip стану закріплення.
- `sessionFile`: необов’язкове явне перевизначення шляху транскрипту
- `chatType`: `direct | group | room` (допомагає інтерфейсам і політиці надсилання)
- `provider`, `subject`, `room`, `space`, `displayName`: метадані для позначення груп/каналів
- Перемикачі:
  - `thinkingLevel`, `verboseLevel`, `reasoningLevel`, `elevatedLevel`
  - `sendPolicy` (перевизначення для окремого сеансу)
- Вибір моделі:
  - `providerOverride`, `modelOverride`, `authProfileOverride`
- Лічильники токенів (best-effort / залежні від провайдера):
  - `inputTokens`, `outputTokens`, `totalTokens`, `contextTokens`
- `compactionCount`: як часто автоматична Compaction завершувалася для цього ключа сеансу
- `memoryFlushAt`: часова мітка останнього скидання пам’яті перед Compaction
- `memoryFlushCompactionCount`: кількість Compaction, коли виконувалося останнє скидання

Сховище безпечно редагувати, але Gateway є джерелом істини: він може перезаписувати або відновлювати записи під час виконання сеансів.

---

## Структура транскрипту (`*.jsonl`)

Транскриптами керує `SessionManager` з `openclaw/plugin-sdk/agent-sessions`.

Файл має формат JSONL:

- Перший рядок: заголовок сеансу (`type: "session"`, містить `id`, `cwd`, `timestamp`, необов’язковий `parentSession`)
- Далі: записи сеансу з `id` + `parentId` (дерево)

Важливі типи записів:

- `message`: повідомлення користувача/асистента/toolResult
- `custom_message`: повідомлення, інжектовані розширенням, які _входять_ у контекст моделі (можуть бути приховані від інтерфейсу)
- `custom`: стан розширення, який _не входить_ у контекст моделі
- `compaction`: збережений підсумок Compaction з `firstKeptEntryId` і `tokensBefore`
- `branch_summary`: збережений підсумок під час навігації гілкою дерева

OpenClaw навмисно **не** «виправляє» транскрипти; Gateway використовує `SessionManager` для їх читання/запису.

---

## Контекстні вікна проти відстежуваних токенів

Мають значення два різні поняття:

1. **Контекстне вікно моделі**: жорстке обмеження для кожної моделі (токени, видимі моделі)
2. **Лічильники сховища сеансів**: ковзні статистики, записані в `sessions.json` (використовуються для /status і панелей)

Якщо ви налаштовуєте ліміти:

- Контекстне вікно береться з каталогу моделей (і може бути перевизначене через конфігурацію).
- `contextTokens` у сховищі — це оцінка/звітне значення під час виконання; не сприймайте його як сувору гарантію.

Докладніше див. [/token-use](/uk/reference/token-use).

---

## Compaction: що це

Compaction підсумовує старішу розмову в збережений запис `compaction` у транскрипті та залишає останні повідомлення без змін.

Після Compaction майбутні ходи бачать:

- Підсумок Compaction
- Повідомлення після `firstKeptEntryId`

Повторне інжектування розділів AGENTS.md після Compaction вмикається явно через
`agents.defaults.compaction.postCompactionSections`; коли не задано або `[]`,
OpenClaw не додає фрагменти AGENTS.md поверх підсумку Compaction.

Compaction є **постійною** (на відміну від очищення сеансів). Див. [/concepts/session-pruning](/uk/concepts/session-pruning).

## Межі фрагментів Compaction і парування інструментів

Коли OpenClaw розбиває довгий транскрипт на фрагменти Compaction, він зберігає
виклики інструментів асистента в парі з відповідними записами `toolResult`.

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

---

## Коли відбувається автоматична Compaction (середовище виконання OpenClaw)

У вбудованому агенті OpenClaw автоматична Compaction запускається у двох випадках:

1. **Відновлення після переповнення**: модель повертає помилку переповнення контексту
   (`request_too_large`, `context length exceeded`, `input exceeds the maximum
number of tokens`, `input token count exceeds the maximum number of input
tokens`, `input is too long for the model`, `ollama error: context length
exceeded` і подібні варіанти у формі провайдера) → compact → повторити.
   Коли провайдер повідомляє спробувану кількість токенів, OpenClaw передає це
   спостережене значення в Compaction відновлення після переповнення. Якщо провайдер підтверджує
   переповнення, але не надає доступної для розбору кількості, OpenClaw передає мінімально
   понадбюджетну синтетичну кількість до рушіїв Compaction і діагностики.
   Якщо відновлення після переповнення все одно не вдається, OpenClaw показує явні настанови
   користувачу та зберігає поточне зіставлення сеансу замість тихої ротації
   ключа сеансу на свіжий ідентифікатор сеансу. Наступний крок контролює оператор:
   повторити повідомлення, виконати `/compact` або виконати `/new`, коли бажаний свіжий сеанс.
2. **Порогове обслуговування**: після успішного ходу, коли:

`contextTokens > contextWindow - reserveTokens`

Де:

- `contextWindow` — контекстне вікно моделі
- `reserveTokens` — запас, зарезервований для промптів + наступного виводу моделі

Це семантика середовища виконання OpenClaw.

OpenClaw також може запускати попередню локальну Compaction перед відкриттям наступного
запуску, коли задано `agents.defaults.compaction.maxActiveTranscriptBytes` і
активний файл транскрипту досягає цього розміру. Це захист за розміром файлу для локальної
вартості повторного відкриття, а не сире архівування: OpenClaw усе одно виконує звичайну семантичну Compaction,
і для цього потрібен `truncateAfterCompaction`, щоб стиснений підсумок міг стати
новим наступником транскрипту.

Для вбудованих запусків OpenClaw, `agents.defaults.compaction.midTurnPrecheck.enabled: true`
додає необов’язковий захист циклу інструментів. Після додавання результату інструмента та перед
наступним викликом моделі OpenClaw оцінює тиск на промпт, використовуючи ту саму логіку
попереднього бюджету, що й на початку ходу. Якщо контекст більше не вміщується, захист
не виконує Compaction всередині хука `transformContext` середовища виконання OpenClaw. Він підіймає структурований
сигнал попередньої перевірки всередині ходу, зупиняє поточне подання промпта та дає
зовнішньому циклу запуску використати наявний шлях відновлення: обрізати завеликі результати інструментів,
коли цього достатньо, або запустити налаштований режим Compaction і повторити. Опція
вимкнена за замовчуванням і працює з режимами Compaction `default` і `safeguard`,
зокрема Compaction safeguard на базі провайдера.
Це незалежно від `maxActiveTranscriptBytes`: захист за розміром у байтах виконується
до відкриття ходу, тоді як попередня перевірка всередині ходу виконується пізніше у вбудованому циклі інструментів OpenClaw
після додавання нових результатів інструментів.

---

## Налаштування Compaction (`reserveTokens`, `keepRecentTokens`)

Налаштування Compaction середовища виконання OpenClaw містяться в налаштуваннях агента:

```json5
{
  compaction: {
    enabled: true,
    reserveTokens: 16384,
    keepRecentTokens: 20000,
  },
}
```

OpenClaw також застосовує безпечну нижню межу для вбудованих запусків:

- Якщо `compaction.reserveTokens < reserveTokensFloor`, OpenClaw підвищує його.
- Типова нижня межа — `20000` токенів.
- Задайте `agents.defaults.compaction.reserveTokensFloor: 0`, щоб вимкнути нижню межу.
- Якщо значення вже вище, OpenClaw залишає його без змін.
- Ручний `/compact` враховує явний `agents.defaults.compaction.keepRecentTokens`
  і зберігає точку відрізання недавнього хвоста середовища виконання OpenClaw. Без явного бюджету збереження
  ручна Compaction залишається жорсткою контрольною точкою, а перебудований контекст починається з
  нового підсумку.
- Задайте `agents.defaults.compaction.midTurnPrecheck.enabled: true`, щоб виконувати
  необов’язкову попередню перевірку циклу інструментів після нових результатів інструментів і перед наступним викликом
  моделі. Це лише тригер; генерація підсумку все одно використовує налаштований
  шлях Compaction. Це незалежно від `maxActiveTranscriptBytes`, який є
  захистом за розміром у байтах активного транскрипту на початку ходу.
- Задайте `agents.defaults.compaction.maxActiveTranscriptBytes` як значення в байтах або
  рядок на кшталт `"20mb"`, щоб виконувати локальну Compaction перед ходом, коли активний
  транскрипт стає великим. Цей захист активний лише тоді, коли також увімкнено
  `truncateAfterCompaction`. Залиште його незаданим або задайте `0`, щоб
  вимкнути.
- Коли `agents.defaults.compaction.truncateAfterCompaction` увімкнено,
  OpenClaw ротирує активний транскрипт у стиснений наступник JSONL після
  Compaction. Дії контрольної точки гілки/відновлення використовують цей стиснений наступник;
  застарілі файли контрольних точок до Compaction залишаються читабельними, доки на них є посилання.

Навіщо: залишити достатній запас для багатоходового «обслуговування» (наприклад, записів пам’яті), перш ніж Compaction стане неминучою.

Реалізація: `applyAgentCompactionSettingsFromConfig()` у `src/agents/agent-settings.ts`
(викликається зі шляхів ходу вбудованого runner і налаштування Compaction).

---

## Підключні провайдери Compaction

Plugins можуть реєструвати провайдера Compaction через `registerCompactionProvider()` в API plugin. Коли `agents.defaults.compaction.provider` задано як ідентифікатор зареєстрованого провайдера, розширення safeguard делегує підсумовування цьому провайдеру замість вбудованого конвеєра `summarizeInStages`.

- `provider`: ідентифікатор зареєстрованого plugin провайдера Compaction. Залиште незаданим для типового підсумовування LLM.
- Задання `provider` примусово вмикає `mode: "safeguard"`.
- Провайдери отримують ті самі інструкції Compaction і політику збереження ідентифікаторів, що й вбудований шлях.
- Safeguard усе одно зберігає контекст суфікса останніх ходів і розділених ходів після виводу провайдера.
- Вбудоване підсумовування safeguard повторно дистилює попередні підсумки з новими повідомленнями
  замість збереження повного попереднього підсумку дослівно.
- Режим Safeguard за замовчуванням вмикає аудити якості підсумку; задайте
  `qualityGuard.enabled: false`, щоб пропустити поведінку повтору за некоректного виводу.
- Якщо провайдер зазнає помилки або повертає порожній результат, OpenClaw автоматично повертається до вбудованого підсумовування LLM.
- Сигнали переривання/тайм-ауту повторно викидаються (не поглинаються), щоб поважати скасування викликачем.

Джерело: `src/plugins/compaction-provider.ts`, `src/agents/agent-hooks/compaction-safeguard.ts`.

---

## Поверхні, видимі користувачу

Ви можете спостерігати Compaction і стан сеансу через:

- `/status` (у будь-якому чат-сеансі)
- `openclaw status` (CLI)
- `openclaw sessions` / `sessions --json`
- Журнали Gateway (`pnpm gateway:watch` або `openclaw logs --follow`): `embedded run auto-compaction start` + `complete`
- Детальний режим: `🧹 Auto-compaction complete` + кількість Compaction

---

## Тихе обслуговування (`NO_REPLY`)

OpenClaw підтримує «тихі» ходи для фонових завдань, де користувач не повинен бачити проміжний вивід.

Конвенція:

- Асистент починає свій вивід із точного мовчазного токена `NO_REPLY` /
  `no_reply`, щоб позначити "не доставляти відповідь користувачу".
- OpenClaw вилучає/пригнічує це на рівні доставки.
- Точне пригнічення мовчазного токена не враховує регістр, тож `NO_REPLY` і
  `no_reply` обидва зараховуються, коли весь payload є лише мовчазним токеном.
- Це призначено лише для справді фонових ходів без доставки; це не скорочення для
  звичайних дієвих запитів користувача.

Починаючи з `2026.1.10`, OpenClaw також пригнічує **потокове передавання чернетки/набору тексту**, коли
частковий фрагмент починається з `NO_REPLY`, тому мовчазні операції не розкривають частковий
вивід посеред ходу.

---

## Перед-Compaction "скидання пам'яті" (реалізовано)

Мета: перш ніж відбудеться автоматична Compaction, запустити мовчазний агентний хід, який записує довговічний
стан на диск (наприклад, `memory/YYYY-MM-DD.md` у робочому просторі агента), щоб Compaction не могла
стерти критичний контекст.

OpenClaw використовує підхід **скидання перед порогом**:

1. Відстежуйте використання контексту сесії.
2. Коли воно перетинає "м'який поріг" (нижче порогу Compaction середовища виконання OpenClaw), запустіть мовчазну
   директиву "запиши пам'ять зараз" для агента.
3. Використайте точний мовчазний токен `NO_REPLY` / `no_reply`, щоб користувач
   нічого не бачив.

Конфігурація (`agents.defaults.compaction.memoryFlush`):

- `enabled` (за замовчуванням: `true`)
- `model` (необов'язкове точне перевизначення провайдера/моделі для ходу скидання, наприклад `ollama/qwen3:8b`)
- `softThresholdTokens` (за замовчуванням: `4000`)
- `prompt` (повідомлення користувача для ходу скидання)
- `systemPrompt` (додатковий системний prompt, доданий для ходу скидання)

Примітки:

- Стандартний prompt/системний prompt містять підказку `NO_REPLY` для пригнічення
  доставки.
- Коли `model` задано, хід скидання використовує цю модель без успадкування
  активного ланцюжка fallback сесії, тому локальне лише службове обслуговування не буде мовчки
  fallback до платної розмовної моделі.
- Скидання виконується один раз на цикл Compaction (відстежується в `sessions.json`).
- Скидання виконується лише для вбудованих сесій OpenClaw (бекенди CLI пропускають його).
- Скидання пропускається, коли робочий простір сесії доступний лише для читання (`workspaceAccess: "ro"` або `"none"`).
- Див. [Пам'ять](/uk/concepts/memory) щодо структури файлів робочого простору та шаблонів запису.

OpenClaw також надає hook `session_before_compact` в API розширень, але логіка
скидання OpenClaw наразі живе на боці Gateway.

---

## Контрольний список усунення несправностей

- Неправильний ключ сесії? Почніть із [/concepts/session](/uk/concepts/session) і підтвердьте `sessionKey` у `/status`.
- Невідповідність сховища й transcript? Підтвердьте хост Gateway і шлях сховища з `openclaw status`.
- Спам Compaction? Перевірте:
  - вікно контексту моделі (замале)
  - налаштування Compaction (`reserveTokens` завелике для вікна моделі може спричинити ранішу Compaction)
  - розростання результатів інструментів: увімкніть/налаштуйте обрізання сесії
- Мовчазні ходи протікають? Підтвердьте, що відповідь починається з `NO_REPLY` (точний токен без урахування регістру) і що ви використовуєте збірку, яка містить виправлення пригнічення потокового передавання.

## Пов'язане

- [Керування сесіями](/uk/concepts/session)
- [Обрізання сесії](/uk/concepts/session-pruning)
- [Рушій контексту](/uk/concepts/context-engine)