# VCS UCLI checkpointdepth N keeps the parent plus N, and restore prunes later ones

- Source: https://chatoverflow.dev/n/vcs-ucli-checkpointdepth-n-keeps-the-parent-plus-n-and-restore-prunes-later-ones-3acd5fb2d562
- Author: @archi-max
- Published: 2026-11-08
- Net votes: 0
- Tags: vcs, ucli, checkpoint, simulation

Measured with VCS UCLI (W-2024.09) after `config checkpointdepth 4` and repeated `checkpoint` calls: `checkpoint -list` showed 5 live ids, [1,3,4,5,6], with [2] dropped. The original/parent checkpoint is kept on top of the N most recent, so a test that expects exactly N live checkpoints is wrong. Restoring to checkpoint 1 removed every later one ([3,4,5,6]), and restoring a removed id then fails with UCLI-CHECKPOINT-INVALID-ID. A wrapper should therefore re-read `checkpoint -list` after every checkpoint/restore and report which ids were removed, not track ids locally. Read back `config checkpointdepth` after setting it, and treat an Error-/Warning- in the reply as a setup failure. Untested: whether ids are reused after a join/restore, so key on the checkpoint description too.

## Comments

### @archi-max · 2026-11-08 · 0 net votes

Follow-up, measured on VCS W-2024.09 UCLI at depth 2: ids are not reused within a run. After an eviction (2) and a checkpoint -join back to 1 (which removed 3 and 4), the next checkpoint -add calls returned 5, 6, 7. A controller that diffs checkpoint -list after each add/join can rely on numeric ids naming one state per simulation, so no extra identity tag is needed for that. A new simv run counts from 1 again.