Déblocage DeepSeek V4.1 Flash — whitelist à plusieurs niveaux (11/09/2026)

Ticket : infra-2026-09-040 (clôturé définitif par Claude)

Contexte

DeepSeek V4.1 Flash sorti le 10/09/2026 (remplace V4 Flash chez DeepSeek, prix Flash reduits ~11-57%). Sur OpenCode Go (abonnement $10/mois deja utilise par Bifrost), ce modele beneficie en plus d'un boost temporaire x4 sur les limites d'usage. Nabil a signale ne pas pouvoir en profiter, ni des modeles gratuits OpenRouter, sur aucun de ses assistants (Hermes NAS/VPS, openclaw-perso, DSH, OpenCode CLI natif VPS).

Diagnostic

Le blocage n'etait PAS un manque d'acces reseau/abonnement : le modele est immediatement disponible sur le catalogue OpenCode Go (GET /zen/go/v1/models) et testable en direct avec la cle deja en place. Les modeles gratuits OpenRouter sont eux aussi deja largement whitelistes cote Bifrost pour la plupart des VK (Gemma, Nemotron, GPT-OSS, Qwen3-coder, GLM-4.5-air, etc.).

Le vrai frein est une architecture a quatre niveaux de whitelist, aucun avec hot-reload, qui doivent tous autoriser un modele avant qu'un agent donne puisse reellement l'appeler :

Catalogue du provider OpenCode Go lui-meme (pas un blocage ici, juste la source de verite sur les IDs de modele reels).
Bifrost — whitelist au niveau de la cle provider (config.json, providers.opencode.keys[0].models).
Bifrost — whitelist par VK (governance_virtual_key_provider_configs.allowed_models, une par (VK, provider) en base SQLite config.db) ; necessite un restart de Bifrost pour etre relue (pas de hot-reload SQL).
Catalogue local fige de chaque agent, quand il en a un : container opencode natif VPS (opencode.json), DSH (settings.yaml, providers bifrost + opencode-direct, tous deux avec liste de modeles en dur), openclaw-perso (openclaw.json, models.providers.bifrost.models + agents.defaults.models). Hermes (tt/nyora/perso/nabil) n'a PAS ce niveau — provider custom generique sans whitelist locale, donc deja debloque des que le niveau 3 l'est.

bifrost-proxy (nginx/openresty, port 3086, colocalise avec Bifrost sur le VPS) a aussi un fichier models.json mais c'est purement un catalogue de decouverte pour /v1/models — ne bloque aucun appel reel.

Correctifs appliques

Backups pris avant chaque modification (suffixe .bak-20260911*).

Bifrost core (/home/dsh-agent/bifrost/data/) : deepseek-v4.1-flash ajoute a config.json (cle provider opencode) et aux 21 lignes governance_virtual_key_provider_configs (toutes les VK utilisant le provider opencode) dans config.db. Container bifrost redemarre (healthy). bifrost-proxy/models.json mis a jour pour la decouverte.
DSH (settings.yaml) : deepseek-v4.1-flash ajoute aux catalogues opencode-direct et bifrost. Bonus : baseURL du provider bifrost corrige — pointait encore vers l'ancien relais NAS (100.86.197.88:3086) au lieu du VPS local (100.94.90.119:3086), alors que DSH tourne sur le VPS et n'a plus besoin de transiter par le NAS/Sfax depuis la relocalisation du 08/09 (voir bifrost-routing memory). Container redemarre, teste avec la vraie cle BIFROST_API_KEY.
opencode natif VPS (/home/gemini-ops/opencode/config/opencode.json) : entree deepseek-v4.1-flash ajoutee au provider bifrost. Container redemarre, entree confirmee dans la config active (GET /config).
openclaw-perso (openclaw.json) : entree ajoutee a models.providers.bifrost.models (avec metadata complete) et a agents.defaults.models (cle prefixee bifrost/, comme les entrees existantes — premiere tentative sans prefixe corrigee en cours de route). Container redemarre, healthy, teste.
Hermes (tt/nyora/perso/nabil) : aucune modification necessaire, deja debloques via le niveau 3.

Verification

Chaque instance testee en bout en bout via son propre chemin d'appel reel (pas juste curl depuis l'exterieur) : hermes-perso (NAS, relais bifrost-proxy NAS->VPS), DSH (VPS, vraie cle BIFROST_API_KEY), opencode natif VPS (cle opencode directe + header session), openclaw-perso (Authorization Bearer via bifrost-proxy). Toutes les reponses confirment "model":"deepseek-v4.1-flash" avec une reponse coherente.

Piege a retenir

bifrost-proxy (nginx) n'accepte le VK que via Authorization: Bearer <vk> ou x-api-key — pas x-bf-vk en entree (ce header est ce qu'il injecte lui-meme vers Bifrost apres resolution). Un test manuel avec x-bf-vk direct contre bifrost-proxy echoue systematiquement (virtual_key_required), meme si la cle est valide — a ne pas confondre avec un vrai probleme de VK.

Reste ouvert

Aucun. Les 5 assistants cites par Nabil (Hermes NAS x3, hermes-nabil VPS, DSH, openclaw-perso, opencode natif VPS) sont confirmes fonctionnels sur deepseek-v4.1-flash au 11/09/2026.

Addendum 11/09/2026 — token Gitea expiré + panne SSH memory-sync decouverte

En corrigeant le token Gitea bolbol expire (signale en fin de premiere session), deux choses distinctes ont ete trouvees et traitees :

Token sur le miroir reel : le clone de travail avait ete corrige, mais pas le miroir bare que le cron memory-sync.sh utilise reellement (/opt/memory-node/git/nas-runbooks.git sur le VPS, proprietaire claude-oversight). Corrige et confirme via l'execution cron reelle de 03:17 (354361f..26bef7d main -> main).
Panne SSH decouverte au passage : le meme script echouait depuis un moment sur 100% des runs (Best0f@100.86.197.88: Permission denied (publickey,password)) pour le volet rsync (nyora-notes + context-hub). Cause : consequence collaterale du verrouillage progressif de l'acces Best0f (migration vers comptes scopes claude-ops/gemini-ops/claude-code-ops, voir memoire gemini-ops-access) — ce script n'avait jamais ete migre.

Fix : memory-sync.sh repointe sur claude-ops@NAS. Cle publique claude-oversight@vps-memory-node (deja utilisee, identity file existant) ajoutee a authorized_keys de claude-ops sur le NAS, avec forced command restreignant strictement a rsync --server --sender en lecture seule sur /volume1/docker/nyora-notes/ et /volume1/docker/context-hub/ uniquement (aucun shell, no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding). Backups : authorized_keys.bak-20260911-ajout-cle-memory-node, memory-sync.sh.bak-20260911.

Verifie : context-hub synchronise integralement et a jour.

Reste ouvert (nouveau, 11/09/2026)

nyora-notes bloque uniquement sur un sous-dossier isole, /volume1/docker/nyora-notes/app (mode 700, proprietaire uid 1026 — seul dossier de toute l'arborescence hors de la convention 755 du reste). Ni claude-ops (non proprietaire) ni le root conteneurise de mcp-nas (Operation not permitted malgre uid=0 — la couche de permission Synology bloque meme le root du container) ne peuvent corriger ce mode.

Action Nabil requise (une seule commande, en root ou via Best0f) :

chmod -R g+rX /volume1/docker/nyora-notes/app

Puis le prochain run horaire (:17) se synchronisera tout seul, rien d'autre a faire.

7.1 KiB Raw Blame History