Issue Station
Sign In
Tools hereToolbox

hermes - 💡(How to fix) Fix [Feature] command-type-aware terminal timeouts with adaptive backoff [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#12619•Fetched 2026-04-20 12:17:54
View on GitHub
Comments
0
Participants
1
Timeline
0
Reactions
0
Author
apoapostolovapoapostolov
Participants
apoapostolovapoapostolov
RAW_BUFFERClick to expand / collapse

Problem

Hermes currently uses a single foreground terminal timeout, which makes short-running shell commands feel sluggish when they finish quickly but still sit behind a long wait window. In practice, simple bash commands can complete in a few seconds, but the agent still waits up to the configured timeout path instead of adapting to the command type.

Request

Add command-type-aware terminal timeouts with adaptive backoff.

Suggested behavior:

  • Use a short default timeout for basic shell commands.
  • Use longer defaults for heavier command classes like installs, builds, test suites, package managers, and network-bound commands.
  • If a command does not finish in the initial window, progressively increase the wait budget in steps until a configured maximum is reached.
  • Once the maximum is exceeded, treat the command as stalled and cancel it.

Why this helps

  • Fast commands return quickly without waiting for the full timeout.
  • Heavy commands still get enough time to finish.
  • Stalled commands do not hang indefinitely.
  • The timeout policy becomes more aligned with real command behavior instead of one global static number.

Possible implementation shape

  • Add command classification based on the command string.
  • Apply per-class timeout defaults and a max cap.
  • Keep the current timeout as a fallback for unclassified commands.
  • Surface the selected timeout and any backoff escalation in tool output/logs for debugging.

Acceptance criteria

  • Short commands like git status, rg, or ls return promptly.
  • Heavier commands get a larger initial budget.
  • Hermes escalates wait time in steps when a command is still running.
  • A stalled command is eventually canceled at a configured maximum.

extent analysis

TL;DR

Implement command-type-aware terminal timeouts with adaptive backoff to improve responsiveness for short-running shell commands.

Guidance

  • Classify commands based on their type (e.g., basic shell commands, installs, builds, test suites, package managers, network-bound commands) to apply different default timeouts.
  • Introduce a progressive backoff mechanism to increase the wait budget in steps until a configured maximum is reached for commands that do not finish within the initial window.
  • Surface the selected timeout and any backoff escalation in tool output/logs for debugging purposes.
  • Ensure that short commands like git status, rg, or ls return promptly, while heavier commands receive a larger initial budget.

Example

# Pseudocode example of command classification and timeout application
command_classes = {
    'basic': 5,  # seconds
    'install': 60,
    'build': 120,
    'test': 300,
    'package_manager': 180,
    'network_bound': 240
}

def get_timeout(command):
    for class_name, timeout in command_classes.items():
        if class_name in command:
            return timeout
    return 30  # default fallback timeout

def execute_command(command):
    initial_timeout = get_timeout(command)
    max_timeout = 600  # configured maximum
    backoff_steps = [initial_timeout, initial_timeout * 2, initial_timeout * 4]
    current_timeout = initial_timeout

    while current_timeout <= max_timeout:
        # Execute command with current timeout
        if command_finished:
            break
        # Escalate timeout using backoff steps
        current_timeout = min(current_timeout * 2, max_timeout)
    # Cancel command if still running after max timeout

Notes

The implementation details may vary depending on the specific requirements and constraints of the Hermes system. The example provided is a simplified illustration of the concept.

Recommendation

Apply workaround by introducing command-type-aware terminal timeouts with adaptive backoff, as this approach aligns with the suggested behavior and acceptance criteria.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#output truncation#response parsing#generation error#database connection#vector store

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING