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.

4.8 KiB Raw Blame History