Teleodynamic Artificial Intelligence: Client-Side Rust Architectures for In-Browser Mini Models

Full report

On this page

Introduction to the Teleodynamic Paradigm in Edge Computing

The trajectory of artificial intelligence has historically been defined by a relentless drive toward centralization, massive parameter scaling, and the exogenous imposition of architectural design. However, a profound paradigm shift is emerging at the intersection of biological systems theory, decentralized edge computing, and browser-based runtimes. This shift is characterized by the concept of Teleodynamic Learning—a thermodynamically grounded approach to machine learning where functional organization, model architecture, and parameter adaptation co-evolve endogenously under strict resource constraints.1 Simultaneously, the maturation of the Rust programming language, alongside WebAssembly (WASM) and WebGPU standards, has transformed the web browser from a thin document viewer into a high-performance, parallelized compute environment capable of executing complex neural network operations locally.3 This synthesis enables the deployment of "mini models"—highly capable, parameter-efficient language and reasoning models operating within the strict memory and thermal constraints of client devices.6 This report provides an exhaustive architectural blueprint and theoretical analysis for constructing a client-side, in-browser machine learning infrastructure using Rust. By fusing the principles of Teleodynamic AI with the computational realities of the modern web platform—leveraging frameworks like Burn, the Origin Private File System (OPFS), and CubeCL—a new class of self-organizing, adaptive, and highly privacy-preserving local intelligence can be realized. The subsequent sections deconstruct the theoretical foundations of teleodynamics, detail the Rust-based execution infrastructure required to support it, analyze the strict memory constraints of the WebGPU environment, and formulate an end-to-end execution pipeline for parameter-efficient inference.

The Theoretical Substrate: Thermodynamics, Morphodynamics, and Teleodynamics

To engineer a system that genuinely mimics biological adaptability on a resource-constrained client device, it is necessary to first decouple machine learning from the static, externally mandated optimization loops that dominate contemporary deep learning. The theoretical substrate for this shift is derived from Terrence Deacon’s theory of emergent dynamics, as articulated in his work on the incomplete nature of biological systems.8 Deacon categorizes systemic complexity into three hierarchical strata: thermodynamics, morphodynamics, and teleodynamics, providing a framework that bridges the gap between raw physics and goal-directed intelligence.8

The Three Strata of Systemic Emergence

The foundational layer, thermodynamics, governs the dissipation of energy and the inevitable increase in entropy.9 In a computational context, this represents the raw, unavoidable consumption of hardware resources—clock cycles, memory bandwidth, energy consumption, and the resultant thermal output of the processing unit. This layer is entirely blind to structure or purpose; it is merely the physical conversion of potential energy into computational work. The second layer, morphodynamics, describes systems that spontaneously organize into ordered macroscopic patterns as a direct result of energy dissipation. Biological and physical examples include Rayleigh-Bénard convection cells, the formation of snowflakes, or the swirling vortices of a river.8 In computational analogues, morphodynamics can be observed in self-organizing feature maps, the spontaneous emergence of localized receptive fields in neural networks, or the decentralized consensus mechanisms of peer-to-peer networks.2 However, morphodynamic systems possess a critical flaw: they are inherently self-undermining. They exist solely to dissipate the energetic gradients that created them, and once those gradients are exhausted, the structure inevitably collapses.8 Teleodynamics, the third and highest stratum, emerges when two or more morphodynamic systems couple in a highly specific manner: the self-undermining quality of each system is reciprocally constrained by the other.8 This reciprocal constraint prevents the total dissipation of available energy, leading to long-term organizational stability, self-preservation, and end-directed behavior.8 It is at this precise juncture of reciprocal constraint that ententional qualities—such as function, purpose, and normativity—spontaneously emerge.8 In this state, data acquires normative value and becomes interpreted information. Deacon weaves together Shannon entropy (the statistical transmission of a message) and Boltzmann entropy (the physical state of the system) to develop a comprehensive theory of interpretation based on teleodynamic work.8 Interpretation, in this paradigm, is inherently normative. Data only becomes information when it holds significance for the interpreter, and interpretive systems are fundamentally teleodynamic because the interpretive process is structurally designed to perpetuate its own existence.8 The interpretation of something as information indirectly reinforces the system's capacity to perform the same interpretive act in the future.8

Blockchains as a Teleodynamic Analogy

To ground this theory in contemporary distributed computing, one can examine the architecture of blockchain networks, which perfectly encapsulate Deacon's three layers. The thermodynamic layer of a blockchain consists of the raw conversion of electrical energy into cryptographic computation (hashing), where computational irreducibility and heat represent the orthograde tendency of the system.9 The morphodynamic layer organizes the disparate network nodes around validating and accepting proposed blocks, reaching consensus, and stabilizing the propagation of state changes throughout the global network.9 Finally, the teleodynamic layer emerges externally through the participant interpretations of network consensus. The assigned value stems from participants' shared belief in the system's verifiable, permissionless nature.9 This collective end-directedness transforms the raw orthograde processes of reaching consensus into a container capable of holding and transferring symbolic value.9 The teleodynamic layer is not inherently part of the technical mining process; rather, it is an emergent phenomenon driven by interpretation.9 This analogy is critical when designing edge AI: the goal is to build a system where the raw matrix multiplications (thermodynamics) organize into recognizable network architectures (morphodynamics), which are in turn constrained by the device's actual physical limitations and the user's interpretive needs to achieve a stable, goal-directed intelligence (teleodynamics).

Teleodynamic Learning: A New Machine Learning Paradigm

Applying this biological and thermodynamic framework directly to artificial intelligence yields the discipline of "Teleodynamic Learning." Standard machine learning optimization relies on a fixed objective function and a static, manually designed neural architecture.2 In stark contrast, Teleodynamic Learning unifies regularization, architecture search, and resource-bounded inference into a single, self-organizing dynamical principle: learning is the co-evolution of structure, parameters, and resources under constraint.1 The defining characteristic of this paradigm is the treatment of learning as the coupled evolution of three interdependent quantities: the structural capacity to represent information (what the system can represent), the continuous adaptation of weights (how it fits parameters), and the energetic resources available to sustain these operations (which changes are affordable).1 This is mathematically modeled as a constrained dynamical system governed by two interacting timescales.

