WorldScript Studio: cómo dejar la IA como opción y no como dependencia crítica
El estudio de escritura open source publica en su versión v1.28.8 los cuatro mecanismos que permiten usar el producto sin clave, sin modelo y sin red.
Un buen número de aplicaciones con IA suspenden una prueba sencilla: revocar la clave de API, apagar la red y volver a abrir el programa. No falla la función de IA, falla el producto entero. Spinners que no resuelven, una página de ajustes que revienta, el arranque bloqueado esperando a que responda un modelo. WorldScript Studio, un estudio de escritura open source donde la IA ayuda con esquemas, personajes y correcciones de prosa, se ha construido justo al revés. En su versión v1.28.8 (commit 2d9157c0) el proyecto documenta los mecanismos que lo sostienen.
Un punto de paso y puertas que lanzan error
Todas las capacidades —generación de texto, JSON estructurado, streaming, imágenes— pasan por un único servicio de proveedor. Detrás hay adaptadores para Gemini, OpenAI, OpenRouter, Anthropic y cualquier servidor local compatible con la API de OpenAI (Ollama, LM Studio) elegido por base URL. Una factoría los normaliza a un tipo común del SDK de Vercel AI. La gracia no es abstraer por abstraer: es que "la IA está caída" tenga exactamente un sitio donde ocurrir. Ninguna función habla con un proveedor directamente, así que ninguna puede desarrollar por su cuenta su propia lógica de reintentos, su propio manejo de claves o su propia definición de "sin conexión". Las claves se almacenan cifradas; en el build de navegador, bajo una clave AES-256-GCM aleatoria y no extraíble en IndexedDB, y ningún SDK de proveedor ve el almacenamiento.
El enrutado es visible para el usuario: cuatro modos —hybrid, cloud, local y eco— con hybrid por defecto. Lo relevante es que las reglas se aplican como código en ese punto de paso, no como convención repartida por los componentes. Una puerta que lanza una excepción se puede probar; una que "debería comprobarse", no. El mismo archivo restringe el entrenamiento (fine-tuning LoRA) a proveedores locales mediante lista blanca, porque los datos de entrenamiento son el manuscrito. Conviene fijarse en el alcance: eso cubre la ruta de entrenamiento, no es una garantía de privacidad general para cualquier función.
Fallos tipados y un respaldo que puede negarse
Los errores no son una sola cosa. Un límite de tasa no es una clave incorrecta, y ninguno de los dos se parece a "el portátil está sin red". La taxonomía separa lo transitorio (red, rate limit), que sí merece un reintento, de lo determinista (autenticación, política, petición inválida), que repetiría el mismo fallo, y de lo offline, que no tiene sentido hasta que vuelva la conexión. Cada clase lleva una clave de mensaje estable, así que la interfaz dice "revisa tu clave" o "estás sin conexión" en vez de soltar un error genérico. El reintento además falla rápido en las llamadas condenadas en lugar de esperar con paciencia educada a una petición que nunca va a funcionar.
Cuando una llamada es terminalmente inalcanzable, algunas funciones pueden caer a generadores heurísticos locales registrados por tarea. Si no hay nada registrado para esa tarea, el registro devuelve null y el llamante mantiene su comportamiento: se le dice al usuario que la función necesita un proveedor configurado. Lo que el registro no hace nunca es inventar una respuesta que suene plausible para tapar la ausencia de modelo.
La prueba de revocar la clave es barata y casi nadie la pasa, y ahí está el interés del asunto: no es WorldScript en concreto, sino el patrón. La IA como capacidad opcional, con un fallo tipado, explicado y contenido, en vez de como infraestructura que sostiene el arranque. Queda por ver si el diseño aguanta igual de bien cuando el catálogo de funciones que dependen del modelo crezca.
