Measure and Reduce the Hermes System Prompt

Every Hermes session starts with a system prompt assembled from platform guidance, the skills index, memory, user profile, project context, and tool schemas. A capable model can have a large context window and still perform poorly when permanent instructions consume space that should hold the task, tool results, and conversation history.

Official documentation: https://hermes-agent.nousresearch.com/docs/reference/cli-commands#hermes-prompt-size

Measure before removing anything

Run hermes prompt-size for a human-readable breakdown. Add --platform telegram or another platform to simulate a gateway surface, and use --json when a script or regression check needs structured output. The command runs offline; it measures assembled prompt components without sending private content to a model.

Look for disproportionate categories rather than chasing a universal byte target. A large tool schema can be justified for an operations session but wasteful in a narrow support bot. A long skills index may indicate too many optional skills enabled. Durable memory should contain compact stable facts, not historical logs.

Reduction checklist

Capture a baseline report for the target platform.
Disable toolsets the workflow cannot use.
Remove or archive duplicate and stale skills.
Keep memory declarative, compact, and durable.
Move project-specific procedures into the project context.
Avoid loading several overlapping umbrella skills.
Re-run the report after each meaningful change.
Start a fresh session before evaluating behavior.

Preserve the right information

Do not solve prompt pressure by deleting safety rules, approval boundaries, or the one skill that defines the workflow. Prefer removing redundancy and narrowing capability. The goal is not the smallest prompt; it is the smallest prompt that still expresses the required authority, context, and quality contract.

Common pitfalls

Comparing CLI and gateway reports without matching the platform.
Assuming context compression shrinks the fixed system prompt.
Keeping raw task logs in durable memory.
Enabling every tool “just in case.”
Measuring bytes once and never checking after skill or plugin growth.
Judging improvement inside an old session whose prompt snapshot is already fixed.

Verification steps

Save the baseline --json output.
Make one scoped reduction.
Generate a second report for the same platform.
Confirm the intended capability and safety instructions remain present.
Start a fresh session and complete a representative task.
Compare context-pressure warnings and tool selection with the baseline.