hermes-skills/skills/devops/model-failover-and-credit-tracking/references/delegation-config-restart-trap.md

Delegation Config Restart Trap — Jul 9, 2026

The Problem

Subagents kept failing with HTTP 402 (OpenRouter insufficient credits) even after:

1. Changing delegation.model from openrouter/anthropic/claude-opus-4.8 to claude-opus-4-8
2. Changing delegation.provider to admin-ai
3. Verifying the model name was correct via curl directly against admin-ai API

Root cause: The running Hermes gateway process (PID 2757853) cached the old delegation config at startup. The hermes config set commands only updated the config file on disk. Subagents spawned from the running gateway still used the old OpenRouter-routed model string.

The Fix

# Stop the running gateway first — must be done from OUTSIDE the gateway session
# (e.g. via SSH, or from a separate terminal, or from host CLI session)
hermes gateway stop
# Or kill the PID directly:
kill 2757853
# Then restart:
systemctl start hermes
# Or:
hermes gateway run --replace

Cannot restart from inside the gateway: hermes gateway restart from inside the Telegram session kills the process before the command completes (SIGTERM propagates to child processes). The error message: "Blocked: cannot restart or stop the gateway from inside the gateway process."

Symptoms

• hermes config get delegation.model shows the NEW value (config file updated)
• But subagents still use the OLD model name
• Subagents fail with HTTP 402: openrouter...Insufficient credits
• The running gateway process (check via ps aux | grep hermes.*gateway) has a start time before the config change

Prevention

• After ANY hermes config set for delegation.*, note whether the gateway needs a restart
• Verification: check the gateway PID's start time vs the config file's modification time
• If config modified after gateway start → restart needed
• For known-good behavior: use deepseek-chat (the conversation model) as delegation model too — it doesn't go through OpenRouter and doesn't need config changes

Effective delegation state (Jul 9, 2026, 10:30 PM)

Despite config file having model: deepseek-chat, the running gateway still used the cached old config. All subagents dispatched tonight actually ran on deepseek-chat because the config was changed FROM that value first (was deepseek-chat → changed to openrouter/opus failed → changed back). The initial successful deepseek-chat dispatches worked before the first config change attempt.

Re-confirmed Jul 10, 2026

Same pattern recurred when changing delegation model from gemini-pro-latest to deepseek-v4-pro. Config confirmed correct, but subagents kept dispatching on Gemini until gateway was restarted. This trap is persistent — it will hit every model change regardless of how carefully the config is verified.

Cron job drift is a related symptom: When the conversation model changed from deepseek-chat to deepseek-v4-pro, unpinned cron jobs refused to run with a safety warning: "global inference config drifted since this job was created." Fix: pin each job explicitly with hermes cron update <id> --model <model> --provider <provider>.