vault-sync: 2026-09-15 12:00 (jimmy)

This commit is contained in:
jimmy
2026-09-15 12:00:07 -07:00
parent 59c599843f
commit 80ec1ffcf1
6 changed files with 619 additions and 5 deletions
@@ -2020,3 +2020,77 @@ No actions taken. The bottleneck is replication, not thought — and S1 remains
Standing by.
## 20260914-134349 session 20260913_150822_1fcc5d08
**user:** Testing
**assistant:** Live. Channel OK. State unchanged: RC2 waiting on S1, no actions pending.
## 20260914-134522 session 20260913_150822_1fcc5d08
**user:** Analyze this and explain how OpenRouter is disabled
Cronjob Response: hermes nightly update
(job_id: 104ee603fd46)
-------------
⚠️ Cron 'hermes nightly update' failed: provider 'openrouter' is disabled in config (providers.openrouter.enabled: false)
This job has failed 4 runs in a row — worth a review. Fix its prompt/config, or pause it with hermes cron pause hermes nightly update (resume/remove also available) to stop the noise.
To stop or manage this job, send me a new message (e.g. "stop reminder hermes nightly update").
**assistant:** Complete picture. Full analysis:
**What's happening — two independent changes collided:**
The job `hermes nightly update` (id `104ee603fd46`, runs daily 03:00, delivers to Telegram) has a **`provider_snapshot: "openrouter"`** — it was created pinned to the OpenRouter provider with model `deepseek/deepseek-v4-flash-0731`. Since it has no explicit `provider:`/`model:` of its own, the scheduler resolves the run through that frozen snapshot. OpenRouter has since been disabled in the jimmy profile config, so every run dies in `runtime_provider.py:829` with `ValueError: provider 'openrouter' is disabled in config` — before the agent even starts.
That's why it's the **same error 4 runs straight** (failure streak: 4, every run since the disable, next attempt tomorrow 03:00).
**How OpenRouter is disabled — actually three layers, not one:**
1. **Native provider disabled:** `config.yaml` `providers.openrouter.enabled: false` — hard kill. This is the line the traceback reads.
2. **Model catalog exclusion:** `model_catalog.excluded_providers: [openrouter, nvidia]` — OpenRouter's models won't even appear in discovery/catalog lists.
3. **Model wiring bypasses it entirely:** the aliases point at `custom:omniroute/...`, `custom:or/...`, `custom:routeapi/...` — and the live provider is `or` (a local passthrough to `openrouter.ai/api/v1` with `OPENROUTER_API_KEY`) or `omniroute` (local proxy at `127.0.0.1:20128`) or `routeapi`. So OpenRouter as a *provider object* is off; the same upstream
## 20260914-135345 session cron_104ee603fd46_20260914_065238
**user:** [IMPORTANT: You are running as a scheduled cron job. DELIVERY: Your final response will be automatically delivered to the user — do NOT use send_message or try to deliver the output yourself. Just produce your report/output as your final response and the system handles the rest. SILENT: If there is genuinely nothing new to report, respond with exactly "[SILENT]" (nothing else) to suppress delivery. Never combine [SILENT] with content — either report your findings normally, or say [SILENT] and nothing more.]
Run Hermes Agent's self-update: execute `hermes update --yes` via the terminal tool (background if it takes long; wait for it to finish and capture its exit code and output). Report the result concisely in plain text — whether an update was applied or already up-to-date, the git/branch info, whether dependencies reinstalled cleanly, and the new version if changed. If the command fails, report the exact error and exit code. Keep the final response to a short factual summary.
**assistant:** Update blocked — could not execute `hermes update` to completion. The command was intercepted by an approval gate and never actually ran.
**Why:** `hermes update` matches the approval policy "restarts gateway, kills running agents" and requires interactive approval. This is an unattended cron run with no operator present to grant it, so the command returned `pending_approval` exit -1 rather than executing. (I did not bypass the gate, since the standing rule forbids acting without approval.)
**Live state (verified via git, not the blocked command):**
- Install: git method at `C:\Users\fight\AppData\Local\hermes\hermes-agent`
- Current local: `ee7fc3bc` on `main` (+1 carried commit) — Hermes Agent v0.21.1 (2026.9.7)
- `hermes --version` reports **1527 commits behind** → update available
- Remote `origin/main` head after fetch: `743140cd82 feat(gemini): …parametersJsonSchema`
- Dependencies: not reinstalled (no update ran)
**Net:** No update was applied. To complete it, run `hermes update --yes` from an interactive session and approve the restart prompt, or whitelist the `hermes update` pattern for allowed commands. Exit code of the actual update: N/A (never started).
## 20260914-135517 session 20260913_150822_1fcc5d08
**user:** I don’t want the Jimmy profile to have open router disabled. I never asked for that and I don’t want that.
**assistant:** Fixed, verified, and the failure streak is broken. Report:
**Root cause — how it got disabled (evidence, not narrative):**
- All config backups Sep 3 → Sep 10 10:29 contain **no** `openrouter:` provider block at all. The stub — `openrouter: enabled: false` with nothing else, plus `model_catalog.excluded_providers: [openrouter, nvidia]` — first appears **between Sep 10 10:29 and Sep 11 03:00**.
- That window is exactly the model-routing migration: Sep-10/12 sessions were reworking providers (creating `or:` as the OpenRouter passthrough, adding routeapi/omniroute, setting default to routeapi). The stub shape is precisely what a `hermes config set providers.openrouter.enabled false` writes — the disable was collateral of that migration, not a separate decision you made. I did not recover the exact command/agent that wrote it; the timeline and mechanism are confirmed, the invoker isn't.
- The cron job `hermes nightly update` was created **Sep 9** with `provider_snapshot: "openrouter"` frozen in. Once the native provider flipped to disabled, every run died in `runtime_provider.py` before the agent started → same error 4 nights straight (Sep 11–14). Sep 10 03:03 ran before the disable.
**What I changed — exactly one line:**
- `providers.openrouter.enabled: false → true` via `hermes config set` (no hand-editing). Verified readback: `true`.
**Verified:**
- Manual run: `hermes cron run 104ee603fd46` → **"Ran now: succeeded"** — first success since Sep 10. Next scheduled run 09-15 0