From 776044b830207b3810c0d54af076e6c0f8666f31 Mon Sep 17 00:00:00 2001
From: bolbol <nabil.derouiche@gmx.com>
Date: Thu, 2 Jul 2026 20:12:52 +0000
Subject: [PATCH] runbook: precisions sk-bf Authorization Bearer, piege
 allow_all_keys, limite anthropic providers custom, recette Hermes Desktop
 Yesmine

---
 common/bifrost-access.md | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/common/bifrost-access.md b/common/bifrost-access.md
index 24e1670..a30d3b8 100755
--- a/common/bifrost-access.md
+++ b/common/bifrost-access.md
@@ -29,3 +29,27 @@ curl -s http://bifrost:8080/v1/chat/completions \
          {"type":"image_url","image_url":{"url":"data:image/jpeg;base64,..."}}]}]}'
 ```
 Implémentation de référence : `gsparc-mezzouna/app/vision.py`.
+
+## MAJ 2026-07-02 - Format sk-bf-* et Hermes Desktop (Yesmine)
+
+Precision importante sur la regle "Authorization: Bearer rejete" ci-dessus : c'est vrai UNIQUEMENT pour les anciennes vk au format bfk-*. Une vk moderne au format sk-bf-* accepte Authorization: Bearer <sk-bf-...> (en plus de x-bf-vk). Pour tout client qui ne peut pas envoyer de header custom (ex. Hermes Agent/Desktop - pas de support headers custom dans config.yaml, cf. github.com/NousResearch/hermes-agent/issues/9398), utiliser une vk sk-bf-* + Authorization Bearer.
+
+### Piege confirme : allow_all_keys jamais honore via l'API
+Que ce soit a la creation ou en update via /api/governance/virtual-keys, le champ allow_all_keys d'un provider_config est systematiquement ignore (reste false en base quoi qu'on envoie). Fix : poser allow_all_keys=1 directement dans config.db (table governance_virtual_key_provider_configs, colonne allow_all_keys), puis docker restart bifrost pour recharger le cache memoire. Meme famille de piege que le rechargement des cles provider au boot (config.json).
+
+### 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
+
+~/.hermes/.env :
+  CUSTOM_API_KEY=sk-bf-<vk du profil concerne>
+
+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".