Context
Live external-plane evidence, 2026-08-13: on a CPU-only deployment the REM/dream pipeline ran back-to-back heavy cycles (tri-vector → topology → next cycle) for 5+ hours of sustained ~400% CPU on the chat lane — over a Memory Core holding 22 memories and 9 summaries. The work was legitimate and progressing (measured: one tri-vector stage = 849s), but the operational picture was indistinguishable, on any monitor, from the frozen-cores incident the deployment had just been fixed for. The client read it as "4 cores frozen again."
On GPU planes a full REM cycle is minutes and invisible. On CPU planes the same cadence produces hours of pinned cores — the GPU-calibration blind spot (cf. the timeout family) applied to scheduling.
The Problem
REM cycles have no per-cycle budget and no inter-cycle gap: while due, the pipeline runs stage after stage continuously, holding the heavy-maintenance lease throughout (see #16561 for the lease-fairness half — this ticket owns the workload shaping half). A maintenance process that saturates its lane for hours (a) starves every lease waiter for the whole span, (b) is visually indistinguishable from a wedge, and (c) delivers marginal value at that intensity on a plane whose corpus is 22 memories.
The Fix (shape)
- A per-cycle budget on cloud/container profiles: N stages or T minutes per lease hold, then release + re-queue — waiters (e.g., bootstrap tenant ingestion) interleave.
- An inter-cycle breathing gap (config leaf, CPU-plane profile default) so cores visibly return to idle between cycles — monitors and humans can distinguish "working in pulses" from "wedged."
- Cadence proportional to corpus size: a 22-memory graph does not need continuous consolidation; REM intensity should scale with undigested backlog.
Acceptance Criteria
Related
#16561 (lease fairness — the other half) · #17042 (retrospective family) · the 2026-08-13 external-plane receipts
Origin Session ID: 37509548-6568-47fe-9e6c-2aabd27c2b11
Context
Live external-plane evidence, 2026-08-13: on a CPU-only deployment the REM/dream pipeline ran back-to-back heavy cycles (tri-vector → topology → next cycle) for 5+ hours of sustained ~400% CPU on the chat lane — over a Memory Core holding 22 memories and 9 summaries. The work was legitimate and progressing (measured: one tri-vector stage = 849s), but the operational picture was indistinguishable, on any monitor, from the frozen-cores incident the deployment had just been fixed for. The client read it as "4 cores frozen again."
On GPU planes a full REM cycle is minutes and invisible. On CPU planes the same cadence produces hours of pinned cores — the GPU-calibration blind spot (cf. the timeout family) applied to scheduling.
The Problem
REM cycles have no per-cycle budget and no inter-cycle gap: while due, the pipeline runs stage after stage continuously, holding the heavy-maintenance lease throughout (see #16561 for the lease-fairness half — this ticket owns the workload shaping half). A maintenance process that saturates its lane for hours (a) starves every lease waiter for the whole span, (b) is visually indistinguishable from a wedge, and (c) delivers marginal value at that intensity on a plane whose corpus is 22 memories.
The Fix (shape)
Acceptance Criteria
Related
#16561 (lease fairness — the other half) · #17042 (retrospective family) · the 2026-08-13 external-plane receipts
Origin Session ID: 37509548-6568-47fe-9e6c-2aabd27c2b11