Two-Timescale Dynamics: Inner and Outer Loops

Teleodynamic Learning navigates a hybrid space via two distinct but deeply coupled loops 2:

1. Inner Dynamics (Continuous): This loop governs the continuous, gradient-based adaptation of parameters within a given structural framework. It has been mathematically proven that these inner parametric dynamics converge under natural gradient descent using a diagonal Fisher information matrix, regardless of whether the overarching structure of the network stabilizes.2 This provides a geometrically grounded convergence guarantee based on the geometry of the parameter manifold, rather than relying on traditional convexity.2
2. Outer Dynamics (Discrete): This loop governs the discrete, topological modification of the model's architecture. Unlike traditional neural architecture search methods where architectures must be manually tuned or halted via arbitrary hyperparameter limits, the structural dynamics in a teleodynamic paradigm self-terminate.2

These two loops co-evolve on separate, proven timescales, linked by an endogenous resource variable that both emerges from and strictly regulates the system's trajectory.2

The Role of Endogenous Resource Variables

In standard machine learning frameworks, resource constraints—such as training budgets, epoch limits, or maximum parameter counts—are imposed externally by the human operator. The learning algorithm itself is completely unaware of these constraints.2 In Teleodynamic Learning, resources are treated realistically as an endogenous, internal dynamical variable, typically represented as Energy ([Figure omitted from source export]).2 This energy variable couples all aspects of learning, acting not as an obstacle to be bypassed, but as an integral feature of the dynamics.2 Every action the system takes consumes or replenishes resources, and this resource pressure gates which structural changes or parameter updates are actually viable.2 The system cannot arbitrarily "spend" its way to lower loss; it is forced to balance predictive performance, structural complexity, and resource availability in dynamic tension.2 This is formalized by integrating the resources directly into the local teleodynamic objective function ([Figure omitted from source export]): [Figure omitted from source export] In this equation, [Figure omitted from source export] represents the predictive loss or fit, [Figure omitted from source export] represents the structural complexity of the network, and [Figure omitted from source export] represents the resource or energy pressure.2 Energetic feasibility thus directly shapes the trajectory of the learning system. During the execution of the main learning loop, the system receives an energy reward ([Figure omitted from source export]) based on whether its prediction was correct or incorrect.2 The global energy is then updated by applying a decay factor ([Figure omitted from source export]) and adding this reward: [Figure omitted from source export] This equation represents local rationality. Each action is locally rational—minimizing [Figure omitted from source export] given the current information—but not necessarily globally optimal.2 The system does not plan ahead; it responds solely to immediate pressures, allowing global behavior to emerge from accumulated local decisions.2 Critically, if the energy drops to or below zero ([Figure omitted from source export]), a termination check is triggered, causing the system to undergo an emergent structural halt.2 This provides self-stabilization without externally imposed stopping rules.1 The learning dynamics naturally move through distinct phase-structured behaviors: from under-structuring, through rapid teleodynamic growth, and finally halting before over-structuring occurs.1

The Distinction Engine (DE11) and Spencer-Brown's Laws of Form

A concrete instantiation of this paradigm is the Distinction Engine (DE11), a teleodynamic learner that eschews opaque weight matrices in favor of generating interpretable logical rules that arise endogenously from coupled dynamics.2 If the DE11 model mispredicts, engineers can explicitly identify which exact logical rule fired and why, offering absolute interpretability.2 The mathematical foundation of DE11 is grounded in George Spencer-Brown’s Laws of Form, alongside information geometry and tropical optimization.1 Laws of Form provides the logical language and structure for the model's hypotheses, which are referred to as "Forms".2 The engine begins its structural generation with two primitive objects, denoted as M and U, which have a Directed Acyclic Graph (DAG) size of 1\.13 At each step of the outer dynamics loop, every unordered pair [Figure omitted from source export] of existing objects that has not yet been distinguished generates a new composite object, defined as [Figure omitted from source export].13 Each of these objects is represented as a node in the DAG, with edges pointing from the newly created composite object to its two parents.13 The DAG size of an object is calculated as the number of distinct nodes in its ancestry graph, including itself.13 The objects grow organically through iterated distinction until no new pairs remain at a given DAG size, bounded by the endogenous energy constraint.13 Tropical optimization serves as the mathematical pillar enabling the system to efficiently navigate this discrete structural space alongside the continuous parametric space.2 On standard machine learning benchmarks, this completely self-organizing system achieves remarkably high performance. DE11 achieves a 93.3% test accuracy on the IRIS dataset (outperforming the 91.1% baseline of logistic regression), 92.6% on the WINE dataset, and 94.7% on the Breast Cancer dataset.1 This proves that teleodynamic systems can match or exceed the accuracy of traditional models while providing the immense benefit of structural interpretability and resource-bounded execution. When mapped to a client-side browser architecture, the theoretical energy variable ([Figure omitted from source export]) transitions from an abstract mathematical construct to a literal representation of device constraints. The energy decay ([Figure omitted from source export]) and bounds can be directly correlated to the host machine's battery life, thermal throttling thresholds, and strict WebAssembly memory quotas, allowing the AI to organically adapt its complexity to the exact physical limitations of the user's laptop or mobile phone.

Rust as the Foundational Language for In-Browser Edge AI

