Bilan de réalité du BYOK : 5 choses qui cassent aujourd'hui dans Open Design

Nous disons aux gens qu'Open Design est BYOK de fond en comble. C'est toujours vrai. L'article fondateur sur le workflow de design BYOK parcourt le chemin qui fonctionne — pointez le daemon vers n'importe quel endpoint compatible OpenAI, collez votre clé, c'est terminé. Pour la majorité des configurations, c'est toute l'histoire, et cela reste toute l'histoire.

Mais le « BYOK » n'est pas une fonctionnalité unique. C'est un contrat qui s'étend jusque dans le composeur de chat, l'endpoint de finalisation, le sélecteur de modèle, le chemin de lancement du CLI et la couche d'analytique. Chacun de ces éléments est un endroit où le contrat peut casser — et en ce moment plusieurs d'entre eux sont des issues ouvertes dans notre tracker public, signalées par des utilisateurs au cours des dernières 48 heures.

Nous aurions pu écrire l'article fondateur et nous arrêter là. À la place, voici la passe d'honnêteté : les fils arrivés cette semaine, ce qui casse, pourquoi cela casse, quoi faire aujourd'hui, et quelle PR (ou créneau de roadmap) le corrige. Aucun de ces problèmes n'est caché. Ils sont enregistrés, étiquetés et liés ci-dessous — et nous préférons que vous les lisiez de notre part plutôt que de les découvrir en plein deck un vendredi.

La promesse face à la liste de bugs

Le cadrage importe, car la mauvaise lecture facile est « le BYOK est à moitié cuit ». Il ne l'est pas. Aucun des cinq cas ci-dessous n'est un bug du type « le BYOK ne fonctionne pas ». Chacun d'eux réside à la frontière entre un adaptateur que nous possédons — la couche compatible OpenAI, le sélecteur de modèle, le chemin de finalisation — et un que nous ne possédons pas : le CLI du fournisseur en amont, ses choix d'empaquetage, ou le modèle de processus de la plateforme hôte.

Cette frontière est là où vit la réalité dans tout orchestrateur de CLI open-source. Nous n'exécutons pas d'inférence, nous ne livrons pas un CLI forké pour chaque fournisseur, et nous n'enveloppons pas tout dans un proxy qui lisse les bords (et taxe discrètement vos tokens). Le prix de cette posture est que lorsque le CLI d'un fournisseur change de forme, ou que Windows impose une limite que macOS n'impose pas, la couture apparaît. Cette semaine, cinq de ces coutures sont apparues d'un coup.

Les voici toutes les cinq, dans l'ordre où elles sont arrivées.

Gemini se perd en chemin vers « Finish Design »

Issue #1619 — bug, ouverte

Symptôme

Le BYOK est configuré pour Gemini. Le test de connexion dans les Réglages réussit. Le sélecteur de modèle renvoie des modèles Gemini. Le chat ordinaire fonctionne — vous pouvez mener une conversation complète avec votre propre clé Gemini sans problème. Mais à l'instant où l'utilisateur appuie sur Finish Design, le daemon lève une erreur de forme Anthropic, comme s'il avait soudain oublié à quel fournisseur il parlait.

Pourquoi cela arrive

La réponse du mainteneur sur le fil le confirme : le chat ordinaire en mode API honore le fournisseur BYOK Gemini sélectionné de bout en bout, mais Finish Design n'a pas encore été généralisé au-delà du chemin de finalisation compatible Anthropic. Tout le reste est acheminé via le proxy conscient des fournisseurs qui sait comment parler le dialecte de chaque amont. Finish Design passe encore par un endpoint de finalisation Anthropic codé en dur, hérité d'une version antérieure — donc une réponse Gemini arrivant dans une forme non-Anthropic fait trébucher le parseur.

Contournement

Acheminez Gemini via OpenRouter dans l'emplacement de fournisseur compatible Anthropic. Le chemin Finish Design voit alors une réponse de forme Anthropic revenir du shim d'OpenRouter et finalise correctement. C'est un saut supplémentaire, et vous payez le routage d'OpenRouter plutôt que d'appeler Gemini directement, mais c'est stable aujourd'hui et cela couvre le seul chemin qui est cassé sans toucher au chemin de chat qui fonctionne déjà.

Qui le corrige

La généralisation de Finish Design est désormais sur la roadmap BYOK en tant que P1. Pas encore de PR — c'est la prochaine chose que l'équipe daemon prend en charge, et c'est le seul des cinq qui soit un défaut dans du code que nous possédons entièrement plutôt qu'une incompatibilité de frontière.

