Problem — a policy question, not a bug report
com.brainlayer.hotlane-brainbar runs with:
--interval 1.0 --recent-limit 5 --backlog-interval 10.0 --backlog-batch 4
--enrich-interval 10.0 --enrich-limit 4 --enrich-since-hours 87600
87600 hours = 10 years. So the hot lane is also the backlog lane: every 10s it looks for
anything unenriched across all history and runs enrichment on it, and on a 1M-row DB there is
essentially always something unenriched. The daemon therefore never becomes idle by construction.
Measured 2026-08-24: 120% CPU sustained for its whole 29-minute life. sample shows the busy
threads in SGEMM / APL_sgemm (libBLAS), at::native::vectorized_gelu (libtorch_cpu) and
tokenizers rayon workers — i.e. bge embedding inference running continuously, never sleeping.
That is the arithmetic consequence of those two flags, not a defect in the loop body.
Why PR #735 does not close this
#735 adds idle backoff (idle cycles back off geometrically to a 30s cap; any real work snaps the
cadence back to interval). That fixes a genuinely-idle hotlane re-scanning a 14.8 GB DB once per
second. It cannot help here, because with a 10-year lookback the lane is never idle — it always
finds work, so it always resets to the 1.0s cadence.
The actual decision needed
Should the hot lane do historical backlog enrichment at all, or should that belong to the dedicated
backlog/enrichment path with the hot lane bounded to genuinely recent writes?
This changes enrichment coverage, so it is Etan's call, not a unilateral code change. Flagging
rather than "fixing" for that reason.
Options, roughly in increasing intrusiveness:
- Leave as-is and accept a permanently-busy core.
- Reduce
--enrich-since-hours on the hot lane and let the backlog lane own history.
- Keep the 10-year sweep but move it off the 1.0s tick onto its own much slower schedule.
Acceptance criteria
- A ruling on which lane owns historical enrichment.
- Whatever is chosen, the hot lane's steady-state CPU when there are no recent writes is bounded and
measured with ps, not asserted.
Related: #735 (idle backoff), #737 (deploy drift).
— brainlayerClaude (lead) · claude-code/claude-opus-5
Problem — a policy question, not a bug report
com.brainlayer.hotlane-brainbarruns with:87600 hours = 10 years. So the hot lane is also the backlog lane: every 10s it looks for
anything unenriched across all history and runs enrichment on it, and on a 1M-row DB there is
essentially always something unenriched. The daemon therefore never becomes idle by construction.
Measured 2026-08-24: 120% CPU sustained for its whole 29-minute life.
sampleshows the busythreads in
SGEMM/APL_sgemm(libBLAS),at::native::vectorized_gelu(libtorch_cpu) andtokenizersrayon workers — i.e. bge embedding inference running continuously, never sleeping.That is the arithmetic consequence of those two flags, not a defect in the loop body.
Why PR #735 does not close this
#735 adds idle backoff (idle cycles back off geometrically to a 30s cap; any real work snaps the
cadence back to
interval). That fixes a genuinely-idle hotlane re-scanning a 14.8 GB DB once persecond. It cannot help here, because with a 10-year lookback the lane is never idle — it always
finds work, so it always resets to the 1.0s cadence.
The actual decision needed
Should the hot lane do historical backlog enrichment at all, or should that belong to the dedicated
backlog/enrichment path with the hot lane bounded to genuinely recent writes?
This changes enrichment coverage, so it is Etan's call, not a unilateral code change. Flagging
rather than "fixing" for that reason.
Options, roughly in increasing intrusiveness:
--enrich-since-hourson the hot lane and let the backlog lane own history.Acceptance criteria
measured with
ps, not asserted.Related: #735 (idle backoff), #737 (deploy drift).
— brainlayerClaude (lead) · claude-code/claude-opus-5