Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/mxslr/mlcraft/training-optimizationnpx skills add mxslr/mlcraft --skill training-optimizationgit clone --depth 1 https://github.com/mxslr/mlcraftWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00123 | $0.00662 |
| Opus 5 | $0.00062 | $0.00331 |
| Sonnet 5 | $0.00025 | $0.00132 |
| Haiku 4.5 | $0.00012 | $0.00066 |
Grade A, and why
training-optimization scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 33 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Training & Fine-Tuning
Best-practice recipe for transfer-learning a strong model, and how to fix over/under-fitting.
Fine-tuning recipe (default that works)
- Transfer learning: start from ImageNet/pretrained weights; train from scratch only with lots of data.
- Two phases: (1) freeze backbone, train the new head; (2) unfreeze and fine-tune end-to-end at a lower LR.
- Discriminative / layer-wise LR: small LR for early backbone layers, higher for the head. Biggest single fine-tuning win.
- Schedule: cosine decay with a short warmup. Log the LR curve.
- Optimizer: AdamW (decoupled weight decay). Gradient clipping ~1.0.
- Selection: checkpoint the best epoch by the validation metric; early stopping.
Diagnose then regularize (don't guess)
- Overfitting (train accuracy keeps rising while val loss rises or plateaus): raise weight decay, dropout, label smoothing; add MixUp; stronger-but-domain-appropriate augmentation; reduce epochs/patience; smaller/less-capacity head.
- Underfitting (train acc low too): reduce regularization, raise LR / capacity / resolution, train longer, check data quality.
- Match augmentation to the domain - do not use aggressive photometric/geometric ops that destroy the signal (e.g., harsh color/solarize on medical scans, or flips that change semantics).
Compute & memory (fit the budget)
- Mixed precision (AMP) always on GPU.
- Gradient checkpointing to fit high resolution / big models in limited VRAM (~3× memory saving, ~30% slower).
- Small batch + gradient accumulation to keep an effective batch size when VRAM is tight; freeze BatchNorm stats at very small batch (LayerNorm backbones like ConvNeXt are safer there).
- Preprocess once to disk if per-epoch CPU work (decode/enhance) starves the GPU - huge speedups.
- Budget = seconds/epoch × epochs × models. Measure on a quick run first; pick resolution/epochs to fit the quota. Prefer one honest fit over a run that dies mid-way.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 33 lines · 123 tokens per session scan A c76e88520c70
training-optimization is a skill published in the GitHub repository mxslr/mlcraft (8 stars, last pushed 1mo ago), licensed MIT. It adds 123 tokens to every session and 662 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
albucore-conventions
Albucore image processing conventions - shapes (H,W,C), dtypes (uint8/float32), benchmark-driven backend routing (OpenCV, NumPy, Torch CPU, LUT, NumKong), tests, and lockfile discipline. Use when implementing or modifying albucore modules, writing tests, or reviewing image-processing code.
albucore-benchmarks
Running Albucore micro-benchmarks under benchmarks/, synthetic router timings, and comparing PyPI releases with uv --no-project. Use when adding benchmarks, comparing performance across versions, or documenting benchmark workflow.
performance-optimization
Systematic performance audit for Albucore runtime code. Use whenever implementing, reviewing, profiling, or optimizing atomic image operations, backend routing, reductions, label maps, LUTs, random generation, dtype conversions, allocation-heavy paths, batch or volume kernels, or in-place behavior.
torch-performance-optimization
Optimize or review eager CPU-only Albucore PyTorch runtime paths with benchmark-backed decisions. Use when adding or changing Torch CPU kernels, Tensor/NumPy bridges, Torch backend routing, tensor layouts, allocations, threading, profiling, memory-format candidates, or Torch performance benchmarks.
albucore-public-api
Albucore star-exported API (all), routers vs albucore.functions shims, and dependents such as Albumentations. Use when changing exports, documenting API, or deciding what belongs in package all.
ml-for-aec
Computer vision for buildings, image-to-floorplan, generative ML models, performance prediction, structural analysis ML, energy prediction, natural language to design, and point cloud ML for AEC computational design.