Read-only configuration audit

Two stale defaults are holding Hermes back.

A plain-English review of what should change, what should stay, and what still needs a decision.

✓ No configuration or services changed
27 August 2026Hermes configuration audit
Executive summary

The short version

Change

Unset two stale pins

  • agent.max_turns: 90
  • tools.tool_search.threshold_pct: 10

Unset them so Hermes inherits current and future defaults.

Keep

Leave the rest alone

  • Compression policy
  • Gateway and restart safety
  • Clarify timeout
  • Platform and provider choices
Recommendation2 / 10
Finding 01

agent.max_turns

Explicit old value
90

A finite setup-era cap. Complex tasks can be cut off before completion.

→
Current default
∞

Unlimited by default. Hermes asks for wrap-up if a deliberate finite cap is reached.

Recommended action: unset3 / 10
Why it is stale

The default evolved. Your pin did not.

90

Historical default

The interactive wizard still presents this as normal.

500

Raised limit

Upstream found 90 too restrictive for complex work.

∞

Current default

Caps caused silent mid-task truncation, so unlimited became standard.

Benefit: fewer incomplete tasks.   Downside: a genuine loop may consume more calls before another guardrail stops it.

No migration overwrites explicit user limits4 / 10
Finding 02

Tool disclosure budget

Your explicit value
10%

More context can be consumed listing deferred MCP and plugin tools.

→
Current source default
5%

A tighter catalog budget leaves more room for the actual conversation and task.

Recommended action: unset threshold_pct5 / 10
Keep

Current, useful settings

Clarify timeout · 1 hour

Good for mobile users who step away before answering.

Gateway inactivity · 30 min

Progress keeps a turn alive; inactivity eventually frees it.

Restart drain · immediate

Avoids stale-lock and systemd restart crash loops.

Cron drain · 30 sec

Gives scheduled work a bounded chance to finish.

These match current defaults6 / 10
Compression

No stale blocker found

Already current
  • Threshold: 0.50
  • Target ratio: 0.20
  • Protected recent messages: 20
  • Protected opening messages: 3
Important improvement inherited

5,000-message hygiene valve

You do not pin the obsolete 400-message limit, so the newer safety value flows through automatically.

Note: models below 512K context get an effective 0.75 compression-threshold floor. The wizard does not explain this clearly.

Recommendation: no change7 / 10
Optional decision

Delegation limits

250 iterations

Matches today’s default

Unset to inherit future tuning, or keep as a deliberate subagent cost cap.

10 concurrent children

Matches today’s default

Unset to inherit future throughput changes, or keep to cap concurrency and spend.

My recommendation: leave both alone in the first pass. They are not hurting current behaviour.

Decision needed later8 / 10
Toolsets and runtime

Keep the custom parts

Platform toolsets

Keep. They define what Telegram, CLI and other surfaces can access.

Security and providers

Keep. These are intentional safety and platform-specific choices.

Code execution limits

Keep for now. They are useful safety bounds and were not proven stale.

Customized ≠ stale9 / 10
Proposed next step

Approve two removals. Nothing else.

agent:
  # remove max_turns: 90

tools:
  tool_search:
    # remove threshold_pct: 10
  1. Back up config.yaml.
  2. Remove only those two keys.
  3. Validate YAML and resolved defaults.
  4. Restart only after separate approval.

No changes have been made. This deck is a proposal only.

Conservative recommendation10 / 10