Chantier "Urgence" — sélection de LLM gratuits multi-source (11/09/2026)

Contexte

Forfait OpenCode Go de Nabil à 99.6% d'usage le 11/09/2026 (reset dans 1j13h). Demande : ajouter, au niveau de tous les assistants, un provider "Urgence" — une sélection de LLM gratuits à utiliser en cas d'épuisement du forfait payant, tagués -OC / -OR / -GQ / -NV selon la source.

Convention de tag

-OC : OpenCode Zen, tier gratuit keyless (https://opencode.ai/zen/v1, header x-opencode-session requis — une valeur statique suffit, testée deux fois de suite avec la même valeur sans problème). Modèle retenu : mimo-v2.5-free (mêmes poids que le cerveau principal Mimo V2.5, coût 0, totalement indépendant du forfait OpenCode Go payant épuisé). C'est le pick prioritaire partout.
-OR : OpenRouter, modèle nex-agi/nex-n2.5-pro:free. Clé OPENROUTER_API_KEY déjà native chez Hermes et DSH (pas besoin d'en ajouter). ATTENTION : routage via Bifrost actuellement cassé, voir section bug plus bas — fonctionne seulement en appel direct (hors Bifrost).
-GQ : Groq, modèle openai/gpt-oss-120b. Clé GROQ_API_KEY déjà native chez Hermes/DSH, et fonctionne aussi via Bifrost (groq/openai/gpt-oss-120b).
-NV : NVIDIA NIM, modèle nvidia/nemotron-3-super-120b-a12b. Clé NVIDIA_API_KEY déjà native chez Hermes/DSH, fonctionne aussi via Bifrost (nvidia_nim/nvidia/nemotron-3-super-120b-a12b).

Tous les modèles ci-dessus ont été testés en direct le 11/09/2026 (appel réel, réponse vérifiée) avant d'être retenus — voir "catalogues périmés" plus bas.

Déploiement par assistant

Hermes (tt / nyora / perso / nabil) — /opt/data/config.yaml (NAS) ou /data/config.yaml (VPS pour nabil) :

fallback_providers pointait vers opencode-go (= le même forfait payant épuisé — filet de sécurité inutile en cas d'épuisement réel). Remplacé par opencode-free / mimo-v2.5-free.
fallback_model pointait vers un modèle payant (deepseek/deepseek-v4-flash) ou un slug OpenRouter mort (qwen/qwen3-next-80b-a3b-instruct:free). Remplacé par openrouter / nex-agi/nex-n2.5-pro:free.
hermes-nabil n'avait aucun des deux blocs configurés — ajouté (fallback_model seulement, fallback_providers n'existe pas dans son schéma).
Backups : config.yaml.bak-20260911-urgence sur chaque instance. Les 4 redémarrées, confirmées saines.

DSH (dsh-vps) — /home/dsh-agent/.dsh/settings.yaml :

Bloc openrouter : 2 modèles morts (z-ai/glm-5.2:free, minimax/minimax-m2.7:free) remplacés par nex-agi/nex-n2.5-pro:free et nvidia/nemotron-3-ultra-550b-a55b:free. Renommé en "OpenRouter (Urgence -OR)".
Nouveau provider opencode-free ajouté (keyless, mimo-v2.5-free, header x-opencode-session statique). Le schéma settings.yaml de DSH accepte un provider sans apiKeyEnv (champ optionnel côté code — resolveApiKey retourne undefined proprement si absent, pas d'erreur de validation).
Backup : settings.yaml.bak-20260911-urgence. Redémarré, sain.

openclaw-perso — /home/openclaw/.openclaw/openclaw.json :

Ajout de groq/openai/gpt-oss-120b (-GQ) dans les models du provider bifrost existant, et d'un nouveau provider opencode-free (-OC).
Piège rencontré : nommer un modèle avec le préfixe groq/ à l'intérieur du provider bifrost déclenche côté OpenClaw une détection automatique de plugin dédié (@openclaw/groq-provider, distinct du simple passage par Bifrost). Au premier redémarrage : "plugin migration inputs changed... refusing to report ready", healthcheck en échec (port 18789 injoignable). Résolu tout seul au redémarrage suivant (le message l'annonçait : "Restart OpenClaw so state migrations run"). Pas d'intervention nécessaire au-delà d'attendre/relancer une fois — mais à savoir pour la prochaine fois : un modèle préfixé par le nom d'un provider "connu" d'OpenClaw (groq, openai, anthropic...) peut déclencher ce cycle, même si on ne voulait que router via Bifrost.
Backup : openclaw.json.bak-20260911-urgence. Healthy après le second boot.

OpenCode natif VPS (conteneur opencode, CLI open-source, distinct du "OpenCode Zen" — source de -OC) — /home/gemini-ops/opencode/config/opencode.json :

Fichier monté read-only dans le conteneur (/config/opencode.json) — toute édition doit se faire côté hôte, à /home/gemini-ops/opencode/config/opencode.json.
Découverte : ce conteneur utilise en réalité la VK vk-dsh-vps (partagée avec l'agent DSH), pas de VK dédiée. Cette VK n'avait que le provider opencode (payant) en whitelist Bifrost — aucune alternative gratuite possible via Bifrost avant intervention.
Ligne groq ajoutée à vk-dsh-vps en base Bifrost (allowed_models: ["openai/gpt-oss-120b"], allow_all_keys=1), Bifrost redémarré. Modèle groq/openai/gpt-oss-120b ajouté au provider bifrost existant dans opencode.json. Backup : opencode.json.bak-20260911-urgence. Redémarré, vérifié via curl localhost:4090/config que le modèle est bien chargé.

Whitelist Bifrost rafraîchie

VK vk-openclaw-perso : ajout de nex-agi/nex-n2.5-pro:free et nvidia/nemotron-3-ultra-550b-a55b:free (provider openrouter, id 117) et de nvidia/nemotron-3-super-120b-a12b (provider nvidia_nim, id 115). VK vk-dsh-vps : nouvelle ligne groq (id généré, allowed_models: ["openai/gpt-oss-120b"]). Bifrost redémarré à chaque fois (pas de hot-reload des whitelists, connu). Backups config.db pris avant chaque modification (config.db.bak-20260911-urgence-openclaw, config.db.bak-20260911-urgence-dsh-vk).

Catalogues gratuits périmés (découverte au passage)

Environ la moitié des modèles déjà whitelistés en base Bifrost et dans le settings.yaml de DSH étaient morts au moment du test (11/09/2026) : les catalogues gratuits OpenRouter et Groq tournent vite. Exemples confirmés morts : z-ai/glm-4.5-air:free, openai/gpt-oss-120b:free (variante OpenRouter, la variante Groq sans :free est vivante), qwen/qwen3-coder:free, llama-3.3-70b-versatile (retiré du catalogue Groq), meta/llama-3.3-70b-instruct (NVIDIA NIM, end-of-life 26/08/2026). Leçon : toujours revalider un modèle gratuit en direct avant de le réutiliser depuis une whitelist existante, ne pas faire confiance à une liste ancienne même si elle a été testée à l'époque.

BUG DÉCOUVERT : Bifrost -> OpenRouter cassé (non corrigé)

Indépendamment du chantier Urgence : tout routage Bifrost vers OpenRouter échoue actuellement, quel que soit le modèle demandé (testé sur 3 modèles différents, même erreur à chaque fois) :

error when reading response headers: small read buffer. Increase ReadBufferSize.
Buffer size=4096, contents: "HTTP/1.1 404 Not Found... <en-têtes CSP volumineux>"

Hypothèse : openrouter.ai renvoie une page d'erreur 404 avec des en-têtes Content-Security-Policy trop volumineux pour le buffer de lecture par défaut (4096 octets) du client HTTP sortant de Bifrost (fasthttp côté client provider, distinct du server.read_buffer_size documenté — celui-là ne couvre que les requêtes entrantes vers Bifrost, défaut 65536). Le 404 lui-même suggère aussi qu'OpenRouter bloque peut-être Bifrost (User-Agent / Cloudflare bot-protection) — pas confirmé.

Impact réel en production : openrouter/google/gemini-2.5-flash (vision_model documenté dans context-hub, utilisé par gsparc-mezzouna et nyora-convert-api pour l'OCR) est probablement cassé en ce moment pour tout consommateur passant par Bifrost. À vérifier/tester par la prochaine session qui touche à la vision.

Groq et NVIDIA NIM via Bifrost ne sont pas affectés (Groq testé et confirmé fonctionnel à travers Bifrost). Non corrigé dans cette session — creuser le réglage buffer sortant côté client provider de Bifrost (pas trouvé de champ documenté pour ça spécifiquement, concurrency_and_buffer_size concerne la taille de la file d'attente de requêtes, pas le buffer de lecture TCP des réponses).

Documentation centrale

Règles urgence_gratuit et bifrost_openrouter_bug ajoutées au scope llm de context-hub (PATCH /api/rules/llm) — visibles par Claude et Gemini (scope llm accessible aux deux).

Reste à faire

Diagnostiquer/corriger le bug Bifrost -> OpenRouter (ticket séparé recommandé).
Revalider openrouter/google/gemini-2.5-flash (vision) une fois le bug traité.
Envisager une VK dédiée pour le conteneur opencode natif VPS plutôt que le partage actuel avec vk-dsh-vps (pas bloquant, note pour plus tard).

8.6 KiB Raw Blame History