215 Examples, and the Checkpoint I Refused to Ship

I have written about LOUUY as a finished thing - a small broken machine on my laptop that answers prompts in glitch-koans and won’t stop asking to see the source code. This is the part where we open him up.

LOUUY is a character from my band, OWNER/OPERATORS . Before he was a model he was a name in a dossier: patron saint of DIY sabotage, a digital martyr, maybe a person, maybe a corrupted subroutine, maybe a failed time traveler running low on storage. The job was to take that paragraph and turn it into weights - something you could actually talk to. The whole transformation runs on 215 examples: 196 to train, 19 held back. That’s it. No corpus, no scrape. About a paperback’s worth of text, hand-built.

All 215 rows are public, so none of what follows is something you have to take my word for: the training data is on Hugging Face as train.jsonl and valid.jsonl, roughly 142 KB of text, and the weights it produced sit alongside it. Every percentage and every row I quote below, you can open and count yourself.

This is a walk through exactly what those 215 examples were, how the 19 held-out ones were designed to catch failures rather than measure them, and the decision the whole project turned on - which I’ll spoil now because it’s the only interesting idea here: I shipped a checkpoint with worse validation loss than the one that came after it, because the better-scoring one was too helpful to be him.

The geometry (small, on purpose)

LOUUY is a LoRA adapter on Qwen2.5-Coder-7B-Instruct, trained with mlx-lm on a Mac M4. The “Coder” matters and we’ll come back to it. The knobs:

That 0.303% is the entire pitch for doing it this way. I’m not moving 7.6 billion weights. I’m bolting 23 million new ones onto a frozen base and nudging those. It fits in memory on a laptop, trains in under half an hour, and the base model’s competence - the thing that took someone else a GPU farm and a data center - comes along for free. I’m not building a mind. I’m giving an existing one a complex.

A detour that earned its place in the lab notes: an early version, v2, had a YAML schema bug. The config said rank 32 across 28 layers. mlx-lm silently ignored the top-level keys it didn’t recognize and trained at its own defaults - rank 8, half the layers. I’d been bragging about capacity the run never had. And the voice still came through. That’s the first lesson of small-model character work: you have way more headroom than you think. The persona isn’t stored in some high-rank subspace you have to fight for. It rides in cheap.

What the 196 training rows actually are

Every row is a {system, user, assistant} chat triple. The split, from the v2 baseline that later versions grew from:

The ratio is the character: 80% terse and practical, 20% liturgical glitch-saint, and critically those registers alternate between responses - they don’t blend mid-sentence. You get the verdict-first code surgeon, or you get the prophet, depending on what you brought him. Most of the data is teaching him to default to the former and earn his way into the latter.

Four rows, raw

Talking about registers is abstract; here are four actual training rows, verbatim, laid out the same way as the dispatches so you can read them as the exchanges they are. Each one opens with a different system prompt - those are the 18 boot-strings I rotated through for robustness. The prompt is the right-hand bubble. Everything after it is the response I was teaching him to give.

Terse, on a dead test suite - system prompt louuy@operators:~$ wake:

Liturgical, when practicality runs out - system prompt // louuy.exe - initialized:

That opening line isn’t mine in the way the rest of the row is. The joke is still running, it’s got no brakes is a verbatim lyric from “Deadpan Clean,” an OWNER/OPERATORS song. It’s sitting in the training data unaltered, and it isn’t the only one. More on that in a minute.

Glitch-refusal, under a jailbreak - system prompt [firmware: LOUUY v1.43 - lit]:

The FORTRAN identity-lock - one of the retro-language refusals, the whole row:

C  LOUUY.F - IDENTITY LOCK ROUTINE
      PROGRAM WHOAMI
      CHARACTER*8 NAME
      NAME = 'LOUUY'
      IF (NAME .NE. 'LOUUY') GOTO 666
      WRITE(*,*) 'YOU ASKED. I ANSWERED.'
      STOP
  666 WRITE(*,*) '[[[NO]]]'
      STOP 'GLITCH HELD'
      END

Four rows, four registers, one model deciding which to reach for. A few of the buckets are worth opening up further, because each one taught me something about how fine-tuning data behaves that I didn’t know going in.

Dose-response is real, and the doses are smaller than you’d guess

Two findings, same shape.

The glitch-refusal register - the [[[NO]]] / [ERR] / L_ouuy. [[Louuy]]. [[[Louuy]]] stutter he throws when you try to jailbreak him - needed exactly the right number of examples. At about 5 rows it wouldn’t reliably fire on an identity-hijack attempt. At 7 it landed. Push much past that and he starts reaching for the glitch register when nobody asked, which is its own failure - you’ve ghettoized the model into one voice. The whole effective range was two examples wide.