To execute a highly adaptive, resource-aware teleodynamic model entirely within a web browser, the underlying software substrate must offer deterministic memory management, zero-cost abstractions, and seamless compilation to WebAssembly. The browser is a hostile environment for traditional machine learning runtimes like Python, which rely on heavy C++ bindings, garbage collection, and massive runtime dependencies. The Rust programming language uniquely satisfies the strict requirements of edge deployment.14 Historically, Rust was considered a difficult proposition for machine learning research because long compilation times disrupted the rapid edit-compile-run loop that draws data scientists to Python.15 However, the ecosystem has rapidly matured. Modern Rust machine learning frameworks are designed around incremental compilation, allowing model code modifications to recompile in under five seconds, even in release mode.15 This delivers a Python-like feedback loop coupled with the unparalleled execution speed and memory safety of Rust.15 Within the Rust ecosystem, the landscape of machine learning frameworks is evolving rapidly, with three notable approaches demonstrating the spectrum of capabilities: RustyASG, Candle, and Burn. RustyASG represents a pure-Rust, experimental, and educational framework.16 It highlights the power of Rust's robust type system, where operations like GPU node retrieval return Result types rather than Option types, forcing developers to explicitly handle execution failures rather than relying on the crash-prone .unwrap() methods common in early implementations.16 While not suitable for production, RustyASG demonstrates that a deep learning framework can be built from scratch without external dependencies like LibTorch.16

The Minimalist Approach: Candle

Candle, developed and maintained by Hugging Face, is a minimalist ML framework designed primarily for highly efficient inference, particularly of large language models (LLMs).17 It explicitly avoids the heavy dependencies of Torch or TensorFlow, ensuring that the resulting WebAssembly executables are remarkably small—avoiding the near-gigabyte overhead associated with loading PyTorch bindings.18 Candle supports a wide array of state-of-the-art models, including LLaMA, Falcon, StarCoder, and Whisper.17 Crucially, it supports quantized models utilizing the llama.cpp approaches (such as GGUF formats), resulting in exceptionally fast inference on standard CPUs.17 This makes Candle highly attractive for pure-CPU WebAssembly execution directly in the browser.17 However, for a teleodynamic architecture that requires continuous parameter adaptation (training) alongside inference, Candle presents limitations. While Hugging Face has acknowledged WebGPU support as a major priority, and experimental branches exist, Candle has historically leaned heavily toward CPU SIMD instructions for its WASM deployments rather than dynamic, generalized GPU compute graph orchestration.19

The Comprehensive Approach: Burn

For a teleodynamic AI architecture necessitating continuous parameter updates (the inner loop) and structural modifications (the outer loop), the Burn framework provides the superior architectural foundation.14 Burn is a comprehensive deep learning framework built from the ground up for both dynamic training and multi-platform inference.20 Burn's architectural philosophy is distinct: it defines operations abstractly via a generic Backend trait, allowing the exact same model code written for training on a cluster to be compiled for inference on an embedded device or a web browser.15

Burn introduces a unique architecture based on tensor operation streams that are fully optimized at runtime by a Just-in-Time (JIT) compiler.14 This approach leverages Rust’s strict ownership rules to precisely track tensor usage and lifecycle, a feature unattainable without a robust type system.14 By tracking exactly when a tensor is consumed or dropped, Burn enables the automatic fusion of computational kernels—a process that delivers the extreme flexibility of dynamic computational graphs with the raw execution speed of highly optimized static graphs.14 Furthermore, Burn allows these backends to be composed; for example, wrapping the webgpu backend in an Autodiff decorator instantly brings backpropagation capabilities to the browser environment, which is mandatory for the teleodynamic inner loop.15

Build-Time Model Interoperability: Burn-ONNX

A significant historical bottleneck in deploying neural networks to client-side environments is the parsing and loading of model graphs at runtime. Traditional systems serialize models into formats like ONNX, which require heavy Protocol Buffer (protobuf) parsers to reconstruct the computational graph in memory.22 In a browser, parsing a multi-megabyte protobuf file consumes excessive memory, drastically delays time-to-first-token (TTFT), and increases the payload size of the WebAssembly module.22 Burn resolves this architectural flaw through the burn-onnx crate, which facilitates the seamless import of ONNX models at build time rather than runtime.22 During the cargo build compilation process, burn-onnx parses the ONNX graph and physically generates native, type-safe Rust source code representing the model's forward pass.22 This build-time translation eliminates the need for any ONNX runtime engine, graph interpreter, or protobuf dependency in the final WASM bundle.22 The generated Rust code is directly integrated into the application, meaning it can be subjected to the Rust compiler's aggressive optimizations.22 The burn-onnx implementation includes advanced graph simplification passes, including constant folding, constant shape propagation, idempotent-operation elimination, common subexpression elimination (CSE), dead code elimination, and attention pattern coalescing.22 If the teleodynamic structural loop decides to prune a section of the network, the underlying Rust implementation ensures maximum execution efficiency. Simultaneously, the build script extracts the tensor weights from the ONNX file and packages them into a proprietary format known as BurnPack (.bpk).22 This binary format is highly optimized for fast, zero-allocation loading, allowing the browser to deserialize the weights directly into memory buffers without overhead.24 The burn-onnx crate currently supports over 160 ONNX operators, boasting full opset compliance across ONNX versions 1 through 24, ensuring that modern models—including complex architectures like Qwen, YOLO, and ModernBERT—can be seamlessly translated into native Rust.22

Hardware Acceleration via CubeCL

The core compute engine powering Burn's hardware acceleration is CubeCL (Cube Compute Language).26 CubeCL is a specialized Rust language extension, a Just-in-Time compiler, and a set of runtimes designed specifically for writing high-performance compute kernels.26 The project originally began as a WebGPU-only backend for Burn, but as the developers sought deeper optimizations, they realized the necessity of an intermediate representation (IR) that could be aggressively optimized before being compiled down to target-specific shading languages.26 Writing kernels directly in this IR was cumbersome, prompting the creation of a Rust frontend utilizing the syn crate.26 By navigating the vast architectural differences between CUDA and WebGPU, the developers synthesized general computing concepts that map efficiently to any hardware platform.26 Today, a single Rust function annotated with the \#\[cube\] macro compiles on-demand to CUDA, HIP, Metal, SPIR-V, WGSL (WebGPU Shading Language), or CPU SIMD instructions.26 The programming model remains low-level by design, ensuring that a single kernel can reach peak theoretical performance on every backend it targets.26 Because CubeCL abstracts the discrepancies between discrete server GPUs and browser-based WebGPU execution, developers can write customized tensor operations—such as the specialized logic required for DE11's composite object distinction—entirely in Rust.13 When the webgpu feature flag is enabled and the code is compiled to the wasm32-unknown-unknown target, CubeCL automatically transpiles these kernels into WGSL.20 This allows the browser's WebGPU pipeline to execute highly parallelized matrix multiplications and teleodynamic objective evaluations on the client's GPU, completely bypassing the latency of crossing the JavaScript-to-Rust boundary during the hot execution loops.20

