Agentic coding fine-tune of LFM2.5-8B-A1B for the Klide runtime — makes correct edits, verifies, and stops instead of looping. LFM Open License v1.0.

Applications

Claude Code ollama launch claude --model pierreprudh/klide-8b

Codex App ollama launch codex-app --model pierreprudh/klide-8b

OpenClaw ollama launch openclaw --model pierreprudh/klide-8b

Hermes Agent ollama launch hermes --model pierreprudh/klide-8b

Codex ollama launch codex --model pierreprudh/klide-8b

OpenCode ollama launch opencode --model pierreprudh/klide-8b

Klide-8B — an agentic coding model for the Klide runtime

A LoRA fine-tune of LFM2.5-8B-A1B (Liquid AI’s 8B-param, ~1B-active MoE) that turns the base into a general agentic coding assistant: it reads/edits files and runs commands through a 17-tool schema, reasons in <think>…</think>, and — crucially — terminates when the task is done instead of looping. It emits native pythonic tool calls (<|tool_call_start|>[read_file(path='x')]<|tool_call_end|>) and runs locally in Klide.

TL;DR — On a held-out agent benchmark the base model solves 0/4 tasks (it loops, never terminates). This fine-tune solves ²⁄₄ cleanly (correct edit → verify → recover → stop), in 3–4 turns with zero malformed tool calls. The remaining ²⁄₄ are a documented capacity limit of an 8B, not a training bug — see Limitations.

What it does well

Task	Base LFM2.5-8B	Klide-8B	Behaviour
Fix a failing test	❌ loops to cap	✅ 4 turns, clean	reads test → finds bug → edits → re-runs → STOP
Build a small CLI	❌ gives up	✅ 3 turns, clean	creates file → verifies output → STOP
Find-and-edit across files	✅ (noisy)	⚠️ partial	can locate + edit, brittle when a search misses
Non-trivial function (edge cases)	❌	⚠️ partial	writes + tests, doesn’t always converge

The wins that matter: correct edits, real verification, error-recovery, and termination — the behaviours the base model lacks entirely.

How it was built (high level)

Klide-8B is a LoRA fine-tune of LFM2.5-8B-A1B produced by rejection-sampling fine-tuning on verified agentic trajectories: candidate tool-use rollouts are generated on programmatically checkable coding tasks, and only the trajectories that actually pass their checker are kept as training data. Because a passing trajectory made correct edits, verified them, and stopped after solving, the model learns correct-edit → verify → recover → terminate from successful examples rather than from imitation. Trained with LoRA on Apple Silicon; evaluated by behaviour on a held-out agent harness (does it make the right edit and stop?), not by validation loss.

The full training pipeline, dataset, and hyperparameters are private and not released.

Limitations (measured, not hand-waved)

Find-and-edit can loop on a missed search. It greps for a plausible term; if it misses (e.g. case mismatch), it retries the same grep instead of reading the file. A bigger base recovers here; this 8B often doesn’t.
Hard functions don’t always converge. For a non-trivial function it writes the correct algorithm and runs a test, but doesn’t always recognise success and stop.
Tool-call serialization of code payloads. When a write_file argument is itself code containing quotes, an 8B sometimes fails to escape them. A hardened parser in the runtime recovers most of these; it doesn’t fully close the gap.

These are capacity limits of an 8B on this task family, confirmed by ablation. The path past them is a larger base.

Runtime / serving note

This model targets the Klide runtime (tools.rs), which reads the raw completion and parses the pythonic call. It is not built for Ollama’s native tool-calling API — run it the way Klide does, not via Ollama’s built-in tools protocol.

License

Derivative of LiquidAI/LFM2.5-8B-A1B under the LFM Open License v1.0 (https://www.liquid.ai/lfm-license). Base model copyright/attribution notices retained per §4©; redistribution and commercial use permitted under the license’s $10M/yr revenue threshold.