Gemini 3 Flash meurt sous Windows avant que le prompt n'arrive

Issue #1611 — bug, ouverte

Symptôme

Gemini 3 Flash Preview échoue dans Open Design sous Windows avec stdin: write EOF après environ 1,5 seconde — avant que le prompt n'atteigne jamais le modèle. Gemini 3 Pro fonctionne très bien dans exactement la même installation. Et le CLI Gemini direct (gemini --model gemini-3-flash-preview ...) réussit lorsque GEMINI_CLI_TRUST_WORKSPACE=true est défini. Donc ce n'est pas la clé, pas le compte, et pas le CLI isolément.

Pourquoi cela arrive

Le diagnostic a pris deux passes, ce qui vaut la peine d'être montré car c'est un bon exemple de la façon dont on démêle ces problèmes. La première lecture de la capture d'écran du rapporteur ressemblait à une erreur de quota en amont 429 RESOURCE_EXHAUSTED. Après une reproduction PowerShell propre qui a écrit OD_GEMINI_3_FLASH_OK sur stdout, le tableau a changé : le modèle est joignable, le CLI est sain, l'échec se situe spécifiquement sur le chemin de lancement Open Design → CLI Gemini, et il est spécifique à la variante Flash sous Windows. Pro emprunte le même chemin de lancement et survit ; Flash non.

Contournement

Sélectionnez Gemini 3 Pro Preview dans le sélecteur de modèle. Il s'exécute via le même chemin de lancement et fonctionne. Séparément — et ce point a pris plus de temps que le bug lui-même — vérifiez ~/.gemini/hooks/. Un hook gsd-check-update.js lent (Hook execution error: Hook timed out after 60000ms) ajoutait environ 104 s de surcharge à chaque exécution dans le cas de cet utilisateur, totalement indépendamment de l'échec de Flash. Nettoyez vos hooks Gemini quoi qu'il en soit ; un hook de vérification de mise à jour bloqué fera paraître n'importe quel agent cassé.

Qui le corrige

Signalé comme spécifique à Flash et côté OD. L'investigation est en cours sur le chemin d'écriture stdin du daemon — le write EOF indique que le stdin de l'enfant s'est fermé avant que le daemon n'ait fini d'écrire le prompt, donc le correctif réside dans la façon dont cette variante particulière est lancée.

Le TUI DeepSeek a un plafond de prompt de 30 Ko sous Windows

Issue #1610 — bug, ouverte

Symptôme

Sur le wrapper DeepSeek v0.8.33 dans un build empaqueté Windows, un long prompt composé échoue à notre garde-fou de pré-vol avec 81397 > 30000 bytes. L'utilisateur n'a rien fait de mal — il a simplement composé un prompt suffisamment riche (contexte système, design system, références) pour franchir les 30 Ko.

Pourquoi cela arrive

Ce garde-fou est intentionnel, et il vous protège d'une erreur pire. L'adaptateur TUI DeepSeek envoie actuellement le prompt comme argument positionnel de ligne de commande — lié à argv — et Windows plafonne la ligne de commande totale bien en dessous de macOS et Linux. Sans la vérification de pré-vol, le même prompt échouerait plus tard, plus profondément dans le lancement, avec une erreur ENAMETOOLONG bien moins utile et aucune indication que la cause était la taille du prompt. Nous échouons donc tôt et nommons le nombre. L'incohérence que l'issue expose se trouve dans la documentation : les conseils de haut niveau laissent entendre que les solutions de repli pour les longs prompts sous Windows s'appliquent largement, mais le chemin TUI DeepSeek n'en a pas encore une — son transport est toujours argv, pas stdin ni un fichier de prompt.

Contournement

Si vous êtes sous Windows avec l'adaptateur TUI DeepSeek, gardez le prompt composé sous 30 Ko, ou passez à un adaptateur basé sur stdin — Claude Code, Codex et OpenCode prennent tous leur prompt via stdin et n'ont aucun plafond comparable. Sur macOS et Linux, cette issue ne mord pas du tout ; la limite argv y est assez élevée pour que les prompts du monde réel ne l'atteignent pas.

Qui le corrige

Le bon correctif est un transport stdin ou fichier de prompt pour l'adaptateur TUI DeepSeek, qui supprime entièrement le plafond argv et l'aligne sur les adaptateurs stdin. C'est suivi dans la file de l'équipe adaptateurs.