Overcoming Browser Execution Constraints: WebAssembly and Multithreading

While WebGPU handles the parallelized matrix operations, the orchestration of the teleodynamic learning loops, data preprocessing, and structural graph modifications must be handled by the CPU via WebAssembly. Executing complex machine learning tasks in WASM requires navigating a labyrinth of browser security and threading constraints.

The Web Worker and SharedArrayBuffer Paradigm

WebAssembly executes within a secure sandbox and shares the same event-loop constraints as JavaScript.29 The main browser thread cannot be blocked; if an AI inference loop occupies the main thread, the user interface will completely freeze, resulting in an unacceptable user experience.29 Therefore, the Rust WASM module must be instantiated within background threads known as Web Workers.4 However, traditional Web Workers operate in isolated memory silos, communicating via the relatively slow postMessage serialization protocol.31 To achieve genuine multithreading for operations that remain on the CPU, the architecture must leverage the SharedArrayBuffer API.4 In standard JavaScript, an ArrayBuffer represents a raw byte buffer accessible by only a single thread.4 The SharedArrayBuffer allows multiple Web Workers to hold references to the exact same continuous block of linear memory, enabling shared-memory concurrency without data serialization overhead.4 The compiled WebAssembly module is shared alongside the SharedArrayBuffer memory object via postMessage during initialization, establishing communication and allowing all spawned threads to run the same WebAssembly code synchronously.4

Integrating Rayon via wasm-bindgen

In the native Rust ecosystem, parallelizing workloads is typically handled by Rayon, a data-parallelism library that expects access to native operating system threads (such as pthreads).4 Because the browser lacks OS-level threads, Rayon cannot function out-of-the-box.33 This constraint is resolved via the wasm-bindgen-rayon adapter.4 This crate intercepts Rayon's internal thread-spawning hooks and instead delegates them to a pre-warmed pool of JavaScript Web Workers.4 When the Rust code invokes a parallel iterator (par\_iter), the workload is distributed seamlessly across the Web Workers, achieving near-native multithreaded performance on the client's CPU without altering the core Rust logic.33

Security and Compilation Prerequisites

The security architecture of the modern web platform strictly guards the SharedArrayBuffer API. Following the discovery of high-resolution timing attacks like Spectre, browsers disabled shared memory unless strict isolation protocols are enforced.33 Enabling this multithreaded WASM architecture requires satisfying a rigid checklist of deployment requirements 33:

If any of these conditions are not met, the WebAssembly module will fail to instantiate the SharedArrayBuffer, and the application must gracefully degrade to single-threaded execution, severely penalizing the speed of the teleodynamic structural updates.

WebGPU Architectural Limits and Memory Management

While Web Workers handle CPU-bound orchestration, the bulk of the computational load (the inner dynamics of parameter adaptation) is offloaded to WebGPU. WebGPU represents a generational leap over WebGL, offering native compute shaders, structured storage buffers, and fine-grained control over GPU memory synchronization.28 However, deploying gigabyte-scale models to WebGPU reveals significant architectural limitations imposed by the browser environment, most notably the maxStorageBufferBindingSize constraint.35

The maxStorageBufferBindingSize Constraint

While native desktop environments allow GPU buffers to consume gigabytes of VRAM in a single monolithic allocation, browser implementations of WebGPU enforce strict limits to prevent malicious scripts from crashing the system's graphics driver or monopolizing hardware.35 While uniform buffer bindings are typically capped at a mere 64KB (maxUniformBufferBindingSize), storage buffers are allowed to be larger, but are still severely constrained.35 The WebGPU specification mandates that the maxStorageBufferBindingSize must be at least 128 MB, but on many mobile devices (such as Android devices running Chrome) and various desktop configurations, this minimum is treated as the maximum limit.35 This limitation is largely derived from underlying Vulkan constraints on specific mobile chipsets.37 Given that even highly quantized "mini models" routinely exceed 300 MB, a naive architecture that attempts to upload the entire model weight buffer in a single WebGPU binding will instantly fail, raising a validation error.7

Buffer Slicing and Memory Streaming

To circumvent this, the Rust architecture must employ buffer slicing and chunked execution strategies, as heavily researched in implementations like "Llamas on the Web" (arXiv:2605.20706).36 The model weights must be segmented into blocks smaller than the adapter's reported maxStorageBufferBindingSize limit.36 During the forward pass, the CubeCL kernels are dispatched sequentially, operating on localized chunks of the network architecture.40 While this increases the total number of kernel dispatches per inference step, WebGPU's asynchronous command encoding ensures that this overhead remains minimal compared to the raw latency of the matrix multiplications. Data transfer between the WASM linear memory and the WebGPU VRAM must be handled delicately. The wgpu crate provides the Queue::write\_buffer method to copy data into a buffer, but this utilizes a temporary staging buffer managed by wgpu.41 For large model weights, this triggers memory spikes. Advanced implementations attempt zero-copy or minimal-copy transfers by using Queue::write\_buffer\_with, which allows the Rust code to write directly into temporary mapped storage instead of providing a slice that has already been allocated as a Vec\<u8\> on the constrained WASM heap.41 This technique is vital; duplicating hundreds of megabytes of weights inside the WASM linear memory will easily trigger out-of-memory crashes.5 Furthermore, as demonstrated in the "Llamas on the Web" architecture, memory must be statically allocated at startup.40 By ensuring predictable memory usage independent of prompt or generated output size, the application maintains stability. Their implementation utilizes an asynchronous loading interface that streams weights using merely four 1 MB buffers, moving data directly from local storage into the WebGPU buffers, radically reducing the memory footprint during the loading process.40

