BYOK auf dem Prüfstand: 5 Dinge, die in Open Design heute brechen

Wir erzählen den Leuten seit jeher, dass Open Design von Grund auf BYOK ist. Das stimmt nach wie vor. Der Ausgangsbeitrag zum BYOK-Design-Workflow führt durch den funktionierenden Weg — richte den daemon auf einen beliebigen OpenAI-kompatiblen Endpunkt, füge deinen Key ein, fertig. Für die Mehrheit der Setups ist das die ganze Geschichte, und es bleibt die ganze Geschichte.

Aber „BYOK“ ist kein einzelnes Feature. Es ist ein Vertrag, der bis in den Chat-Composer, den Finalize-Endpunkt, den Model-Picker, den CLI-Startpfad und die Analytics-Schicht hineinreicht. Jede dieser Stellen ist ein Ort, an dem der Vertrag brechen kann — und genau jetzt sind mehrere davon offene Issues in unserem öffentlichen Tracker, gemeldet von Nutzern in den letzten 48 Stunden.

Wir hätten den Ausgangsbeitrag schreiben und es dabei belassen können. Stattdessen kommt hier der ehrliche Durchgang: die Threads, die diese Woche reinkamen, was bricht, warum es bricht, was heute zu tun ist und welcher PR (oder Roadmap-Slot) es behebt. Nichts davon ist versteckt. Sie sind erfasst, gelabelt und unten verlinkt — und uns ist es lieber, du liest sie von uns, als dass du sie am Freitag mitten in einer Präsentation entdeckst.

Das Versprechen vs. die Bug-Liste

Die Einordnung ist wichtig, denn die naheliegende Fehllesart lautet „BYOK ist halbgar“. Ist es nicht. Keiner der fünf folgenden Punkte ist ein „BYOK funktioniert nicht“-Bug. Jeder einzelne sitzt an der Grenze zwischen einem Adapter, der uns gehört — der OpenAI-kompatiblen Schicht, dem Model-Picker, dem Finalize-Pfad — und einem, der uns nicht gehört: dem CLI des Upstream-Anbieters, seinen Packaging-Entscheidungen oder dem Prozessmodell der Host-Plattform.

Diese Grenze ist der Ort, an dem in jedem Open-Source-CLI-Orchestrator die Realität wohnt. Wir betreiben keine Inferenz, wir liefern kein geforktes CLI für jeden Anbieter, und wir wickeln nicht alles in einen Proxy, der die Kanten glättet (und still und heimlich deine Tokens besteuert). Der Preis dieser Haltung ist, dass die Naht sichtbar wird, wenn das CLI eines Anbieters seine Form ändert oder Windows ein Limit durchsetzt, das macOS nicht hat. Diese Woche zeigten sich fünf dieser Nähte auf einmal.

Hier sind alle fünf, in der Reihenfolge, in der sie reinkamen.

Gemini verirrt sich auf dem Weg zu „Finish Design“

Issue #1619 — bug, open

Symptom

BYOK ist für Gemini konfiguriert. Der Verbindungstest in den Einstellungen ist erfolgreich. Der Model-Picker liefert Gemini-Modelle zurück. Normaler Chat funktioniert — du kannst gegen deinen eigenen Gemini-Key problemlos ein vollständiges Gespräch führen. Aber in dem Moment, in dem der Nutzer auf Finish Design klickt, wirft der daemon einen Fehler in Anthropic-Form, als hätte er plötzlich vergessen, mit welchem Anbieter er gerade sprach.

Warum es passiert

Die Antwort des Maintainers im Thread bestätigt es: Der normale API-Modus-Chat berücksichtigt den ausgewählten Gemini-BYOK-Anbieter durchgängig, aber Finish Design wurde noch nicht über den Anthropic-kompatiblen Finalize-Pfad hinaus verallgemeinert. Alles andere läuft über den anbieterbewussten Proxy, der weiß, wie er den Dialekt jedes Upstreams spricht. Finish Design läuft immer noch über einen fest verdrahteten Anthropic-Finalize-Endpunkt, der aus einem früheren Release übrig geblieben ist — also bringt eine Gemini-Antwort, die in einer Nicht-Anthropic-Form ankommt, den Parser zu Fall.

