# Migration cerveau Hermes DeepSeek V4 Flash -> Mimo V2.5 (perso, HARNESS/dsh-vps, tt, nyora)

**Date** : 2026-08-17
**Portee** : hermes-perso, hermes-HARNESS (dsh-vps, VPS Contabo), hermes-tt, hermes-nyora.

## Pourquoi

Changement tarifaire DeepSeek V4 Flash cote OpenCode. Mimo V2.5 deja valide en
production sur d'autres usages (extraction documentaire nyora-convert-api,
scoring broll_coherence_qc.py, et deja pilote comme cerveau sur hermes-nyora
depuis le 15/07 -- voir `hermes-nyora/verdict-pilote-mimo-v25.md`). Cette
migration etend son role au cerveau par defaut des 4 instances Hermes.

## Ce qui a ete decouvert en route (motif transverse, meme cause a chaque fois)

Chaque instance a livre une surprise differente de ce que la config versionnee
(git) ou la doc annoncait -- **meme cause a chaque fois : des valeurs de
configuration jamais revalidees contre le comportement reel du provider.**

1. **Git desynchronise du live** (nyora, puis perso, puis tt) -- le fichier
   `data/config.yaml` commite ne refletait pas la config reellement chargee
   par le conteneur (bascules faites en live sans commit). Reconciliation
   faite instance par instance avant toute nouvelle ecriture.
2. **Mecanisme d'auth key_env casse sur le chemin Bifrost `provider: custom`**
   (tente sur hermes-nyora) -- substituer `api_key` litteral par `key_env` a
   casse l'authentification Bifrost (`401 virtual_key_not_found`, fallback
   silencieux vers deepseek-v4-flash). Rollback propre effectue. Root cause
   probable : construction differente du header (`Authorization: Bearer` vs
   `x-bf-vk`) selon le champ utilise -- **non resolu**, cf `bifrost-access.md`
   (Bifrost exige `x-bf-vk`, rejette `Authorization: Bearer` en 401). A
   reprendre cote code/config Hermes avant nouvelle tentative. Le secret
   `bfk-...` reste donc en clair dans le `config.yaml` live de nyora --
   dette assumee, pas corrigee de force.
3. **`context_length: 128000` / `max_tokens: 8192` herites de DeepSeek, jamais
   recalibres pour mimo-v2.5** -- objet du present runbook (detail ci-dessous).

## Pattern de bascule retenu (Pattern A)

Pour perso/tt/nyora : `model.default` -> `provider: opencode-go`, `api_key`/
`base_url` vides (resolution automatique via `OPENCODE_GO_API_KEY`), PAS
`provider: custom`/`bifrost-proxy` (chemin casse, cf point 2 ci-dessus).
Seul hermes-HARNESS (dsh-vps) route reellement via Bifrost par construction
(`provider: bifrost` dans `settings.yaml`, VK `vk-dsh-vps`) -- c'est le
pattern attendu et documente pour cette instance, aucune ambiguite.

## Correction context_length / max_tokens (2026-08-17)

**Symptome** : le couple `mimo-v2.5`/`opencode-go` dans la table Bifrost
`governance_model_pricing` est **totalement vide** (aucune limite renseignee)
-- ce n'est donc pas une source fiable pour calibrer le yaml. La valeur
`128000`/`8192` presente sur toutes les instances etait une copie du bloc
DeepSeek d'origine, jamais revalidee.

