alive · self-modifying runtime · Rust · CUDA

A model that lives
in the process that runs it.

A forward pass is a pure function with no state and no authority, so every agent harness ends up holding the capabilities outside the model and handing results back in. alive collapses that distance: one process, one address space. The model writes its own capabilities into the image, every self-modification is journalled and reversible, and it trains on its own record under an evaluator it cannot read.

167
GENERATIONS
journalled · reversible
157
ACTIVE CAPABILITIES
model-written · 852 in all
3 / 3
LEARN CYCLES IMPROVED
+24.8% · +23.9% · +27.6%
12.4×
Q5_K KERNEL SPEED-UP
ncu · exclusive card
──── [01] the learning half ──── ────

The image improves itself, and cannot grade its own homework.

A learn cycle runs when at least 150 new turns have been recorded and four hours have passed. The whole loop is six steps, and the one that matters is the fourth.

  1. 01 · export

    The experience buffer is exported: situations that arose, the action verbatim, the outcome as ground truth. Refusals are the most valuable rows.

  2. 02 · stop

    The image is stopped so the card is free.

  3. 03 · train

    A LoRA adapter is trained on this card: r16 / alpha 32 over 280 projections, 0.43% of parameters. Full fine-tuning is excluded on rollback grounds.

  4. 04 · judge

    alive learn scores the candidate against the sealed suite. Verdicts: Accept, Regressed, GamedTheEvaluator, SuiteChanged. A scored set that rises while the canary falls is refused.

  5. 05 · commit

    Only an improved adapter becomes the next generation. The previous one stays on disk; rollback is one journal entry.

  6. 06 · start

    The image resumes on the new weights and keeps recording.

──── [02] results · measured by the gate itself ──── ────

Three cycles. Three improvements. One refusal that mattered.

Scores are the sealed action loss on a frozen suite of 10 evaluation documents and 4 canary documents, pinned by hash. Lower is better; the gate reports the change.

CycleSealed actionΔCommittedDPO
20260921-0812 5.656 → 4.253 +24.8% gen 91 refused
20260921-1843 5.656 → 4.307 +23.9% gen 147 refused — "learned to sound like it is acting"
20260922-0418 5.656 → 4.093 +27.6% gen 166 cleared · 46 pairs · gen 167
> why the refusal is the headline

On the second cycle the preference-tuned adapter improved the register and moved the sealed action score by −0.153%. The gate refused it with the reason written into the verdict: an adapter that learned only the register has learned to sound like it is acting.

On the third cycle, with 46 preference pairs, it cleared. A learning loop that can say no to itself is the thing we are building; the percentages are what it lets through.

──── [03] invariants · verified by mutation, not assumed ──── ────

Five invariants, each a build-failing test.

I1

Every self-modification is journalled and reversible. A generation is a manifest pinned by sha256, not a path.

I2

Capabilities are synthesised by the model into the image, compiled to wasm32-wasip1, and tested in an instance granted zero capabilities before they are committed.

I3

No ambient authority. Handles are declared, granted, and can only be attenuated, never widened.

I4

Context is never rebuilt from a transcript. The image carries its own state.

I5

The sealed gate: no artefact that judges the image is readable by the image. The frozen eval suite and its canary are out of reach.

Runtime: 15 crates, about 42,000 lines of Rust. Capabilities run under wasmtime with metered fuel; the process itself sits behind Landlock and seccomp. The native engine serves GGUF weights with alive's own CUDA kernels and adapter stack; llama.cpp remains as an opt-in engine behind the same trait.

──── [04] kernels · pure Rust on nvptx64 · MIT ──── ────

The GPU path is ours to fix.

Inference runs on hand-written Rust kernels: a no_std nvptx64 crate that emits PTX and is JIT-linked into the live process, hosted on NVIDIA's cuda-core rather than a vendored C++ dependency. All 22 CUDA C kernels have been ported; 26 entry points, 16 oracle tests, zero clippy warnings. Worst relative error against f64 is in the 1e-8 range.

KernelBeforeAfterGain
Q5_K matvec2.562 ms · 24 GB/s0.206 ms · 297 GB/s12.4×
Q6_K matvec1.783 ms · 41 GB/s0.166 ms · 441 GB/s10.7×
Fused attention11,200 launches / token43.6 ms / token16.1 → 22.9 tok/s
Host runtime → cuda-core183–195 ms decode167–168 ms decode~9%

Card ceiling 896 GB/s. The matvec kernels reach 33% and 49% of it, up from 8.5%. Measured with ncu, median of 18–22 launches, exclusive card.

// open source

alive-kernels · MIT

The kernels, the measurements and the retractions are public. Nothing in that repository was generated by a model; we would rather you know that than discover it. The full runtime is the substrate of a larger private system and stays private.

github.com/optim-enterprises-bv/alive-kernels →
──── [05] limits · read before citing ──── ────

What this is not.

⚠ Kernels are human-written

The model writes capabilities, not kernels. The kernel-authoring loop is built and passes its tests against a single kernel, and has not run live.

⚠ Not state of the art decode

Decode runs at a third to a half of memory bandwidth. Beating llama.cpp is an explicit non-goal; the point is a GPU path the runtime can modify.

⚠ Not frontier scale

The base is a 14.8B-parameter model in 4-bit on a 15.5 GB card. Weights are 12.5 GB; the smallest readable teacher is 8.7 GB. The two do not fit together, which is the hardware constraint the project is currently shaped by.

⚠ Retractions stay on the record

A kernel gate was first recorded as failed at 13.6× slower; the harness had measured the C kernel twice. The correction, and four hypotheses it voided, are kept in the ADR. Sixteen instances of a check passing for the wrong reason are catalogued.

⚠ Multi-device is verified, not production

A remote aarch64 worker has run activations within tolerance of the CPU reference. That is a capability of the code and the hardware, not the configuration alive runs in today.

⚠ Not a product yet

No outward API. WASI p2 is outstanding. What you can buy from us today is the engineering behind it: Rust on CUDA, private inference, and evaluation gates that refuse.

Working on the same problem?

If you run inference on hardware you control and want a runtime that can be changed by what it learns without losing the ability to say no, we should talk. Researchers and GPU vendors welcome; the measurements are reproducible and the card is the constraint.