Files

T

serversdown 1301f12e74 feat: run dream cycle as a systemd user service + journald-visible logs

- deploy/lyra-dream.service: --loop 1800 user service on lyra-cortex, so Lyra's
  consolidation + reflection keeps ticking unattended between conversations
- deploy/README.md: install / linger / operate runbook
- logbus: mirror events to stderr so out-of-band runs (the dream service under
  journald) are observable, not just via the in-process web SSE feed

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-17 01:42:55 +00:00

1.3 KiB

Raw Blame History

Deploy

Dream cycle (`lyra-dream.service`)

Lyra's unattended inner loop. Runs lyra-dream --loop 1800 so she consolidates memory and reflects every 30 min between conversations. Installed as a systemd user service on lyra-cortex (10.0.0.41), running as serversdown — no root needed to manage it.

Install / update

cp deploy/lyra-dream.service ~/.config/systemd/user/lyra-dream.service
systemctl --user daemon-reload
systemctl --user enable --now lyra-dream.service

Persist across reboot / logout (one-time, needs sudo)

A user service stops when the user logs out and doesn't start at boot until login — unless lingering is enabled:

sudo loginctl enable-linger serversdown

Operate

systemctl --user status lyra-dream.service      # is she ticking?
journalctl --user -u lyra-dream.service -f       # watch her think (logbus -> stderr)
systemctl --user restart lyra-dream.service      # after a code change
systemctl --user stop lyra-dream.service         # quiet her down

Tunables live in lyra/dream.py (drive thresholds, curiosity gains) and the --loop interval in the unit's ExecStart. The consolidation backend follows SUMMARY_BACKEND in .env (cloud gpt-4o-mini for bulk; the MI50 is too slow for the summarization backfill).

1.3 KiB Raw Blame History