OpenDesign entre Windows, WSL, planes y proxies

Vigencia editorial: 12 de octubre de 2026. Los mecanismos de autenticación, modelos y límites dependen de cada proveedor y pueden cambiar.

“Local-first” suena a una sola computadora. En Windows con WSL, sin embargo, una computadora contiene dos entornos que comparten recursos pero no necesariamente ejecutables, credenciales ni sesiones.

La aplicación de OpenDesign puede vivir en Windows mientras Codex, Claude Code, OpenCode y los repositorios viven dentro de Ubuntu. En la pantalla todo parece local; desde el daemon son mundos distintos.

Esta frontera define mucho más que la instalación. Define quién ejecuta el modelo, dónde se guardan las credenciales y contra qué cuota se contabiliza cada generación.

Tres caminos hacia un modelo

OpenDesign puede llegar a un modelo por tres rutas conceptuales:

Ruta	Autenticación	Consumo
Local CLI	Autenticación del agente instalado	Plan o facturación API, según esa autenticación
BYOK / proveedor custom	Clave API	Cuenta o saldo API del proveedor
OpenDesign Cloud	Cuenta de OpenDesign	Créditos incluidos o comprados allí

Si OpenDesign lanza un Codex CLI autenticado con ChatGPT, el trabajo se descuenta de la cuota de Codex. Si lanza Claude Code autenticado con Pro o Max, consume ese plan. Si recibe una clave en el panel de proveedores, ya no está usando la sesión del CLI: realiza llamadas API.

La interfaz no cambia esta regla. La decide el camino efectivo que toma la request.

Por qué un CLI instalado en WSL puede no aparecer

Un daemon iniciado por una aplicación de Windows inspecciona el entorno de Windows. No necesariamente ve:

binarios instalados dentro de Linux;
el PATH de la shell de WSL;
configuraciones bajo el home de Ubuntu;
sesiones OAuth guardadas por los CLIs Linux;
variables exportadas en .bashrc o servicios de systemd.

Por eso tener codex, claude u opencode funcionando desde Ubuntu no garantiza que OpenDesign Desktop los muestre como Local CLI.

La solución más directa para conservar la aplicación nativa es duplicar los CLIs en Windows y autenticarlos allí. Las instalaciones quedan separadas, aunque consuman la misma cuota del plan.

OpenDesign Desktop en Windows
        ↓
Codex / Claude Code nativos
        ↓
Cuotas de ChatGPT y Claude

Si los agentes ya viven en WSL, la guía oficial de WSL2 recomienda ejecutar OpenDesign en ese mismo entorno. Así CLI, daemon, módulos y credenciales coinciden. La interfaz puede abrirse desde el navegador de Windows. Revisá también qué ejecutable resuelve od: Linux incluye una utilidad del sistema con ese nombre, ajena a OpenDesign.

Navegador Windows
        ↓
OpenDesign daemon en WSL
        ↓
CLIs y repositorios de WSL

El proxy como puente deliberado

Existe una tercera opción: exponer en WSL un proxy compatible con OpenAI y configurarlo como proveedor custom.

OpenDesign en Windows
        ↓
Proxy local en 127.0.0.1
        ↓
Proveedor externo

La conectividad Windows–WSL y las defensas SSRF del daemon también importan: OpenDesign bloquea por defecto endpoints privados/internos; si esa protección rechaza el destino, revisá la allowlist exacta documentada, sin abrir rangos amplios. Es una condición de despliegue que hay que probar. Seguridad del proxy.

Este camino no reutiliza automáticamente la cuota de Codex o Claude. OpenDesign cree que está hablando con una API; el proxy decide qué proveedor y credencial utiliza detrás.

El patrón permite adaptar protocolos y sesiones, pero publicar una API no habilita cualquier uso. OpenCode Go está pensado para tráfico de agentes de programación: exige un cliente identificable y una sesión estable. Un proxy no vuelve compatible un workload arbitrario; hay que verificar el cliente y el endpoint de cada modelo, que puede usar Responses, Chat Completions o Messages.

Un proxy no es necesariamente un parche. Puede convertirse en una frontera de control:

