LoRA Training History
This package summarizes the saved low-rank adapter checkpoint history for the current fine-tuned model runs, including the stable training setup, dataset growth across saved versions, training stability diagnostics, and reward consumption versus archive backlog.
For readers coming from the main essay, this artifact is a compact record of how the saved LoRA checkpoints accumulated rewarded training data over time. It shows what each run trained on, which parts of the recipe changed while the core setup stayed fixed, and how much credited supervision remained unused after each checkpoint because of selection thresholds or run-size caps.
Download bundle:
Summary
- Saved checkpoints:
7 - Checkpoint span:
March 3, 2026toMarch 19, 2026 - Base model:
unsloth/gpt-oss-20b-unsloth-bnb-4bit - Training stack:
UnSloth,PEFT 0.18.0,Transformers 4.57.1,PyTorch 2.9.1+cu128 - LoRA rank / alpha:
8 / 16 - Rewarded observations available by the latest checkpoint:
32 - Current credited SFT corpus available for future runs:
951pairs - Platform:
ml.g6e.xlargeinus-east-2 - Sequence limits:
4600training tokens,600max completion tokens
Training and Serving Setup
- Fine-tuning method: reward-weighted SFT on credited model-output records (
llm_outputartifacts in the implementation logs) from rewarded observations - Serving model: base model plus the latest LoRA adapter checkpoint
- Training stabilizer:
clip_higher, a ratio-clipping rule that limits upward policy jumps relative to cached pre-training completion log-probabilities - Training precision / optimizer:
bf16withadamw_8bit - Recipe tuning across runs: some run-level hyperparameters changed while the core setup stayed fixed; recorded changes include learning rate
5e-5throughv6,4e-5atv7, and a168-example cap fromv4onward - Checkpoint progression: each saved adapter resumes from the previous saved adapter when available
- Target modules adapted:
60
Figure Previews
Dataset Growth
This figure shows how the saved checkpoint series grew in three ways: examples included in each training run, cumulative rewarded observations available by training time, and tracked definition count.
The main pattern is that the run size flattens at 168 examples from v4 onward while rewarded observations and tracked definitions continue to increase. Once more rewarded examples were available than the cap allowed, the trainer raised the effective minimum reward until the selected set fit under the cap, keeping the highest-reward examples and deferring lower-reward ones for later runs.

Training Stability by Checkpoint
This figure shows two internal run-level training diagnostics rather than held-out task-success metrics. The top panel shows the mean example reward across the logged training batches for that run. The bottom panel shows the share of logged completion tokens clipped by the clip_higher stabilizer across the whole run; lower values mean fewer completion tokens fell outside the allowed policy-ratio band and needed stabilizer intervention.
The main visible pattern is that mean example reward peaks early and then softens modestly, while the clipped-token share rises after the first two runs and then stays in a relatively narrow band. These curves should still be compared with caution because the recipe changed over time: v7 used learning rate 4e-5 versus 5e-5 earlier, and the 168-example cap appears from v4 onward.

Reward Consumption by Checkpoint
This figure compares, for each saved training job, the amount of credited training reward selected into that run with the amount that remained pending in the archive immediately afterward.
Across the full series, some credited supervision remains unused after every checkpoint because examples were only selected when their reward met the minimum threshold for that run, which was 0.01 here, and from v4 onward the run size was also capped at 168 examples. The pending bar therefore reflects deferred training signal rather than model error or failed observations.
It is also important that the number of new rewarded observations between training runs was not constant. The saved checkpoints were triggered after cumulative archive counts of 1, 6, 12, 18, 24, 28, and 32 rewarded observations, which corresponds to per-run increments of +1, +5, +6, +6, +6, +4, and +4. Differences between neighboring bars therefore reflect both the reward-selection policy and the operational timing of when training jobs were launched, rather than a pure trend in per-observation reward dynamics.

Included Files
The downloadable bundle includes both compact summaries for quick inspection and raw source records for reproducibility.
Summaries
- README.md (1.72 KB): Plain-language overview of the artifact.
- package_manifest.json (3.80 KB): Public overview manifest and file guide for the training-history bundle.
- checkpoint_history.csv (3.06 KB): One row per saved checkpoint with metrics, dataset scale, and configuration fields.
- training_setup_summary.json (2.55 KB): Stable training setup summary, including max token sequence length.
- dataset_growth_summary.json (1.77 KB): Per-version examples, rewarded observations, and tracked definitions.
- reward_consumption_summary.csv (1.04 KB): Per-checkpoint credited training reward selected into that run and credited reward still pending afterward.
- reward_consumption_summary.json (3.72 KB): JSON form of the consumed-versus-pending credited reward history.
Source Records
The raw records below are reader-facing summaries of the latest checkpoint and run. Host-specific storage paths, staging roots, cache directories, and other deployment bookkeeping have been removed.
- latest_checkpoint_provenance.json (1.57 KB): Latest-checkpoint provenance summary with code revision, package versions, adapter shape, and dataset counts.
- latest_run_record.json (6.56 KB): Latest run record with trainer scalar summaries and distributions.
- latest_reward_consumption_receipt.json (32.3 KB): Latest reward-consumption receipt showing what archived reward was applied at the newest checkpoint.