State Persistence and Zero-Copy Loading via OPFS

The viability of a client-side AI architecture hinges on minimizing the time-to-first-token (TTFT) and alleviating the "cold start" problem.7 Downloading a 500 MB to 1.5 GB model payload upon every page load is fundamentally unscalable, consuming massive network bandwidth and inducing unacceptable latency.5 Standard browser storage mechanisms are insufficient for this task. localStorage is synchronously blocking and capped at roughly 5MB. While IndexedDB offers larger storage quotas and asynchronous access, it possesses a fatal flaw for machine learning: retrieving large binary blobs from IndexedDB often requires loading the entire payload into the main JavaScript memory thread simultaneously, which routinely breaches the browser tab's RAM limits (typically \~4GB) and triggers out-of-memory (OOM) crashes.7 The solution lies in the Origin Private File System (OPFS). OPFS is a specialized storage endpoint provided by the modern File System API. It acts as an origin-partitioned virtual file system that is highly optimized for performance.44 Unlike IndexedDB, OPFS files are stored directly on the host machine's disk, and their contents can be manipulated byte-by-byte in-place via high-performance streams.44 Because it bypasses traditional permission prompts and security checks (as it is invisible to the user's OS file explorer), it provides seamless access for web applications.45

Rust and OPFS Integration for Persistent AI

Integrating OPFS with Rust allows the architecture to mimic the behavior of memory-mapped files (mmap) commonly used in native operating system programming.43 By utilizing the opfs Rust crate (which provides platform-agnostic wrappers over tokio::fs for native and web-sys for WASM), the system can acquire a FileSystemDirectoryHandle and subsequently a FileSystemFileHandle.45 To cache model weights efficiently, the architecture implements the following flow:

1. Upon initial load, the Rust application fetches the .bpk (BurnPack) or .safetensors payload via network streams.5
2. It requests a FileSystemWritableFileStream from the OPFS endpoint via the create\_writable() method.45
3. The network stream is directly piped into the OPFS file handle in small chunks. This crucial step avoids ever accumulating the entire model in the WASM heap simultaneously.5
4. The stream is closed, and the model resides permanently on the user's local disk.45

Upon subsequent application loads, the "cold start" is eliminated. The Rust application queries the OPFS virtual directory, opens the persistent cache file, and initiates an asynchronous read stream.43 As described in the previous section, the architecture reads the OPFS file in segmented streams (e.g., small 1 MB to 64 MB chunks). As each chunk is pulled from the local disk, it is copied directly into the pre-allocated WebGPU staging buffers.40 By bypassing the WASM linear memory entirely during the load sequence, the application's RAM footprint remains strictly flat, regardless of the model size.40 This static memory allocation guarantees predictable execution and immunizes the application against the strict memory limits imposed by browsers, particularly Safari on iOS devices.40

Parameter-Efficient Mini Models (SLMs) for the Edge

The physical and hardware realities of edge devices—even with highly optimized WebGPU pipelines—dictate that models must be drastically compressed. While massive server clusters execute parameter-dense models (e.g., 70B+ parameters), the browser environment is optimally suited for Small Language Models (SLMs) ranging from 100 million to 1.7 billion parameters.6 Recent advancements in model distillation and synthetic data training have produced highly capable SLMs that comfortably fit within a 1 to 2 GB memory footprint.6 A year prior to this report, running a useful language model locally required 7 billion parameters; today, the threshold for utility has dropped below 500 million.6

Viable SLM Architectures

Two distinct model families have proven exceptional for client-side teleodynamic deployment:

1. Qwen 2.5-0.5B: At roughly 490 million parameters, this model represents a theoretical limit for high-density logical extraction.52 When quantized to 4-bit precision (e.g., Q4\_K\_M), its VRAM requirement drops to a staggering 400 MB.53 Because it is so compact, it allows for blazing fast token generation even on entry-level integrated graphics. On a mid-tier native RTX 3060 GPU, this model generates upward of 320 tokens per second; on an M4 Max, it hits 220 tokens per second.53 While WebGPU incurs some overhead, the throughput remains exceptional for real-time edge processing.
2. SmolLM Series: Released by Hugging Face, the SmolLM series includes 135M, 360M, and 1.7B parameter variants.7 These models were trained on a highly curated mixture of synthetic textbooks (Cosmopedia v2) and educational web samples (FineWeb-Edu).51 The absolute smallest variant, SmolLM-135M, requires roughly 250 MB of storage (unquantized) and is exceptionally suited for domain-specific fine-tuning.51 Because its memory footprint is so minuscule, it easily bypasses all browser tab crash limits, making it the ideal candidate for background processing tasks.7 Furthermore, variants like SmolVLM bring these exact same memory efficiencies to Vision Language Models, allowing client-side image processing and extraction.56

Post-Training Compression Techniques

To shoehorn these models into the WebGPU environment, heavy compression is mandatory. Quantization—the process of converting 32-bit floating-point weights (FP32) down to 16-bit (FP16), 8-bit (INT8), or 4-bit block quantization formats—drastically reduces both the storage footprint and the memory bandwidth required during the forward pass.17 Because matrix multiplication in transformers is fundamentally bottlenecked by memory bandwidth rather than raw compute operations (FLOPs), aggressively quantizing the weights yields a near-linear speedup in generation time.53 Additionally, techniques like vocabulary pruning can significantly reduce memory usage over standard pruning methods, as scaling down the width of layers retains parallelization throughput better than scaling down network depth.52 To mitigate the hallucination tendencies of small base models, the architecture leverages Low-Rank Adaptation (LoRA).55 In a client-side context, this allows developers to serve a single, highly quantized base model (cached permanently in OPFS) alongside several tiny, task-specific adapter weights (often just megabytes in size).55 For instance, a SmolLM-135M model can be fine-tuned on the PAWS dataset to act exclusively as a paraphrasing engine.55 By swapping these LoRA weights dynamically into the computation graph at runtime based on the immediate context, the teleodynamic system can exhibit highly varied intelligence without increasing its overarching memory footprint.55 When combined with structured generation logic (such as XGrammar to force JSON schema adherence), these mini models produce remarkably robust outputs that rival much larger server-side APIs.56

Synthesizing the Architecture: An End-to-End Execution Flow

By weaving together the teleodynamic learning framework, the Rust/Burn ecosystem, the WASM/WebGPU computation layer, and OPFS persistence, we arrive at the complete architectural design for a client-side AI engine. The execution flow unfolds in several distinct, highly choreographed phases:

Phase 1: Initialization and Environmental Probing

Upon loading the web application, the JavaScript bootstrap code executes a hardware and capability probe. It verifies the presence of the necessary COOP/COEP headers to ensure cross-origin isolation.33 It then instantiates a pre-determined number of Web Workers based on the navigator.hardwareConcurrency API, utilizing the wasm-bindgen-rayon adapter to intercept thread requests.4 Concurrently, it requests a WebGPU adapter and device from the browser.36 Crucially, this phase probes the device's exact physical limitations: the maxStorageBufferBindingSize, available battery API status, and memory quotas.35 In a teleodynamic framework, these physical constraints are directly mapped to the energy variable ([Figure omitted from source export]) in the model's objective function.2 The model is initialized not with arbitrary hyperparameters, but with the literal thermodynamic realities of the host machine.

Phase 2: State Retrieval via OPFS

The WASM binary initializes the burn runtime. Instead of executing a network request to download weights, the application queries the OPFS virtual directory.48 If the .bpk model weights are present, a FileSystemFileHandle is obtained.45 The architecture reads the OPFS file in segmented streams. As each chunk is pulled from the local disk, it is copied directly into a pre-allocated WebGPU staging buffer using Queue::write\_buffer\_with to avoid instantiating temporary arrays on the constrained WASM heap.40 This streaming instantiation continues, chunk by chunk, until the network weights are fully serialized into the GPU's VRAM. This maintains a minimal and strictly flat RAM footprint throughout the entire loading process, evading browser OOM crashes.40

Phase 3: Teleodynamic Inference and Structural Adaptation

Once the weights are seated in VRAM and the structural logic (such as the DE11 Laws of Form topologies) is compiled into WebGPU shaders via CubeCL's WGSL transpilation, the inference loop begins.14 In a traditional LLM inference scenario, this involves a standard prefill phase (processing the prompt) followed by an autoregressive decode phase (generating tokens one by one).40 However, because this architecture implements a teleodynamic framework, inference is coupled with real-time structural adaptation.2 As the model processes data, the outer loop continuously monitors the endogenous energy variable ([Figure omitted from source export]). If the predictive task is simple, the model restricts structural growth, executing only a subset of the graph to conserve device energy.2 If the task is highly complex, and the device possesses sufficient thermal and battery headroom (a high [Figure omitted from source export] value), the Distinction Engine generates new composite objects ([Figure omitted from source export]), physically modifying the logical architecture of the network on the fly.2 Simultaneously, the continuous inner loop utilizes the burn framework's autodiff decorators to backpropagate gradients locally, updating parameters in response to real-time user interactions.15 These micro-updates to the parameters and structure are continuously serialized and flushed back to the OPFS storage layer via the FileSystemWritableFileStream in a background Web Worker.44 This ensures that the personalized intelligence persists across browser sessions without ever transmitting a single byte of sensitive user data to a remote server.

Phase 4: Emergent Halting and Resource Conservation

The definitive hallmark of this teleodynamic system is its emergent structural halt.2 As the model expands to accommodate complex reasoning tasks, the energetic penalty ([Figure omitted from source export]) grows exponentially within the local objective function ([Figure omitted from source export]).2 Concurrently, the WebGPU memory utilization approaches the physical limits detected during the initialization phase. When the local teleodynamic objective indicates that the marginal cost of further structural growth outweighs the predictive benefit—or when the hardware constraints literally force the energy variable [Figure omitted from source export] to drop below zero—the system self-terminates the learning and expansion phase.2 This guarantees that the model will never induce a browser tab crash, trigger a thermal shutdown, or violate the maxStorageBufferBindingSize limitations. The intelligence scales organically and precisely to the absolute limits of the vessel that contains it.

Second and Third-Order Implications

The successful deployment of this client-side teleodynamic architecture generates profound cascading effects across the technology landscape, fundamentally altering the economics, privacy, and sustainability of artificial intelligence. Decentralization of Intelligence and Absolute Privacy: By ensuring that model inference, continuous parameter adaptation, and structural modification occur entirely on the client side, absolute data sovereignty is returned to the user.6 Sensitive information—such as medical records, legal documentation, personal diaries, or proprietary corporate data—never crosses a network boundary.6 Because the model adapts locally and persists those adaptations into the isolated OPFS layer, the teleodynamic system acts as a form of ultra-secure, localized federated learning without the vulnerabilities associated with central aggregation servers.44 Redefining the Economics of Edge Computing: Traditional API-based AI scales linearly in cost: every single user interaction incurs server-side GPU computation expenses and network bandwidth costs.6 For operators, scaling an application to millions of users requires massive capital expenditure. By shifting the computational burden directly to the client's underutilized hardware—orchestrated efficiently via Rust, WASM, and WebGPU—application providers eliminate inference costs entirely.57 The economic model of AI deployment transitions from an unsustainable recurring operational expenditure (OpEx) to a fixed-cost delivery of the initial WASM payload and base OPFS model weights.57 Sustainable and Thermodynamically Grounded AI: Contemporary massive language models require sprawling data centers consuming megawatts of power, operating in total ignorance of their thermodynamic footprint. By embedding the energy constraint ([Figure omitted from source export]) directly into the machine learning objective function, teleodynamic AI inherently optimizes for power efficiency.2 An architecture that self-organizes its complexity based strictly on the local device's thermal capacity, memory limits, and battery life represents the first step toward genuinely sustainable, biologically analogous artificial intelligence.2

Conclusion

The convergence of Teleodynamic Learning, the Rust programming language, and the modern web platform represents a fundamental evolution in how artificial intelligence is designed, deployed, and executed. By moving away from static, monolithic models reliant on massive server clusters, and embracing self-organizing, morphodynamic systems constrained by endogenous resource variables, developers can deploy highly capable mini models directly into the browser environment. Through the strategic utilization of the Burn framework's JIT compilation and build-time ONNX interoperability, WebGPU's parallelized compute shaders generated via CubeCL, WASM's multithreaded capabilities via Rayon adapters, and the persistent streaming storage offered by the Origin Private File System, the historical bottlenecks of client-side machine learning have been systematically resolved. The resulting architecture is not merely a downscaled version of server-side AI, but a distinct, adaptive organism that conforms precisely to the thermodynamic and computational realities of the edge device. This client-side, Rust-based architecture fundamentally guarantees zero-latency execution, absolute data privacy, and a democratized, thermodynamically sustainable infrastructure for the future of localized intelligence.

Works cited

1. \[2603.11355\] Teleodynamic Learning a new Paradigm For Interpretable AI \- arXiv, accessed June 24, 2026, https://arxiv.org/abs/2603.11355
2. Teleodynamic Learning a new Paradigm For Interpretable AI \- arXiv, accessed June 24, 2026, https://arxiv.org/pdf/2603.11355
3. Rust GPU Programming with wgpu: The 2026 Guide \- Rustify, accessed June 24, 2026, https://rustify.rs/articles/rust-gpu-computing-wgpu-2026
4. Using WebAssembly threads from C, C++ and Rust | Articles \- web.dev, accessed June 24, 2026, https://web.dev/articles/webassembly-threads
5. 9 WebAssembly \+ Rust Tricks for Native-Speed Web Apps | by Bhagya Rana | Medium, accessed June 24, 2026, https://medium.com/@bhagyarana80/9-webassembly-rust-tricks-for-native-speed-web-apps-95aff2f8959b
6. Run AI Models in the Browser with WebGPU & WASM \- Mad Devs, accessed June 24, 2026, https://maddevs.io/writeups/running-ai-models-locally-in-the-browser/
7. SLMs with JS: Running 'Smol' LLMs Entirely in Your Browser | by Ashwin Jayaprakash, accessed June 24, 2026, https://medium.com/@fanbyprinciple/slms-with-js-running-smol-llms-entirely-in-your-browser-4cbc8b164940
8. Incomplete Nature \- Wikipedia, accessed June 24, 2026, https://en.wikipedia.org/wiki/Incomplete\_Nature
9. Teleodynamics of Proof of Work. From Terrance Deacon's Incomplete… | by Stephen Macurdy | Medium, accessed June 24, 2026, https://medium.com/@macurdy/thermoeconomics-ebd64c6d7387
10. A thermodynamic basis for teleological causality \- Royal Society Publishing, accessed June 24, 2026, https://royalsocietypublishing.org/rsta/article/381/2252/20220282/112446/A-thermodynamic-basis-for-teleological-causalityA
11. Teleodynamic Learning a new Paradigm For Interpretable AI | Request PDF \- ResearchGate, accessed June 24, 2026, https://www.researchgate.net/publication/401909814\_Teleodynamic\_Learning\_a\_new\_Paradigm\_For\_Interpretable\_AI
12. Teleodynamic Learning: A New Paradigm For Interpretable AI, accessed June 24, 2026, https://arxiv.org/html/2603.11355
13. The Distinction Engine: Recovery of the 137-Element Relational Registry from a Single Logical Axiom, accessed June 24, 2026, https://ai.vixra.org/pdf/2604.0057v1.pdf
14. Burn, accessed June 24, 2026, https://burn.dev/
15. GitHub \- tracel-ai/burn: Burn is a next generation tensor library and Deep Learning Framework that doesn't compromise on flexibility, efficiency and portability., accessed June 24, 2026, https://github.com/tracel-ai/burn
16. I Built a Deep Learning Framework in Rust from Scratch \- Part 2: GPU Backend and the Lonely Debugging Journey \- DEV Community, accessed June 24, 2026, https://dev.to/xzdes/i-built-a-deep-learning-framework-in-rust-from-scratch-part-2-gpu-backend-and-the-lonely-13p4
17. Update on the Candle ML framework. : r/rust \- Reddit, accessed June 24, 2026, https://www.reddit.com/r/rust/comments/16rvlbf/update\_on\_the\_candle\_ml\_framework/
18. Rust applications \- Research \- Hugging Face Forums, accessed June 24, 2026, https://discuss.huggingface.co/t/rust-applications/23060
19. WebGPU support · Issue \#344 · huggingface/candle \- GitHub, accessed June 24, 2026, https://github.com/huggingface/candle/issues/344
20. burn \- Rust \- Docs.rs, accessed June 24, 2026, https://docs.rs/burn
21. Rust \- burn, accessed June 24, 2026, https://burn.dev/docs/burn/
22. Burn ONNX 0.21.0: build-time ONNX import that generates plain Rust model code \- Reddit, accessed June 24, 2026, https://www.reddit.com/r/rust/comments/1tdx4wq/burn\_onnx\_0210\_buildtime\_onnx\_import\_that/
23. burn-import \- crates.io: Rust Package Registry, accessed June 24, 2026, https://crates.io/crates/burn-import/0.11.1
24. ModelGen in burn\_import::onnx \- Rust \- Docs.rs, accessed June 24, 2026, https://docs.rs/burn-import/latest/burn\_import/onnx/struct.ModelGen.html
25. GitHub \- tracel-ai/burn-onnx: Convert ONNX models into native, backend-agnostic Burn code for inference and fine-tuning., accessed June 24, 2026, https://github.com/tracel-ai/burn-onnx
26. GitHub \- tracel-ai/cubecl: Multi-platform high-performance compute language extension for Rust., accessed June 24, 2026, https://github.com/tracel-ai/cubecl
27. cubecl \- crates.io: Rust Package Registry, accessed June 24, 2026, https://crates.io/crates/cubecl
28. Semantic search powered by WASM and WebGPU | by Amine Dirhoussi | Medium, accessed June 24, 2026, https://medium.com/@aminedirhoussi1/semantic-search-powered-by-wasm-and-wgpu-492e900b8796
29. How to use Shared Array Buffer as the wasm memory · Issue \#3298 \- GitHub, accessed June 24, 2026, https://github.com/wasm-bindgen/wasm-bindgen/issues/3298
30. Multithreading Rust and Wasm, accessed June 24, 2026, https://rustwasm.github.io/2018/10/24/multithreading-rust-and-wasm.html
31. wasm\_mt \- Rust \- Docs.rs, accessed June 24, 2026, https://docs.rs/wasm-mt
32. Rust WebAssembly — Sharing data between WebWorkers | by Julien de Charentenay, accessed June 24, 2026, https://julien-decharentenay.medium.com/rust-webassembly-sharing-data-between-webworkers-f156ba65d141
33. Run Multi Threads With Rust On Browser — Rayon And 2 Layers Web Worker Mechanism, accessed June 24, 2026, https://dev.to/toshiya\_matsumoto\_ac94abe/run-multi-threads-with-rust-on-browser-rayon-and-2-layers-web-worker-mechanism-10ne
34. wasm\_bindgen\_rayon \- Rust \- Docs.rs, accessed June 24, 2026, https://docs.rs/wasm-bindgen-rayon
35. From WebGL to WebGPU | Chrome for Developers, accessed June 24, 2026, https://developer.chrome.com/docs/web-platform/webgpu/from-webgl-to-webgpu
36. Why is webgpu on mac "max binding size" much smaller than reported "max buffer size"?, accessed June 24, 2026, https://stackoverflow.com/questions/78034628/why-is-webgpu-on-mac-max-binding-size-much-smaller-than-reported-max-buffer-s
37. Chat demo does not work on Android because of maxStorageBufferBindingSize · Issue \#209 · mlc-ai/web-llm \- GitHub, accessed June 24, 2026, https://github.com/mlc-ai/web-llm/issues/209
38. \[BUG\] not enough memory, while I have plenty · Issue \#1 · softwiredtech/stable-diffusion-webgpu \- GitHub, accessed June 24, 2026, https://github.com/softwiredtech/stable-diffusion-webgpu/issues/1
39. \[2605.20706\] Llamas on the Web: Memory-Efficient, Performance-Portable, and Multi-Precision LLM Inference with WebGPU \- arXiv, accessed June 24, 2026, https://arxiv.org/abs/2605.20706
40. Llamas on the Web: Memory-Efficient, Performance-Portable, and Multi-Precision LLM Inference with WebGPU \- arXiv, accessed June 24, 2026, https://arxiv.org/html/2605.20706v1
41. Buffer in wgpu \- Rust \- Docs.rs, accessed June 24, 2026, https://docs.rs/wgpu/latest/wgpu/struct.Buffer.html
42. Rust wasm: How to access Webassembly.Memory of current instance (from Rust)?, accessed June 24, 2026, https://stackoverflow.com/questions/60199564/rust-wasm-how-to-access-webassembly-memory-of-current-instance-from-rust
43. Advanced Caching and Streaming for Large Scale Point Cloud Data Visualization on the Web, accessed June 24, 2026, https://digitalcommons.usu.edu/context/etd2023/article/1002/viewcontent/COMSetd2023Dec\_Poudel\_Pravin.pdf
44. The origin private file system | Articles \- web.dev, accessed June 24, 2026, https://web.dev/articles/origin-private-file-system
45. Origin private file system \- Web APIs | MDN, accessed June 24, 2026, https://developer.mozilla.org/en-US/docs/Web/API/File\_System\_API/Origin\_private\_file\_system
46. LiteRT LM on the Web: Running Generative AI Locally in the Browser | by Shivay Lamba, accessed June 24, 2026, https://shivaylamba.medium.com/litert-lm-on-the-web-running-generative-ai-locally-in-the-browser-f6d5393c3756?source=rss-------1
47. Rust with the Burn Deep Learning Framework: Memory-Mapped Dataset | by Alfred Weirich, accessed June 24, 2026, https://medium.com/@alfred.weirich/rust-with-the-burn-deep-learning-framework-memory-mapped-dataset-7879f90b61dd
48. opfs \- Rust \- Docs.rs, accessed June 24, 2026, https://docs.rs/opfs
49. opfs \- crates.io: Rust Package Registry, accessed June 24, 2026, https://crates.io/crates/opfs
50. FileSystemWritableFileStream in web\_sys \- Rust \- Docs.rs, accessed June 24, 2026, https://docs.rs/web-sys/latest/web\_sys/struct.FileSystemWritableFileStream.html
51. SmolLM \- blazingly fast and remarkably powerful \- Hugging Face, accessed June 24, 2026, https://huggingface.co/blog/smollm
52. Compact: Common-token Optimized Model Pruning Across Channels and Tokens \- arXiv, accessed June 24, 2026, https://arxiv.org/html/2509.06836v1
53. Ollama VRAM Requirements 2026: Table for Every Model (1B-405B) | Local AI Master, accessed June 24, 2026, https://localaimaster.com/blog/ollama-model-ram-vram-table
54. slower than qwen 2.5 on a100 40gb · Issue \#323 · OpenBMB/MiniCPM \- GitHub, accessed June 24, 2026, https://github.com/OpenBMB/MiniCPM/issues/323
55. From Tiny Models to Private AI \- Fine-Tuning SLMs and Running Them Securely in Your Web Browser | ashishware.com, accessed June 24, 2026, https://ashishware.com/2025/11/16/slm\_in\_browser/
56. Simon Willison on smollm, accessed June 24, 2026, https://simonwillison.net/tags/smollm/
57. LLMs running in the browser | Kevin Scott, accessed June 24, 2026, https://thekevinscott.com/llms-in-the-browser/
58. burn::module \- Rust \- Docs.rs, accessed June 24, 2026, https://docs.rs/burn/latest/burn/module/index.html