Le test du CLI local OpenCode expire avant que le modèle ne chauffe

Issue #1603 — bug, priority:p0, ouverte

Symptôme

Dans Réglages → BYOK → OpenCode, le test de connexion expire de manière fiable à 45 secondes. Le détail étrange : si l'utilisateur ouvre d'abord le terminal d'OpenCode Desktop et y attache un LLM local, le même test Open Design réussit alors à l'essai suivant.

Pourquoi cela arrive

Ce détail « ouvrez d'abord le terminal Desktop » est tout l'indice. Open Design ne s'attache pas à une session OpenCode Desktop en cours d'exécution. Pour un test de fumée des Réglages, le daemon lance son propre sous-processus CLI OpenCode tout frais et attend une réponse ok. Avec un modèle local froid — qui n'a pas encore été chargé en mémoire — cette première réponse peut prendre plus que le budget de 45 secondes, car le modèle est lu depuis le disque et chauffé avant de pouvoir répondre quoi que ce soit. Ouvrir le terminal Desktop et le laisser répondre à un prompt chauffe le modèle dans le cache de l'OS d'une manière dont le sous-processus frais du daemon peut alors immédiatement bénéficier. Ce n'est donc pas vraiment un bug d'OpenCode ; c'est une hypothèse de timing de démarrage à froid qui est fausse pour les modèles locaux.

Contournement

Avant de tester OpenCode dans Open Design, ouvrez OpenCode Desktop, attachez votre LLM local et laissez-le répondre à un prompt. Lancez ensuite le test de connexion OD — le modèle est chaud et la réponse arrive dans le budget. À partir de la v0.7.0, le budget du test de connexion est aussi configurable, donc si votre modèle local est réellement lent à charger, vous pouvez augmenter la fenêtre au lieu de le chauffer à la main.

Qui le corrige

Le correctif côté daemon est une fenêtre de préchauffage plus longue ou configurable spécifiquement pour les adaptateurs de modèle local, afin qu'un modèle local froid ne soit pas jugé sur la même horloge qu'une API hébergée. C'est suivi en p0 — la plus haute priorité des cinq, car les utilisateurs de modèles locaux sont exactement le public que le BYOK est censé servir.

L'application web empaquetée refuse de se charger en HTTP simple

Issue #1620 — bug, ouverte

Symptôme

Bug légèrement différent, même famille. Le rapporteur exécute l'application web empaquetée sur une IP de LAN en HTTP simple, et la page lève une erreur au chargement — elle n'atteint jamais un état utilisable.

Pourquoi cela arrive

Après la PR #1428, le fournisseur d'analytique et le nonce d'export PDF ont commencé à appeler crypto.randomUUID() directement, en contournant l'utilitaire à paliers introduit dans la PR #900 qui se replie gracieusement lorsque l'API crypto sécurisée n'est pas disponible. Chromium n'expose pas crypto.randomUUID dans les contextes non sécurisés — et une simple IP de LAN en HTTP simple n'est, par définition de Chromium, pas un contexte sécurisé. L'appel direct lève donc une erreur au chargement, et la page tombe avec lui. Ce n'est pas strictement un bug BYOK, mais il mord exactement le même public : les gens qui font tourner leur propre infrastructure, souvent isolée du réseau, souvent en HTTP simple parce que monter un certificat pour un outil interne ne vaut pas la friction.

Contournement

Servez l'application web en HTTPS ou via localhost. Les deux satisfont l'exigence de contexte sécurisé de Chromium — localhost est traité comme sécurisé même sans certificat — et la page se charge normalement. Pour une configuration interne rapide, localhost est le chemin sans coût ; pour l'accès LAN, un certificat auto-signé en HTTPS est le chemin durable.

Qui le corrige

La PR #1621 réachemine les sites d'appel restants à travers l'utilitaire UUID à paliers de la PR #900, afin que le repli de contexte sécurisé s'applique de nouveau partout au lieu de seulement là où il était déjà câblé. Elle est ouverte et en cours de revue.

Ce que cela dit réellement du BYOK dans Open Design

