Manual Versus Automatic: When to Compress Yourself

Introduction

Hermes will compress automatically when the threshold trips. You can also compress yourself with /compress, on demand, at any point. The two modes coexist for a reason: automatic compression handles the general case, but it is reactive. Manual compression lets you compress proactively, at a moment that makes sense for the workflow.

Key Concepts

• Automatic compression: Hermes triggers it when the buffer crosses the threshold (default 0.50).
• Manual compression: You run /compress at any time, regardless of the threshold.
• Phase boundaries: Natural moments to compress (after finishing a sub-task, before starting a new investigation, after a long tool output).
• Cost trade-off: Compressing earlier preserves headroom; compressing later preserves detail.

Real World Context

A developer finishes a long investigation that produced a 12K-token tool output, then prepares to switch to a fresh task in the same session. They run /compress proactively before the next turn. The investigation summary stays, the noisy tool output collapses, and the new task starts with most of the budget free. Had they waited for automatic compression, the next task would have begun in a more crowded session.

Deep Dive

When automatic compression is the right tool:

• The session is one continuous task and you do not have a natural pause point.
• You are not paying close attention to the status bar.
• You trust Hermes to pick a reasonable moment.

When manual compression is the right tool:

• You just finished a sub-task and are about to start a fresh one.
• A tool produced an enormous output that you no longer need verbatim.
• You want to compress before a large paste so the paste does not push the buffer into hard-cap territory.
• You are about to ask a question that depends on a clean attention budget.

The /compress command runs the same compression operation that the automatic trigger would invoke. It does not delete anything from the SQLite session log; the on-disk record is preserved and searchable. What it does is rewrite the in-memory buffer to a summary-plus-recent-turns shape.

A pattern worth noticing: when you find yourself running /compress at predictable points ("every time I finish a debugging session", "every time I paste a log"), you are spotting structure that your session lacks. Often the better answer is to wrap that sub-task in a delegate (using delegate_task or a subagent) so its tokens never enter the parent session in the first place. Compression is a remediation; structure is a prevention.

Common Pitfalls

1. Treating /compress as a synonym for /clear: They are different. /compress preserves the summarized history; clearing or restarting drops it.
2. Compressing immediately before a critical follow-up: If you genuinely need verbatim recall of the last few turns, compression may collapse them into a summary. Recent turns are usually preserved verbatim, but very large tool outputs sometimes get summarized.

Best Practices

1. Compress at phase boundaries, not threshold boundaries: Once you internalize when you want to compress, you stop relying on the auto-trigger.
2. For very long sessions, structure work into delegated sub-tasks: That way each sub-task has its own context and the parent stays lean.

Summary

• Automatic compression handles the general case; manual /compress lets you compress proactively.
• Manual compression is most useful at phase boundaries: after finishing a sub-task or before a big paste.
• /compress rewrites the live buffer but does not delete the on-disk session record.
• When you find yourself compressing repeatedly at predictable points, consider restructuring with delegated sub-tasks instead.

# Inside Hermes:
> /compress
Compressing conversation buffer...
  Before: 32,400 tokens (78% of context)
  After:   9,200 tokens (22% of context)
  Recent 6 turns preserved verbatim. 18 earlier turns summarized.
>