Fluxo de design BYOK: rode Claude, Codex ou Qwen com sua própria chave
A maioria das ferramentas de design com IA adiciona discretamente uma margem a cada token que você gasta. O Open Design adota a postura oposta — traga a chave do seu próprio modelo, pague o provedor diretamente e mantenha controle total sobre onde a inferência roda. Veja como a camada BYOK funciona de verdade.
Se você usou algum produto de design com IA hospedado em 2026, provavelmente notou a conta subindo aos poucos. Uma assinatura em cima de uma cobrança por assento, sobreposta a uma margem de inferência que ninguém divulga. A conta é opaca de propósito.
O Open Design não roda inferência. Não temos margem sobre tokens. Todo o fluxo de trabalho é construído em torno de bring-your-own-key (BYOK) — você aponta o daemon para qualquer endpoint compatível com OpenAI, cola sua própria API key e pronto.
Este post explica por que fizemos essa escolha, como ela funciona por baixo dos panos e o que ela realmente muda no seu dia a dia. Se você quer o argumento filosófico mais amplo por trás disso, por que construímos o Open Design como uma camada de skills, não um produto é o texto complementar — este aqui é a versão prática.
O que “BYOK” realmente significa aqui
Existem duas definições de BYOK circulando pelo espaço de ferramentas de IA, e elas não são a mesma coisa:
- BYOK de fachada — a ferramenta deixa você colar uma chave, mas ainda roteia a inferência pelos servidores dela, registra seus prompts e pode aplicar limites de taxa.
- BYOK de verdade — a ferramenta chama o provedor do modelo diretamente da sua máquina (ou da sua infraestrutura). Seus prompts nunca tocam os servidores do fornecedor. O fornecedor não tira margem.
O Open Design é do segundo tipo. O daemon faz chamadas HTTP para o endpoint que você configurar, com a sua chave, a partir da sua máquina. Não fazemos proxy. Não registramos nada. Não vemos seus prompts.
Para onde a chamada realmente vai
Quando o daemon pega um job, ele compõe o prompt — reunindo os arquivos SKILL.md e DESIGN.md relevantes para a tarefa — e então faz uma única requisição HTTP para a base URL que você definiu. A resposta volta em streaming para a sua máquina, o agente grava o artefato em disco, e esse é o ciclo inteiro. Não há nenhum servidor do Open Design no caminho. O mesmo daemon que descobre suas skills também é dono da chamada de rede, e é por isso que “onde isso roda?” é uma configuração, não uma conversa de vendas.
O adaptador compatível com OpenAI
A maioria dos endpoints de inferência de IA em 2026 fala a API OpenAI Chat Completions. Usamos isso como o protocolo de menor denominador comum. Se o seu provedor a fala (e quase todos falam), você já é suportado por padrão — sem plugin, sem integração por provedor para esperar.
Provedores para os quais você pode apontá-lo
| Provedor | Formato típico de base URL | Bom para |
|---|---|---|
| OpenAI | https://api.openai.com/v1 | gpt-image-2, gpt-5.x, as passadas gerais mais fortes |
| Anthropic | shim de compatibilidade OpenAI, ou o adaptador dedicado do Claude | refinamento que exige bom gosto, briefings longos |
| DeepSeek | https://api.deepseek.com/v1 | rascunho de contexto longo com bom custo-benefício |
| Groq | base URL do provedor | ciclos de rascunho de baixa latência |
| OpenRouter | https://openrouter.ai/api/v1 | qualquer modelo de fronteira, uma única relação de faturamento |
| vLLM / TGI / Ollama auto-hospedados | seu próprio host, ex.: http://localhost:11434/v1 | trabalho totalmente local e confidencial do cliente |
| Qwen / Kimi / Hermes | base URL do provedor | modelos regionais com endpoints compatíveis com OAI |
A lista não é uma allowlist codificada — é apenas onde as pessoas costumam parar. Qualquer coisa que responda ao formato Chat Completions funciona.
Dois campos, depois reinicie
A configuração são dois campos:
OPENAI_BASE_URL=https://api.deepseek.com/v1
OPENAI_API_KEY=sk-…Coloque-os no .env.local, reinicie o daemon e você está em outro modelo. Mudar para uma caixa Ollama local em um projeto sensível são as mesmas duas linhas:
OPENAI_BASE_URL=http://localhost:11434/v1
OPENAI_API_KEY=ollamaNão há registro de modelo para atualizar, nenhuma conta para revincular, nenhuma migração. A chave e o endpoint são toda a superfície.
Por que isso importa para o trabalho de design
Os fluxos de design têm um formato de custo específico em que os produtos de inferência hospedada vão mal:
- A iteração é a unidade de trabalho. Uma passada de design de verdade significa de 30 a 50 ciclos de prompt, não três. Os planos hospedados limitam pesado na marca dos 50 ciclos.
- Contexto longo é a norma. Um briefing sério envolve documentos de marca, trabalhos anteriores, especificações de sistema e imagens de referência. Esse contexto estoura os orçamentos de token das UIs hospedadas.
- A escolha do modelo deveria ser ad-hoc. Algumas passadas pedem um modelo rápido e barato. Algumas pedem o mais forte disponível. Algumas pedem um modelo local para conteúdo sensível. Um produto hospedado escolhe um por você.
O BYOK resolve os três. Você paga por token, escolhe o modelo e não é estrangulado por limites.
A iteração deixa de ser racionada
Esta é a que muda discretamente como você trabalha. Quando cada ciclo extra é medido contra um plano, você começa a se autocensurar — fica com o terceiro rascunho porque o quarto parece caro. No BYOK, o custo marginal de mais uma passada é alguns centavos no provedor do modelo, então a decisão volta a ser sobre o trabalho, não sobre o medidor. O terceiro rascunho costuma ser onde o design fica bom; uma ferramenta que tributa a iteração está tributando exatamente o passo que importa.
E quanto ao custo?
Uma preocupação comum: “Se eu estou pagando diretamente, não vai sair mais caro?”
Na prática, não. Veja um dia típico de trabalho de design no nosso uso interno:
| Tarefa | Tokens | Provedor | Custo |
|---|---|---|---|
| Recepção do briefing (3 docs) | 30K de entrada | Claude Sonnet | US$ 0,09 |
| Primeira passada de rascunho | 80K de entrada + 20K de saída | Claude Sonnet | US$ 0,54 |
| 5 ciclos de iteração | 250K de entrada + 80K de saída | Claude Sonnet | US$ 1,95 |
| Polimento final | 50K de entrada + 30K de saída | Claude Opus (uma passada) | US$ 1,35 |
| Total do dia | ~US$ 3,93 |
Isso dá um deck, duas variações de landing e uma exploração de marca. O equivalente hospedado — supondo um plano “creator” de US$ 30/mês com cobranças por excedente — custaria cerca de US$ 50 pelo mesmo trabalho, daria menos iterações e prenderia você a um único modelo.
Se você quiser ficar mais barato, troque o Claude Sonnet pelo DeepSeek V3.2 e o dia cai para menos de US$ 1. A questão não é que um modelo seja o certo — é que o controle de preço/qualidade está nas suas mãos, em vez de embutido em um nível de assinatura.
Privacidade e conformidade
Há um segundo motivo pelo qual o BYOK importa: os prompts contêm a marca do seu cliente.
Inferência hospedada significa rotear documentos de marca, nomes de produtos não anunciados, preços internos e criações pré-lançamento pelos servidores de um terceiro. A maioria das empresas tem uma opinião sobre isso. Algumas têm um contrato sobre isso.
Com BYOK, a ida e volta do prompt é entre o seu laptop e o provedor de modelo que você já avaliou (ou auto-hospedou). O Open Design não está no circuito. Não temos log para intimar, nenhuma superfície de violação para vazar, nenhuma lacuna de auditoria para explicar.
O que “sem log” compra na prática
Para trabalho de agência, setores regulados ou qualquer coisa pré-lançamento, esta é a única postura que se sustenta. Se uma revisão de segurança perguntar “para onde vão nossos ativos de marca?”, a resposta é “para o provedor de modelo no nosso contrato, e para mais lugar nenhum” — não “para o dashboard de um fornecedor que não controlamos.” Auto-hospedar um endpoint Ollama ou vLLM aperta isso ainda mais: os bytes nunca saem da sua rede. Esse é o mesmo trade-off explorado no teste de realidade do BYOK, que é honesto sobre onde as arestas ainda estão — modelos locais e modelos de fronteira não são intercambiáveis em bom gosto, e você é dono da superfície de prompt injection por conta própria.
Como trocar de provedor no meio do projeto
Um dos benefícios subestimados do BYOK é a arbitragem de provedores durante um projeto:
- Rascunho — use um modelo barato (DeepSeek V3.2, Qwen 3) no formulário de perguntas e na primeira iteração
- Refinamento — mude para Claude Sonnet ou GPT-5 nas passadas intermediárias em que o bom gosto importa
- Conteúdo sensível — troque para um modelo Ollama local para prompts confidenciais do cliente
- Polimento final — gaste uma passada no modelo mais forte disponível (Opus, GPT-5 Pro)
No Open Design, trocar é editar duas linhas no .env.local. Não há migração, nenhum reonboarding, nenhum upgrade de plano.
Um roteamento trabalhado para um briefing
Concretamente, um único briefing de landing-page poderia rodar assim:
# 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-…As mesmas skills, o mesmo design system em disco, os mesmos artefatos — só o motor por trás do fluxo de trabalho mudou. Como skills e sistemas são apenas arquivos (SKILL.md e DESIGN.md), nada na sua configuração está atrelado a um modelo específico. É isso que realmente significa ser dono do fluxo de trabalho: a ferramenta sai do caminho, e o modelo é um parâmetro que você muda conforme o briefing exige.
Experimente
Clone o repositório, defina OPENAI_BASE_URL e OPENAI_API_KEY no .env.local, rode pnpm tools-dev. O daemon usará qualquer endpoint para o qual você apontá-lo, com qualquer modelo que você pague, na agenda que você quiser.
Essa é toda a história do BYOK. Não há nível especial, nenhum fluxo de upgrade, nenhuma relação de faturamento conosco. Você paga o provedor do modelo, você mantém suas chaves, você mantém seus prompts. Nós fornecemos a camada.
Leitura relacionada
- Por que construímos o Open Design como uma camada de skills, não um produto — a aposta por trás de entregar uma camada fina em vez de um app hospedado
- O teste de realidade do BYOK: 5 coisas que quebram — os trade-offs honestos e as arestas de trazer sua própria chave
- 31 skills, 72 sistemas: como funciona a biblioteca do Open Design — os arquivos
SKILL.md/DESIGN.mdque permanecem constantes não importa qual modelo você rode