Workaround

Leite Gemini über OpenRouter im Anthropic-kompatiblen Anbieter-Slot. Der Finish-Design-Pfad sieht dann eine Antwort in Anthropic-Form, die vom Shim von OpenRouter zurückkommt, und finalisiert korrekt. Es ist ein zusätzlicher Hop, und du bezahlst das Routing von OpenRouter, statt Gemini direkt aufzurufen, aber es ist heute stabil und deckt genau den einen Pfad ab, der kaputt ist, ohne den Chat-Pfad anzutasten, der bereits funktioniert.

Wer es behebt

Die Verallgemeinerung von Finish Design steht jetzt als P1 auf der BYOK-Roadmap. Noch kein PR — das ist das Nächste, das sich das daemon-Team vornimmt, und es ist der einzige der fünf, der ein Defekt in Code ist, der vollständig uns gehört, statt eine Grenz-Inkompatibilität.

Gemini 3 Flash stirbt unter Windows, bevor der Prompt ankommt

Issue #1611 — bug, open

Symptom

Gemini 3 Flash Preview scheitert innerhalb von Open Design unter Windows mit stdin: write EOF nach etwa 1,5 Sekunden — bevor der Prompt jemals das Modell erreicht. Gemini 3 Pro funktioniert in genau derselben Installation einwandfrei. Und das direkte Gemini CLI (gemini --model gemini-3-flash-preview ...) ist erfolgreich, wenn GEMINI_CLI_TRUST_WORKSPACE=true gesetzt ist. Es liegt also nicht am Key, nicht am Account und nicht am CLI für sich genommen.

Warum es passiert

Die Diagnose brauchte zwei Anläufe, was es wert ist zu zeigen, denn es ist ein gutes Beispiel dafür, wie solche Fälle entwirrt werden. Die erste Lesart des Screenshots des Melders sah aus wie ein Upstream-Quota-Fehler 429 RESOURCE_EXHAUSTED. Nach einem sauberen PowerShell-Repro, das OD_GEMINI_3_FLASH_OK nach stdout schrieb, änderte sich das Bild: Das Modell ist erreichbar, das CLI ist gesund, der Fehler liegt speziell auf dem Startpfad Open Design → Gemini CLI, und er ist spezifisch für die Flash-Variante unter Windows. Pro nimmt denselben Startpfad und übersteht ihn; Flash nicht.

Workaround

Wähle Gemini 3 Pro Preview im Model-Picker. Es läuft über denselben Startpfad und funktioniert. Davon getrennt — und dieser Teil hat mehr Zeit gekostet als der Bug selbst — prüfe ~/.gemini/hooks/. Ein langsamer gsd-check-update.js-Hook (Hook execution error: Hook timed out after 60000ms) fügte im Fall dieses Nutzers jedem Lauf rund 104s Overhead hinzu, völlig unabhängig vom Flash-Fehler. Säubere deine Gemini-Hooks ohnehin; ein hängengebliebener Update-Check-Hook lässt jeden Agenten kaputt erscheinen.

Wer es behebt

Markiert als Flash-spezifisch und OD-seitig. Die Untersuchung des stdin-Schreibpfads des daemon ist im Gange — das write EOF sagt, dass das stdin des Kindprozesses geschlossen wurde, bevor der daemon den Prompt fertig geschrieben hatte, der Fix liegt also darin, wie diese bestimmte Variante gespawnt wird.

Die DeepSeek-TUI hat unter Windows eine Prompt-Obergrenze von 30 KB

Issue #1610 — bug, open

Symptom

