Conclusion first

I cut the "fixed injection" tokens that Hermes Agent sends to the model on every request from 17,371 to 10,967 (about a 37% reduction). Meanwhile, the absolute cap on injected history is decided not by the context setting but by the compaction setting (threshold x context_length). In other words, tightening the parameter that trims old history does not change the cap itself. In usage dominated by one-off questions, the threshold is never actually reached, so there is no felt effect. The real savings come from shrinking the fixed injection.

Measurement environment: operator's local Hermes Agent, tokenizer cl100k_base, measured on the operator's setup.

1. Composition of the fixed injection (Ground Truth)

Hermes resends five fixed blocks every turn.

2. What was changed

2-1. Disabling skills

I cleaned up unused skills based on usage data (skills/.usage.json).

• skills.disabled: 55 to 79 (24 added)
• Added: 15 unused built-ins, 5 unused custom, 4 code/debugging skills
• The protected built-in plan was excluded (driven by a slash command)
• Result: injected skills 32 (1,296 tok) to 8 (661 tok)

2-2. Shrinking the tool schema

Individual tools cannot be disabled, only at the toolset level.

• agent.disabled_toolsets: [browser] to [browser, session_search, vision, video, clarify, tts, todo]
• Result: injected tools 20 (10,197 tok) to 15 (7,111 tok)
• Vision/video analysis is delegated to a cloud model through the auxiliary setting, so attached image handling is unaffected

2-3. SOUL.md and memory diet

• Rewrote SOUL.md as "English rules + Korean comments." The character count grew, but tokens fell from 4,889 to 2,357 (about 52%)
• Abolished low-frequency forced formats (fixed 20-35 line command explanations, etc.), removed duplicate paragraphs, removed references to nonexistent files/skills
• MEMORY.md and USER.md were also converted to English

Korean has poor tokenizer efficiency (about 4 chars/token for English vs about 1.1 chars/token for Korean). Rewriting rules in English while keeping the final-answer language instruction is favorable for savings.

3. History storage structure and the relation to the absolute cap

3-1. Store everything, inject conditionally

• Storage: all user/assistant/tool messages are stored in the DB (session retention 30 days). Chat input and system prompts are stored separately too.
• Injection: every turn resends the history so far as-is. It is trimmed only under the two conditions below.

3-2. Where the absolute cap is decided

injected history cap = context_length x compression.threshold
                     = 65,536 x 0.75
                     = 49,152 tokens

The key point is that lowering proactive_prune_tokens does not change the total cap. This parameter only removes tool results; user/assistant bodies keep accumulating and eventually fill up to the threshold point.

3-3. Levers that reduce the total, and their limits

The lever that lowers the total cap is lowering threshold (and target_ratio). However:

• Compaction does not delete the conversation but regenerates it as a summary, so the total content does not change.
• More frequent compaction means more summary calls and broken prompt-cache, which can actually increase cost.
• So in usage dominated by one-off questions, the threshold (24k/49k) is never reached and these optimizations are meaningless.

In conclusion, the real savings come from shrinking the fixed injection (-6,404 tokens per request), and keeping the history-related compaction settings at their defaults is reasonable.

4. Measured history values

For one session in the operator's environment:

History is stored as user/assistant/tool messages in separate rows, and a turn that uses a tool is recorded as a 3-row set (assistant tool_calls, then tool result, then assistant reply).

5. Side cleanups

• state.db conversation history purge: 3.2M to 2.05M (kept a backup)
• Log truncate: 2.78M to 16K
• Deleted the skills index cache so it is regenerated on the next run

6. Summary

• Savings per request: fixed injection -6,404 tokens (about 37%)
• History: store everything, injection cap fixed by context_length x threshold
• proactive_prune_tokens is not about the total but the "starting point for removing tool results"
• In one-off usage there is no felt effect from history compaction optimization
• In the end, reducing "what and how often you send" (the fixed injection) is the certain saving