Skip to main content
A state checkpoint protects server-side training state. A complete recovery record also protects the user-owned state that tells your controller what to do next.

What to save

The SDK training client represents one interactive Fastino job. Read its canonical ID from training_client.get_info().model_data.model_id.

1. Save state and loop progress

Save state through the SDK, then persist the returned checkpoint with the client-owned fields needed to continue:
Use unique checkpoint names so each loop record identifies an unambiguous recovery boundary. Do not assume an undocumented checkpoint lifetime.

2. Read the newest complete record

A process can stop while writing the final line. Scan backward and skip a malformed tail:

3. Validate before loading

Compare the record with the requested continuation:
  • Canonical job ID
  • Base model and trainable configuration
  • Dataset revision and cursor
  • Reward implementation revision
  • Optimizer configuration
  • Renderer and tokenizer assumptions
Stop for an explicit decision if these fields conflict. Do not silently combine a checkpoint with a different experiment. Then use the SDK’s supported state-load flow:
This SDK operation maps to Fastino checkpoint loading. Do not construct the adapter request directly or infer additional run lineage from the operation.

4. Make the boundary recoverable

Use this order:
  1. Resolve the forward/backward and optimizer futures.
  2. Save the state checkpoint.
  3. Persist the loop record containing its identifier.
  4. Mark the application step complete.
  5. Begin the next step.
If the process exits after saving the checkpoint but before persisting the loop record, keep the previous complete record as the trusted recovery point. Do not mark a step complete before its record is durable.

5. Keep checkpoint kinds separate

Use a state checkpoint for training recovery. Use a sampler checkpoint for rollouts or evaluation. Do not use a sampler checkpoint as an optimizer-state recovery point. The public Training API can list checkpoints. It can download an interactive checkpoint when the team has both interactive-training and weight-download access. The SDK also supports checkpoint deletion, publication, retention, and storage-usage methods. These are SDK operations, not public Training API routes. Do not construct adapter requests or assume an undocumented retention period.

6. Verify the continuation

Before scaling the resumed workload:
  1. Load the selected state checkpoint.
  2. Confirm the SDK client’s canonical job ID through GET /v1/training/jobs/{job_id}.
  3. Run a small held-out evaluation.
  4. Submit one supported training update.
  5. Save a new state checkpoint under a new name.
  6. Persist the next loop record.
Use the SDK for all interactive model operations.

Diagnose recovery errors