BYOK-Design-Workflow: Claude, Codex oder Qwen mit deinem eigenen Key betreiben
Die meisten KI-Design-Tools schlagen still und leise eine Marge auf jeden Token auf, den du ausgibst. Open Design vertritt die gegenteilige Haltung — bring deinen eigenen Modell-Key mit, zahle direkt beim Anbieter und behalte die volle Kontrolle darüber, wo die Inferenz läuft. So funktioniert die BYOK-Ebene wirklich.
Wenn du 2026 ein gehostetes KI-Design-Produkt genutzt hast, ist dir wahrscheinlich aufgefallen, dass die Rechnung schleichend steigt. Ein Abo obendrauf auf eine Pro-Platz-Gebühr, geschichtet über einen Inferenz-Aufschlag, den niemand veröffentlicht. Die Rechnung ist absichtlich undurchsichtig.
Open Design führt keine Inferenz aus. Wir haben keine Marge auf Tokens. Der gesamte Workflow ist um Bring-your-own-Key (BYOK) herum gebaut — du richtest den daemon auf einen beliebigen OpenAI-kompatiblen Endpunkt, fügst deinen eigenen API-Key ein, und das war's.
Dieser Beitrag erklärt, warum wir diese Entscheidung getroffen haben, wie sie unter der Haube funktioniert und was sie in deinem Arbeitsalltag tatsächlich verändert. Wenn du das größere philosophische Argument dahinter willst, ist warum wir Open Design als Skill-Layer gebaut haben, nicht als Produkt das begleitende Stück — dieses hier ist die praktische Version.
Was „BYOK“ hier wirklich bedeutet
Im Bereich der KI-Tools kursieren zwei Definitionen von BYOK, und sie sind nicht dasselbe:
- Oberflächliches BYOK — das Tool lässt dich einen Key einfügen, leitet die Inferenz aber weiterhin über seine eigenen Server, protokolliert deine Prompts und wendet möglicherweise Rate Limits an.
- Echtes BYOK — das Tool ruft den Modellanbieter direkt von deiner Maschine (oder deiner Infrastruktur) aus auf. Deine Prompts berühren nie die Server des Anbieters. Der Anbieter nimmt keine Marge.
Open Design ist die zweite Art. Der daemon macht HTTP-Aufrufe an den von dir konfigurierten Endpunkt, mit deinem Key, von deiner Maschine aus. Wir proxyen nicht. Wir protokollieren nicht. Wir sehen deine Prompts nicht.
Wohin der Aufruf tatsächlich geht
Wenn der daemon einen Job aufnimmt, stellt er den Prompt zusammen — er zieht die für die Aufgabe relevanten SKILL.md- und DESIGN.md-Dateien heran — und macht dann eine einzige HTTP-Anfrage an die von dir gesetzte Basis-URL. Die Antwort streamt zurück zu deiner Maschine, der Agent schreibt das Artefakt auf die Festplatte, und das ist die gesamte Schleife. Es gibt keinen Open-Design-Server im Pfad. Derselbe daemon, der deine Skills entdeckt, ist auch für den Netzwerkaufruf zuständig — deshalb ist „Wo läuft das?“ eine Einstellung und kein Verkaufsgespräch.
Der OpenAI-kompatible Adapter
Die meisten KI-Inferenz-Endpunkte sprechen 2026 die OpenAI Chat Completions API. Wir nutzen das als kleinsten gemeinsamen Nenner als Protokoll. Wenn dein Anbieter es spricht (und fast alle tun das), wirst du standardmäßig unterstützt — kein Plugin, keine anbieterspezifische Integration, auf die du warten müsstest.
Anbieter, auf die du es richten kannst
| Anbieter | Typische Form der Basis-URL | Gut für |
|---|---|---|
| OpenAI | https://api.openai.com/v1 | gpt-image-2, gpt-5.x, stärkste allgemeine Durchläufe |
| Anthropic | OpenAI-Kompatibilitäts-Shim oder der dedizierte Claude-Adapter | geschmacksintensive Verfeinerung, lange Briefings |
| DeepSeek | https://api.deepseek.com/v1 | kosteneffizientes Long-Context-Drafting |
| Groq | Anbieter-Basis-URL | Draft-Zyklen mit geringer Latenz |
| OpenRouter | https://openrouter.ai/api/v1 | jedes Frontier-Modell, eine einzige Abrechnungsbeziehung |
| Selbst gehostetes vLLM / TGI / Ollama | dein eigener Host, z. B. http://localhost:11434/v1 | vollständig lokal, mandantenvertrauliche Arbeit |
| Qwen / Kimi / Hermes | Anbieter-Basis-URL | regionale Modelle mit OAI-kompatiblen Endpunkten |
Die Liste ist keine fest codierte Allowlist — sie zeigt nur, wo die Leute üblicherweise landen. Alles, was die Chat-Completions-Form beantwortet, funktioniert.
Zwei Felder, dann neu starten
Die Konfiguration besteht aus zwei Feldern:
OPENAI_BASE_URL=https://api.deepseek.com/v1
OPENAI_API_KEY=sk-…Trag sie in .env.local ein, starte den daemon neu, und du bist auf einem anderen Modell. Der Wechsel zu einer lokalen Ollama-Box für ein sensibles Projekt sind dieselben zwei Zeilen:
OPENAI_BASE_URL=http://localhost:11434/v1
OPENAI_API_KEY=ollamaEs gibt keine Modell-Registry zu aktualisieren, kein Konto neu zu verknüpfen, keine Migration. Der Key und der Endpunkt sind die gesamte Oberfläche.
Warum das für Designarbeit zählt
Design-Workflows haben eine spezifische Kostenform, mit der gehostete Inferenzprodukte schlecht umgehen:
- Iteration ist die Arbeitseinheit. Ein echter Design-Durchlauf bedeutet 30–50 Prompt-Zyklen, nicht drei. Gehostete Pläne drosseln hart an der 50-Zyklen-Marke.
- Langer Kontext ist die Norm. Ein ernsthaftes Briefing umfasst Markendokumente, frühere Arbeiten, Systemspezifikationen und Referenzbilder. Dieser Kontext sprengt die Token-Budgets in gehosteten Oberflächen.
- Die Modellwahl sollte ad hoc sein. Manche Durchläufe wollen ein schnelles, günstiges Modell. Manche wollen das stärkste verfügbare. Manche wollen ein lokales Modell für sensible Inhalte. Ein gehostetes Produkt wählt eines für dich aus.
BYOK behebt alle drei. Du zahlst pro Token, du wählst das Modell, du wirst nicht gedrosselt.
Iteration wird nicht länger rationiert
Das ist der Punkt, der leise verändert, wie du arbeitest. Wenn jeder zusätzliche Zyklus gegen einen Plan abgerechnet wird, fängst du an, dich selbst zu zensieren — du nimmst den dritten Entwurf, weil sich der vierte teuer anfühlt. Bei BYOK sind die Grenzkosten eines weiteren Durchlaufs ein paar Cent beim Modellanbieter, also wird die Entscheidung wieder zu einer Frage der Arbeit, nicht des Zählers. Der dritte Entwurf ist meist der Punkt, an dem das Design gut wird; ein Tool, das Iteration besteuert, besteuert genau den Schritt, der zählt.
Und die Kosten?
Eine verbreitete Sorge: „Wenn ich direkt zahle, wird es dann nicht teurer?“
In der Praxis nein. Hier ist ein typischer Tag Designarbeit in unserer internen Nutzung:
| Aufgabe | Tokens | Anbieter | Kosten |
|---|---|---|---|
| Briefing-Aufnahme (3 Dokumente) | 30K Input | Claude Sonnet | $0,09 |
| Erster Entwurfsdurchlauf | 80K Input + 20K Output | Claude Sonnet | $0,54 |
| 5 Iterationszyklen | 250K Input + 80K Output | Claude Sonnet | $1,95 |
| Letzter Feinschliff | 50K Input + 30K Output | Claude Opus (ein Durchlauf) | $1,35 |
| Tagessumme | ~$3,93 |
Das ist ein Deck, zwei Landing-Page-Varianten und eine Brand-Exploration. Das gehostete Äquivalent — angenommen ein „Creator“-Plan für $30/Monat mit Überziehungsgebühren — würde für dieselbe Arbeit rund $50 kosten, dir weniger Iterationen geben und dich an ein Modell binden.
Willst du günstiger werden, tausch Claude Sonnet gegen DeepSeek V3.2 und der Tag fällt unter $1. Der Punkt ist nicht, dass ein Modell das richtige ist — es ist, dass der Preis-/Qualitäts-Regler in deinen Händen liegt, statt in einer Abo-Stufe einbetoniert zu sein.
Datenschutz und Compliance
Es gibt einen zweiten Grund, warum BYOK zählt: die Prompts enthalten die Marke deines Kunden.
Gehostete Inferenz bedeutet, Markendokumente, noch nicht angekündigte Produktnamen, interne Preise und Pre-Launch-Kreatives durch die Server eines Dritten zu leiten. Die meisten Unternehmen haben dazu eine Meinung. Manche haben dazu einen Vertrag.
Mit BYOK findet der Prompt-Round-Trip zwischen deinem Laptop und dem Modellanbieter statt, den du bereits geprüft (oder selbst gehostet) hast. Open Design ist nicht im Loop. Wir haben kein Log, das vorgeladen werden könnte, keine Angriffsfläche, von der etwas durchsickern könnte, keine Audit-Lücke, die wir erklären müssten.
Was „kein Log“ in der Praxis bringt
Für Agenturarbeit, regulierte Branchen oder alles Pre-Launch ist das die einzige Haltung, die standhält. Wenn ein Security-Review fragt „Wohin gehen unsere Markenassets?“, lautet die Antwort „zum Modellanbieter in unserem Vertrag, und sonst nirgendwohin“ — nicht „in ein Anbieter-Dashboard, das wir nicht kontrollieren“. Das Selbst-Hosten eines Ollama- oder vLLM-Endpunkts zieht es weiter an: Die Bytes verlassen dein Netzwerk überhaupt nicht. Dies ist derselbe Trade-off, der in dem BYOK-Reality-Check untersucht wird, der ehrlich darüber ist, wo die rauen Kanten noch sind — lokale Modelle und Frontier-Modelle sind im Geschmack nicht austauschbar, und die Prompt-Injection-Fläche gehört dir selbst.
Wie man mitten im Projekt den Anbieter wechselt
Einer der unterschätzten Vorteile von BYOK ist die Anbieter-Arbitrage während eines Projekts:
- Drafting — nutze ein günstiges Modell (DeepSeek V3.2, Qwen 3) für das Frageformular und die erste Iteration
- Verfeinerung — wechsle zu Claude Sonnet oder GPT-5 für die mittleren Durchläufe, bei denen der Geschmack zählt
- Sensible Inhalte — wechsle zu einem lokalen Ollama-Modell für mandantenvertrauliche Prompts
- Letzter Feinschliff — verbrenne einen Durchlauf auf dem stärksten verfügbaren Modell (Opus, GPT-5 Pro)
In Open Design bedeutet ein Wechsel, zwei Zeilen in .env.local zu bearbeiten. Es gibt keine Migration, kein erneutes Onboarding, kein Plan-Upgrade.
Ein durchgespieltes Routing für ein Briefing
Konkret könnte ein einzelnes Landing-Page-Briefing so ablaufen:
# draft + first iterations — cheap and fast
OPENAI_BASE_URL=https://api.deepseek.com/v1
OPENAI_API_KEY=sk-…
# then, for the passes where taste decides the outcome:
OPENAI_BASE_URL=https://api.anthropic.com/v1 # via the compat shim
OPENAI_API_KEY=sk-ant-…Dieselben Skills, dasselbe Designsystem auf der Festplatte, dieselben Artefakte — nur die Engine hinter dem Workflow hat sich geändert. Weil Skills und Systeme einfach Dateien sind (SKILL.md und DESIGN.md), ist nichts an deinem Setup an ein bestimmtes Modell gebunden. Genau das bedeutet es, den Workflow zu besitzen: Das Tool geht aus dem Weg, und das Modell ist ein Parameter, den du änderst, wie es das Briefing verlangt.
Probier es aus
Klone das Repo, setze OPENAI_BASE_URL und OPENAI_API_KEY in .env.local, führe pnpm tools-dev aus. Der daemon nutzt den Endpunkt, auf den du ihn richtest, mit dem Modell, für das du zahlst, nach dem Zeitplan, den du willst.
Das ist die gesamte BYOK-Geschichte. Es gibt keine spezielle Stufe, keinen Upgrade-Flow, keine Abrechnungsbeziehung mit uns. Du zahlst den Modellanbieter, du behältst deine Keys, du behältst deine Prompts. Wir liefern die Ebene.
Weiterführende Lektüre
- Warum wir Open Design als Skill-Layer gebaut haben, nicht als Produkt — die Wette dahinter, eine dünne Ebene auszuliefern statt einer gehosteten App
- Der BYOK-Reality-Check: 5 Dinge, die kaputtgehen — die ehrlichen Trade-offs und rauen Kanten, wenn man seinen eigenen Key mitbringt
- 31 Skills, 72 Systeme: wie die Open-Design-Bibliothek funktioniert — die
SKILL.md-/DESIGN.md-Dateien, die konstant bleiben, egal welches Modell du betreibst