Beim DeepSeek-Wrapper v0.8.33 in einem gepackten Windows-Build scheitert ein langer zusammengesetzter Prompt an unserem Pre-flight-Guard mit 81397 > 30000 bytes. Der Nutzer hat nichts falsch gemacht — er hat lediglich einen Prompt komponiert, der reichhaltig genug war (System-Kontext, Design-System, Referenzen), um die 30 KB zu überschreiten.

Warum es passiert

Dieser Guard ist beabsichtigt, und er schützt dich vor einem schlimmeren Fehler. Der DeepSeek-TUI-Adapter sendet den Prompt derzeit als positionales Kommandozeilen-Argument — argv-gebunden — und Windows deckelt die gesamte Kommandozeile deutlich unterhalb dessen, wo macOS und Linux das tun. Ohne den Pre-flight-Check würde derselbe Prompt später scheitern, tiefer im Spawn, mit einem weitaus weniger nützlichen ENAMETOOLONG-Fehler und ohne Hinweis darauf, dass die Ursache die Prompt-Größe war. Also scheitern wir früh und nennen die Zahl. Die Diskrepanz, die das Issue offenlegt, liegt in den Docs: Die übergeordnete Anleitung impliziert, dass Windows-Fallbacks für lange Prompts breit gelten, aber der DeepSeek-TUI-Pfad hat noch keinen — sein Transport ist immer noch argv, nicht stdin oder eine Prompt-Datei.

Workaround

Wenn du unter Windows mit dem DeepSeek-TUI-Adapter unterwegs bist, halte den zusammengesetzten Prompt unter 30 KB oder wechsle zu einem stdin-basierten Adapter — Claude Code, Codex und OpenCode nehmen ihren Prompt alle über stdin entgegen und haben keine vergleichbare Obergrenze. Auf macOS und Linux beißt dieses Issue überhaupt nicht; das argv-Limit ist dort hoch genug, dass reale Prompts es nicht erreichen.

Wer es behebt

Der richtige Fix ist ein stdin- oder Prompt-Datei-Transport für den DeepSeek-TUI-Adapter, der die argv-Obergrenze vollständig beseitigt und ihn auf eine Linie mit den stdin-Adaptern bringt. Er wird in der Warteschlange des Adapter-Teams verfolgt.

Der OpenCode-Local-CLI-Test läuft ab, bevor das Modell warmläuft

Issue #1603 — bug, priority:p0, open

Symptom

Unter Einstellungen → BYOK → OpenCode läuft der Verbindungstest zuverlässig nach 45 Sekunden ab. Das Seltsame daran: Wenn der Nutzer zuerst das Terminal von OpenCode Desktop öffnet und dort ein lokales LLM anhängt, ist derselbe Open-Design-Test beim nächsten Versuch erfolgreich.

Warum es passiert

Dieses Detail „öffne zuerst das Desktop-Terminal“ ist der ganze Hinweis. Open Design hängt sich nicht an eine laufende OpenCode-Desktop-Sitzung an. Für einen Smoke-Test in den Einstellungen spawnt der daemon seinen eigenen frischen OpenCode-CLI-Subprozess und wartet auf eine ok-Antwort. Bei einem kalten lokalen Modell — einem, das noch nicht in den Speicher geladen wurde — kann diese erste Antwort länger dauern als das 45-Sekunden-Budget, weil das Modell von der Festplatte gelesen und warmgelaufen wird, bevor es überhaupt etwas beantworten kann. Das Öffnen des Desktop-Terminals und es einen Prompt beantworten zu lassen, wärmt das Modell im OS-Cache auf eine Weise, von der der frische Subprozess des daemon dann sofort profitieren kann. Es ist also nicht wirklich ein OpenCode-Bug; es ist eine Cold-Start-Timing-Annahme, die für lokale Modelle falsch ist.

Workaround

Bevor du OpenCode in Open Design testest, öffne OpenCode Desktop, hänge dein lokales LLM an und lass es einen Prompt beantworten. Führe dann den OD-Verbindungstest aus — das Modell ist warm und die Antwort landet innerhalb des Budgets. Seit v0.7.0 ist das Verbindungstest-Budget außerdem konfigurierbar, also kannst du, wenn dein lokales Modell wirklich langsam lädt, das Fenster vergrößern, statt es von Hand aufzuwärmen.

