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