Lisez la liste comme une carte de contrat, pas comme un verdict de qualité. Quatre de ces cinq issues se situent aux frontières d'adaptateurs — le chemin de lancement du CLI de Gemini, le transport CLI lié à argv de DeepSeek, le modèle de lancement à froid d'OpenCode, les règles de contexte sécurisé de la plateforme hôte. La cinquième, celle de Finish Design, se situe à notre propre endpoint de finalisation, où nous avons codé en dur une réponse de forme Anthropic il y a une version et ne l'avons pas encore généralisée. Celle-là est de notre fait ; les quatre autres sont la taxe que vous payez pour respecter des outils que vous n'avez pas construits.

Et c'est là le point structurel. Tout système BYOK qui n'est pas un proxy rebaptisé finit ici. Soit vous possédez l'inférence — et perdez le BYOK, car vous devenez celui qui achète les tokens et les majore — soit vous respectez les outils amont et héritez de leurs bords : leurs CLI, leurs particularités d'empaquetage, les limites de plateforme que chacun gère différemment. Nous avons choisi la seconde posture délibérément, et nous la choisirions de nouveau. Le coût, ce sont des semaines qui ressemblent à celle-ci, où les équipes daemon et adaptateurs ont enregistré du travail sur cinq surfaces en deux jours.

Le compromis reste le bon. Une configuration fonctionnelle sur Claude Code, Codex, Cursor, Gemini Pro sous macOS, et DeepSeek sous Linux — la matrice qui couvre environ 90 % de nos utilisateurs réels — tourne proprement aujourd'hui, sans taxe de proxy et sans marge sur vos tokens. Les cinq fils ci-dessus sont à quoi ressemblent les 10 % restants de la matrice à la mi-mai 2026 : nommés, enregistrés, et chacun avec un correctif en cours. Des coutures honnêtes valent mieux qu'une surface lisse qui cache où va la facture.

Quoi utiliser aujourd'hui (matrice)

Voici la version pratique de la section ci-dessus — les cinq mêmes coutures, mises en correspondance avec ce qu'il est sûr d'utiliser maintenant. Un ✓ signifie que le chemin fonctionne tel quel ; un ✗ renvoie à l'issue qui le bloque, avec le contournement dans la section concernée.

Fournisseur	macOS	Linux	Windows	Chemin Finish Design
Claude Code (Sonnet / Opus)	✓	✓	✓	natif
Codex	✓	✓	✓	natif
Cursor (BYOK)	✓	✓	✓	natif
Gemini 3 Pro Preview	✓	✓	✓	shim OpenRouter (#1619)
Gemini 3 Flash Preview	✓	✓	✗ (#1611)	shim OpenRouter (#1619)
DeepSeek (API)	✓	✓	✓	shim OpenRouter
DeepSeek TUI (longs prompts)	✓	✓	✗ (#1610)	shim OpenRouter
OpenCode (modèle local)	✓	✓	✓ (chauffer d'abord, #1603)	n/a

Deux lectures de ce tableau. Si votre stack est dans le bloc tout-✓ — Claude Code, Codex, Cursor ou Gemini Pro — vous êtes sur le chemin propre et rien de ce qui précède ne change votre journée. Si vous êtes sur l'une des lignes ✗, la section correspondante contient le contournement qui vous fait tourner aujourd'hui en attendant que le correctif lié arrive. Dans tous les cas, abonnez-vous au label BYOK sur le tracker si vous voulez une notification quand une ligne bascule de ✗ à ✓.

Quoi faire ensuite

La bibliothèque de skills d'Open Design est la couche de travail sous tout cela — les contrats pilotés par fichiers que l'adaptateur BYOK alimente une fois la connexion saine. Les coutures ci-dessus concernent l'acheminement des octets de votre clé au modèle et retour ; les skills sont ce que le modèle en fait réellement. Si vous voulez voir ce qu'un skill consomme du modèle et ce dont il se moque — ce qui explique aussi pourquoi ces bords d'adaptateur ne changent pas la sortie, seulement si vous l'atteignez — ce répertoire est le bon point de départ.

Parcourez la bibliothèque de skills.

Lectures associées

• Workflow de design BYOK : faites tourner Claude, Codex ou Qwen sur votre propre clé — l'explication originale du BYOK, et le chemin fonctionnel au bord duquel se trouvent les cinq coutures ci-dessus
• Pourquoi nous avons conçu Open Design comme une couche de skills, pas un produit — pourquoi nous respectons les outils amont au lieu de les envelopper dans un proxy, ce qui est toute la raison de l'existence de ces frontières
• 31 skills, 72 systems — comment fonctionne la bibliothèque — ce que le BYOK alimente réellement une fois la connexion saine