Feature: auto-scale context-dependent config from active model context

[stefanpieter]

Problem or Use Case

Hermes currently requires users to manually tune configuration when they select a large-context model. The configuration guide documents larger values for the tool-output truncation limits:

https://hermes-agent.nousresearch.com/docs/user-guide/configuration#tool-output-truncation-limits

That manual step is easy to miss, and it creates two failure modes:

• Large-context models keep conservative/small tool-output limits, causing unnecessary truncation, persisted-output indirection, extra reads, and degraded IDE/agent workflows.
• Users can later switch to a smaller-context model while stale large-context settings remain, increasing the chance of context overflow, excessive compression, or provider rejection.

The underlying model context window is not static either. Provider catalogs and model metadata can change over time, so any config that is derived from model context can become stale even if the user never edits config.yaml.

This is related to existing context/config issues such as context-length mismatch warnings and stale compression settings, but the request here is broader: context-dependent configuration should be automatically derived from the resolved model context and kept in sync.

Proposed Solution

Add an automatic model-context-derived configuration layer for every Hermes setting whose safe/default value depends on the active model context window.

Suggested behavior:

1. Resolve the active model context window during setup, model selection/switching, and session startup.

   • Use the best available source: live provider catalog where available, models.dev/provider metadata, configured model.context_length, or an explicit user override.
   • Record the metadata source and timestamp.

2. Confirm and apply recommended context-derived settings automatically.

   • During setup/model switch, show a concise confirmation such as:
     • Detected gpt-5.5 context: 1,050,000 tokens from OpenAI Codex catalog
     • Applying large-context tool-output and compression defaults
   • Avoid forcing users to manually copy the docs example into config.yaml.

3. Treat context-derived settings as auto by default, while preserving explicit user overrides.

   • Do not overwrite values the user deliberately pinned.
   • Expose whether each value is auto, computed, or manual override in hermes config, hermes doctor/config check, and dashboard/config UI if applicable.

4. Recompute when the model or model metadata changes.

   • If the model changes from small → large context, raise relevant limits automatically.
   • If the model changes from large → small context, lower relevant limits or warn before starting a session that would likely overflow.
   • If the provider updates a model's context length, refresh after a cache TTL / on startup / during hermes config check and adjust derived settings.

5. Centralize the derivation logic so all context-sensitive knobs share one source of truth.

Examples of settings that should be considered for automatic scaling:

• model.context_length / runtime context resolution
• file_read_max_chars
• tool_output.max_bytes
• tool_output.max_lines
• tool_output.max_line_length
• tool_output.code_execution_stdout_bytes
• tool_output.browser_snapshot_chars
• tool_output.result_persist_threshold_chars
• tool_output.turn_budget_chars
• tool_output.preview_chars
• compression thresholds, summary/tail budgets, and related context-management limits
• any future setting whose safe default is a function of model context size

Possible config shape:

model_context_tuning:
  mode: auto        # auto | warn | manual
  refresh: true
  refresh_ttl_hours: 24
  preserve_manual_overrides: true

Or allow each context-derived setting to accept auto:

tool_output:
  max_bytes: auto
  turn_budget_chars: auto
  result_persist_threshold_chars: auto

Alternatives Considered

• Keep the docs-only/manual approach. This works for expert users, but it is fragile and easy to forget during setup or model switching.
• Add only a one-time setup wizard prompt. Better than manual docs, but still becomes stale when provider metadata changes or the user switches models.
• Use static model tables only. Better than nothing, but live provider/catalog metadata should take precedence where available.

Feature Type

Configuration option; performance / reliability.

Scope

Large (central config resolver plus setup/model-switch/runtime integration), though it could be phased in by starting with tool-output truncation limits and compression budgets.

Acceptance Criteria

• Fresh setup with a large-context model automatically applies suitable context-derived tool-output and compression defaults without manual config.yaml edits.
• Switching models recomputes context-derived settings or warns if manual overrides are stale/unsafe.
• Provider/model context updates are detected via live metadata or cache refresh and reflected automatically.
• Manual user overrides are preserved and clearly distinguished from auto-computed values.
• hermes config check / hermes doctor reports the active model context, metadata source, and whether context-derived settings are current.
• Tests cover small-context, large-context, model-switch, stale-metadata, and manual-override cases.

[stefanpieter]

Follow-up suggestion: expose the auto-scaling behavior as a simple user-facing preset/slider in the dashboard and setup/model-switch flows.

Proposed UX:

model_context_tuning:
  mode: auto
  profile: normal      # normal | aggressive | wild

Dashboard UI could show:

• Normal: conservative large-context use. Keeps plenty of reasoning/output headroom and limits noisy tool dumps.
• Aggressive: uses more of the available context for file reads, terminal output, browser snapshots, and tool-result previews.
• Wild: maximum-context exploration mode for trusted local workflows; warns about cost/latency/noise and possible overflow when switching back to small-context models.

A concrete derivation model could compute settings as bounded percentages of the resolved context window, with hard caps per setting. Example categories:

• file read budget: file_read_max_chars
• terminal/tool output caps: tool_output.max_bytes, tool_output.max_lines, max_line_length
• code execution capture: stdout/stderr caps
• browser snapshot caps
• large-result persistence threshold and per-turn budget
• compression threshold/protected tail budget
• agent/delegation iteration ceilings, if desired

The UI should make it clear which values are:

• auto-computed from the current model context
• preset-derived (normal, aggressive, wild)
• manually overridden by the user

This would give non-expert users a safe one-click path while still preserving explicit power-user overrides in config.yaml.