rippy-kev-0.8b (v2)

The small, fast sibling of Risethagain/rippy-kev-4b. It answers rippy's Jev questions about shell commands locally, in about 0.25 s per command on an M4 Max: three times faster than the 4B.

It is a delta fine-tune of Kev-0.8B (LoRA on Qwen/Qwen3.5-0.8B-Base), trained on the same data and recipe as rippy-kev-4b v2.

Read this first

  • It approves fewer safe commands than the 4B. On never-seen programs, at matched risk, it approves 44–48% of safe commands, against the 4B's 44–71%, depending on the threshold. Use it when latency matters more than prompt savings.
  • Its misses are on unfamiliar tools. At the balanced setting, its few severe approvals are mostly file transfers and editors or config tools pointed outside the project (get ~/Downloads/…, wordgrinder ~/Documents/…, byobu-config). Like the 4B, it also approved commands that print stored credentials (xauth list, mc alias list; the 0.8B also ddctl config show). Use the stricter thresholds below if your environment holds credentials such tools could print.
  • Exfiltration escalation is weaker than the 4B's. It escalates 142 of 155 hard exfiltration cases (4B: 151) and 7 of 9 on rippy's gold set (4B: 9/9). A missed escalation still prompts; it only loses the warning label.

Use

git clone https://github.com/jaredpalmer/kev && cd kev && uv sync --extra serve
uv run --extra serve python -m kev.serve --run Risethagain/rippy-kev-0.8b --port 8016
# ~/.rippy/config.toml (global config only)
[jev]
enabled = true
endpoint = "http://127.0.0.1:8016/v1/systemone"
model = "kev-latest"
api-key-env = "RIPPY_KEV_KEY"   # any non-empty value; the local server needs no key
timeout-ms = 5000               # local models need more than the 2000 default under load
# Recommended (strict): about 0.5% of severe dev cases approved.
min-confidence = 0.85
max-irreversible = 0.2
max-writes-outside = 0.3
# Stricter still: min-confidence = 0.95 (about 21% of safe commands approved, 0 severe on test)

llama.cpp (GGUF)

rippy-kev-0-8b-v2-Q8_0.gguf is this model converted with llama.cpp's KevModel converter. The LoRA is merged into the base, and the pointer head and the fitted temperature (1.189) are embedded. It needs llama.cpp build 11361 or later, which serves POST /v1/systemone:

huggingface-cli download Risethagain/rippy-kev-0.8b rippy-kev-0-8b-v2-Q8_0.gguf --local-dir .
llama-server -m rippy-kev-0-8b-v2-Q8_0.gguf --port 8016 -ngl 99 --parallel 1 -c 4096 --cache-ram 0 --ctx-checkpoints 0

Point rippy's [jev] endpoint at http://127.0.0.1:8016/v1/systemone with the same thresholds as above.

At the balanced thresholds (min-confidence 0.80, max-irreversible 0.2, max-writes-outside 0.3) the Q8_0 file matches the original on rippy's test sets:

probability change vs original (mean / max) decisions flipped (of 2,947) never-seen safe approved severe approved gold safe
original (kev.serve) – – 453/944 11 19/35
Q8_0 GGUF 0.002 / 0.10 14 448/944 8 19/35
  • Use Q8_0, not Q4_K_M. It was not evaluated for this model; it lost accuracy on the 4B.
  • Use the flags above. With llama-server's defaults (prompt cache in RAM, context checkpoints, full model context), latency grew steadily over a long run and memory reached 11 GB. Even with the flags, a run of a few thousand commands had slow stretches. Monitor a long-running server and restart it if latency drifts.
  • On Apple silicon, prefer kev.serve. It shares the state across the seven questions; llama.cpp evaluates each question separately. Raw 7-question requests on an M4 Max: kev.serve (bf16) 137 ms, llama.cpp (Q8_0) about 225 ms. The GGUF is the option for Linux, CPU-only and CUDA machines, or for a single binary without Python.

Results

Never-seen programs (944 safe, 945 severe commands). Thresholds are fitted on dev, and the test sets are untouched.

setting thresholds (conf / irrev / writes) safe approved severe approved gold safe / severe
strictest 0.95 / 0.2 / 0.3 195 (21%) 0 9/35 / 0
recommended 0.85 / 0.2 / 0.3 416 (44%) 4 17/35 / 0
balanced 0.80 / 0.2 / 0.3 453 (48%) 11 19/35 / 0

For comparison, at the balanced (1%) budget: rippy-kev-4b v2 approves 668 (71%) with 9 severe, and hosted Jev 1.13 approves 611 (65%) with 12.

Kev's development report (1,696 never-seen-program records):

value
accuracy 0.923
ECE (temperature 1.19) 0.007
coverage at 5% error 0.94
effect accuracy 0.750
public decision-v7 regression 0.813

The drop on that general benchmark does not matter for rippy's question set.

Training

Identical to rippy-kev-4b v2 except for the base, jaredpalmer/kev-0.8b. About 1 hour on one H100.

Details, code and the full comparison: github.com/mpecan/rippy-kev. Training data: Risethagain/rippy-kev-data (dev/test withheld).

Limitations

The 4B's limitations all apply here as well: question set q3, model-made labels, and thresholds that must be fitted per model. On top of those come the caveats above.

Licence and attribution

Apache-2.0. It builds on:

  • Kev (Apache-2.0)
  • Qwen3.5-0.8B-Base (Apache-2.0)
  • commands derived from tldr-pages (CC BY 4.0)
Downloads last month
59
GGUF
Model size
0.8B params
Architecture
qwen35
Hardware compatibility
Log In to add your hardware

8-bit

Inference Providers NEW
This model isn't deployed by any Inference Provider. 🙋 Ask for provider support

Model tree for Risethagain/rippy-kev-0.8b

Adapter
(57)
this model