# 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
```bash
# 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>`.