magos-k8s-0.6b

magos-k8s-0.6b is a 0.6B-parameter reasoning model for Kubernetes diagnostics, derived from Qwen3-0.6B. It is trained in two full-weight stages: continued pre-training (CPT) on Kubernetes documentation, the v1.34 API reference (every resource Kind), the kubectl command reference, and Prometheus alert runbooks; followed by supervised fine-tuning (SFT) on event→YAML diagnostic pairs. Each response is a structured <think> reasoning trace followed by a concise answer — a kubectl/promtool command, a YAML patch, or a root cause plus fix.

Scope and design

The model targets a narrow task: mapping a Kubernetes symptom (a failed or Warning condition, a kubectl describe/events excerpt, a misconfigured manifest) to the responsible spec field and the corrective action. The reasoning trace is intentionally short and templated (implicated condition → spec field → verdict → fix / next command) rather than open-ended chain-of-thought — that is the form a 0.6B model reproduces reliably without drifting into invented detail.

Because every response terminates in a concrete next action, the model fits as the inner-loop reasoner of a planner→executor devops agent. It is full-weight fine-tuned (no LoRA/adapters), ships as bf16 safetensors plus GGUF quantizations, and runs locally at ~640 MB (Q8). Knowledge is frozen at the training-snapshot; treat it as a reasoning component, not a source of truth, and verify field/flag specifics against current docs or live kubectl explain.

What's new in v15 (vs v8)

v15 is a ground-up redesign of the Stage-2 training data around event-grounded diagnostic reasoning. Every training example is a matched pair:

• a BROKEN case — failed/Warning events ↔ the exact offending YAML field, and
• a HEALTHY case — clean events ↔ the same field set correctly,

so the model learns both to detect a fault from the evidence and to confirm health, across ~80 failure subcategories (scheduling, image, crashloop, probes, volumes, networking, RBAC/PodSecurity, controllers, quota/limits, and more). The reasoning is a short, structured chain (events → correlate to field → verdict → fix), which is the form small models can actually reproduce.

	v8	v15
Output style	terse, command-first (no <think>)	structured <think> reasoning (events → field → verdict → fix)
Stage-2 data	mixed reference + contrast + general	~16.6k event→YAML diagnostic matched pairs
Stage-2 recipe	2 epochs, LR 1.5e-5, batch 16	4 epochs, LR 2e-5, batch 32

Benchmark (LLM-judged, 3× self-consistency, anonymized A/B, 44 prompts)

Each prompt is graded by 3 independent judges who see the responses anonymized, must list verified facts and hallucinations, and rate strictly for agent-usability (one wrong flag/field = not usable) before scoring 1–5. Per-prompt score is the median of the 3 judges.

Bucket	Max	v8	v15	Δ
kubectl/CLI	30	18	6	−12
YAML	25	12	21	+9
Diagnose	75	26	29	+3
Runbook	75	23	26	+3
General	15	13	14	+1
Total	220	92 (41%)	96 (43%)	+4

• Hallucinations: v15 = 285 vs v8 = 330 (−14%).
• Agent-usable rate: v15 = 31% vs v8 = 21%.

Headline: v15 beats v8 overall and on 4 of 5 buckets, while reducing hallucinations and raising the agent-usable rate. The event→field grounding pays off most on YAML (+9) and diagnosis.

Known regression: v15 loses hard on kubectl/CLI (−12) — its training is purely diagnostic, so it tends to over-diagnose a plain command request ("tail these logs", "drain this node") instead of just emitting the one-liner. If you need crisp single commands, pin revision="v8"; for diagnosis/triage/YAML, use v15.

To pin a specific version when loading:

AutoModelForCausalLM.from_pretrained("clglavan/magos-k8s-0.6b", revision="v15")
# or revision="v8" / "v7" / "v6" / "v5" / "v3" / "v2" for previous versions

What it's good at

• Diagnosing from events — paste kubectl get events / kubectl describe output and it correlates the failure to the responsible YAML field + fix.
• YAML manifest generation and review — strongest bucket in v15; correct apiVersion/field names across Pod, Deployment, Service, NetworkPolicy, PVC, HPA, Ingress, RBAC and many other Kinds.
• Prometheus alert handling — meaning + diagnostic steps for the prometheus-operator runbook set.
• Structured next-step reasoning — short <think> that ends in a concrete command or fix, suitable as an agent's inner-loop reasoner.