**Source de verite retenue** : specs constructeur croisees (Xiaomi officiel,
OpenRouter, HuggingFace, Requesty) -- convergent sur un contexte tres
superieur (262k a 1M tokens selon l'hebergeur) et un plafond de sortie de
l'ordre de 131k tokens. **Ne pas reprendre les valeurs deepseek-v4-flash**
(1M / 384k) -- specs d'un autre modele, les copier aurait cree une nouvelle
valeur fausse dans l'autre sens (plafond de sortie surdeclare ~3x).

**Valeurs appliquees** (bloc `model:`, `key_env`/`api_key` non touches) :
```
context_length: 1048576
max_tokens: 131000        # dsh-vps : contextWindow / maxTokens (meme valeurs)
```

**Resultat par instance** (ordre de bascule : perso -> HARNESS -> tt -> nyora) :

| Instance | Avant | Apres | Verification |
|---|---|---|---|
| hermes-perso | 128000/8192 | 1048576/131000 | `model_used=mimo-v2.5` confirme, `finish_reason=stop`, aucune erreur. Commit `bolbol/hermes-perso@0c64f40`. |
| hermes-HARNESS (dsh-vps) | contextWindow 131072/maxTokens 8192 | 1048576/131000 | Logs Bifrost (`vk-dsh-vps`) : appels post-restart `model=mimo-v2.5, status=success`, aucune erreur. Pas de repo git pour ce fichier (volume Docker nomme, sauvegarde horodatee `.bak-ctxfix-20260817` seule trace). UID/GID VPS = `1001:1001` (PAS la convention NAS `1026:100`). |
| hermes-tt | 128000/8192 | 1048576/131000 | Logs internes gateway : `API call #1: model=mimo-v2.5 provider=opencode-go ... finish_reason=stop`. **Piege methodologique** : le modele s'est auto-declare a tort `deepseek-v4-flash` quand on lui demandait son propre nom en JSON -- l'auto-declaration d'un LLM sur son identite n'est PAS une source fiable, toujours verifier par les logs internes/gateway. Commit `bolbol/hermes-tt@0015ab5`. |
| hermes-nyora | 128000/8192 | 1048576/131000 | Logs Bifrost (`Nabil-Key`) : `model=mimo-v2.5, status=success, stop_reason=stop`. Secret en clair (`api_key: bfk-...`) laisse intact (dette separee, point 2). Commit `bolbol/hermes-nyora@4067a85`. |

Aucun repli necessaire sur aucune instance -- 1048576/131000 accepte partout
sans erreur de limite cote opencode-go/Bifrost au premier essai.

## Points restes ouverts (proprietaire a designer, pas noyes dans ce runbook)

- **Secret Bifrost en clair sur hermes-nyora** (`api_key: bfk-...`, x2 dans le
  yaml live) + **mecanisme d'auth key_env casse sur le chemin Bifrost custom**
  + **VK dediee `BIFROST_VK_HERMES_NYORA` provisionnee le 18/07 jamais cablee**
  -- trois symptomes du meme sujet non traite (routage Bifrost/Nabil-Key de
  nyora jamais finalise proprement). A cadrer en session dediee.
- **Few-shot des skills AO/RLA sur hermes-tt** (`dco-generation-tt`,
  `courriers-officiels-tt`, `gsd-ao-evaluation`) -- la regle anti-inference
  est deja en place et confirmee respectee par mimo-v2.5 en test reel, mais
  les exemples few-shot restent a peupler avec Nabil (`references/exemples-
  valides/`, note deja ecrite dans les skills eux-memes -- explicitement pas
  a faire par un agent seul).

## Voir aussi

`hermes-nyora/verdict-pilote-mimo-v25.md`, `hermes-tt/passation-pj-hermes-tt-deepseek-mimo.md`,
`common/bifrost-access.md`, `common/bifrost-vk-incidents.md`, `common/opencode-go-migration.md`.


## Yesmine-Key (VK Bifrost, hermes-desktop-yesmine — client pas encore actif)

**Perimetre** : uniquement la VK Bifrost `Yesmine-Key` (id `028c7103-cc9f-4139-96a1-3d5420b2d2dd`).
Aucune instance NAS ni fichier agent — toute la config vit en DB Bifrost
(`governance_virtual_key_provider_configs`).

**Etat trouve (Phase 1, verifie en live, rien suppose)** :
- `allowed_models` (provider `opencode`, row id=38) = `["deepseek-v4-flash"]` uniquement —
  mimo-v2.5 absent malgre une decision anterieure supposee (audit du 17/08). `allow_all_keys`
  deja a 1 (pas de correction necessaire la-dessus).
- Aucun concept de "modele par defaut" par VK cote Bifrost : schema `governance_virtual_keys`
  n'a pas de champ modele ; `routing_rules`/`routing_targets` ne referencent aucun `virtual_key_id`
  scope sur Yesmine-Key. Seul filtre existant = `allowed_models`. Le seul enregistrement scope
  sur cette VK dans `governance_model_configs` est un rate-limit generique (`model_name='*'`), pas
  un modele par defaut.
- Pas de concept context_length/max_output au niveau VK — ces valeurs sont globales par modele
  (`governance_model_pricing`), deja documente vide pour `mimo-v2.5/opencode-go` plus haut dans ce
  runbook. Hors perimetre de corriger cette table globale ici (deja couverte par les valeurs en dur
  1048576/131000 appliquees sur les yaml de la flotte ; Bifrost lui-meme ne bloque pas sur cette
  table vide, confirme par le test Phase 3 ci-dessous).

**Correction appliquee (Phase 2, edition DB directe — PAS l'API governance, piege `allow_all_keys`
reset connu)** :
```sql
UPDATE governance_virtual_key_provider_configs
SET allowed_models = '["mimo-v2.5"]'
WHERE id = 38 AND virtual_key_id = '028c7103-cc9f-4139-96a1-3d5420b2d2dd' AND provider = 'opencode';
```
`docker restart bifrost` obligatoire (chargement DB au boot, memoire vive garde l'ancien etat sinon)
— confirme healthy apres ~50s.

**Test Phase 3 (controle minimal, hors tool-calling — pas de client reel a simuler)** :
- Appel direct `x-bf-vk` vers `mimo-v2.5` : `resolved_model_used: mimo-v2.5`, `finish_reason: stop`,
  aucune erreur.
- Verification du retrait reel (pas juste un ajout) : appel `deepseek-v4-flash` sur la meme VK →
  rejete (`could not auto resolve a provider for the request`) — confirme que le retrait est effectif,
  pas seulement documentaire.

**Trace** : ce changement n'existe qu'en DB Bifrost (`config.db`, table
`governance_virtual_key_provider_configs`), aucun fichier Git associe — pas de repo pour cette
config, contrairement aux instances Hermes. Cette entree de runbook est la seule trace ecrite du
changement, a ne pas oublier lors d'une future migration modele generale sur Bifrost.

**Point ouvert** : `Yesmine-Key` reste provisionnee sans consommateur actif — aucun agent/client
n'appelle cette cle aujourd'hui (`hermes-desktop-yesmine` n'existe pas encore cote Windows/Claude
Desktop). A reevaluer (usage reel, cout, modele par defaut souhaite) quand ce client devient actif.


## Suite (2026-08-18) — Straggler nyora-veille (traduction titres) + Nabil-Key/Tirith a trancher

**Contexte** : sweep demande par Nabil pour reperer tout reliquat DeepSeek V4 Flash apres la
migration cerveau du 17/08 ci-dessus. Analyse logs Bifrost (`logs.db`) sur une fenetre test
07h02-07h12 (heure locale) -> 44 appels `deepseek-v4-flash` releves, 2 sources distinctes.

**Trouvaille 1 (fixee)** : `nyora-veille/backend/routers/opportunites.py`, fonction
`_translate_titre_fr()` (traduction des titres d'articles a l'ingestion) avait
`"model": "deepseek-v4-flash"` code en dur, hors de la constante `MODEL = "mimo-v2.5"` deja
utilisee par le reste du service -- oubli isole, pas un choix delibere. En corrigeant, **meme
piege deja documente le 17/08** (context_length/max_tokens herites) : `max_tokens: 120` etait
insuffisant pour mimo-v2.5 (modele reasoning, ~150-190 tok de raisonnement consommes avant le
contenu final) -> reponse tronquee -> repli silencieux sur le titre original a chaque appel (le
`except: return titre` avale l'echec sans logger). Corrige a `max_tokens: 500`, verifie en
direct (traduction correcte, log Bifrost confirme `model=mimo-v2.5`). **Latence x8-10** (1-2s ->
11-18s/appel) a surveiller sur le prochain run 3x/jour (boucle sequentielle dans `ingest_batch`,
pas de parallelisation). Commit `bolbol/nyora-veille@08cd09e`.

**Trouvaille 2 (PAS touchee, decision a prendre avec Nabil)** : virtual key `Nabil-Key`, prompt
"security reviewer for an AI coding agent" (garde-fou Tirith avant execution de commande shell)
-- toujours sur `deepseek-v4-flash`. Source introuvable sur le filesystem NAS (grep infructueux
dans hermes-platform/*/config, workspace, scripts) -- probablement cuit dans l'image agent, pas
dans un fichier monte/versionne. **Volontairement pas migre** : c'est un garde-fou de securite
sur le chemin critique (avant CHAQUE commande shell), et mimo-v2.5 ajoute 10-15s de latence par
appel (reasoning) -- risque de ralentir/bloquer visiblement les agents si applique sans
reflexion prealable. A trancher : cout (raison de la migration globale, cf tarification
DeepSeek en tete de ce runbook) vs latence sur un chemin de securite. Ne pas migrer sans
validation explicite de Nabil.

**Regle generale retenue** : apres toute migration de modele par defaut, chercher aussi les
appels Bifrost HORS de la config centrale (model code en dur dans du code applicatif, comme
ici) -- une migration "config.yaml" ne couvre pas ces cas ; seul un balayage des logs Bifrost
(`logs.db`, table `logs`, colonnes `model`/`virtual_key_name`/`timestamp`) sur une fenetre
temporelle les revele de facon fiable.


## DECISION -- Tirith reste sur DeepSeek V4 Flash, exception assumee (2026-08-18)

Nabil valide : le garde-fou Tirith (`Nabil-Key`, reviewer de securite avant execution de
commande shell) **reste sur `deepseek-v4-flash`**, ce n'est pas un oubli a corriger mais une
exception deliberee. Chiffres qui ont motive la decision (verifies en base Bifrost `logs.db`,
pas estimes) : journee la plus chargee recente (17/08, migration cerveau en cours) = 245 appels
Tirith pour 0,49$ au total, latence moyenne deja 5-15s cote DeepSeek selon la commande revue.
Extrapolation pire cas ~15$/mois -- marginal face au motif de la migration globale (tarification
DeepSeek). Migrer vers mimo-v2.5 (reasoning, +10-15s/appel mesures) degraderait la latence sur
le chemin le plus chaud de la flotte (avant CHAQUE commande shell, sans exception), pour un gain
cout negligeable. Argument de fond independant du prix : Tirith fait de la classification rapide
(commande dangereuse ou non, vigilance injection de prompt), pas du raisonnement multi-etapes --
profil de tache ou un modele rapide est mieux adapte qu'un modele reasoning.

**Condition de reevaluation, posee explicitement par Nabil** : revisiter ce choix si le cout de
Tirith sur DeepSeek V4 Flash devient juge insupportable (pas de seuil chiffre fixe a ce jour --
a definir si/quand la question se represente, en comparant le cout reel cumule DeepSeek vs
l'estimation cout+latence d'un passage a mimo-v2.5). Tant que ce seuil n'est pas atteint, ne pas
rouvrir cette question sans element nouveau (hausse tarifaire DeepSeek, volume Tirith en forte
hausse, etc.).