# Bifrost : VK stale-cache + migration fallback OpenRouter -> OpenCode Go

**Instance auteur** : Claude (via mcp-nas)
**Date** : 2026-07-06
**Tags** : infra, bifrost, hermes, opencode, openrouter, cout
**Statut** : valide

## Probleme observe

1. Pipeline nyora-veille (n8n workflow "VEILLE | Ingest Opportunites", node "Enrichir via Bifrost")
   en echec repete (401 virtual_key_not_found) le 06/07 a 07:34 et 13:29-13:30 UTC, alors que le
   x-bf-vk hardcode dans le node correspond exactement a la valeur Nabil-Key en base
   (bfk-e5832bfebd22e9d8252a426d0734ed5f2d923204c8033d6d). Aucun cout facture (echec avant tout
   routage provider).
2. hermes-nyora (mimo-v2.5, pilote 01-08/07) a bascule 2x le 05/07 (~21:38 et 21:48 UTC) sur son
   fallback natif `fallback_providers: openrouter` (bypass Bifrost, cle OPENROUTER_API_KEY en
   .env) suite a des reponses vides du pilote sur OpenCode. Cout reel facture sur OpenRouter,
   hors quota epuise.
3. Bifrost logs.db (depuis 06/06) : 1370 appels reussis, 17,43$, VK non identifiee, modele
   deepseek/deepseek-v4-flash sur OpenRouter -> trace de sessions Claude Cowork/Claude Code
   routees via Bifrost et interceptees par une regle de routing.

## Cause racine

- Point 1 : cache Bifrost desynchronise (VK valide en base mais rejetee en memoire) -> **un simple
  restart du container bifrost recharge correctement le VK store**. Meme famille de piege que
  celui deja connu pour les cles provider (config.json au boot) : Bifrost ne recharge pas
  systematiquement son etat interne sans redemarrage explicite.
- Point 2 : `fallback_providers` des 3 instances Hermes pointait vers `openrouter` (paye a l'usage)
  au lieu de `opencode-go` (deja couvert par le forfait Go). Design d'origine (voir
  migration-provider-opencode-go.md, 14/06) : a l'epoque volontaire comme filet de secours large,
  mais genere une facturation reelle des qu'un modele opencode echoue (meme hors quota).
- Point 3 : regle de routing Bifrost `Haiku -> Gemini 2.5 Flash` (id
  f5f03c54-049a-4f53-8590-7392730f42e0) avait un NOM ne correspondant pas a sa cible reelle en
  base (deepseek/deepseek-v4-flash payant sur openrouter au lieu de gemini-2.5-flash gratuit sur
  Google AI Studio). Les 4 autres regles Opus/Sonnet/Catch-all pointent, elles, vers des modeles
  `:free` OpenRouter et sont correctes.

## Solution appliquee (06/07/2026)

1. `routing_targets` (config.db Bifrost) : rule f5f03c54... -> provider=google,
   model=gemini-2.5-flash (etait openrouter/deepseek-v4-flash). Backup pris avant edit
   (config.db.bak-<timestamp>). Restart container bifrost pour charger.
2. Les 3 `data/config.yaml` Hermes (hermes-tt, hermes-nyora, hermes-perso) :
   `fallback_providers: openrouter/deepseek-v4-flash` -> `opencode-go/deepseek-v4-flash`,
   `key_env: OPENCODE_GO_API_KEY` (nom reel de la var injectee par le compose top-level, pas
   OPENCODE_API_KEY comme indique dans l'ancien runbook de migration). Backup des 3 fichiers pris
   avant edit. Restart des 3 containers hermes-agent-* (perso a eu besoin d'un start manuel apres
   le restart, le call restart API ayant timeout cote client -> verifier l'etat plutot que
   de re-tenter en boucle).
3. Aucun changement necessaire sur le node n8n "Enrichir via Bifrost" : le restart bifrost a
   suffi a corriger le probleme de VK stale.

## Verification

```
curl -s --unix-socket /var/run/docker.sock http://localhost/containers/<c>/json | jq .State
# bifrost, hermes-agent-tt/nyora/perso : running + healthy apres restart

curl -X POST http://bifrost:8080/v1/chat/completions -H 'x-bf-vk: <Nabil-Key>' \
  -d '{"model":"deepseek-v4-flash","max_tokens":30,"messages":[{"role":"user","content":"dis OK"}]}'
# HTTP 200, routing_info.provider=opencode -> confirme
```

## A surveiller

- Si un 401 virtual_key_not_found reapparait sans changement de config -> suspecter a nouveau le
  cache VK, restart bifrost avant toute autre investigation.
- Fiabilite mimo-v2.5 (reponses vides) non resolue en soi ; le fallback pointant desormais vers
  opencode-go, tout echec futur du pilote restera gratuit (dans le forfait) au lieu d'etre facture.
- Auditer les 4 autres regles Opus/Sonnet/Catch-all : noms vs cibles reelles a revalider
  periodiquement (meme type de desync que la regle Haiku).

## References

- migration-provider-opencode-go.md (14/06/2026)
- llm-audit-register.md (24/06/2026), item "N8n Ingest Opportunites"