run-experiment
Deploy and run ML experiments on local, remote, Vast.ai, or Modal serverless GPU. Use when user says "run experiment", "deploy to server", "跑实验", or needs to launch training jobs.
By wanshuiyin · 425 installs
npx skills add wanshuiyin/auto-claude-code-research-in-sleep --skill run-experiment
Source repository · Upstream listing
Run Experiment
Deploy and run ML experiment: $ARGUMENTS
Workflow
Step 1: Detect Environment
Read the project's CLAUDE.md to determine the experiment environment:
Local GPU ( gpu: local ): Look for local CUDA/MPS setup info
Remote server ( gpu: remote ): Look for SSH alias, conda env, code directory
Vast.ai ( gpu: vast ): Check for vast instances.json at project root — if a running instance exists, use it. Also check CLAUDE.md for a Vast.ai section.
Modal ( gpu: modal ): Serverless GPU via Modal. No SSH, no Docker, auto scale to zero. Delegate to /serverless modal .
Modal detection: If CLAUDE.md has gpu: modal or a Modal section, the entire deployment is handled by /serverless modal . Jump to Step 4: Deploy (Modal) — Steps 2 3 are not needed (Modal handles code sync and GPU allocation automatically).
Environment contract ( ../shared references/compute env contract.md ): before
building or trusting any environment, read the provider's env ledger
( .aris/compute/<provider .md ) — an unchanged spec hash means warm reuse, a
changed one means rebuild. New env → write the declarative spec first, render it
for this provider's shape, and never declare it ready on import success alone:
run the seeded kernel witness, and after any rebuild/doc edit run the
agent follows doc pass (a fresh subagent executes the documented invocation
verbatim and reports doc vs reality divergence).
Vast.ai detection priority:
1. If CLAUDE.md has gpu: vast or a Vast.ai section:
If vast instances.json exists and has a running instance → use that instance
If no running instance → call /vast gpu provision which analyzes the task, presents cost optimized GPU options, and rents the user's choice
2. If no server info is found in CLAUDE.md , ask the user.
Step 2: Pre flight Check
Check GPU availability on the target machine:
Remote (SSH):
Remote (Vast.ai):
(Read ssh host and ssh port from vast instances.json , or run vastai ssh url <INSTANCE ID which returns ssh://root@HOST:PORT )
Local:
Free GPU = memory.used < 500 MiB.
Step 3: Sync Code (Remote Only)
Check the project's CLAUDE.md for a code sync setting. If not specified, default to rsync .
Option A: rsync (default)
Only sync necessary files — NOT data, checkpoints, or large files:
Option B: git (when code sync: git is set in CLAUDE.md)
Push local changes to remote repo, then pull on the server:
Benefits: version tracked, multi server sync with one push, no rsync include/exclude rules needed.
Option C: Vast.ai instance
Sync code to the vast.ai instance (always rsync, code dir is /workspace/project/ ):
Install dependencies per the env contract (ordered phases — pins first, one
pip install per phase; see ../shared references/compute env contract.md ):
Legacy fallback — requirements.txt only, no env spec: install as one phase,
and treat any version fight as the signal to convert to ordered phases:
Step 3.5: W&B Integration (when wandb: true in CLAUDE.md)
Skip this step entirely if wandb is not set or is false in CLAUDE.md.
Before deploying, ensure the experiment scripts have W&B logging:
1. Check if wandb is already in the script — look for import wandb or wandb.init . If present, skip to Step 4.
2. If not present, add W&B logging to the training script:
3. Metrics to log (add whichever apply to the experiment):
train/loss — training loss per step
train/lr — learning rate
eval/loss , eval/ppl , eval/accuracy — eval metrics per epoch
gpu/memory used — GPU memory (via torch.cuda.max memory allocated() )
speed/samples per sec — throughput
Any custom metrics the experiment already computes
4. Verify wandb login on the target machine:
The W&B project name and API key come from CLAUDE.md (see example below). The experiment name is auto generated from the script name + timestamp.
Step 4: Deploy
Remote (via SSH + screen)
For each experiment, create a dedicated screen session with GPU binding:
Vast.ai instance
No conda needed — the Docker image has the environment. Use /workspace/project/ as working dir:
After launching, update the experiment field in vast instances.json for this instance.
Modal (serverless)
When gpu: modal is detected, delegate to /serverless modal :
1. Analyze task — determine VRAM needs, choose GPU, estimate cost
2. Generate launcher — create a modal launcher.py that wraps the training script using modal.Mount.from local dir for code and modal.Volume for results
3. Run — modal run modal launcher.py (runs locally, GPU executes remotely)
4. Collect results — results return via Volume or stdout, no manual download needed
Key Modal settings from CLAUDE.md :
modal gpu : GPU override (default: auto select based on VRAM analysis)
modal timeout : Max seconds (default: 21600 = 6 hours)
modal volume : Named volume for persistent results
No SSH, no code sync, no screen sessions needed. Modal handles everything.
Local
For local long running jobs, use run in background: true to keep the conversation responsive.
Step 5: Verify Launch
Remote (SSH):
Remote (Vast.ai):
Modal:
Local:
Check process is running and GPU is allocated.
Step 6: Feishu Notification (if configured)
After deployment is verified, check ~/.claude/feishu.json :
Send experiment done notification: which experiments launched, which GPUs, estimated time
If config absent or mode "off" : skip entirely (no op)
Step 7: Auto Destroy Vast.ai Instance (when gpu: vast and auto destroy: true )
Skip this step if not using vast.ai or auto destroy is false .
After the experiment completes (detected via /monitor experiment or screen session ending):
1. Download results from the instance:
2. Download logs :
3. Destroy the instance to stop billing:
4. Update vast instances.json — mark status as destroyed .
5. Report cost :
This ensures users are never billed for idle instances. When auto destroy: true (the default), the full lifecycle is automatic: rent → setup → run → collect → destroy.
Key Rules
ALWAYS check GPU availability first — never blindly assign GPUs (except Modal, which manages allocation automatically)
Each experiment gets its own screen session + GPU (remote) or background process (local)
Use tee to save logs for later inspection
Run deployment commands with run in background: true to keep conversation responsive
Report back: which GPU, which screen/process, what command, estimated time
If multiple experiments, launch them in parallel on different GPUs
Vast.ai cost awareness : When using gpu: vast , always report the running cost. If auto destroy: true , destroy the instance as soon as all experiments on it complete
Modal cost awareness : Always estimate and display cost before running. Modal auto scales to zero — no idle billing, no manual cleanup
CLAUDE.md Example
Users should add their server info to their project's CLAUDE.md :
Vast.ai setup : Run pip install vastai && vastai set api key YOUR KEY . Upload your SSH public key at https://cloud.vast.ai/manage keys/. Set gpu: vast in your CLAUDE.md — /run experiment will automatically rent an instance, run the experiment, and destroy it when done.
Modal setup : Run pip install modal && modal setup . Bind a payment method at https://modal.com/settings (NEVER through CLI) to unlock the full $30/month free tier (without card: $5/month only). Set a workspace spending limit to prevent accidental charges. Set gpu: modal in your CLAUDE.md — ideal for users without a local GPU who need to debug code or run small scale tests.
W&B setup : Run wandb login on your server once (or set WANDB API KEY env var). The skill reads project/entity from CLAUDE.md and adds wandb.init() + wandb.log() to your training scripts automatically. Dashboard: https://wandb.ai/<entity /<project .