Flusso di lavoro di design BYOK: usa Claude, Codex o Qwen con la tua chiave
La maggior parte degli strumenti di design AI aggiunge in silenzio un margine a ogni token che spendi. Open Design adotta la posizione opposta: porta la chiave del tuo modello, paga direttamente il provider e mantieni il pieno controllo su dove gira l'inferenza. Ecco come funziona davvero il livello BYOK.
Se hai usato un prodotto di design AI ospitato nel 2026, probabilmente hai notato la bolletta che lievita. Un abbonamento sopra un costo per postazione, stratificato sopra un ricarico sull'inferenza che nessuno pubblica. La matematica è opaca di proposito.
Open Design non esegue inferenza. Non abbiamo un margine sui token. L'intero flusso di lavoro è costruito attorno al bring-your-own-key (BYOK): punti il daemon a qualsiasi endpoint compatibile con OpenAI, incolli la tua API key e hai finito.
Questo articolo spiega perché abbiamo fatto questa scelta, come funziona sotto il cofano e cosa cambia davvero nel tuo flusso di lavoro quotidiano. Se vuoi l'argomentazione filosofica più ampia che ci sta dietro, perché abbiamo costruito Open Design come un livello di skill, non come un prodotto è il pezzo complementare: questo è la versione pratica.
Cosa significa davvero "BYOK" qui
Ci sono due definizioni di BYOK che circolano nel mondo degli strumenti AI, e non sono la stessa cosa:
- BYOK di superficie: lo strumento ti permette di incollare una chiave, ma instrada comunque l'inferenza attraverso i propri server, registra i tuoi prompt e può applicare limiti di frequenza.
- BYOK reale: lo strumento chiama il provider del modello direttamente dalla tua macchina (o dalla tua infrastruttura). I tuoi prompt non toccano mai i server del fornitore. Il fornitore non prende alcun margine.
Open Design è il secondo tipo. Il daemon effettua chiamate HTTP a qualunque endpoint configuri, con la tua chiave, dalla tua macchina. Non facciamo da proxy. Non registriamo nulla. Non vediamo i tuoi prompt.
Dove va davvero la chiamata
Quando il daemon prende un job, compone il prompt — recuperando i file SKILL.md e DESIGN.md rilevanti per l'attività — e poi effettua una singola richiesta HTTP al base URL che hai impostato. La risposta torna in streaming alla tua macchina, l'agente scrive l'artefatto su disco, e questo è l'intero ciclo. Non c'è alcun server Open Design nel percorso. Lo stesso daemon che scopre le tue skill possiede anche la chiamata di rete, ed è per questo che "dove gira questo?" è un'impostazione e non una trattativa commerciale.
L'adattatore compatibile con OpenAI
La maggior parte degli endpoint di inferenza AI nel 2026 parla l'API OpenAI Chat Completions. La usiamo come protocollo minimo comune denominatore. Se il tuo provider la parla (e quasi tutti lo fanno), sei supportato per impostazione predefinita: nessun plugin, nessuna integrazione per provider da aspettare.
Provider a cui puoi puntarlo
| Provider | Forma tipica del base URL | Adatto a |
|---|---|---|
| OpenAI | https://api.openai.com/v1 | gpt-image-2, gpt-5.x, i passaggi generali più forti |
| Anthropic | shim di compatibilità OpenAI, o l'adattatore Claude dedicato | raffinamento ad alta sensibilità estetica, brief lunghi |
| DeepSeek | https://api.deepseek.com/v1 | bozze a contesto lungo a costi contenuti |
| Groq | base URL del provider | cicli di bozza a bassa latenza |
| OpenRouter | https://openrouter.ai/api/v1 | qualsiasi modello di frontiera, un'unica relazione di fatturazione |
| vLLM / TGI / Ollama self-hosted | il tuo host, ad es. http://localhost:11434/v1 | lavoro completamente locale, riservato al cliente |
| Qwen / Kimi / Hermes | base URL del provider | modelli regionali con endpoint compatibili OAI |
La lista non è una allowlist codificata: è semplicemente dove le persone finiscono di solito. Qualsiasi cosa risponda alla forma Chat Completions funziona.
Due campi, poi riavvia
La configurazione sono due campi:
OPENAI_BASE_URL=https://api.deepseek.com/v1
OPENAI_API_KEY=sk-…Inseriscili in .env.local, riavvia il daemon, e sei su un modello diverso. Passare a una macchina Ollama locale per un progetto sensibile sono le stesse due righe:
OPENAI_BASE_URL=http://localhost:11434/v1
OPENAI_API_KEY=ollamaNon c'è alcun registro di modelli da aggiornare, nessun account da ricollegare, nessuna migrazione. La chiave e l'endpoint sono l'intera superficie.
Perché questo conta per il lavoro di design
I flussi di lavoro di design hanno una specifica forma di costo con cui i prodotti a inferenza ospitata sono in difficoltà:
- L'iterazione è l'unità di lavoro. Un vero passaggio di design significa 30-50 cicli di prompt, non tre. I piani ospitati strozzano duramente intorno alla soglia dei 50 cicli.
- Il contesto lungo è la norma. Un brief serio coinvolge documenti di brand, lavori precedenti, specifiche di sistema e immagini di riferimento. Quel contesto sfonda i budget di token nelle UI ospitate.
- La scelta del modello dovrebbe essere ad-hoc. Alcuni passaggi vogliono un modello veloce ed economico. Alcuni vogliono il più forte disponibile. Alcuni vogliono un modello locale per contenuti sensibili. Un prodotto ospitato ne sceglie uno al posto tuo.
BYOK risolve tutti e tre. Paghi per token, scegli il modello, non vieni strozzato.
L'iterazione smette di essere razionata
Questo è quello che cambia silenziosamente il modo in cui lavori. Quando ogni ciclo in più viene conteggiato su un piano, inizi ad autocensurarti: prendi la terza bozza perché la quarta sembra costosa. Con BYOK il costo marginale di un altro passaggio è qualche centesimo presso il provider del modello, quindi la decisione torna a riguardare il lavoro, non il contatore. La terza bozza è di solito dove il design diventa buono; uno strumento che tassa l'iterazione sta tassando esattamente il passaggio che conta.
E i costi?
Una preoccupazione comune: "Se pago direttamente, non sarà più costoso?"
In pratica, no. Ecco una tipica giornata di lavoro di design nel nostro utilizzo interno:
| Attività | Token | Provider | Costo |
|---|---|---|---|
| Acquisizione del brief (3 documenti) | 30K input | Claude Sonnet | $0.09 |
| Passaggio di prima bozza | 80K input + 20K output | Claude Sonnet | $0.54 |
| 5 cicli di iterazione | 250K input + 80K output | Claude Sonnet | $1.95 |
| Rifinitura finale | 50K input + 30K output | Claude Opus (un passaggio) | $1.35 |
| Totale giornata | ~$3.93 |
Si tratta di un deck, due varianti di landing e un'esplorazione di brand. L'equivalente ospitato — ipotizzando un piano "creator" da $30/mese con addebiti per superamento — costerebbe circa $50 per lo stesso lavoro, ti darebbe meno iterazioni e ti legherebbe a un solo modello.
Se vuoi spendere meno, sostituisci Claude Sonnet con DeepSeek V3.2 e la giornata scende sotto $1. Il punto non è che un modello sia quello giusto: è che il quadrante prezzo/qualità è nelle tue mani anziché incorporato in un livello di abbonamento.
Privacy e conformità
C'è una seconda ragione per cui BYOK conta: i prompt contengono il brand del tuo cliente.
L'inferenza ospitata significa instradare documenti di brand, nomi di prodotti non ancora annunciati, prezzi interni e creatività pre-lancio attraverso i server di una terza parte. La maggior parte delle aziende ha un'opinione al riguardo. Alcune hanno un contratto al riguardo.
Con BYOK, il viaggio di andata e ritorno del prompt è tra il tuo laptop e il provider del modello che hai già verificato (o ospitato in proprio). Open Design non è nel percorso. Non abbiamo alcun log da citare in giudizio, nessuna superficie di violazione da cui far trapelare dati, nessuna lacuna di audit da spiegare.
Cosa ti dà in pratica il "nessun log"
Per il lavoro di agenzia, i settori regolamentati o qualsiasi cosa pre-lancio, questa è l'unica posizione che regge. Se una revisione di sicurezza chiede "dove vanno i nostri asset di brand?", la risposta è "al provider del modello nel nostro contratto, e da nessun'altra parte", non "a una dashboard di un fornitore che non controlliamo". Ospitare in proprio un endpoint Ollama o vLLM stringe ulteriormente: i byte non lasciano mai affatto la tua rete. Questo è lo stesso compromesso esplorato in la verifica della realtà di BYOK, che è onesto su dove ci sono ancora gli spigoli grezzi: i modelli locali e i modelli di frontiera non sono intercambiabili sul gusto, e la superficie di prompt injection è tua da gestire.
Come cambiare provider a metà progetto
Uno dei vantaggi sottovalutati di BYOK è l'arbitraggio dei provider durante un progetto:
- Bozza: usa un modello economico (DeepSeek V3.2, Qwen 3) per la fase di domande e la prima iterazione
- Raffinamento: passa a Claude Sonnet o GPT-5 per i passaggi intermedi dove conta il gusto
- Contenuti sensibili: passa a un modello Ollama locale per i prompt riservati al cliente
- Rifinitura finale: brucia un passaggio sul modello più forte disponibile (Opus, GPT-5 Pro)
In Open Design, cambiare significa modificare due righe in .env.local. Non c'è migrazione, nessun nuovo onboarding, nessun upgrade di piano.
Un instradamento concreto per un singolo brief
Concretamente, un singolo brief di landing page potrebbe svolgersi così:
# 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-…Stesse skill, stesso design system su disco, stessi artefatti: è cambiato solo il motore dietro il flusso di lavoro. Poiché skill e sistemi sono solo file (SKILL.md e DESIGN.md), nulla del tuo setup è legato a un modello particolare. Questo è ciò che significa davvero possedere il flusso di lavoro: lo strumento si toglie di mezzo, e il modello è un parametro che cambi a seconda di ciò che il brief richiede.
Provalo
Clona il repository, imposta OPENAI_BASE_URL e OPENAI_API_KEY in .env.local, esegui pnpm tools-dev. Il daemon userà qualunque endpoint gli punti, con qualunque modello paghi, con qualunque cadenza tu voglia.
Questa è l'intera storia del BYOK. Non c'è un livello speciale, nessun flusso di upgrade, nessuna relazione di fatturazione con noi. Paghi il provider del modello, conservi le tue chiavi, conservi i tuoi prompt. Noi forniamo il livello.
Letture correlate
- Perché abbiamo costruito Open Design come un livello di skill, non come un prodotto: la scommessa dietro il rilasciare un livello sottile anziché un'app ospitata
- La verifica della realtà di BYOK: 5 cose che si rompono: i compromessi onesti e gli spigoli grezzi del portare la tua chiave
- 31 skill, 72 sistemi: come funziona la libreria di Open Design: i file
SKILL.md/DESIGN.mdche restano costanti indipendentemente dal modello che esegui