generate() only. Rollout and reflection live in the env adapter and the engine respectively. Review Lesson 6's architecture diagram.SkillOpt-Sleep has three opt-in knobs that strengthen the nightly consolidation by drawing on past experience. They're all off by default — the basic cycle works without them. But turning them on is where the gains compound: the Sleep README shows +3–5 percentage points on SearchQA from replay scaling alone.
| Knob | Default | What it does |
|---|---|---|
dream_rollouts |
1 | Run each task K times → learn from good-vs-bad contrast (contrastive reflection) |
recall_k |
0 | Pull the K most-similar past tasks from a persisted archive into tonight's dream |
dream_factor |
0 | Generate N lightweight synthetic variants of each task |
Without replay, each night only sees today's tasks. The optimizer reflects on failures from those tasks alone. With replay enabled:
recall_k) — searches the archive for past tasks similar to tonight's, pulling them into the dream batch. More relevant context → better reflection.dream_rollouts) — runs each task multiple times. Some runs succeed, some fail. The contrast between good and bad trajectories gives the optimizer a clearer signal about what specifically made the difference.dream_factor) — generates variations of each task (different inputs, same shape). Prevents overfitting to specific examples.
SearchQA with dream_rollouts=5 and recall_k=20:
baseline 0.803 → 0.848 (+4.5pp). The gain rises monotonically with
recall depth. Without replay: +1–2pp. With full-history replay: +5.6pp. The
validation gate keeps everything safe regardless.
Edit your ~/.skillopt/config.yaml (or pass as CLI flags):
# Start conservative — recall from recent history, moderate dreaming
skillopt-sleep run \
--dream-rollouts 3 \
--recall-k 10
# More aggressive — deeper recall, more contrast
skillopt-sleep run \
--dream-rollouts 5 \
--recall-k 20
Cost note: Each dream rollout calls your target model once per task.
With dream_rollouts=5 and 10 tasks, that's 50 target-model calls per night.
Budget accordingly — or use a cheaper model for dreaming.
The experience archive persists between nights. After a few cycles with
recall_k > 0, check it:
skillopt-sleep status --show-archive
You should see tasks accumulating over time. The recall mechanism uses embedding similarity — tonight's tasks pull in their most relevant ancestors. This is why more nights = better skills: the archive becomes a richer source of contrastive experience.
Run two cycles and compare the proposals:
# Night 1: baseline (no replay)
skillopt-sleep run
skillopt-sleep status # note the proposal quality + held-out score
# Night 2: with replay
skillopt-sleep run --dream-rollouts 5 --recall-k 10
skillopt-sleep status # compare
Apply the rubric to both proposals. The replay version should produce more specific rules — because the optimizer has more contrastive signal to work with.
Synthetic augmentation (dream_factor) generates tasks that don't exist
in your real usage. Start with dream_factor=0 until you've validated
that your real tasks produce good proposals. Synthetic variants help generalization
but can dilute signal if your scoring function doesn't transfer well to generated tasks.
recall_k=10 but only have 3 nights of history. What happens?dream_factor's job). It just uses whatever history is available. The system gets stronger as the archive grows naturally through daily use.SkillOpt-Sleep RESULTS.md — Microsoft Research. The gate-safety stress test, experience-replay scaling curves, and dream-diversity ablation. ~10 minutes. The SearchQA replay table is the key evidence.