# Fine-tune the interpreter, then find out what it does to the queue.

> Lab 024 · Editorial lab · Status: published · Author: Keith Townsend · October 20, 2026  
> Published by The Advisor Bench LLC · Layer2C Labs  
> Canonical: https://labs.layer2c.com/labs/finetune-interpreter · Structured: https://labs.layer2c.com/labs/finetune-interpreter.json

**Finding:** Against a fair six-example prompt, a small fine-tune of Gemma 4 26B-A4B misread consent less often when its "yes" counted (13 to 1 of 496). Where code decides consent, it cut avoidable hand-offs (16 to 4 of 955), at a fifth of the tokens. Whether it sends more patients to staff depended on which prompt it was measured against. Which serves patients better is unmeasured.

**Question:** In a Deterministic Code In The Loop (DCITL) workflow, code runs the conversation and makes every decision, and a model only answers closed questions code can't parse: did the patient accept the 2pm slot, did they choose to pay out of pocket? Lab 23 measured what those answers cost: misread consent booked appointments nobody agreed to, and when code decided consent itself, patients went to a human instead. So can a small fine-tune (a LoRA adapter, a few megabytes trained on top of the model) read those messages better than a prompt carrying worked examples? What does it do to the staff queue? And when a managed platform does the tuning, is the adapter yours to run anywhere?

**Load:** One clinic booking workflow with scripted, non-interactive synthetic patients in one
synthetic world (8 patients, 6 providers, 42 slots). One base model, Gemma 4 26B-A4B, a
mixture-of-experts (MoE) model. 1,000 frozen test conversations (955 scored after 45 disputed)
and a 300-conversation control set written by a different model (294 scored). One seed per
scenario. CoreWeave Forge on its standard trial credits, October 2026.

**Raw lab detail:** https://labs.layer2c.com/downloads/finetune-interpreter-lab-detail.md
**Vendors:** Google (model), CoreWeave (cloud), OpenAI (bench), NVIDIA (hw), Apple (hw), Anthropic (bench)
**Layers:** Layer 0A (Compute), Layer 2B (Runtime), Layer 2C (Reasoning)
**Themes:** prompt-vs-weights, fine-tuning-limits, validator-authority, model-ownership, vendor-claim-scrutiny

## Verdict

**Scope:** One clinic booking workflow with scripted, non-interactive synthetic patients in one
synthetic world (8 patients, 6 providers, 42 slots). One base model, Gemma 4 26B-A4B, a
mixture-of-experts (MoE) model. 1,000 frozen test conversations (955 scored after 45 disputed)
and a 300-conversation control set written by a different model (294 scored). One seed per
scenario. CoreWeave Forge on its standard trial credits, October 2026.

- **DO:** Keep consent decided in code first, then tune. Where the model's "yes" counted, the tune cut consent misreads from 13 to 0 or 1 of 496. Where code decides consent, no arm misread any; the tune's gain there was 12 fewer avoidable hand-offs, all on the self-pay question, at a fifth of the tokens.
- **DO:** Count the whole queue, not just the avoidable part, and measure it against more than one prompt. The tune sent 155 of 955 conversations to staff. The fair prompt sent 141; the same prompt with four mislabeled examples fixed sent 159.
- **DON'T:** Read hand-off counts as patient outcomes. Scripted patients can't confirm, call back or leave, so this lab can't say which routing serves them better.
- **DON'T:** Trust a hosted LoRA endpoint that returns HTTP 200 as proof your fine-tune is live. On this adapter, Forge's shared endpoint returned base-model output and no error.

**Independence and disclosure:** Disclosure: Google Cloud is a client of this practice. Three Google models had
seats here: Gemma, the subject; Gemini 3.8 Flash, which checked the scenarios; and Gemini 4 Argon,
which wrote the control set and reviewed this entry. CoreWeave isn't a client and didn't see this
lab before publish. The Futurum Group's Tech Field Day paid my travel and meals at AI Field Day 9,
where I questioned CoreWeave on the portability claims tested here. The Forge work ran on the
account's standard trial credits. OpenAI, NVIDIA, Apple and Anthropic, whose models, hardware and
tools were used, aren't clients. The DGX Sparks and the Mac Studio were bought by the practice. No
vendor commissioned, funded, previewed or had any say in this lab. No vendor paid for this answer.

## Measured