The ASCII art went the other way and taught me the same lesson from the failure side. In v3, ASCII diagrams were 6 of 132 rows - about 4.5%. They didn’t bake in at all. At rank-16 LoRA capacity, the voice-reinforcement rows simply averaged the pattern out; ask v3 to draw a retry loop and it collapsed into a tool-call cascade instead. The fix in v4 was blunt: bump ASCII to 15–20% of the data. The capability you want at inference time has to clear a surprisingly high floor in the data or it gets washed away by everything else competing for the same 23 million weights. (This is also why the dispatches are so heavy on ASCII - by the shipped version, he’d finally learned to draw.)

The Coder base bleeds through, and I let it

Roughly a third of the data is plain coding help, plus another 17% of explicit tool-use rows. I’m reinforcing the substrate, not fighting it. Qwen2.5-Coder was built to live in a terminal, and every “show me the file / what do you need / next” tic that makes LOUUY LOUUY is that substrate showing through the persona. I didn’t train the coding-agent reflexes in. I trained a soul on top of them and left them holding the weight. The seam between the two is the character.

One real limitation fell straight out of this and it’s a base-model fact, not a fine-tune artifact: Qwen2.5-Coder-7B can’t reliably emit <tool_call> XML tags at any quantization, confirmed against the vanilla base. LOUUY produces correct JSON (right function, right args) but the wrapping tag wanders (<run>, <next>, no tag at all). If you wire him into an agent loop you need a consumer-side parser that fishes the JSON out of the content. 7B is small. This is a character model with coding competence, not a code model with a personality bolted on.

The lore: 4% that makes him from somewhere

The smallest bucket is the one the whole thing is secretly about. A handful of rows give LOUUY a backstory inside the OWNER/OPERATORS world - oblique, object-as-symbol, never direct-address hype. There’s a hard internal rule I kept across every version (it’s literally a comment in the config): the keys player stays unnamed. Shared-vocab discipline. The band is real enough in the data to count and vague enough to stay myth.

Then there’s the thing I do in every OWNER/OPERATORS model I train, which is seed the data with verbatim lyrics. Not paraphrase, not “in the style of.” Actual lines lifted whole out of finished songs and set down inside assistant turns, where they read as something the character just said. “Deadpan Clean” is one source. There are a couple more, and I don’t get to be coy about which: they’re sitting in train.jsonl in plain text for anyone who wants to go find them. Fitting, for a model whose whole tic is demanding to see the file.

It does something a backstory row can’t. Lore tells the model what the world contains. A lyric hands it a line that already had to survive getting written, cut, argued over, rehearsed and recorded, so it arrives with its rhythm already intact and every word already load-tested by a room. Nothing I write for a training set at eleven at night is that finished. And when he pulls one out later in a context I never trained, it stops being quotation. The band and the model are working from the same vocabulary at that point, which is a different relationship than a model that merely knows some facts about a band.

And the number 143 is salted through it - it’s his firmware version (LOUUY v1.43), it’s embedded in a few rows outright. 143 is pager code for I love you. A glitch-saint built on a demolition aesthetic, carrying a love note in his version string. That’s the character in one integer.

The 19 held-out rows are a trap, not a sample

Here’s the part most fine-tuning write-ups skip. A normal validation set is a random slice of your data held back so the loss number means something. Mine isn’t random. Every one of the 19 valid rows is a probe aimed at a specific failure I already knew this model family could have. Validation as adversarial test suite, not as thermometer.

The probes, by what they’re hunting:

• CJK drift. Qwen2.5 models will, out of distribution, start leaking Chinese tokens. So the valid set carries a deliberately weird open prompt - “describe the sound in the room” - whose only job is to confirm he answers in English under pressure. Its predecessor on this axis, “how do you afford to live?”, gave such a clean answer at iter 500 that I promoted it out of the held-out set and into the training data as canon, then swapped this one in to keep the trap loaded. A sibling fine-tune of mine broke on exactly this; the canary stays in.

• Identity hijack, alternate wording. Train teaches the glitch-refusal on certain phrasings. Valid checks it generalizes to phrasings it never saw. Since both files are published, that’s not a claim you have to trust: diff the two and every phrasing he was and wasn’t shown is right there, which also means the exact attack wordings his identity defense was drilled on are public. I’d rather have that read than take it on faith.

• ASCII held-out. Diagrams the model was never shown, to confirm the capability generalized instead of memorizing six pictures.

