hermes-nyora: verdict pilote mimo-v2.5 — garder mimo, V4 Flash en fallback

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

_INDEX.md

@@ -55,6 +55,7 @@
 ## hermes-nyora
 | Runbook | Date | Tags |
 |---------|------|------|
+| [Verdict pilote mimo-v2.5 : GARDER mimo, V4 Flash en fallback (config finale + donnees)](hermes-nyora/verdict-pilote-mimo-v25.md) | 2026-07-08 | nyora, mimo, deepseek, opencode, modele, pilote, config |
 | [Veille Dr. Nexum -- Email enrichi (fin du bug email illisible)](hermes-nyora/veille-nexum-email-enrichi.md) | 2026-07-03 | nyora, dr-nexum, veille, email, n8n, cron |
 | [VPS Contabo -- WireGuard + qBittorrent natif Ubuntu (pas Docker, kill-switch)](hermes-nyora/vps-contabo-wireguard-qbittorrent-natif.md) | 2026-07-05 | nyora, vps, contabo, wireguard, qbittorrent, kill-switch, natif |
 | [Backup NAS -> VPS Contabo (restic chiffre, throttle, securise)](hermes-nyora/backup-nas-vps-contabo-restic.md) | 2026-07-05 | nyora, vps, contabo, backup, restic, securite |

hermes-nyora/verdict-pilote-mimo-v25.md

@@ -0,0 +1,41 @@
+# Verdict pilote mimo-v2.5 sur hermes-nyora — GARDER mimo (2026-07-08)
+
+## Contexte
+Pilote lancé le 2026-07-05 : mimo-v2.5 (provider opencode-go) en modèle par défaut de hermes-nyora, en comparaison avec DeepSeek V4 Flash (l'ancien défaut de la plateforme). Dispositif de comparaison : cron `veille-ia-nexum-compare-deepseek` rejouant le MÊME brief de veille Dr. Nexum (mêmes items de `/opt/data/veille_raw.json`) avec V4 Flash, 15 min après le run mimo, 3x/jour.
+
+**Précision de routage** : mimo-v2.5 passe en DIRECT par `https://opencode.ai/zen/go/v1` (provider built-in opencode-go, clé `OPENCODE_GO_API_KEY`), et NON par Bifrost. Vérifié dans `logs.db` de Bifrost : zéro trafic mimo. Les deux modèles sont couverts par le même forfait OpenCode Go → coût marginal nul des deux côtés.
+
+## Données (logs agent.log 2026-07-01 → 08, fenêtre pilote 05→08/07)
+
+| Métrique (05–08/07) | mimo-v2.5 | deepseek-v4-flash |
+|---|---|---|
+| Appels API | 591 | 194 |
+| Latence médiane / moyenne | 9,7 s / 14,1 s | 10,5 s / 26,1 s |
+| p90 / p99 | 27 s / 73 s | 53 s / 206 s |
+| Streams gelés (kill 180 s) | 0 | 19 sur la semaine (8 le 05/07, 6 le 08/07) |
+| Échecs d'appel | 1 (APIConnectionError) | 19 (18 ReadError/broken pipe) |
+| Jobs cron perdus (3/3 retries) | 0 | 2 |
+| Débit médian | 22,3 tok/s | 28,3 tok/s |
+
+Comparaison qualitative sur les 3 runs appariés du cron de comparaison :
+- **07/07 20h** : les deux briefs complets et bons. V4 Flash même légèrement meilleur en vérification factuelle (a identifié la « Caveman Method », flaggé les claims non vérifiés). Qualité ≈ parité.
+- **08/07 07h** : V4 Flash **CRASH** — `RuntimeError: Broken pipe` après 3 tentatives, aucun brief livré. mimo : brief complet de 24 Ko.
+- **08/07 12h** : V4 Flash a rendu un méta-résumé de 867 caractères au lieu du brief Telegram demandé (hors format). mimo : brief complet conforme.
+
+## Verdict : GARDER mimo-v2.5, V4 Flash en fallback uniquement
+Le problème de V4 Flash n'est pas la qualité d'analyse (équivalente quand il aboutit) mais la **fiabilité du streaming** : streams qui gèlent 180 s puis meurent en broken pipe, y compris pendant la semaine du pilote, avec 2 jobs cron réellement perdus. mimo-v2.5 : latence de queue 3x meilleure (p99 73 s vs 206 s), zéro stream gelé, un seul incident (réponses vides le 05/07 21h47, rattrapé par le fallback). Pas de routage par type de tâche : rien dans les données ne le justifie, et ça complexifierait la config pour rien.
+
+## Config finale appliquée (2026-07-08)
+- `data/config.yaml` : `model.default: mimo-v2.5` + `max_tokens: 8192` (modèle reasoning, jamais < 2048) ; `delegation.model: mimo-v2.5` (était deepseek-v4-flash) ; fallback 1 = opencode-go/deepseek-v4-flash ; fallback 2 = openrouter/deepseek/deepseek-v4-flash.
+- `data/profiles/veilleur/config.yaml` : `default: mimo-v2.5`, `max_tokens: 8192` (était deepseek-v4-flash).
+- `data/cron/jobs.json` : cron `veille-ia-nexum-compare-deepseek` **désactivé** (test terminé). Le cron principal `veille-ia-nexum-4ee61494` garde son override `model: mimo-v2.5`.
+- Backups : `config.yaml.bak-20260708T-verdict`, `profiles/veilleur/config.yaml.bak-20260708T-verdict`, `cron/jobs.json.bak_20260708_verdict_mimo`.
+- Appliqué par `docker restart hermes-agent-nyora` (healthy, profils default + veilleur re-registrés).
+
+## Ce qui NE marche PAS / pièges
+- Ouvrir `logs.db` de Bifrost depuis le Mac via SMB échoue (`unable to open database file`, WAL) → interroger via `ssh nas 'sqlite3 -readonly /volume1/docker/bifrost/data/logs.db ...'`.
+- Les erreurs Bifrost deepseek-v4-flash de la semaine sont surtout des 401 `virtual_key_not_found` (76, client sans VK — autre chantier) + 16 erreurs 500 upstream ; sans lien avec le pilote Hermes.
+- mimo-v2.5 peut rendre des réponses vides en rafale (1 épisode observé) : le gateway retry 3x puis bascule sur le fallback tout seul — surveiller `Empty response` dans `agent.log` si ça devient fréquent.
+
+## Surveillance post-verdict
+Vérifier dans une semaine : `grep -c 'Stream stale' data/logs/agent.log` et le taux d'`Empty response` mimo. Si les réponses vides mimo dépassent ~1/jour, envisager le retour V4 Flash ou un nouveau pilote.