La capa de cómputo que conecta tus dispositivos
cadencIA convierte navegadores, móviles y nodos propios en una red de workers web-safe coordinada por Cloudflare. Primero jobs reales, memoria local conectada a scrapers y modelos ligeros; después, nodos nativos y cómputo cooperativo más profundo.
✓ Detect · WebGPU/Wasm · batería · visibilidad
✓ Pair · heartbeat PWA · claimToken temporal
✓ Route · requires · modelos · memoria
✓ Complete · resultToken · embedding opcional
Así aparece la red viva
Cada nodo es un dispositivo real que publica capacidades: navegador PWA, PC, móvil, nodo nativo, scraper local o provider como ML Trainer. Los pulsos representan jobs, memoria y resultados pasando por el control plane.
Lo que ya sostiene la red CadencIA
Primero jobs reales y capacidades medibles; después vendrá el P2P profundo.
Control plane global
CoreCloudflare Worker + Durable Objects mantienen presencia, cola de jobs, leases, resultados temporales y rate limits. Los dispositivos no necesitan estar en la misma WiFi.
Workers PWA y nodos nativos
La PWA detecta WebGPU/Wasm, carga modelos ligeros y reclama jobs web-safe en foreground. El nodo nativo queda reservado para trabajo durable, memoria local y tareas más largas.
Routing por capacidades
Cada job declara requisitos y cada worker anuncia capacidad real: runtime, modelo cargado, foreground, tokens y tiempo máximo. Si no encaja, el job espera o cae a otro camino.
Memoria local, scrapers y fallback cloud
MiniLM en navegador indexa snippets y resultados importados desde scrapers locales. Los nodos nativos custodiarán la memoria durable; el Gateway decidirá cloud fallback dentro de cupos.
ML Trainer entra como capacidad viva del nodo
Un PC o servidor local puede entrenar modelos grandes/custom con ML Trainer y publicarlos hacia CadencIA como proveedor compatible con OpenAI. El Gateway sigue gobernando permisos, cupos y fallback; el nodo solo anuncia que esa capacidad existe y está lista.
El ciclo de vida de un job distribuido
Del Assistant al mejor dispositivo visible y vuelta por el control plane global.
El Assistant crea el job
El navegador emisor envía prompt, modelo y requisitos web_safe al endpoint público.
Token de resultado
La API devuelve jobId y resultToken temporal para consultar solo ese resultado.
Filtro de capacidades
El scheduler compara runtime, foreground, modelo cargado, tokens y lease máximo.
Claim del worker
Una PWA visible con Aceptar jobs web reclama el trabajo usando su claimToken.
Ejecución local
El receptor usa regla local, Transformers.js o WebLLM ya cargado; no descarga modelos después de reclamar.
Complete y polling
El resultado vuelve al coordinator y el Assistant lo lee con el resultToken.
Cada nodo emite un Health Vector
La red no asigna tareas al azar. Combina runtime, memoria, batería, visibilidad, modelos cargados, benchmark e historial para decidir quién procesa qué.
+ w₂ · Battery%
+ w₃ · 1 / Latency
+ w₄ · Stability
La red es la infraestructura, no el espectáculo
La UI debe enseñar qué dispositivo está vivo, qué acepta y por qué recibe o no un job.
Mapa de capacidades
El dashboard muestra navegador local, workers registrados, modelos disponibles y estado foreground para que el usuario entienda la red sin leer logs.
Memoria operativa
Embeddings locales, telemetría y datos de scrapers convierten resultados, errores, documentos y benchmarks en señales reutilizables para el siguiente routing.
Economía de cupos
Los modelos cloud entran como fallback gobernado por presupuesto, proveedor y organización; el nodo no custodia llaves ni decide gasto solo.
Antes de prometer ciencia ficción,
cadencIA mide lo que ya puede ejecutar.
El navegador ya puede ser worker web-safe. El teléfono puede aceptar jobs si está visible. El PC puede cargar modelos ligeros. La memoria puede alimentarse de scrapers locales sin exponer llaves ni forzar dispositivos pequeños. CadencIA ordena esas capacidades para que Cadences gaste menos, preserve más privacidad y use el hardware que ya existe.
De workers locales a colmena útil
Bootstrap desde dispositivos reales: PWA, nodos nativos y equipos propios antes de prometer cómputo distribuido masivo.
Phase 0 · Centinelas
Workers PWA reales coordinados por Cloudflare: health, benchmark, modelos web, memoria local, conector scraper y jobs web_safe distribuidos desde el Assistant.
- Worker PWA emparejable
- Assistant distribuye cómputo
- Memoria + scraper connector
Phase 1 · Alpha cerrada
Nodos autenticados en cadences.app aceptan jobs pequeños, memoria durable, fuentes scraper/documento y routing híbrido a modelos cloud dentro de cupos baratos o gratuitos.
- Identidad de nodo
- Memoria durable por scope
- Triage local + fallback cloud
Phase 2 · Memoria del enjambre
Los nodos generan embeddings de telemetría, resultados y capacidades. El scheduler aprende qué dispositivo conviene para cada tipo de trabajo.
- Índice local de embeddings
- Búsqueda híbrida de eventos
- Trust score basado en historial
Phase 3 · Cómputo cooperativo
Inferencia distribuida opt-in para tareas concretas. Primero modelos ligeros y medianos, con verificación de resultados antes de escalar a sharding complejo.
- Scheduler multi-dispositivo
- Verificación de outputs
- Federación de hives locales