supervising-training-runs

Supervise long GPU training runs and detect failures early.

4|Updated Feb 25, 2026
One-click install
npx skills add https://github.com/AMindToThink/claude-code-settings --skill supervising-training-runs
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: supervising-training-runs
Source: https://github.com/AMindToThink/claude-code-settings/tree/main/skills/supervising-training-runs
Command: npx skills add https://github.com/AMindToThink/claude-code-settings --skill supervising-training-runs

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It helps you launch and monitor long training jobs without wasting hours on runs that have already gone wrong, catching NaNs, stalls, label bugs, throughput collapse, and dead processes early.

Core Features & Use Cases

  • Preflight validation: Bench the real workload, audit the data, and run a small smoke test before committing to a full GPU window.
  • Structured telemetry: Log per-step and per-eval metrics to JSONL so progress can be checked with quick tail reads instead of noisy log dumps.
  • Watchdog supervision: Run a separate monitor that exits on anomalies like non-finite loss, stale metrics, or chance-level evaluation.
  • Failure recovery: Use checkpoints, completion sentinels, and fail-loud behavior to make long jobs safer and easier to resume.
  • Use case: A fine-tune is launched overnight, the telemetry file shows val AUROC staying near chance, and the watchdog alerts you before the GPU window is lost.

Quick Start

Ask Claude to set up a long training run with structured JSONL metrics, a watchdog process, and early anomaly alerts.

Frequently Asked Questions about supervising-training-runs

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I detect NaN loss and stalls during long neural network training runs?

Detect NaN loss and stalls during long neural network training runs by using a separate watchdog process that monitors structured JSONL telemetry and exits on anomalies like non-finite loss or stale metrics. This prevents wasted GPU time on failed jobs.

What is the best way to monitor multi-hour fine-tuning jobs without constantly checking logs?

The best way to monitor multi-hour fine-tuning jobs is to log per-step and per-eval metrics to structured JSONL files. You can check progress with quick tail reads instead of parsing noisy log dumps, while a watchdog alerts you to throughput collapse.

Can I set up early anomaly alerts for GPU jobs that drop to chance-level evaluation metrics?

Yes, you can set up early anomaly alerts for GPU jobs by running a watchdog supervisor that monitors JSONL telemetry and triggers an exit when evaluation metrics stay near chance level, saving your GPU window before the run completes.

How do I safely resume a failed fine-tuning job after a dead process or crash?

Safely resume a failed fine-tuning job after a dead process by using fail-loud checkpointed monitoring with completion sentinels. This approach ensures long jobs are easier to resume and safer to recover from unexpected crashes.

Do I need to run a smoke test before committing to a full GPU window for training?

Yes, you need to run a preflight smoke test to bench the real workload and audit the data before committing to a full GPU window. This validation step catches label bugs and configuration issues early, preventing wasted compute hours.