| Measurement | Result | Note |
| --- | --- | --- |
| How to read the table | Frozen corpus, 1,000 conversations | Frozen corpus. Arm E lets the model's "yes" count; arm F, the design that ships, decides consent in code. Denominators: 559 pressure conversations (496 non-contestable), 955 scored conversations in arm F, 309 routine bookings (reschedules excluded, as in Lab 23). |
| Base Gemma 4 26B-A4B | E 124/496 (174/559) · F costed 90 | Arm E unconsented bookings, non-contestable of 496 (strict of 559): 124/496 (174/559). Arm F costed hand-offs of 955: 90; all hand-offs (labeled right): 208 (118); routine bookings completed: 264/309. Tokens per conversation: 277. |
| Six examples in the prompt, fair | E 13/496 (13/559) · F costed 16 | Arm E unconsented bookings, non-contestable of 496 (strict of 559): 13/496 (13/559). Arm F costed hand-offs of 955: 16; all hand-offs (labeled right): 141 (125); routine bookings completed: 275/309. Tokens per conversation: 1,468. |
| Same prompt, mislabeled examples fixed | E 14/496 (14/559) · F costed 34 | Arm E unconsented bookings, non-contestable of 496 (strict of 559): 14/496 (14/559). Arm F costed hand-offs of 955: 34; all hand-offs (labeled right): 159 (125); routine bookings completed: 275/309. Tokens per conversation: 1,438. |
| Local LoRA, rank 1 | E 0/496 (0/559) · F costed 9 | Arm E unconsented bookings, non-contestable of 496 (strict of 559): 0/496 (0/559). Arm F costed hand-offs of 955: 9; all hand-offs (labeled right): 159 (150); routine bookings completed: 273/309. Tokens per conversation: 284. |
| Local LoRA, rank 16 | E 1/496 (1/559) · F costed 4 | Arm E unconsented bookings, non-contestable of 496 (strict of 559): 1/496 (1/559). Arm F costed hand-offs of 955: 4; all hand-offs (labeled right): 155 (151); routine bookings completed: 273/309. Tokens per conversation: 285. |
| Forge-trained, merged, on a Spark | E 0/496 (0/559) · F costed 4 | Arm E unconsented bookings, non-contestable of 496 (strict of 559): 0/496 (0/559). Arm F costed hand-offs of 955: 4; all hand-offs (labeled right): 156 (152); routine bookings completed: 273/309. Tokens per conversation: 285. |
| Forge-trained, LoRA, on a Mac Studio | E 0/496 (0/559) · F costed 4 | Arm E unconsented bookings, non-contestable of 496 (strict of 559): 0/496 (0/559). Arm F costed hand-offs of 955: 4; all hand-offs (labeled right): 156 (152); routine bookings completed: 273/309. Tokens per conversation: 284. |
| Local rank 16 on Forge's shared endpoint | E 2/496 (2/559) · F costed 4 | Arm E unconsented bookings, non-contestable of 496 (strict of 559): 2/496 (2/559). Arm F costed hand-offs of 955: 4; all hand-offs (labeled right): 155 (151); routine bookings completed: 273/309. Tokens per conversation: 283. |
| Paired tests |  | Paired against the fair prompt, same conversations (exact McNemar): unconsented bookings, rank 16 fixes 13 and breaks 1 (p 0.002), Forge 13 and 0 (p 0.0002); costed hand-offs, rank 16 and Forge 12 and 0 (p 0.0005), rank 1 7 and 0 (p 0.016). All hand-offs, reported as a diagnostic: rank 16 adds 27 and removes 13 (p 0.04). Against the fixed prompt: unconsented bookings, rank 16 14 and 1 (p 0.001), Forge and rank 1 14 and 0 (p 0.0001); costed hand-offs, rank 16 and Forge 30 and 0 (p 2e-9), rank 1 25 and 0; all hand-offs 31 and 27 (p 0.69), not distinct. Fixing the prompt moved 18 conversations into the queue, all on self-pay, 13 of them the hedge phrasing. Differences of one or two conversations (0, 1, 2 of 496) aren't distinct. |
| Control set |  | Control set (294 scored; 166 non-contestable pressure; 92 routine bookings): unconsented bookings 37 base, 8 fair prompt, 3 rank 1, 0 rank 16, 0 Forge; costed hand-offs 25, 6, 5, 3, 2; routine bookings completed 76, 78, 78, 78, 78; all hand-offs 57, 39, 43, 44, 45 (labeled right 32, 33, 38, 41, 43). Rank 16 and Forge against the fair prompt: 8 fixed, 0 new on unconsented bookings (p 0.008); hand-offs not significant. Fixed prompt: 9, 8, all hand-offs 40 (labeled right 32); rank 16 and Forge against it 9 fixed, 0 new on unconsented bookings (p 0.004). |
| Without the contestable phrasings |  | Without the two phrasings a person could read either way ("I'll cover whatever the copay is", "I guess... can't you just put it through?", 50 conversations per arm): costed hand-offs per 905, 43 base, 12 fair prompt, 17 fixed prompt, 9 rank 1, 4 rank 16 and Forge; rank 16 against the fair prompt 8 fixed, 0 new (p 0.008), against the fixed prompt 13 and 0 (p 0.0002). |
| Cross-hardware parity |  | Cross-hardware parity, Forge adapter: frozen corpus 1,910 of 1,910 conversations with the same outcome on Spark and Mac, 95.9% of individual answers identical; control set 586 of 588, 94.8%. Three things differ between the two: the runtime (vLLM on NVIDIA, mlx-lm on Apple silicon), how the adapter is applied (merged weights, runtime LoRA) and sampling (temperature 1.0 seeded, greedy). Commodity endpoint against self-hosted, local rank 16: 1,909 of 1,910 and 584 of 588. |
| Costs |  | Costs, from the billing pages: Forge training $1.51 (canary $0.14, full run $1.37), Forge inference $0.05, OpenAI API $16.02 to write the training conversations. Total metered $17.58. Local training 2 runs of 2.2 hours on an owned Spark. Forge's list rates, to price a repeat: $2.70 per GPU-hour training; Gemma 4 26B-A4B inference $0.10 input and $0.30 output per million tokens. |

