3.9 KiB

Executable File

Raw Blame History

BIFROST-ACCESS — Passerelle LLM (vision / OCR)

Note partagée aux 3 instances Hermes. Source : projet gsparc-mezzouna, 2026-06-14.

Bifrost = passerelle LLM OpenAI-compatible sur le NAS.

Endpoint & authentification

Conteneur bifrost sur le réseau n8n, port interne 8080.
- Depuis un conteneur du réseau n8n : http://bifrost:8080/v1
- Depuis le LAN : http://192.168.100.33:3085/v1 (UI sur 3085)
Auth = header x-bf-vk: <clé virtuelle>. Le header Authorization: Bearer est REJETÉ (HTTP 401 virtual_key_required). Toujours envoyer x-bf-vk.
Clé virtuelle commune (Nabil-Key, budget 8 $/mois) : bfk-e5832bfebd22e9d8252a426d0734ed5f2d923204c8033d6d.
GET /v1/models (avec x-bf-vk) → liste des modèles (ids complets, ex. openrouter/google/gemini-2.5-flash).

PIÈGE vision / OCR

DeepSeek est text-only. Envoyer une image à deepseek-v4-flash/pro/r1 → 404 "No endpoints found that support image input". → Pour toute extraction d'image (scan, ticket, OCR), utiliser un modèle vision : openrouter/google/gemini-2.5-flash (rapide, fiable, payant ~fraction de centime/image). Le « forfait OpenCode gratuit » ne couvre PAS la vision.

Exemple

curl -s http://bifrost:8080/v1/chat/completions \
  -H "x-bf-vk: bfk-e5832bfebd22e9d8252a426d0734ed5f2d923204c8033d6d" \
  -H "Content-Type: application/json" \
  -d '{"model":"openrouter/google/gemini-2.5-flash","messages":[
       {"role":"user","content":[
         {"type":"text","text":"Décris cette image en JSON strict."},
         {"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 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".

3.9 KiB Executable File Raw Blame History