oculta la credencial real al cliente;
aplica allowlists de modelos;
agrega encabezados de sesión;
sanitiza logs;
impone límites y timeouts;
evita que cada aplicación conozca el proveedor final.

Pero cada responsabilidad agregada también convierte al proxy en infraestructura que alguien debe mantener.

Sesiones: el detalle que cambia el resultado

Un endpoint compatible no garantiza una conversación correctamente identificada. OpenCode Go solicita una sesión estable por conversación mediante información nativa del cliente o el encabezado x-opencode-session.

El proxy debe evitar dos extremos:

generar un ID nuevo en cada request, perdiendo continuidad y caching;
reutilizar un único ID global, mezclando proyectos y conversaciones.

La unidad correcta suele ser un thread o proyecto de OpenDesign:

x-opencode-session = hash(project_id + conversation_id)

La derivación no debe incluir prompts, secretos ni la API key.

Credencial real frente a credencial local

Cuando OpenDesign obliga a completar un campo API key para un proveedor custom, hay dos diseños posibles.

Reenviar la key real

OpenDesign guarda la key del proveedor y la transmite al proxy, que la reenvía.

Es simple, pero la credencial queda almacenada y circula por más componentes.

Separar las credenciales

OpenDesign utiliza un token local aleatorio. El proxy lo valida y obtiene la key real desde su propio entorno protegido.

OpenDesign        → token local
Proxy             → valida token local
Proveedor externo → recibe la key real

Esta separación limita el impacto de una exportación, un log accidental o una falla en el cliente. Para una instalación estable es la opción preferible.

Reglas mínimas para un proxy local

Un puente de este tipo debería cumplir al menos con estas condiciones:

escuchar únicamente en loopback salvo necesidad explícita;
no registrar Authorization, bodies completos ni variables sensibles;
mantener una sesión estable por conversación;
declarar un User-Agent identificable;
permitir sólo los modelos necesarios;
usar timeouts y límites de tamaño;
fallar de forma visible, sin cambiar silenciosamente de proveedor;
conservar una prueba mínima de health y descubrimiento de modelos.

Abrirlo en 0.0.0.0 transforma un puente local en un servicio accesible desde la red. Esa decisión exige autenticación, firewall y una revisión distinta.

Las cuotas siguen al proveedor efectivo

La regla para entender el gasto es seguir la request completa:

¿Quién recibió finalmente la llamada autenticada?

Codex CLI con sesión ChatGPT: cuota Codex.
Claude Code con sesión Pro/Max: cuota Claude.
API de OpenAI o Anthropic: facturación API.
Proxy hacia OpenCode Go: límites incluidos de Go.
Go con fallback a saldo habilitado: saldo Zen después del límite.
OpenDesign Cloud: créditos de OpenDesign.

La etiqueta del modelo en la interfaz puede confundir. Un modelo de OpenAI servido por OpenCode Go no consume el plan de ChatGPT; consume la asignación del proveedor que atendió la request.

Una arquitectura razonable para un entorno híbrido

Para preservar sesiones existentes y separar consumos, una distribución posible es:

Camino	Uso
OpenDesign → Codex Windows	Trabajo descontado del plan de Codex
OpenDesign → Claude Code Windows	Trabajo descontado del plan de Claude
OpenDesign → proxy WSL → OpenCode Go	Modelos económicos bajo los límites de Go
Orca → CLIs WSL	Desarrollo y coordinación existentes

La duplicación de CLIs no es elegante, pero mantiene claras las fronteras. Mover todo el daemon a WSL reduce duplicación, aunque renuncia a parte de la comodidad de la aplicación nativa.

Veredicto

La integración local no depende sólo de que dos procesos vivan en la misma computadora. Depende de que compartan el entorno correcto.

Instalar los CLIs en Windows es la ruta más simple para que OpenDesign Desktop consuma cuotas de los planes. Ejecutar el daemon en WSL es la ruta más coherente para reutilizar instalaciones existentes. Un proxy es la ruta más flexible cuando el proveedor ofrece una API y necesitamos controlar sesiones, credenciales o compatibilidad.

Ninguna opción gana siempre. La decisión correcta surge de elegir qué queremos preservar: comodidad de escritorio, sesiones existentes, control del tráfico o aislamiento de credenciales.