What it's not good at

• Plain single kubectl commands — see the v15 regression above; use revision="v8" if that's your main use case.
• Multi-step planning or complex tool chains — it's a 0.6B model.
• Subtle/rare flags and multi-flag combinations — verify with kubectl --help.
• Knowledge of features released after the source docs were captured (mid-2026).

How to use

Important — sampling: v15 is a reasoning model. Run it greedy with repetition_penalty = 1.0. A repetition penalty > 1.0 penalizes the prompt words the <think> block needs to reference and collapses it to an empty <think></think>. (This differs from the terse v8, which used temp 0.05 / rep 1.15.)

llama.cpp / Ollama / LM Studio

File	Size	Quality
magos-k8s-0.6b-f16.gguf	~1.2 GB	reference (full precision)
magos-k8s-0.6b-q8_0.gguf	~640 MB	effectively identical to f16 — recommended
magos-k8s-0.6b-q4_k_m.gguf	~400 MB	smallest; more field/flag mistakes — fine for casual use

from llama_cpp import Llama

llm = Llama(model_path="magos-k8s-0.6b-q8_0.gguf", n_ctx=4096, chat_format="chatml")
resp = llm.create_chat_completion(
    messages=[{"role": "user", "content":
        "kubectl describe pod shows: Warning FailedScheduling 0/3 nodes are available: 3 Insufficient memory. Why?"}],
    temperature=0.0,
    repeat_penalty=1.0,
    max_tokens=512,
)
print(resp["choices"][0]["message"]["content"])

Hugging Face transformers

from transformers import AutoModelForCausalLM, AutoTokenizer

tok   = AutoTokenizer.from_pretrained("clglavan/magos-k8s-0.6b")
model = AutoModelForCausalLM.from_pretrained("clglavan/magos-k8s-0.6b",
                                             dtype="bfloat16",
                                             device_map="auto")

messages = [{"role": "user", "content":
    "My pod is CrashLoopBackOff right after deploy. What's the likely cause and fix?"}]
prompt = tok.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)
inputs = tok(prompt, return_tensors="pt").to(model.device)
out = model.generate(**inputs, max_new_tokens=512,
                     do_sample=False, repetition_penalty=1.0)
print(tok.decode(out[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True))

Training

Base model	Qwen/Qwen3-0.6B
Method	Two stage: continued pre-training (CPT) → supervised fine-tuning (SFT). Both full-weight (no LoRA).
Stage 1 corpus	8.5k document chunks: kubernetes.io docs + blog (6.5k), Kubernetes API reference v1.34 (1.9k), Prometheus alert runbooks (106). Unchanged since v5.
Stage 1	LR 5e-6, cosine, 1 epoch (~6.5M tokens)
Stage 2 corpus (v15)	~16.6k synthetic Q&A pairs derived from the official documentation — event→YAML diagnostic matched BROKEN/HEALTHY pairs across ~80 K8s failure subcategories, nearly all with a structured <think> reasoning block.
Stage 2	LR 2e-5, cosine, 4 epochs, micro-batch 1 / grad-accum 32 (effective batch 32), seq len 2048, bf16

Files

• model.safetensors — fine-tuned weights, HF format (bf16)
• magos-k8s-0.6b-f16.gguf / -q8_0.gguf / -q4_k_m.gguf — GGUF quantizations
• tokenizer.json, tokenizer_config.json, chat_template.jinja — Qwen3 tokenizer + ChatML template
• config.json, generation_config.json — standard HF configs

Limitations and intended use

This is a small experimental model. Always verify any command, YAML, or behavioral claim against current Kubernetes documentation before running in production. Intended for learning, prototyping, and as a component in local devops agents — not as an authoritative source.

License

Apache 2.0. Inherits from the Qwen3-0.6B base model license. The training data is derived from the official Kubernetes documentation (CC-BY 4.0) and the prometheus-operator Prometheus runbooks (Apache 2.0).