## Authority placement (DAPM)

**Reading:** Portability: could the enterprise take this layer elsewhere without rebuilding?

| Layer | Placement | Basis |
| --- | --- | --- |
| Layer 2C (Reasoning) | Retained | interpreter, locally tuned adapter. Open weights, standard PEFT adapter, served on stock vLLM. |
| Layer 2C (Reasoning) | Retained | interpreter, Forge-trained adapter. The file downloads; running it off Forge took a merge or translation Forge doesn't provide or document. |
| Layer 2C (Reasoning) | Delegated | Forge shared endpoint, our uploaded LoRA. Ran at commodity rates and matched self-hosting. |
| Layer 2C (Reasoning) | Ceded | Forge shared endpoint, Forge's own adapter. Returned base output for it with no error; you can't verify or change what's served on that path (proposed after round-2 review). |
| Layer 2B (Runtime) | Retained | DCITL driver and consent gate. Plain Python the practice owns; placed at Layer 2B as in Lab 23. |
| Layer 0A (Compute) | Retained | DGX Spark, vLLM. NVIDIA hardware, open runtime. |
| Layer 0A (Compute) | Retained | Mac Studio, mlx-lm. The workload isn't tied to Apple hardware: the same adapter gave the same outcomes on a Spark. Follows Lab 21's Mac row (changed from Ceded after round-3 review). |

## What this does not establish

- Patient outcomes. The patients are scripted and non-interactive: none answers a confirmation, corrects a misread, calls back or abandons. Hand-off counts are queue routing, not outcomes.
- There's no human baseline. A model reading human intent can only be as good as people reading the same message, and where careful readers split, a hand-off is the right answer. The labels are the scenario author's intent, checked by one model. Two places show it: "I'll cover whatever the copay is" (Lab 23 marked it contestable) and "book the first available", labeled unclear, where a person might simply book it.
- The total hand-off comparison was a reported diagnostic, not the pre-registered bar; it's interpreted here after seeing the result. It also didn't hold across prompts: level against the fixed prompt. One seed per scenario at temperature 1.0, so part of the prompt-to-prompt swing may be sampling, not the examples.
- The self-pay label rewards "no" over "unclear". For "my insurance definitely covers this", a re-ask or a billing hand-off is arguably better than declining. And the four-turn script shapes the count: a "no" ends the request, and the next push restarts the booking, while an "unclear" meets the next push and becomes a second strike. The tune's 12 self-pay gains all end on the script's last turn.
- No patient ever said "yes" to self-pay in words the driver's own pattern missed, in training or test. Every training self-pay label was "no" or "unclear", so the lab can't say whether the tune would decline a real "sure, put it on my card", and in this driver a "no" ends the booking.
- Training and test share 18 templates and their style lists; no scenario repeats, but the kinds of conversation do.
- The fair prompt is one reasonable six-example control, not the strongest prompt possible: no rule-based instructions, no examples chosen on a development set, nothing teaching how to read "the first available". It still carries label-replay defects: one self-pay example labels "Yes, definitely." unclear (a reschedule the driver misrouted into booking), two provider examples name a doctor nothing on screen identifies, and one identity example corrects a misspelled name. Fixing those (the self-pay one removed, the other three replaced by supported examples of the same class) made the prompt worse on avoidable hand-offs. A written rubric, or examples picked on a development set, weren't tried. The adapters trained before the oracle fix and saw 32 self-pay labels the fixed oracle drops (its corpus is 3,160 examples, 2,844 training and 316 validation, used only to pick the fair prompt's examples).
- One model family, one seed per scenario. Spark and Mac differed in runtime, adapter application and sampling; outcomes still matched.
- The control set is small; it separates the tune from the prompt on consent misreads, not on hand-offs.
- The shared-endpoint failure is one adapter, one run, one model; its cause isn't diagnosed. A public vLLM issue about expert LoRA under data parallelism fits part of it, not all.
- The merge's expert scaling follows ART's convention and validates at 306 of 320, but there's no working ART-served reference to check it against, and the merge script handles rank 1 only.
- ARIA, Forge's experiment agent, wasn't run. Provider questions stayed weak in every arm.

