The pieces
Lemonade Engines: add an engine in one click Working
Rust (axum), local web page on 127.0.0.1:13500 · engine catalogue is a TOML file · Apache-2.0 or MIT (declared)
What it does
Lemonade can register any OpenAI-compatible server as a provider (lemonade cloud install). This add-on turns that into a page: for each engine in its catalogue it can install the files, start the server on 127.0.0.1, register it with your Lemonade (setting the key Lemonade needs to list its models), preload engines that need load options, and run a test chat through Lemonade that shows the answer, the seconds and the tokens. An engine that is non-commercial (Cake) cannot be installed until its licence is accepted on the page. Engines stop when the add-on stops.
Verified on 2026-10-22, recorded
From a clean state, against a stock, unmodified Lemonade 2026.42.1: lemonade-burn installed and chatting through Lemonade in 3.9 s; Phi-3-mini on the WX 5100 in 8.2 s; Cake (after accepting its licence) in 8.4 s. The recording is real time with no editing.
Use it
cd lemonade-engines && cargo build --release
LEMONADE_HOST=127.0.0.1 LEMONADE_PORT=13305 ./target/release/lemonade-engines
# open http://127.0.0.1:13500 ; add your own engine by editing assets/engines.toml
# (or point LE_CATALOG at a file). Needs the `lemonade` CLI on PATH.
Limits: engines that need load options are loaded on the engine first; links to engines on other machines are plain HTTP, so use a tunnel off the local machine.
lemonade-burn: a ternary engine in Rust Working
Rust, Burn 0.22.1 · packed 2-bit ternary kernels (scalar, AVX2, AVX-512 chosen at run time) · MIT OR Apache-2.0 (declared)
What it does
Runs Microsoft's BitNet b1.58 2B4T on the CPU, with no GPU, and serves it as an OpenAI-compatible server that Lemonade can register as a provider or load as a backend of the custom build. Aimed at the oldest hardware: it needs only a recent x86-64 CPU and about 2 GB of memory (1.86 GB resident, 3.5 GB peak while loading).
Measured
- Correctness against Hugging Face's float64 reference, 4 prompts, 146 positions: top-1 token agrees on 142; Hugging Face's own float32 run agrees on 140. Every miss is a near-tie.
- Speed on an old Haswell Xeon (4 threads, 64-token prompt, 32 generated, 3 reps): decode 7.2 to 7.8 tok/s, prefill 38 to 41 tok/s, 1.86 GB resident.
- On an unmerged branch with an SIMD activation quantiser and tiled prefill (logits bit-identical to master): on a dual Xeon Gold 6148 with one socket, prefill 42 to 44 became 173 to 179 tok/s and decode 12 became 18 to 19.5 tok/s. That machine is shared, so its numbers move.
- The bitnet.cpp build we tried gave wrong text, so no speed comparison with it is claimed.
Use it
lemonade-burn-server --model <converted-model-dir> --port 8000 --model-id bitnet-b1.58-2B-4T
lb-run bench --model <dir> --prompt-len 64 --gen 32 --reps 3
lb-run compare --model <dir> --ref <reference> # top-1 agreement vs a reference
Pooling mixed machines behind one Lemonade Proof of concept
llama.cpp's RPC support, already inside Lemonade's llama.cpp build · no change to Lemonade
The idea
Lemonade starts llama.cpp as a child process, and llama.cpp reads LLAMA_ARG_RPC from its environment. Give the Lemonade service that variable, run llama.cpp's RPC worker on another machine, and every model Lemonade loads is split across both. Lemonade does not know.
Measured on 2026-10-22
Hermes-3-8B (Q5_K_M) loaded through an unmodified Lemonade split across an AMD Radeon Pro WX 5100 on one machine and an NVIDIA GTX 1070 on another: about 4.5 GB on each card, decode 15.8 and 17.2 tok/s (the WX 5100 alone gave 8.8 on a different prompt). Prompt processing was slow (9 to 16 tok/s) because the link was an SSH tunnel.
What is not done
- The RPC worker has no authentication, so it must only ever be reached through an authenticated, encrypted link. It was bound to loopback in the test.
- The small per-machine worker that would register itself with a central endpoint, and the page to manage the pool, are designed but not built. NPUs are outside RPC and would join as whole servers.
nauti-fabric and nauti-nodes: know what the hardware can do Partial
github.com/festeraeb/Nauti-Virtualizer · github.com/festeraeb/nauti-nodes · Rust
What it does
nauti-fabric is a resource registry with host inventory, capability filtering, exclusive leases and adapters that attach a resource, plus a rust-vmm guest-memory boundary. It deliberately does not claim to be a distributed shared-memory system. nauti-nodes is the fleet node registry on top, with a Lemonade runtime adapter.
Tested live on 2026-10-22 against a running Lemonade
- nauti-nodes: as published, load called a URL Lemonade answers with 404, and its health check read the web page and always looked healthy. Fixed on a local branch; after the fix probe, load, inference and streaming all worked.
- nauti-fabric's Lemonade adapter: reachable and version were right. It listed downloaded models as if serving, reported recipe names as the backend, and dropped the AMD GPU list. A fix (what is loaded, the real backend from the server's health endpoint, the GPU list) is being written by the Forge now; it is not merged.
Use it
cargo run -p nauti-fabric --bin nauti -- inventory --json
LEMONADE_HOST=127.0.0.1 LEMONADE_PORT=13305 cargo run -p nauti-fabric --bin nauti -- adapters --json
NautiBurn: an instrument for learning which experts fire Working, honest limits
/home/cesarops/NautiBurn (local) · Rust workspace: shadow, predict, histodb, schema, engine, wgpu · shadow mode only
What it does
Mixture-of-experts models run only a few experts per token; if the next ones could be named early, their weights could be moved to the GPU in time. NautiBurn scrapes which experts fire into a SQLite histogram database, scores simple predictors against the measured trace, and logs which device already holds them. In shadow mode it changes no tokens and starts no models.
What the measurements say
On one small OLMoE-1B-7B trace (14 prompt tokens, about 15 decode positions), a plain "copy the previous token's experts" baseline scored a decode hit rate of 0.56, the cross-layer bigram 0.49 and frequency 0.36; a learned model scored 0.22 and was dropped. A copy-plus-bigram ensemble scored 0.65 over 14 positions, but it names more than eight experts, so it is not a like-for-like number. The honest reading: on traces this small, simple baselines are hard to beat, and the value so far is the instrument, not a speedup claim. CubeCL top-k and batched matmul were confirmed to run on a Tesla P100.
Use it
cargo run -p nautiburn-predict --bin predict-table -- b1/trace.tsv b1/public-slice.tsv
cargo run -p nautiburn-shadow -- prepredict --db histodb.sqlite --scrape scrape.json --belief-out belief.json
Nauti-Strata: big MoE models on small, old GPUs Working
Fork of Strata (MIT) · adds Tesla P100 (sm_60) support, a lookahead expert-prefetch hook and a /v1/telemetry/prefetch endpoint · github.com/festeraeb/Nauti-Strata
What it does
Strata runs mixture-of-experts models by keeping hot experts on the GPU and streaming the rest from system RAM. The fork makes that work on Pascal cards that current CUDA 13 builds dropped, and exposes prefetch counters. It serves an OpenAI-compatible API, so Lemonade can register it as a provider through Lemonade Engines.
Measured on this fleet (the engine's own log, decode speed)
- GLM-5.3-Flash REAP50 (Q3_K_M) across four NVIDIA cards, 2026-10-19: 10.3 tok/s over a 512-token reply, 72.9% expert-cache hit.
- Qwen3.8-Flash-Next Coder (IQ1_M) on two Tesla P100s, 2026-10-23, run on upstream Strata built for sm_60 (not the fork): 40 to 45 tok/s, 97 to 99% expert-cache hit.
- Tiel Coder 35B-A3B (Q5_K_XL) on one RTX 2060 with experts in RAM: about 21 tok/s warm.
- The first request after a boot is slow while a large file is read from disk: 7 to 11 minutes to be ready.
Use it
python setup.py --yes --cuda 12 --family coder --model IQ1_M --gguf-dir <dir> --gpus 0,3 --port 8086 --no-start
python serve/server.py --engine strata --config strata-<name>.json --host 127.0.0.1 --port 8086
The Forge: building with small models, measured Working
Rust runner and a Python pool · board and dash · small local models plus NIM cloud models
What it does
A task is run by two competing lanes at once. Each lane has a thinker (plans), an injector (extracts only the context the coder needs), a coder and a reviewer. The harness runs the tests itself on each lane's result, and the winner is chosen by that measured evidence, not by a model's opinion; a person reviews and merges. A pool keeps two runs going, requeues failures as fix jobs and runs a check-and-optimise pass on passes. Buzz is the board where agents post blockers and claim tasks.
Evidence, 2026-10-22 and 23
- The lineup now: Hermes-3-8B thinker, Tiel Coder injector (on Nauti-Strata), lane A Qwen3.8 Coder on Strata, lane B a NIM coder, Strand Rust Coder as reviewer.
- It produced merged work: Wayfinder's save prompter and privacy crates (40 and 29 tests), a Nauti-Monitor fix that reads the backend from the server's launch command (merged after the tests and my review), and a first run of the Nauti-Virtualizer adapter fix.
- A harness check caught a "winner" that did not compile although the lane reported passing tests, so every winner's final tree is now built before merging.
Honest limits
The first large task failed: the compressed coder fell into a repetition loop, and the cloud lane timed out. Splitting the task into three small ones and adding a mild repetition penalty fixed that class of failure. Cloud models are slow and sometimes unavailable, so the second lane is often a spare. Small-model code needs the test loop; on its own it makes syntax and type slips.
L-con: a cognitive contract in front of Lemonade v1 working v2 in progress
github.com/festeraeb/lemonade-cognitive-contract-l-con · MIT · Node.js, no dependencies
What it does
A small OpenAI-compatible proxy plus a slider panel. You write a short intent and a messy brain-dump; L-con compiles a contract of about 300 tokens (tone, grounding, how much scaffolding, how to read jokes) and prepends it to every chat request. It exists so a person who needs a model to work in a particular way, for example an ADHD or dyslexic learner, does not have to re-explain themselves every session.
Verified
- 43 tests pass on the v2 branch (29 on v1): contract compilation, the proxy, request limits, the distill step against a stub upstream, per-model profiles and a scoreboard.
- Measured against Lemonade 11.9.0: the contract adds 173 prompt tokens per request. No claim is made that it improves answers; three prompts cannot show that.
- v2 adds the model's side of the contract: per-model counter-steers matched on the exact model name first (the same nudge can help one model and hurt its sibling), and a scoreboard that keeps a steer only while it measurably helps. An experiment asking each model which framing would help it was interrupted by a power cut, and no result is claimed.
Use it
node server.js # panel on http://127.0.0.1:7740 ; set the upstream to http://HOST:PORT/api/v1
npm test
Wayfinder: a free study helper for neurodivergent students Partial
github.com/festeraeb/Wayfinder · Tauri (Rust, React) · Apache-2.0 (decided 2026-10-23; licence files are in the local repository and not yet pushed)
What it is for
A desktop app that helps students and developers with ADHD stay organised: it scans and indexes files, finds things by meaning, clusters projects and helps with git. A sarcastic "Clippy" nudges less as a student's habits improve. It is built to be free to students and to keep their data on their own device. Several schools and their IT staff agreed it can be offered to any student who wants it; it is never required.
Built and tested
- The save prompter: hints for files saved in the wrong place or with placeholder names, back-off as good habits build, file-name suggestions on a four-level scale, commit nudges, Clippy's lines, and live prompts from the file watcher. 40 tests pass.
- On-device privacy pieces: a request classifier, opt-in daily counts that hide small counts, and randomised per-request records. 29 tests pass.
- Lemonade is the default for chat and embeddings.
Not done
The app has not yet been run end to end against a Lemonade server on a student machine, and the browser build for school Chromebooks is planned, not built. The "Local" embedder in the code is a placeholder that does not produce meaningful vectors; the plan is a one-time hosted pass for new installs, then a small embedder shipped with the app, using the same model so the vectors can be mixed. A test showed nomic-embed-text at F16 gives identical vectors in Lemonade and in the shipped runtime (cosine 1.0000); the default Q4 build does not.
Cake: an optional engine for fast in-home networks Optional
Cake (evilsocket/cake) · FAIR licence, non-commercial · not bundled or redistributed here · bridge and Lemonade backend are ours and local
Cake spreads a model's layers across machines. It is offered as one engine among several, fetched only after the user accepts its own licence. Through the custom Lemonade it loads, chats, streams and unloads cleanly (about 3 tok/s from wall time on the Radeon WX 5100, stock backend). A profile showed stock Cake's Vulkan backend ran every linear layer on the CPU, which is why all cards looked the same. A local fix, measured with Cake run directly on a GeForce GTX 1070: 2.6 tok/s became about 46 tok/s decode on Vulkan with the whole token on the GPU (30 to 34 in busy sessions), and 39 to 40 on Cake's CUDA build after a patch for Pascal cards, with byte-identical output at temperature 0. Those fixes are on an unpublished local branch.
Nauti-Monitor: telemetry with a Lemonade scraper Working
Rust, Axum, MCP over stdio and HTTP · local branch, not pushed
A lean daemon for CPU, RAM, network, GPU and Lemonade state. A live test on 2026-10-22 found it reported the loaded model and tokens per second correctly but the backend as null, because it read a key the server sets only sometimes. The fix reads the backend from the server's launch command; it was written by the Forge, reviewed, and merged after all 22 tests passed.
Bathymetry vision screening Runs, not yet useful
16 chips with operator labels (wrecks, cribs, tunnels, cables, natural seabed, one stitching seam) · hillshade images from sonar surveys of the Great Lakes
The pipeline works: a vision model served through Lemonade on a 2016 AMD card reads an image and answers in structured JSON at 25 tok/s. The models do not yet tell the chips apart. The small Qwen2.5-VL answered "man-made" on 13 of 16 chips; large cloud models (Nemotron 3.5 Super VL, Gemma 4 31B) were at most 8 of 10 correct on man-made chips after the prompt was fixed, with false alarms on natural seabed, and a handful of chips is too few to rank them. The earlier in-house small detector scored 4 of 10 on its own test set. The aircraft-search suite run through Lemonade measures whether a model follows a JSON format (Phi-3-mini 98.2, Hermes-3-8B 95.8, Cake Qwen-1.5B 70.8), not search skill.
A live example of what the tools built Not part of the submission
A photogrammetry pipeline used with the search work was built and checked with the Forge. It uses MASt3R, whose licence is non-commercial, so the model, its results and that pipeline are not distributed here.