docs: bifrost-proxy (3086) recette client Hermes Desktop validee, VK stale-cache 3e occurrence, deepseek-v4-flash reajoute au catalogue statique — 11/07/2026

common/bifrost-access.md

@@ -40,16 +40,22 @@ Que ce soit a la creation ou en update via /api/governance/virtual-keys, le cham
 ### Endpoint /anthropic/v1/messages : ne marche pas avec les providers custom
 Teste et confirme : /anthropic/v1/messages fonctionne pour les providers CANONIQUES de Bifrost (ex. groq -> 200 OK, reponse bien traduite au format Anthropic). Pour un provider CUSTOM (base_provider_type: openai, ex. opencode), la meme requete renvoie 404 "HTML response received from provider". Ne pas utiliser le plan "provider Anthropic natif cote client + base_url vers /anthropic" pour router vers DeepSeek/OpenCode via Bifrost. Utiliser /v1/chat/completions (mode OpenAI-compatible standard) a la place.
 
-### Recette Hermes Desktop -> Bifrost -> DeepSeek V4 Flash (OpenCode)
-~/.hermes/config.yaml :
-  model:
-    provider: custom
-    base_url: http://192.168.100.33:3085/v1
-    default: opencode/deepseek-v4-flash
-    api_mode: chat_completions
-    context_length: 128000
+### Recette Hermes Desktop -> Bifrost -> DeepSeek V4 Flash (OpenCode) — MAJ 2026-07-11 (valide, testee de bout en bout)
 
-~/.hermes/.env :
-  CUSTOM_API_KEY=sk-bf-<vk du profil concerne>
+**Utiliser bifrost-proxy (port 3086), pas Bifrost direct (3085).** Le proxy traduit `Authorization: Bearer <vk>` (ou `x-api-key`) en `x-bf-vk` cote Bifrost. Fonctionne avec le format de vk classique `bfk-*` — pas besoin du format `sk-bf-*` ni d'un client capable d'envoyer un header custom.
+
+Config generique (tout client OpenAI-compatible, type Hermes Desktop) :
+```
+Base URL : http://192.168.100.33:3086/v1
+Auth     : Authorization: Bearer <vk>   (champ "API Key" standard)
+```
+
+**Piege vecu (11/07)** : ecrire l'IP avec un `:` au lieu d'un `.` (ex. `192:168.100.33`) casse le parsing cote client → symptome "connected but no models" trompeur, ne pas chercher plus loin avant d'avoir verifie l'IP au caractere pres.
+
+**`/v1/models` sur le port 3086 ne requete PAS Bifrost en direct** : il sert un catalogue STATIQUE (`/mnt/docker/bifrost-proxy/models.json` sur le NAS), relu a chaque requete (pas de restart necessaire pour l'editer). Si un modele manque dans le picker du client alors qu'il est bien autorise sur la vk cote Bifrost (verifiable via `curl http://172.17.0.1:3085/v1/models -H "x-bf-vk: <vk>"`), l'ajouter directement dans ce fichier. Cf. incident 11/07 dans bifrost-vk-incidents.md — `deepseek-v4-flash` avait disparu de ce catalogue lors de la reduction de stack fin juin/debut juillet.
+
+VK Yesmine (Hermes Desktop) : `Yesmine-Key`, `bfk-04e2a58c7ce42bd676c4e0768b4b40ae5dc01a9999979527`, providers openrouter/google/nvidia_nim/opencode (deepseek-v4-flash). Reutilisable telle quelle pour tout futur client desktop — **MacBook M5 Pro inclus** — tant que le format reste `bfk-*`.
+
+#### Ancienne piste (2026-07-02, port 3085 direct + vk `sk-bf-*`) — DEPRECIEE
+Documentee a l'epoque en misant sur un support natif de `Authorization: Bearer` par les vk au format `sk-bf-*`. Non reconfirmee depuis, et la vk Yesmine reellement utilisee est restee au format `bfk-*`. Le contournement via bifrost-proxy (3086) est desormais la methode de reference : plus simple (aucune regeneration de vk necessaire), et validee de bout en bout le 11/07/2026 (connexion + appel chat reel sur deepseek-v4-flash confirmes).
 
-Vk dediee a Yesmine (Hermes Desktop T470) : Yesmine-Key, budget 3 dollars/mois, providers openrouter/google/nvidia_nim/opencode, allowed_models opencode limite a deepseek-v4-flash. Detail complet : NyoraNotes, note "Bifrost debloque pour Yesmine - Hermes Desktop T470".