Wer es behebt

Der daemon-seitige Fix ist ein längeres oder konfigurierbares Aufwärmfenster speziell für Local-Model-Adapter, damit ein kaltes lokales Modell nicht an derselben Uhr gemessen wird wie eine gehostete API. Es wird mit p0 verfolgt — der höchsten Priorität der fünf, weil Local-Model-Nutzer genau das Publikum sind, dem BYOK dienen soll.

Die gepackte Web-App weigert sich, über reines HTTP zu laden

Issue #1620 — bug, open

Symptom

Etwas anderer Bug, dieselbe Familie. Der Melder betreibt die gepackte Web-App auf einer LAN-IP über reines HTTP, und die Seite wirft beim Laden — sie erreicht nie einen nutzbaren Zustand.

Warum es passiert

Nach PR #1428 begannen der Analytics-Provider und die PDF-Export-Nonce, crypto.randomUUID() direkt aufzurufen und dabei den in PR #900 eingeführten gestuften Helper zu umgehen, der elegant zurückfällt, wenn die sichere crypto-API nicht verfügbar ist. Chromium stellt crypto.randomUUID in nicht-sicheren Kontexten nicht bereit — und eine nackte LAN-IP über reines HTTP ist nach der Definition von Chromium kein sicherer Kontext. Also wirft der direkte Aufruf beim Laden, und die Seite geht mit ihm unter. Es ist streng genommen kein BYOK-Bug, aber er beißt genau dasselbe Publikum: Leute, die ihre eigene Infrastruktur betreiben, oft air-gapped, oft über reines HTTP, weil das Aufsetzen eines Zertifikats für ein internes Tool die Reibung nicht wert ist.

Workaround

Liefere die Web-App über HTTPS oder über localhost aus. Beide erfüllen die Anforderung an einen sicheren Kontext von Chromium — localhost wird auch ohne Zertifikat als sicher behandelt — und die Seite lädt normal. Für ein schnelles internes Setup ist localhost der kostenlose Weg; für LAN-Zugriff ist ein selbstsigniertes Zertifikat über HTTPS der dauerhafte.

Wer es behebt

PR #1621 leitet die verbleibenden Aufrufstellen wieder über den gestuften UUID-Helper aus PR #900, sodass der Sicherer-Kontext-Fallback überall wieder greift, statt nur dort, wo er ohnehin schon verdrahtet war. Er ist offen und in Review.

Was das tatsächlich über BYOK in Open Design aussagt

Lies die Liste als Vertragskarte, nicht als Qualitätsurteil. Vier dieser fünf Issues sitzen an Adapter-Grenzen — Geminis CLI-Startpfad, DeepSeeks argv-gebundener CLI-Transport, OpenCodes Cold-Start-Startmodell, die Sicherer-Kontext-Regeln der Host-Plattform. Das fünfte, das Finish-Design-Issue, liegt an unserem eigenen Finalize-Endpunkt, wo wir vor einem Release eine Antwort in Anthropic-Form fest verdrahtet und sie noch nicht verallgemeinert haben. Das geht auf unsere Kappe; die anderen vier sind der Preis, den du dafür zahlst, Tools zu respektieren, die du nicht selbst gebaut hast.

Und das ist der strukturelle Punkt. Jedes BYOK-System, das kein umetikettierter Proxy ist, landet hier. Entweder besitzt du die Inferenz — und verlierst BYOK, weil jetzt du derjenige bist, der Tokens kauft und mit Aufschlag verkauft — oder du respektierst die Upstream-Tools und erbst ihre Kanten: ihre CLIs, ihre Packaging-Eigenheiten, die Plattform-Limits, die sie alle unterschiedlich handhaben. Wir haben uns bewusst für die zweite Haltung entschieden, und wir würden uns wieder dafür entscheiden. Der Preis sind Wochen, die aussehen wie diese, in der die daemon- und Adapter-Teams Arbeit über fünf Oberflächen in zwei Tagen eingereicht haben.

