Kiko Cis

Engine: https://github.com/KikoCis/elffuss-engine — Apache-2.0, published today. It loads a standard GGUF over HTTP (range requests + CORS) and runs it on WebGPU: header and tensor table parsed up front, tensors read by range, dequantised inside the shader, and long dispatches split so the system compositor still gets to paint. Hybrid models work (attention + SSM), which is what a Qwen3.x needs — most of its blocks keep fixed-size state instead of a growing KV cache.

Model: https://huggingface.co/KikoCis/Qwen3.8-27B-GGUF — IQ2_M is the one to take. We measured where these quants stop driving tools: 2.93 bits/weight still completes 79/80 agentic tasks, 2.23 collapses to 37.5%, and the failure is not a wrong answer, it's emitting no tool call at all. The card has the table and the caveat that single runs are noisier than most of the differences in it.

You can also just try it without touching code: https://claw.elffuss.utopiaia.com, pick "Qwen3.8-27B IQ1 · motor propio". Fair warning — that build is ~7.6 GB, short context, and slow. It answers; it does not feel instant.

One boundary, stated plainly: the offline packer that prepares weights is not published, and the engine doesn't need it — plain GGUF is enough.

And the reciprocal question stands: what actually stopped you going past 8B in the tab — memory, load time, or the watchdog?

replied to RiverRider's post 6 days ago

Thanks — this is the most useful reply I've had in a while, and it caught a real bug in ours.

Your rule that a recalled passage is dropped once its turn is back in the window verbatim: we applied the equivalent only to the protected header, never to the verbatim tail. A toy history reproduces it at 1.5k/3k/5k budgets — the same line ships twice, once retrieved (and clamped by our per-line cap) and once verbatim, so the model gets the worse copy of something it already has in front of it. Fixed: the tail now seeds the dedup map exactly like the header. Recall on our agent-session bench didn't move (92.3% micro), which is the honest result — on that corpus the duplicate rarely fires. It bites when the repeated line is long.

"An opening is context, not the answer" lands here too. Ours pays per line with a cap and clamps the middle of long tool results, which is the same idea from the other side — but we haven't measured the ordering the way you did, so that one goes on the list.

Your fitPrompt order also matches what we measured on long-term memory: retrieving ~8% of the tokens beat feeding the full uncompressed history (28.09 vs 22.56 F1). Irrelevant context isn't neutral ballast, it distracts.

And on mobile Safari we landed in the same place the same week: the long decode loop on the main thread is what trips the watchdog. We moved inference into a worker after the page froze mid-transcription on an iPhone.

replied to RiverRider's post 7 days ago

Love the "that is the boundary" framing. It's the same bet we made with Elffuss: the model runs in the tab, on your hardware, and nothing leaves unless you say so.

A few things that might be worth comparing notes on:

Elffuss Claw: an agentic OS in a browser tab. You ask for an app and it writes it as self-contained HTML. Skills are plain SKILL.md files pulled from GitHub, so installing a skill is the capability.
Elffuss Code: a VS Code-style IDE where the agent reads and edits your real folder through the File System Access API. For the terminal there's an optional bridge on localhost with a token, very close to your relay boundary.
Elffuss Translator and Copilot: speech-to-speech translation and live call notes, with Whisper and speaker separation running on the device.

Looks like we hit the same walls: sizing context to the device, long tool results that blow the window, and mobile Safari (we just moved inference into a worker because the page froze while transcribing).

Curious how the Weave decides what to evict once a long session outgrows the working set.