AURA turns heterogeneous machines into useful AI infrastructure.
QRX hides model formats and backend complexity behind automatic hardware discovery, signed runtime packages, governed model catalogs and local-to-network scheduling.
Automatic is the beginner path.
Users should not have to choose CUDA capability, GGUF quantization, MLX packages or individual MoE experts. AURA detects what the machine can actually do and selects a compatible verified path.
Signed model and runtime supply chain.
Runtime announcements bind publisher identity, package/platform/backend requirements and content hashes. Model catalogs bind model version, architecture, format, quantization, license, capability and manifest root.
A different control model.
QRX is not claiming hyperscaler capacity today. Its advantage is architectural: local-first execution, open provider participation, explicit provenance and QRX-native storage/payment integration.
| Dimension | Typical centralized AI cloud | QRX / AURA direction |
|---|---|---|
| Data path | Request normally leaves the device for provider infrastructure. | Compatible jobs can stay local; larger jobs can be routed to QRX providers. |
| Compute ownership | Provider-owned datacenters. | Heterogeneous community/provider hardware with capability-based roles. |
| Runtime trust | Provider controls runtime/model deployment. | Signed runtime packages, content hashes, governed model manifests and provenance rules. |
| Storage | Separate cloud storage/product. | QRX Drive can be the content-addressed distribution/storage layer. |
| Payment | Account, subscription or API billing. | QUB-funded job escrow and provider settlement at the protocol/service layer. |
| Offline | Often limited to separate local products. | Local execution is a first-class path where the runtime/model fits the device. |
| Lock-in | Cloud-specific API, account and deployment stack. | Multiple runtime adapters and a QRX-native model/runtime distribution layer. |
Small machines still have a role.
The 0.0.9 catalog direction includes Nano/Edge models and larger Qwen/Kimi/DeepSeek families. A host that cannot run a large LLM can still contribute routing, verification, cache, relay, pre/post processing or Drive capacity.
Nano / Edge
Small Qwen, DeepSeek-distill and Ministral-class choices allow useful local work on constrained hosts.
Pods / MoE
Provider pods can advertise inference, router, embedding, RAG, verification and model-cache roles, with expert locality and predictive prefetch.
Drive-first distribution
Verified local CAS and QRX-native supply are preferred; governed HTTPS origin fallback is a bootstrap/fallback mechanism, not the trust root.