A 12-line task for Sleep-Time Research (Sleep-Time Compute): two cycles, and a solver that beat our own accelerated baseline by 26x, after the system broke its own headline result twice and caught both breaks itself.
Dogukan Tuna · · 7 min read
Sleep-Time Research (Sleep-Time Compute) is a mode I shipped this week into Epos, Ultraresearch's first mode, built entirely for long-horizon autonomous work and research and for orchestrating multi-agent workflows. A run can now keep going past its own turn instead of stopping cold, banking a cycle and re-seeding itself on the same task. I wanted to see what it actually does with three hours and a real problem before I trusted it with a bigger one, so I gave it something narrow and checkable: make CP (CANDECOMP/PARAFAC) tensor decomposition converge faster than our own best baseline. Nothing about method, nothing about approach. Twelve lines.
Three hours, two cycles, and twenty-one workers later (all Opus 5 on medium reasoning), I had a single-file numpy solver that beats that baseline by 26x, verified and replicated from scratch. That number is not what this post is about. The system broke its own headline result twice, found both breaks with its own auditors, and told me exactly where each one was wrong.
The prompt, in short: speed up CP (CANDECOMP/PARAFAC) convergence against textbook CP-ALS. Measure wall-clock seconds to a relative error of 1e-6, or the final error if it never gets there, against plain ALS on identical data and the same stopping rule. Include one ill-conditioned case with collinear factors. Try genuinely different accelerations, one per cycle, and say which ideas died.
Three choices sit behind those lines. An exact oracle: synthetic tensors with known factors, so "faster" is measurable rather than argued about. Separable hypotheses: momentum, line search, second-order, preconditioning are independent enough that culling one doesn't hide the others. A mandatory ill-conditioned case: collinear factors, because every method looks fine on an easy problem and the real discrimination happens in the swamp. I didn't specify a method anywhere. Just the measurement and the adversary.
The plan was never a contract. In both cycles, an audit phase found something real and the system opened a phase that wasn't scheduled to deal with it, and named the phase honestly: not "verify the result," but "fix the break" and "apply the audit fixes."
The first move, before any accelerator got written, was freezing the bench: a data generator, a plain CP-ALS reference, a shared initialization, and a test for the measuring instrument itself. 81/81 rows bit-identical across two sweeps, including bit-for-bit agreement between the accelerated and plain code with acceleration switched off. Every worker after that inherited a frozen, validated benchmark. Nobody rebuilt it, nobody invented their own measure.
Trap 1. In cycle 1's audit phase, a worker wrote down an identity that I hadn't asked for:
The error in the compressed core differs from the error in the full tensor by a constant. The solver had been handed the compressed core while its stopping rule still compared against the full tensor's norm. Used naively, that stopping rule quits early and reports a number that isn't true. The fix: every stop is now confirmed by an exact residual on the original tensor. Without it, exact-rank recovery fails outright. With it, the same test passes at 8.2e-11.
Trap 2, the bigger one. The run's highest-scored worker, at 90, found that the "sweep-equivalent" currency used to compare methods charged nothing for the linear-solve cost inside second-order methods, undercounting them by up to 2.6x and making a slower method look faster. Cycle 1's headline had been that only a second-order ladder cracks the hardest collinear case. That headline was an artifact of the unit of measurement. Cycle 2's correction inverted it outright: a well-tuned first-order method gets there too, on wall-clock seconds. The 300-iteration cap, not the method class, was what made the collinear cases look unsolvable. That's the single biggest correction the investigation made to itself.
The winner, cp_accel, is one file, numpy only, and every piece's contribution was measured in isolation rather than assumed. A single warm full-space sweep followed by CANDELINC/HOSVD compression to an R×R×R core makes each subsequent sweep about 24x cheaper: for an exact-rank tensor the projection loses nothing, since the true factors already live in the mode subspaces. On top of that: an eigendecomposition basis instead of an SVD (2.61x, iteration counts identical either way), an extrapolation scheme that decides whether to grow or reset its step from the ALS residual it's already computing rather than paying for a second evaluation at the extrapolated point (2.65x, and it needs fewer sweeps besides), and two rounds of cutting numpy call overhead in the inner loop: 28 calls per sweep down to 5 (1.88x, then 1.45x).
Multiply the four measured pieces and the total against full-space HER (our own accelerated reference, not the weak textbook baseline) comes out to 26x, on the problems where both converge.
Mostly no, and it's worth being exact about which part. Extrapolation acceleration for ALS is decades old: Bro's line search, Rajih, Comon and Harshman's Enhanced Line Search from 2008, and the field is still active. What I couldn't find anywhere, after checking, is the specific trick used here: skipping the evaluation at the extrapolated point entirely and inferring accept-or-reset from the residual you're computing anyway. The classical method pays for that evaluation. This one doesn't, and I don't have a citation for the shortcut, which means the honest label is a small, real implementation choice I couldn't find published anywhere, not a new algorithm. Incremental, not novel.
The compression is lossless only under the exact-rank assumption; with noise, cp_accel sits exactly at the noise floor while textbook ALS stalls well above it: correct behavior, not a stronger claim than the data supports. The eigendecomposition basis squares the conditioning of whatever it's given, and stays safe against the 1e-6 tolerance only up to roughly 1 − c ≈ 1e-5, extrapolated from four measured points and labeled as such. Past a collinearity of 0.999, convergence rate becomes the bottleneck, not the basis. Nothing solves that case here. And a narrow class of non-uniform collinear instances is a flat lottery: the good basin gets found four to six times in fifteen draws regardless of method, and cheap probes are anti-predictive at picking it. Untested beyond this: four-way tensors, real noisy data, missing entries, constraints.
CANDELINC/HOSVD compression, HER-style extrapolation, Gauss-Newton solvers: none of it is new science, and this post hasn't tried to claim otherwise. What's actually being tested here is Sleep-Time Research: given three hours and a checkable task, does the process stay honest with itself when nobody's watching a given cycle. Twice, an audit phase it opened on its own found a real bug in its own headline claim and reported the correction louder than the original result. That's the part worth keeping from Building Log #1.