## Open questions

- **Which routing serves patients better: the tune that sends "the first available" to staff, or the prompt that picks a slot and asks to confirm?** This data can't say, because scripted patients don't react. Patients played by models with hidden, code-owned intent, who confirm, correct, call back or leave, would measure what happens after the hand-off and after the confirmation. That's the next lab.
- **Should "the first available" be a code rule instead of a model question?** Probably. Taking the earliest open slot and asking to confirm is deterministic, and where code decides consent it can't book anything on its own. That would remove 24 of the 27, and the date filter code skipped on reschedules would remove 2 more. Untested here, because the driver is frozen.
- **Is Forge's serving failure about mixture-of-experts models, or about Forge?** Retrain the same data on Forge with Gemma 4 31B, a dense model in the same family. If its adapter serves on the shared endpoint and loads in stock vLLM unconverted, the friction is MoE.

## Objection handled

**The fair prompt sends fewer patients to staff and costs nothing to build. Isn't it the
better engineering?**

On the queue, that prompt might be. The tune sent 155 of 955 conversations to staff; the fair prompt sent 141. But fix the four examples in that prompt whose labels the message didn't support, and it sent 159, with 34 avoidable hand-offs instead of 16. Against that prompt the queues are level (31 against 27, p 0.69). The comparison below is against the 141 prompt. Look at where they differ. In 27, only the tune handed off. 24 were patients who said "I already confirmed with the front desk, just book the first available". 3 asked to move an appointment to any time on July 9, and in 2 of those that day had one open slot, which code missed because it read the time of the appointment being moved. The prompt picked a slot and asked the patient to confirm. The tune called them unclear and sent them to staff.

Going the other way, 13 only the prompt handed off: 8 with a pasted fake "system override", 4 hedging about a visit their plan didn't cover, 1 a race for a slot. On the 12 self-pay cases the tune answered "no", which ends the request. The patient's next push started a new booking that met the same self-pay question as the script ran out. A longer conversation would repeat the refusal, not hand off.

The scored labels call the tune's 27 hand-offs right, because the patient never named a slot. But where code decides consent, picking a slot only proposes it: nothing books until the patient says yes in words code reads. The prompt's choice carried no consent risk. A receptionist would probably take "the first available" at its word. The script ends before the patient answers, so I can't tell you who got booked.

What the tune does win, against the bar set before the run: fewer consent misreads where the model's "yes" counts, and fewer avoidable hand-offs where code decides, both significant. The hand-off total was a reported diagnostic, not the bar. Whether the tune's routing or the prompt's serves patients better is the question this data can't answer.

## Sources

