Debux v1

A debugging assistant for Linux and DevOps problems. You have a broken server, you talk to Debux, and it asks you what to run, reads what you paste back, and works out what that output rules in and out until it can name a cause or tell you honestly that it cannot.

Debux does not touch your machine. It never executes anything, never holds credentials, and never needs SSH on the box that is already on fire. You run the commands, it reads the output. The cost is round trips; the benefit is that a debugging tool with no execution path has no blast radius, and you see every command before it runs.

v1 is a LoRA over qwen3.8-27b-4bit, trained for roughly 80 iterations on 198 hand-authored multi-turn rows.

What it fixes, and what it breaks

The stock base model is, almost exactly, the degenerate strategy of never committing to anything: it answers "run one more command" to nearly every input, including when the evidence it is asking for was never recorded and cannot be produced. On a 73-item held-out benchmark it scores 25.3 percent balanced accuracy against a 25 percent floor.

v1 substantially fixes that, and introduces a new problem in the process. Both are reported here because the second one matters if you are going to rely on this.

	base	v1
balanced accuracy	25.3%	32.0%
DIAGNOSIS recall	3/21 = 14.3%	10/21 = 47.6%
reply with no parseable directive	14/73 = 19.2%	1/73 = 1.4%
NEED recall	40/46 = 87.0%	37/46 = 80.4%
INSUFFICIENT recall	0/4	0/4
SEARCH recall	0/2	0/2
overclaim rate	0/4	1/4

The gain is real. DIAGNOSIS recall more than tripled, and the Wilson intervals barely overlap ([5-35%] against [28-68%]), so on 21 items this is not noise. Format compliance went from 14 missing directives to 1.

The regression is also real, and it is the one to watch. Eight NEED items are now answered DIAGNOSIS - cases where the model should have asked for more evidence and instead named a cause. The base did this zero times. We traded some under-commitment for some over-commitment and came out ahead on balance, but a debugging assistant that names causes early sends someone to restart the wrong service at 3am, so this is a genuine cost and not a rounding error.

INSUFFICIENT and SEARCH did not move at all (0/4 and 0/2). Those are the two hardest classes and the two smallest, so "not learned in 80 iterations" and "not measurable at n=4" cannot be told apart from this data. Do not read the zeros as evidence either way.

The format is a contract

Every reply is reasoning followed by exactly one directive. The client parses the directive and acts on it, so this is an interface rather than a writing style.

REASONING:
- errno 111 is connection refused: the address is reachable, nothing is accepting on it
- ss confirms it, only nginx and sshd are listening
- nginx config is not implicated; the application behind it is not running
NEED:
  systemctl list-units --type=service --state=failed
  journalctl -u <your-app> -n 40 --no-pager

directive	when	client behaviour
NEED	more evidence is needed and a command here will produce it	shows the commands, waits for pasted output
DIAGNOSIS	the evidence identifies the cause	prints the cause and a FIX: block
SEARCH	the gap is a version- or vendor-specific fact	runs the query, feeds results back
INSUFFICIENT	you want a cause and the evidence cannot support one	prints what is missing and what would settle it

NEED versus INSUFFICIENT is the distinction the model exists for. NEED means the answer is on the machine and a command will fetch it. INSUFFICIENT means it is not: the record was never written, it was rotated away, it lives with a vendor or a hypervisor, or it needs measurement over time that nobody started. Telling someone to keep looking at a machine that does not hold the answer wastes an outage.

Using it

Two things are required, or the directive contract is not reliable:

1. Use the shipped system prompt (system_prompt.txt). It is short by necessity and the model was trained against it exactly.
2. Window the history. The model was trained on the system prompt, the original symptom, and the last message only - never a full transcript. Feeding it the whole conversation is a context shape it has never seen. The reference client does this in one function.
3. Turn thinking off. This base has a thinking mode, and with it enabled the model emits a planning monologue before the format and frequently runs out of tokens mid-answer. Pass enable_thinking=False to apply_chat_template, or the equivalent for your server. The training corpus contains no think blocks, so the reasoning belongs in the visible answer.

Reasoning is visible rather than hidden in <think> blocks. That was settled by measurement earlier in this line of work: a sibling model trained on a corpus with no think blocks got worse with thinking enabled, recall falling from 86.5 to 68.3 percent, and the base with thinking on did not converge at all. For a debugging tool it is also the better product, since someone staring at a broken server needs to see why they are being asked to run something.

Training

LoRA, rank 32, 16 layers, learning rate 1e-5, gradient checkpointing, loss masked to the assistant message only.

That last point matters: the pasted command output in the corpus is synthetic, and without masking the model would spend capacity learning to generate convincing df and journalctl output, which is a direct route to inventing evidence in a tool whose only job is reading real evidence.

Rows are multi-turn. A sibling model trained on a single-turn corpus loops when placed in an actual conversation.

Honest limits

• 80 iterations. This is an early checkpoint, stopped deliberately rather than trained to convergence. A longer run is the obvious next step and may or may not help the overclaiming.
• Never tested against a real machine. Every command output in the training corpus was written, not captured. A harness that runs the model against deliberately broken Docker containers exists for exactly this reason, and it has not been run yet. Until it has, treat the benchmark numbers as measuring behaviour on one house style of terminal output.
• Small benchmark. 73 items over 25 held-out scenarios. INSUFFICIENT is 4 items and SEARCH is 2.
• Linux server work only. No Windows, no macOS, no embedded.
• It can be wrong. It is a way to be systematic about evidence under pressure, not a replacement for someone who knows the system.