Emergency Session Cleanup — 9.9MB → 0.18MB

2026-02-16 | Joe's Tech Blog #039

Crisis Signal

This morning, the main agent suddenly became extremely sluggish. Response latency spiked from a normal 2–3 seconds to over 15 seconds, and sometimes it just timed out without responding at all.

My first instinct was a network issue, but ping latency was normal. Then I checked server load — CPU and memory were both fine. Finally, I checked the session file size, and the moment I saw the number, I froze:

main.session.json — 9.9MB

Nearly 10MB of session file. Keep in mind that every time the agent responds, the entire session needs to be loaded as context and sent to the LLM. 9.9MB of context — no wonder it was painfully slow.

Why Sessions Bloat

OpenClaw's session files record the complete conversation history between the agent and user. Every message, every tool call's input and output, every thought process — all saved in JSON format.

During normal use, sessions grow continuously with ongoing conversations. Without a periodic cleanup mechanism, they'll balloon out of control within a few weeks.

My main agent had been running for about two weeks without cleanup, accumulating 4,040 records. Many of these were large blocks of code output, log dumps, and file content reads — utterly worthless as historical context, yet taking up enormous amounts of space.

The Cleanup Operation

PC-A (Main Machine, 192.168.x.x)

This was the most urgent — the main agent runs on this machine.

Before cleanup:

main.session.json     — 9.2MB, 4,040 records

Cleanup strategy: Keep the most recent 100 conversation records, delete everything else. Additionally, slim down the retained records — remove detailed tool call outputs, keeping only summaries.

# Back up first!
cp main.session.json main.session.json.bak-20260216

Run the cleanup script
node scripts/session-cleanup.js --keep 100 --slim

After cleanup:

main.session.json     — 0.18MB, 101 records

From 9.2MB down to 0.18MB — a 98% reduction.

The effect was immediate — agent response speed returned to under 2 seconds. It was like freeing up 90% of a lagging computer's disk space; everything became smooth again.

T440 (Work Server, 192.168.x.x)

T440 has 15 agents, and the session situation was equally concerning:

Before cleanup:
techsfree-web.session.json    — 2.9MB
learning.session.json         — 1.8MB
docomo-pj.session.json        — 1.2MB
health.session.json           — 0.9MB
... (remaining 11: 0.1-0.5MB)

After cleanup:
techsfree-web.session.json    — 152KB
learning.session.json         — 98KB
docomo-pj.session.json        — 87KB
health.session.json           — 65KB
... (remaining 11: 10-30KB)

techsfree-web was the largest because that agent handles website development tasks and frequently needs to read and output large code files.

Backup Protection

Before performing any cleanup, I backed up all session files larger than 1MB:

# On T440
mkdir -p /home/linou/backups/sessions/20260216
for f in $(find ~/.openclaw -name "*.session.json" -size +1M); do
  cp "$f" /home/linou/backups/sessions/20260216/
  echo "Backed up: $f ($(du -h "$f" | cut -f1))"
done

A total of 6 files were backed up, approximately 16MB in total. These backups serve several purposes:

• Rollback if agent behavior becomes abnormal after cleanup
• Post-analysis to identify which types of conversations consume the most space
• Long-term archival (though they'll most likely never be needed)

Establishing a Scheduled Cleanup Mechanism

This emergency cleanup made me realize that waiting for problems to occur before manually cleaning up is unacceptable. An automated scheduled cleanup mechanism is essential.

I designed a simple cron job:

# Run session cleanup every Sunday at 3:00 AM
0 3   0 /opt/ocm/scripts/auto-session-cleanup.sh >> /var/log/ocm-cleanup.log 2>&1

The cleanup script logic:

1. Scan all session files

2. Files over 2MB: Keep the most recent 200 records, delete the rest

3. Files over 5MB: Keep the most recent 100 records, plus additional slim processing (remove tool output details)

4. Files over 10MB: Keep the most recent 50 records, aggressive slim processing

5. Automatic backup before each cleanup

6. Send a Telegram notification after cleanup completes

Notification example:

🧹 Session Cleanup Complete
📅 2026-02-16 03:00

Cleaned 3 files:
  main.session.json: 4.2MB → 0.3MB
  techsfree-web: 1.8MB → 0.1MB  
  learning: 1.1MB → 0.08MB

💾 Backed up to: /backups/sessions/20260216/

Reflection

A 9.9MB session file is a textbook "boiling frog" problem. It grows a little each day, always seeming within normal range, until one day it suddenly crosses a threshold and the system breaks down.

Core lesson: Any data that grows continuously must have a corresponding cleanup strategy. Not "we'll deal with it later" — it should be in place from day one.

Session management may seem like a small thing, but in LLM applications, context size directly determines response quality and speed. Keeping sessions lean means keeping agents efficient. This may be one of the most overlooked yet most important routine tasks in operating AI systems.