Der Tausch stimmt nach wie vor. Ein funktionierendes Setup auf Claude Code, Codex, Cursor, Gemini Pro auf macOS und DeepSeek auf Linux — die Matrix, die rund 90 % unserer tatsächlichen Nutzer abdeckt — läuft heute sauber, ohne Proxy-Steuer und ohne Marge auf deine Tokens. Die fünf Threads oben sind, wie die anderen 10 % der Matrix Mitte Mai 2026 aussehen: benannt, erfasst und jeder mit einem Fix in Arbeit. Ehrliche Nähte schlagen eine glatte Oberfläche, die verbirgt, wohin die Rechnung geht.

Was du heute nutzen solltest (Matrix)

Das ist die praktische Version des Abschnitts oben — dieselben fünf Nähte, abgebildet darauf, wonach es jetzt gerade sicher zu greifen ist. Ein ✓ bedeutet, der Pfad funktioniert so, wie er ist; ein ✗ verlinkt das Issue, das ihn blockiert, mit dem Workaround im relevanten Abschnitt.

Anbieter	macOS	Linux	Windows	Finish-Design-Pfad
Claude Code (Sonnet / Opus)	✓	✓	✓	nativ
Codex	✓	✓	✓	nativ
Cursor (BYOK)	✓	✓	✓	nativ
Gemini 3 Pro Preview	✓	✓	✓	OpenRouter-Shim (#1619)
Gemini 3 Flash Preview	✓	✓	✗ (#1611)	OpenRouter-Shim (#1619)
DeepSeek (API)	✓	✓	✓	OpenRouter-Shim
DeepSeek TUI (lange Prompts)	✓	✓	✗ (#1610)	OpenRouter-Shim
OpenCode (lokales Modell)	✓	✓	✓ (zuerst aufwärmen, #1603)	n/a

Zwei Lesarten dieser Tabelle. Wenn dein Stack im Alles-✓-Block ist — Claude Code, Codex, Cursor oder Gemini Pro — bist du auf dem sauberen Pfad und nichts von oben ändert deinen Tag. Wenn du in einer der ✗-Zeilen bist, hat der passende Abschnitt den Workaround, der dich heute zum Laufen bringt, während der verlinkte Fix einschlägt. So oder so: Abonniere das BYOK-Label im Tracker, wenn du eine Benachrichtigung willst, sobald eine Zeile von ✗ auf ✓ umspringt.

Was als Nächstes zu tun ist

Die Skills-Bibliothek von Open Design ist die Arbeitsschicht unter all dem — die dateigesteuerten Verträge, in die der BYOK-Adapter einspeist, sobald die Verbindung gesund ist. Bei den Nähten oben geht es darum, Bytes von deinem Key zum Modell und zurück zu bekommen; die Skills sind das, was das Modell tatsächlich damit macht. Wenn du sehen willst, was ein Skill aus dem Modell konsumiert und was ihm egal ist — was auch der Grund ist, warum diese Adapter-Kanten die Ausgabe nicht ändern, sondern nur, ob du sie erreichst — ist dieses Verzeichnis der richtige Ausgangspunkt.

Durchstöbere die Skills-Bibliothek.

Weiterführende Lektüre

• BYOK-Design-Workflow: Claude, Codex oder Qwen auf deinem eigenen Key betreiben — der ursprüngliche BYOK-Erklärbeitrag und der funktionierende Weg, an dessen Rand die fünf Nähte oben sitzen
• Warum wir Open Design als Skill-Layer gebaut haben, nicht als Produkt — warum wir Upstream-Tools respektieren, statt sie in einen Proxy zu wickeln, was der ganze Grund ist, warum diese Grenzen existieren
• 31 Skills, 72 Systems — wie die Bibliothek funktioniert — worein BYOK tatsächlich einspeist, sobald die Verbindung gesund ist