CadencIA: del navegador al nodo nativo como capa de compute distribuido
CadencIA nace de una pregunta práctica: ¿y si Cadences.app no tuviera que depender siempre de un único backend remoto para ejecutar trabajo de IA? En vez de tratar cada dispositivo como un simple cliente, podemos tratarlo como una pieza potencial de cómputo: un navegador con WebGPU, una PWA en foreground, un nodo nativo en la LAN, un fallback cloud gobernado por cuotas o una máquina con modelos locales.
Estado real, 27 mayo 2026
La novedad importante ya no es solo que una PWA pueda medirse a sí misma. Ahora el Assistant de la consola tiene un modo Distribuir cómputo: el navegador emisor crea un job público, recibe un jobId y un resultToken temporal, y consulta el resultado mientras otro dispositivo visible lo reclama, ejecuta y completa.
Esto funciona más allá de la red local porque el plano de control vive en Cloudflare. No es P2P directo todavía: el flujo actual es Samsung/iPhone/PC -> CadencIA API -> PWA worker -> CadencIA API -> Assistant. La restricción deliberada es que el receptor debe estar emparejado, en foreground, aceptando jobs web y con el modelo requerido ya cargado si el job lo pide.
El smoke test desplegado valida el ciclo completo: heartbeat de worker, announce de job con modelo requerido, claim por capacidades, complete y lectura del resultado con token. La prueba física multi-dispositivo queda como siguiente validación de producto, pero el contrato de backend ya no es una maqueta.
1 El problema: la IA ya no vive en un solo sitio
Durante años el patrón dominante ha sido sencillo: la aplicación recoge contexto, llama a un proveedor remoto y espera una respuesta. Ese modelo sigue siendo útil, pero se queda corto cuando el producto necesita privacidad, baja latencia, control de coste o ejecución cerca del usuario.
En Cadences convivimos con muchos tipos de cómputo: Workers AI para tareas cloud, navegadores que ya tienen WebGPU, apps de escritorio con acceso a disco y periféricos, nodos nativos en la LAN y modelos locales que no deberían salir de una máquina. La pregunta deja de ser qué provider usamos y pasa a ser qué dispositivo puede ejecutar este job concreto, ahora, con estas restricciones.
La tesis
CadencIA es la capa de compute distribuido de Cadences: registra capacidades, decide rutas, asigna jobs y permite que cada runtime aporte lo que sabe hacer sin convertir el producto en una dependencia rígida de un único backend.
2 Cadences AI Gateway y CadencIA no son lo mismo
La separación importante es conceptual. El Gateway pertenece al producto y al negocio. CadencIA pertenece a la ejecución.
Cadences AI Gateway
- Auth, clientes, organizaciones y permisos.
- Rate limits, facturación, trazas y coste por provider.
- Políticas de producto: qué se puede pedir, quién lo pide y bajo qué plan.
- Abstracción de proveedores cloud, cupos gratuitos/baratos y APIs externas.
CadencIA compute layer
- Identidad de nodos, health vectors y capacidades.
- Modelos disponibles, modelos cacheados, runtimes y restricciones de ejecución.
- Swarm registry, job coordinator, leases y complete.
- Ejecución local, privada, web-safe, LAN o fallback gobernado cuando convenga.
3 Arquitectura actual: control plane pequeño, workers heterogéneos
Cloudflare Worker API
Expone endpoints públicos y autenticados, valida tokens, aplica CORS y enruta a Durable Objects. Es la puerta de entrada del control plane.
Swarm Registry
Un Durable Object mantiene nodos vivos, último heartbeat, health vector, modelos anunciados y metadatos de runtime.
Job Coordinator
Otro Durable Object guarda la cola, aplica filtros por requisitos, decide el mejor peer libre y emite leases dinámicos.
Swarm memory
La siguiente capa registra telemetría, trabajos completados, fallos, latencias y modelos cacheados como memoria consultable del enjambre.
cadencia-node
Worker nativo en Rust: identidad Ed25519, health/GPU, servidor local LAN, job loop, executor e inferencia local opcional.
PWA Worker
Navegador foreground que detecta WebGPU/Wasm, carga modelos web bajo demanda y puede reclamar jobs web-safe con claimToken temporal.
4 Cómo se reparte un job
Un job no se asigna por intuición. El productor declara un payload y, si hace falta, un bloque requires. El worker que reclama envía sus capacidades: backend, runtime, memoria, modelos disponibles, si está en foreground, si es web-safe y cuánto trabajo puede aceptar.
{
"kind": "web_safe",
"payload": { "prompt": "Classify this message as positive or negative." },
"requires": {
"web_safe": true,
"foreground": true,
"runtime_in": ["webgpu", "wasm"],
"model": "distilbert-sentiment",
"max_job_secs_lte": 30,
"max_tokens_lte": 128
}
}| Campo | Qué protege |
|---|---|
web_safe | Evita que una PWA pública reclame trabajos con side effects o requisitos fuera del navegador. |
foreground | Garantiza que el usuario mantiene la página viva y visible mientras se ejecuta el job. |
runtime_in | Permite distinguir WebGPU, Wasm, native, CUDA o Metal sin acoplar el job a un dispositivo concreto. |
model | Solo se asigna a workers que ya han anunciado ese modelo como disponible. |
max_job_secs_lte | Calcula leases realistas: base 30s, margen sobre el límite declarado y máximo controlado. |
5 La PWA remota: útil, pero deliberadamente limitada
La parte más interesante del prototipo actual es que el navegador ya no es solo interfaz. La PWA detecta capacidades, ejecuta un benchmark corto, carga modelos con Transformers.js o WebLLM, se empareja con el control plane y aparece en el swarm como worker web.
Aun así, hay una regla importante: la PWA no descarga modelos después de reclamar un job. Solo anuncia rule-web-safe-triage y, si el usuario ya lo cargó, un modelo permitido como distilbert-sentiment, minilm-embeddings o un modelo WebLLM experimental. El API filtra ese listado con allowlist explícito.
La consola web ya separa tres estados que antes se confundían: modelo descargado en el navegador, modelo cargado en RAM y modelo disponible para reclamar jobs remotos. Esa distinción es la importante: un modelo cacheado mejora el arranque, pero solo un modelo cargado, permitido y anunciado como capacidad real puede entrar en el routing. Además, el laboratorio recuerda el chat por dispositivo usando el nodeId del navegador, no una única conversación global.
Heartbeat
Publica runtime, foreground, benchmark, modelos soportados, modelos cacheados y modelos ya cargados.
Claim
Requiere claimToken temporal, foreground y web_safe. Solo entra en jobs aptos para navegador.
Complete
Revalida foreground/web_safe, limita el resultado y completa el lease asignado.
6 Seguridad: no confiar en el navegador más de la cuenta
Diseño conservador
- El
clientNodeIdvisible no es secreto: el servidor deriva un nodeId aislado consha256("web-pwa:<clientNodeId>"). - El navegador recibe un
claimTokenefímero de cinco minutos. - Puede haber varios tokens vivos por TTL para que un heartbeat no invalide un complete en curso.
- Los endpoints públicos tienen rate limit por IP y no abren la cola general.
- Los resultados se limitan en tamaño y el complete exige de nuevo foreground/web_safe.
Esta no es una red anónima de ejecución arbitraria. Es un plano de control con límites claros: primero jobs web-safe, después pairing más fuerte, scopes reales por organización y workers nativos donde el navegador no llega.
7 Lo que ya funciona y lo que no queremos fingir
Ya funciona
- PWA pública emparejada por heartbeat y claimToken.
- Swarm registry con nodos nativos y PWAs visibles.
- Scheduler
global-org-best-free-v1con mejor nodo libre compatible. - Claim/complete para jobs web-safe y modelos web ya cargados.
- Assistant con modo
Distribuir cómputoy polling seguro medianteresultTokentemporal. - Memoria local en PWA con embeddings MiniLM separados del runtime de chat.
- Registro separado de modelos soportados, cacheados y cargados para no anunciar capacidades falsas.
- Chat de laboratorio persistido por dispositivo/navegador.
- API y PWA desplegadas en producción con smoke end-to-end del scheduler.
Sigue siendo laboratorio
- El scheduler es polling, todavía no push.
- La PWA solo trabaja en foreground.
- No hay scopes multi-org completos en producción.
- El pairing QR/deep-link aún está pendiente.
- La memoria del enjambre aún no está sincronizada entre nodos.
- La prueba física Samsung/iPhone aún debe hacerse con ambos dispositivos visibles.
- Los jobs pesados siguen perteneciendo mejor al nodo nativo.
8 Por qué esto importa para Cadences
La promesa no es que todo corra en el navegador ni que todo sea descentralizado por estética. La promesa es más sobria: tener una capa de ejecución que pueda elegir entre cloud, edge, navegador, escritorio y nodo local según el trabajo.
Para un CRM, eso puede ser clasificar texto sensible sin enviarlo a un provider externo. Para un sistema de voz, puede ser enrutar una transcripción a un worker local. Para un gateway de IA, puede ser elegir entre coste, latencia, privacidad y disponibilidad en cada request. Para una organización, puede ser aprovechar máquinas propias antes de pagar tokens remotos.
CadencIA convierte esa idea en infraestructura: health, capacidades, modelos, leases, resultados y políticas. Todavía pequeña. Ya funcionando. Lo suficientemente real como para dejar de ser una demo y empezar a parecer una plataforma.
Siguiente paso
El camino natural es cerrar pairing seguro por QR/deep-link, scopes por organización, jobs WebLLM más expresivos, capacidades explícitas de tools/internet y un adaptador del Cadences AI Gateway para que el producto pueda enrutar a CadencIA como un provider más, pero con memoria de capacidades reales y límites de coste por proveedor.
9 El siguiente vector: routing híbrido y memoria del enjambre
Hay una pieza intermedia muy potente entre “todo local” y “todo cloud”: nodos autenticados en cadences.app que puedan pedir ayuda a modelos potentes de Cadences —Cloudflare Workers AI, DeepSeek, Gemini, Groq u otros— dentro de cupos explícitos. El nodo no debería custodiar llaves de proveedor. Pide un job, declara contexto y restricciones, y el Gateway decide si se ejecuta local, en PWA, en nodo nativo o en un fallback cloud barato.
Esa estrategia permite bootstrap realista: usar modelos pequeños o embeddings locales para triage, privacidad y memoria; reservar proveedores potentes para pasos donde aportan valor; y mantener presupuestos por organización, nodo, usuario y tipo de tarea. CadencIA no sustituye al Gateway: le da señales de ejecución para que el Gateway gaste mejor.
La otra mitad es memoria. El indexador tipo “mempalace” que ya existe en whatsapp-local-agent —SQLite, chunks, embeddings locales, FTS5, búsqueda vectorial y RRF— encaja casi directo para telemetría del swarm. En vez de indexar solo mensajes, un nodo puede indexar eventos: health vectors, modelos cacheados, leases completados, errores, latencias, batería, GPU, estabilidad y resultados. Con eso el scheduler deja de ver un snapshot y empieza a consultar historia.
Local primero
Triage, embeddings y jobs privados se resuelven en el navegador o nodo propio cuando sea suficiente.
Cloud con cupo
Modelos potentes entran como fallback gobernado por presupuesto, proveedor y plan.
Memoria operativa
Embeddings de telemetría permiten buscar “qué nodos suelen cumplir este tipo de job”.