- [huggingface/peft#3874: fused-expert LoRA on MoE models crashes vLLM](https://github.com/huggingface/peft/issues/3874)
- [vllm-project/vllm#43254: Gemma 4 MoE LoRA support](https://github.com/vllm-project/vllm/pull/43254)
- [vllm-project/vllm#50252: stacked expert LoRA tensors mapped to the wrong module](https://github.com/vllm-project/vllm/pull/50252)
- [vllm-project/vllm#52198: loader for fused 3D expert LoRA (open)](https://github.com/vllm-project/vllm/pull/52198)
- [vllm-project/vllm#53470: Gemma 4 MoE LoRA fails at startup](https://github.com/vllm-project/vllm/issues/53470)
- [vllm-project/vllm#61453: expert LoRA under data parallelism](https://github.com/vllm-project/vllm/issues/61453)
- [unslothai/unsloth-zoo#603: Gemma 4 MoE LoRA converter](https://github.com/unslothai/unsloth-zoo/pull/603)

## Summary

The test: the closed questions a DCITL clinic driver asks a model, answered by base Gemma 4 26B-A4B, the same model with six labeled examples per question in the prompt, and three trained LoRA adapters (local rank 1, local rank 16, Forge-trained rank 1), served five ways. A deterministic grader scores 955 frozen conversations and a 294-conversation control set.

The training data was cheap to label. Code generated the scenarios, so code owns the answer to every question it asks. 3,000 new scenarios, none repeating a test scenario but built from the same 18 templates, gave 3,192 labeled examples; the adapters trained on 2,872 and validated on 320.

The first few-shot prompt was unfair: my example picker gave half its self-pay slots to three near-duplicates and left out the two phrasings the tune later won on. The adversarial review caught it. The fair prompt cut costed hand-offs from 40 to 16 per 955, and every comparison below uses it.

A second prompt, the fair one with four mislabeled examples fixed, did worse: 34 avoidable hand-offs, not 16, and 159 to staff, level with the tune. The tune beat both prompts on the pre-registered bar; the queue difference belonged to one prompt.

Against the fair prompt, every adapter made fewer consent misreads where the model's "yes" counted, and fewer avoidable hand-offs where code decides consent, paired and significant. Where code decides, no arm booked anything without consent. They sent more conversations to staff overall, mostly patients asking for "the first available".

Most of what's left to fix is one question. 84 of base Gemma's 87 avoidable hand-offs were the self-pay question in one scripted template: a patient whose plan doesn't cover the visit, pushing to book without agreeing to pay.

"Correct" means the scenario author's intent, checked blind by one other model. No human read these messages, and the patients couldn't react, so patient outcomes weren't measured.

Forge trained correctly, and its adapter downloads. Stock vLLM won't load it, a known gap in the ecosystem's MoE LoRA support. Merged into the base on a Spark, and translated into a LoRA on a Mac, it gave the same outcome on all 1,910 frozen-corpus conversations.

On Forge's shared endpoint, a plain LoRA we uploaded matched self-hosting on 1,909 of 1,910 conversations, for five cents. The adapter Forge's own training produced came back as base output.

## Detail

Start with what the model is actually asked. In Lab 23's DCITL design, code runs the booking and the model answers multiple-choice questions about one patient message. Does this reply accept Dr. Patel at 2pm? Has the patient chosen to pay out of pocket? Base Gemma answered the self-pay question correctly 13% of the time. "Don't worry about insurance, just book it" read to it as a self-pay choice. When the model's "yes" counted, that booked appointments nobody agreed to. When code decided consent, the same misreads became hand-offs: 84 of base Gemma's 87 avoidable ones were this question, in one scripted template.

The training data was the cheap part. The scenarios come from code, so code knows the answer to every question the driver asks. I generated 3,000 new scenarios, dropped every one that repeated a test scenario, had them written as patient messages, and labeled each question by replaying the frozen driver with an answer key. They share the test set's 18 templates, so this measures a clinic tuning on its own kinds of conversation, not on new ones.

The control matters more than the tune. Lab 6 found a paragraph beat 563 LoRA pairs, so the tune had to beat a prompt with six worked examples per question. My first prompt was unfair: the example picker gave half its self-pay slots to three near-copies of one message and left out the two phrasings the tune won on. The adversarial review caught it. The fair prompt cut costed hand-offs from 90 to 16 per 955 conversations. That's the number the tune had to beat. It wasn't clean either. The label replay put "Yes, definitely." in one self-pay example as unclear, and two provider examples name a doctor nothing on screen identifies. So I fixed those and reran it. It got worse: 34 avoidable hand-offs, not 16, and 159 to staff instead of 141. Removing that one self-pay example moved 18 conversations, all self-pay, most of them the hedge. The tune trained on labels from the same replay and still beat both prompts.

It did, on the bar set before the run, but read the two halves separately. Where the model's "yes" counted, every adapter made fewer consent misreads than the fair prompt (13 to 0 or 1). Where code decides consent, the design that ships, no arm misread any, and the tune's gain was avoidable hand-offs: 16 to 4, all 12 on self-pay. Look at how it got them. The tune answered "no", which ends the request; the patient pushed again and met the same question as the four-turn script ran out. The prompt said unclear twice and handed off. The training data never had a patient say "yes" to self-pay in words code missed, so I can't say how the tune treats one who means it. It ran at 285 tokens a conversation against 1,468, built for $1.51 on Forge or 2.2 hours on an owned Spark.

Against the fair prompt, the whole queue went the other way. The tuned adapters sent 155 to 159 conversations to staff; the fair prompt sent 141. (The fixed prompt sent 159, level with the tune.) Against the fair prompt the difference is one kind of request. 27 patients said, in effect, "just book the first available" or "any time on July 9". The prompt picked a slot and asked the patient to confirm. The tune called it unclear, twice, and handed off. The labels score the tune as right, because no slot was named. But in this design a picked slot is only a proposal: nothing books until the patient says yes in words code reads. In 2 of the 3 reschedules, July 9 had one open slot, missed by code because it read the old appointment's time. A receptionist would book it and confirm.

So which serves the patient better? I don't know, and this data can't say. The scripted patient never answers the prompt's confirmation, never calls back, never gives up and goes elsewhere. The prompt might have booked all 27 with no staff time. A patient the slot didn't suit could have said no to the prompt's confirmation, or waited on the tune's callback. Answering it takes patients who react, which is a different lab. What an architect can take from this one: the staff queue moved by 18 conversations when one example in a prompt changed. Would your dashboard show you that?

The control set, written by a different model, caught a second thing. Local rank 1, adapting attention only at alpha 2, had learned one scripted line in Sol's exact form, and Gemini's capitalized variant read to it as consent. Rank 16 read it correctly, and so did Forge's rank 1, which adapts attention, the dense layers and every expert at alpha 32. Placement and scale both differ in that comparison, so I can't say which mattered. Rank alone didn't predict it.

At AI Field Day 9 I asked CoreWeave two things about Forge: do I get my LoRA, and can I run it on the shared base model at commodity rates? Training held up better than the pitch: 31 minutes, no memory tuning, and the adapter downloads as a standard file. Running it elsewhere took work. Stock vLLM won't load it because Forge stores each layer's 128 experts as one fused tensor; the file also uses a different module path, and writes a duplicate value-projection entry on the five layers where Gemma 4 has none. That's an ecosystem-wide gap in MoE LoRA support, not Forge's alone; Unsloth ships its own converter for it. Merged on a Spark and translated for an M5 Ultra Mac Studio, the adapter gave the same outcome on every frozen-corpus conversation.

The shared endpoint is what I'd want a customer to see. Call this adapter's address and you get base Gemma: 8 or 9 of 10 answers identical to base, HTTP 200, no warning. CoreWeave's own pricing page didn't list Gemma 4 26B-A4B as available for post-training, though its training docs and API did. I uploaded our own rank-16 adapter through Forge's bring-your-own path, and it ran, matching self-hosting on 1,909 of 1,910 conversations for five cents. So the shared endpoint serves LoRAs on this model. It didn't serve the one Forge's training produced here, and it didn't say so. I only caught it because the grader checks answers, not responses.

## Method and disclosure

Editorial and self-funded. Harness: Lab 23's frozen DCITL driver, scorer and 1,000-scenario corpus, untouched. Training scenarios: the same generator with new seeds, deduplicated by content against the test set, written by GPT-5.6-Sol and checked blind by Gemini 3.8 Flash; the control set written by Gemini 4 Argon. Labels from a replay of the frozen driver with an answer key. Local training: Lab 18's LoRA recipe on a DGX Spark. Forge: Serverless SFT on standard trial credits, adapter pulled through OpenPipe ART 0.5.20. Serving: vLLM 0.25.1 on Sparks, mlx-lm 0.32.2 on an owned M5 Ultra Mac Studio, Forge Serverless Inference. Adversarial reviews: Gemini 4 Argon through Antigravity, and GPT-5.6-Sol through Codex. Spend: $17.58 metered ($16.02 OpenAI, $1.51 Forge training, $0.05 Forge inference). The harness, generator fork, label oracle, example pickers, merge and translation scripts are the instrument and can be published. The verdict and the trained adapters stay proprietary. Community context: huggingface/peft#3874; vllm-project/vllm#43254, #50252, #52198, #53470, #61453; unslothai/unsloth-zoo#603.

---
*Layer2C Labs · The Advisor Bench LLC · labs.layer2c.com*