The Atome C99 engine has a property most inference stacks do not: at runtime it allocates no heap, makes no system calls, and touches no network. Everything lives in static buffers sized at compile time. That sounds like an austerity measure, but it is actually the source of the engine's best security and reliability properties.
What “no heap” actually means
The block structure is fixed: one LayerNorm, one ternary depthwise convolution, one diagonal state-space model, one top-k attention, one router — and a static buffer for each pathway output, the SSM state, the KV cache, the router weights, and the logits. There is nothing else. No malloc means no fragmentation, no out-of-memory mid-inference, and no allocator to audit. The whole engine compiles to roughly 2.6 KB of .text. A failure mode that simply cannot occur is the cheapest failure mode to handle.
Why air-gapped is a feature
A model that cannot phone home cannot leak. For defense, medical and industrial deployments, “the data never leaves the chip” is a compliance story you can actually defend, because there is no network path to begin with — not a policy, an architecture. No cloud dependency also means no latency, no per-inference cost, and no outage when the link drops. The model is part of the firmware, answers the same way on every device, and keeps working when the building's internet does not.
The discipline it forces
Designing for a fixed structure means saying no: no wide convolutions, no dense feed-forward block, no multi-bank weights, no per-row scales. Those are deliberate omissions, not gaps. Each would either break the bit-exact parity contract between Python and C or blow the RAM budget. The constraint is the design — and it is what lets the same trained checkpoint export to flash and run identically on the reference and the chip.
When this matters most
If your product handles audio, medical signals, location, or anything a user would not want sent to a server, an air-gapped on-device model removes the question entirely instead of answering it with a privacy policy. If your product must keep working in a tunnel, on a factory floor, or in a remote sensor with no connectivity, the same property is a reliability guarantee. The engine, its build targets, and the measured RAM table are all in the c_engine directory of the public repository.
What an attacker cannot reach
Security people think in terms of attack surface, and an air-gapped, heap-free engine removes several surfaces outright. There is no network listener to probe, so remote exploitation has no entry point. There is no dynamic allocator, so an entire class of heap-corruption bugs cannot occur. There are no system calls into an operating system, because there is no operating system — the engine is a library compiled into your firmware. None of this makes the surrounding product automatically secure, but it shrinks the part of the system that touches the model down to a small, static, auditable surface, which is exactly what you want when you have to reason about a device that may sit in the field for a decade.
Determinism is its own kind of safety
Because the engine allocates nothing and the Python and C paths are bit-exact, the device's behavior is deterministic and reproducible: the same input produces the same output, on every unit, every time, and that output matches what you validated on your workstation. For safety-relevant functions this is worth as much as the privacy story. You can test a fixed set of inputs, prove the outputs, and know that the fielded devices will not drift because there is no allocator state, no network variability, and no floating-point divergence between the reference and the chip. Predictability, here, is a feature you design in, not a property you hope for.
Power and longevity in the field
An air-gapped, heap-free engine also tends to be a frugal one, and frugality is what lets a device live for years on a battery or a harvested-energy budget. With no radio to power, no operating system scheduler running, and ternary weights that replace multiplies with sign flips and skips, the energy spent per inference is dominated by a short burst of simple arithmetic rather than by networking or a busy CPU. That matters for the exact products this architecture targets: a sensor on a wall, a wearable, a remote monitor that must run untouched for a long time. Lower, more predictable energy per inference translates directly into longer battery life and fewer maintenance visits, and because the computation is deterministic you can characterize that energy budget once and trust it across the fleet.
Bottom line
A zero-heap, air-gapped engine is not an austerity compromise; it is where the architecture's best properties come from. No network path means data cannot leak and the device keeps working offline. No allocator means a whole class of failures cannot occur and the code stays small and auditable. Bit-exact determinism means the behavior you validated is the behavior that ships, and frugal arithmetic means long battery life in the field. For privacy-sensitive, safety-relevant or long-lived products, those are not nice-to-haves — they are the reason to build on-device in the first place.
Frequently asked questions
Can an LLM run completely offline?
Yes. Atome's C engine has no network path and no cloud dependency — inference runs entirely on the device, so it works offline and the data never leaves the chip.
Why does a heap-free engine matter on a microcontroller?
No malloc means no memory fragmentation and no out-of-memory failures during inference, plus a smaller, auditable codebase — about 2.6 KB of .text. That predictability is critical for embedded reliability.