Flujo de diseño BYOK: ejecuta Claude, Codex o Qwen con tu propia clave
La mayoría de las herramientas de diseño con IA añaden discretamente un margen a cada token que gastas. Open Design adopta la postura opuesta: trae tu propia clave de modelo, paga directamente al proveedor y mantén el control total de dónde se ejecuta la inferencia. Así funciona realmente la capa BYOK.
Si has usado un producto de diseño con IA alojado en 2026, probablemente hayas notado que la factura va subiendo. Una suscripción sobre un cargo por puesto, superpuesto a un margen de inferencia que nadie publica. Las cuentas son opacas a propósito.
Open Design no ejecuta inferencia. No tenemos un margen sobre los tokens. Todo el flujo de trabajo está construido en torno a bring-your-own-key (BYOK): apuntas el daemon a cualquier endpoint compatible con OpenAI, pegas tu propia clave de API y listo.
Este artículo explica por qué tomamos esa decisión, cómo funciona internamente y qué cambia realmente en tu flujo de trabajo diario. Si quieres el argumento filosófico más amplio detrás de esto, por qué construimos Open Design como una capa de skills, no como un producto es la pieza complementaria; esta es la versión práctica.
Qué significa realmente «BYOK» aquí
Hay dos definiciones de BYOK dando vueltas en el espacio de las herramientas de IA, y no son lo mismo:
- BYOK superficial: la herramienta te deja pegar una clave, pero sigue enrutando la inferencia a través de sus servidores, registra tus prompts y puede aplicar límites de tasa.
- BYOK real: la herramienta llama al proveedor del modelo directamente desde tu máquina (o tu infraestructura). Tus prompts nunca tocan los servidores del proveedor de la herramienta. El proveedor no se queda ningún margen.
Open Design es del segundo tipo. El daemon hace llamadas HTTP a cualquier endpoint que configures, con tu clave, desde tu máquina. No hacemos de proxy. No registramos nada. No vemos tus prompts.
A dónde va realmente la llamada
Cuando el daemon recoge un trabajo, compone el prompt —incorporando los archivos SKILL.md y DESIGN.md relevantes para la tarea— y luego hace una única solicitud HTTP a la base URL que hayas configurado. La respuesta vuelve en streaming a tu máquina, el agente escribe el artefacto en disco, y ese es todo el ciclo. No hay ningún servidor de Open Design en la ruta. El mismo daemon que descubre tus skills también es dueño de la llamada de red, por eso «¿dónde se ejecuta esto?» es un ajuste y no una conversación de ventas.
El adaptador compatible con OpenAI
La mayoría de los endpoints de inferencia de IA en 2026 hablan la API OpenAI Chat Completions. La usamos como el protocolo de mínimo común denominador. Si tu proveedor la habla (y casi todos lo hacen), tienes soporte por defecto: sin plugin, sin integración por proveedor que esperar.
Proveedores a los que puedes apuntarlo
| Proveedor | Forma típica de la base URL | Bueno para |
|---|---|---|
| OpenAI | https://api.openai.com/v1 | gpt-image-2, gpt-5.x, las pasadas generales más potentes |
| Anthropic | shim de compatibilidad OpenAI, o el adaptador dedicado de Claude | refinamiento con mucho criterio, briefs largos |
| DeepSeek | https://api.deepseek.com/v1 | borradores de contexto largo a bajo coste |
| Groq | base URL del proveedor | ciclos de borrador de baja latencia |
| OpenRouter | https://openrouter.ai/api/v1 | cualquier modelo de frontera, una sola relación de facturación |
| vLLM / TGI / Ollama autoalojados | tu propio host, p. ej. http://localhost:11434/v1 | trabajo totalmente local y confidencial del cliente |
| Qwen / Kimi / Hermes | base URL del proveedor | modelos regionales con endpoints compatibles con OAI |
La lista no es una allowlist con valores fijos: es simplemente donde la gente suele acabar. Cualquier cosa que responda a la forma de Chat Completions funciona.
Dos campos, y luego reiniciar
La configuración son dos campos:
OPENAI_BASE_URL=https://api.deepseek.com/v1
OPENAI_API_KEY=sk-…Colócalos en .env.local, reinicia el daemon, y ya estás en un modelo distinto. Cambiar a una máquina local con Ollama para un proyecto sensible son las mismas dos líneas:
OPENAI_BASE_URL=http://localhost:11434/v1
OPENAI_API_KEY=ollamaNo hay ningún registro de modelos que actualizar, ninguna cuenta que volver a vincular, ninguna migración. La clave y el endpoint son toda la superficie.
Por qué esto importa para el trabajo de diseño
Los flujos de trabajo de diseño tienen una forma de coste específica que a los productos de inferencia alojada se les da mal:
- La iteración es la unidad de trabajo. Una pasada de diseño real significa entre 30 y 50 ciclos de prompt, no tres. Los planes alojados imponen límites duros al llegar a la marca de los 50 ciclos.
- El contexto largo es la norma. Un brief serio implica documentos de marca, trabajo previo, especificaciones de sistema e imágenes de referencia. Ese contexto desborda los presupuestos de tokens de las interfaces alojadas.
- La elección de modelo debería ser ad hoc. Algunas pasadas quieren un modelo rápido y barato. Algunas quieren el más potente disponible. Algunas quieren un modelo local para contenido sensible. Un producto alojado elige uno por ti.
BYOK soluciona los tres. Pagas por token, eliges el modelo y no te limitan.
La iteración deja de estar racionada
Este es el que cambia discretamente tu forma de trabajar. Cuando cada ciclo extra se contabiliza contra un plan, empiezas a autocensurarte: te quedas con el tercer borrador porque el cuarto se siente caro. Con BYOK, el coste marginal de una pasada más son unos pocos céntimos en el proveedor del modelo, así que la decisión vuelve a ser sobre el trabajo, no sobre el contador. El tercer borrador suele ser donde el diseño se pone bueno; una herramienta que grava la iteración está gravando justo el paso que importa.
¿Y el coste?
Una preocupación habitual: «Si pago directamente, ¿no saldrá más caro?».
En la práctica, no. Aquí tienes un día típico de trabajo de diseño en nuestro uso interno:
| Tarea | Tokens | Proveedor | Coste |
|---|---|---|---|
| Recepción del brief (3 documentos) | 30K de entrada | Claude Sonnet | $0,09 |
| Pasada del primer borrador | 80K de entrada + 20K de salida | Claude Sonnet | $0,54 |
| 5 ciclos de iteración | 250K de entrada + 80K de salida | Claude Sonnet | $1,95 |
| Pulido final | 50K de entrada + 30K de salida | Claude Opus (una pasada) | $1,35 |
| Total del día | ~$3,93 |
Eso es una presentación, dos variantes de landing y una exploración de marca. El equivalente alojado —asumiendo un plan «creator» de $30/mes con cargos por exceso— costaría alrededor de $50 por el mismo trabajo, te daría menos iteraciones y te ataría a un solo modelo.
Si quieres abaratarlo, cambia Claude Sonnet por DeepSeek V3.2 y el día baja por debajo de $1. La cuestión no es que un modelo sea el correcto, sino que el dial de precio/calidad está en tus manos en lugar de venir cocinado en un nivel de suscripción.
Privacidad y cumplimiento
Hay una segunda razón por la que BYOK importa: los prompts contienen la marca de tu cliente.
La inferencia alojada significa enrutar documentos de marca, nombres de producto aún no anunciados, precios internos y creatividades previas al lanzamiento a través de los servidores de un tercero. La mayoría de las empresas tienen una opinión al respecto. Algunas tienen un contrato sobre ello.
Con BYOK, el viaje de ida y vuelta del prompt es entre tu portátil y el proveedor del modelo que ya has verificado (o autoalojado). Open Design no está en el bucle. No tenemos ningún registro que pueda ser citado judicialmente, ninguna superficie de brecha de la que filtrar, ningún hueco de auditoría que explicar.
Qué te aporta «sin registro» en la práctica
Para el trabajo de agencia, las industrias reguladas o cualquier cosa previa al lanzamiento, esta es la única postura que se sostiene. Si una revisión de seguridad pregunta «¿a dónde van nuestros activos de marca?», la respuesta es «al proveedor del modelo de nuestro contrato, y a ningún otro sitio», no «a un panel de un proveedor que no controlamos». Autoalojar un endpoint de Ollama o vLLM lo aprieta aún más: los bytes nunca salen de tu red en absoluto. Este es el mismo compromiso que se explora en el examen de realidad de BYOK, que es honesto sobre dónde siguen estando las aristas: los modelos locales y los modelos de frontera no son intercambiables en cuanto a criterio, y la superficie de inyección de prompts la asumes tú.
Cómo cambiar de proveedor a mitad de proyecto
Uno de los beneficios infravalorados de BYOK es el arbitraje de proveedores durante un proyecto:
- Borrador: usa un modelo barato (DeepSeek V3.2, Qwen 3) para el formulario de preguntas y la primera iteración
- Refinamiento: cambia a Claude Sonnet o GPT-5 para las pasadas intermedias donde el criterio importa
- Contenido sensible: pásate a un modelo local de Ollama para prompts confidenciales del cliente
- Pulido final: gasta una pasada en el modelo más potente disponible (Opus, GPT-5 Pro)
En Open Design, cambiar es editar dos líneas en .env.local. No hay migración, ni reincorporación, ni mejora de plan.
Un enrutamiento trabajado para un brief
Concretamente, un único brief de landing page podría desarrollarse así:
# 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-…Los mismos skills, el mismo sistema de diseño en disco, los mismos artefactos: solo cambió el motor detrás del flujo de trabajo. Como los skills y los sistemas son simplemente archivos (SKILL.md y DESIGN.md), nada de tu configuración está atado a un modelo concreto. Esto es lo que significa realmente ser dueño del flujo de trabajo: la herramienta se quita de en medio, y el modelo es un parámetro que cambias según lo exija el brief.
Pruébalo
Clona el repositorio, configura OPENAI_BASE_URL y OPENAI_API_KEY en .env.local, ejecuta pnpm tools-dev. El daemon usará el endpoint al que lo apuntes, con el modelo que pagues, en el horario que quieras.
Esa es toda la historia de BYOK. No hay ningún nivel especial, ningún flujo de mejora, ninguna relación de facturación con nosotros. Pagas al proveedor del modelo, conservas tus claves, conservas tus prompts. Nosotros proporcionamos la capa.
Lecturas relacionadas
- Por qué construimos Open Design como una capa de skills, no como un producto: la apuesta detrás de enviar una capa fina en lugar de una app alojada
- El examen de realidad de BYOK: 5 cosas que se rompen: los compromisos honestos y las aristas de traer tu propia clave
- 31 skills, 72 sistemas: cómo funciona la biblioteca de Open Design: los archivos
SKILL.md/DESIGN.mdque permanecen constantes sin importar qué modelo ejecutes