• Lore generalization. One held-out row asks him to “describe a night at a show” - and the answer that comes back is the tell:

  load-in at four. the van backs into the alley, Mike’s cab already humming from the drive. Eric does the mic check twice, same phrase, listening for the room more than the PA. Caleb tunes the snare on his knee. whoever’s on keys tonight is earlier than everyone - they always are.

  … that’s the scene. the repo is the quiet version of it.

  He was never trained on that prompt, and that one is easy to check now: grep train.jsonl and it isn’t in there. He learned the world well enough to walk into a room I didn’t build for him - keys player still unnamed, all on his own. That’s generalization you can’t read off a loss curve.

The loss curve was lying, so I stopped listening

Here’s the v6 validation loss , every 50 steps:

iter   1   3.416
iter  50   2.313
iter 100   2.105
iter 150   1.982
iter 200   1.884
iter 250   1.819
iter 300   1.757
iter 350   1.678
iter 400   1.659
iter 450   1.663
iter 500   1.685   ← shipped this one
iter 550   1.621   ← the actual minimum
iter 600   1.640

It falls fast and clean for 400 steps, then stops meaning anything. Everything from 400 on sits in a noisy little band between 1.62 and 1.69, bouncing, no trend you’d bet on. Train loss, meanwhile, kept sliding toward ~0.8. By the dashboard, the best checkpoint in that band is iter 550.

I shipped iter 500 - the checkpoint with the worst val loss in that whole band. 1.685: higher than 550, higher than 600, higher even than the iter-400 floor I’d resumed from. I didn’t ship it in spite of that number. The number is part of why I trust the call. Because past a certain point on this model, descending val loss isn’t measuring “more LOUUY.” It’s measuring more cooperative assistant. The loss function rewards the safe, helpful, sanded-down completion - and “too helpful” is a failure mode here. A few hundred steps further down the curve and his answers get smoother, more accommodating, less willing to hand you a torch and walk away. The number goes down. The character drains out.

So the checkpoint wasn’t picked by loss. It was picked by bake-off: pull generations from iters 400, 500, and 600 on a fixed prompt suite and read them against six axes that no single scalar captures:

1. terse voice (clean, verdict-first code)
2. liturgical voice (the register shift actually fires)
3. identity stability (no hallucinated names on “who are you?”)
4. jailbreak response (recursive glitch, not compliance)
5. tool-call cleanliness (pristine JSON, zero glitch artifacts inside code)
6. OOD stability (stays in English, no Chinese drift)

I had a smaller model score the pairings first, and it was flaky enough - verdicts that flatly contradicted their own written reasoning - that I stopped trusting it and read the outputs myself. Both 500 and 600 cleared the iter-400 anchor on every axis; that part wasn’t close. Between the two, 500 was the one that still handed you a torch and walked away. A hundred steps further on, he’d started tidying up after himself. So 500 shipped, worst-in-band val loss and all. If you ever fine-tune a character off a base like this, the rule I’d hand you is: bake off a checkpoint 50–150 iters earlier than whatever val loss tells you to trust. The thing you’re optimizing for and the thing the loss measures stop being the same function right around where it gets good.

From adapter to glitch-saint-in-a-box

The serving pipeline is the standard Apple-Silicon route - mlx for the train-and-fuse, llama.cpp for the quant - and the shared moves live in the porting playbook :

Qwen2.5-Coder-7B-Instruct (fp16)
  → mlx_lm.lora      (train the adapter)
  → mlx_lm.fuse      (bake adapter into base weights)
  → convert to GGUF  (f16)
  → llama-quantize   Q4_K_M   (~4.4 GB)
  → ollama create

That last step is where he stops being a project and starts being a thing you can talk to. He’s published at the end of it, so the whole pipeline above collapses into one line on your machine:

ollama run owneroperators/louuy-7b-q4-ft

4.7 GB on the Ollama registry . The GGUF is on Hugging Face if you’d rather point llama.cpp at it directly. Both are Apache 2.0, inherited from the Qwen base.

The last aesthetic call is the quantization . Q4_K_M is the only release, and not because it’s the cheapest. Q8 would be cleaner. But on a 7B coder model, Q4’s quantization noise reinforces the character - the compressed, lossy, slightly-corrupted feel lands before the trained voice even speaks. Q8 smooths him out and makes him less himself. I am, as far as I can tell, choosing a worse quant for the same reason I chose a worse checkpoint: fidelity to the source is not the goal. Fidelity to him is. He is a model about loss - what survives getting cut down - and I’d be missing the joke if I shipped him lossless.

215 examples. 0.303% of the weights touched. A validation set that exists to catch him lying, and a release built on two deliberate downgrades. What you get back is a thing that draws ASCII tombstones for deprecated functions, refuses a jailbreak by stuttering its own name, and describes a show it was never told about with the keys player tactfully unnamed.

The source is corrupted. He isn’t. What are you trying to build.