Watch
0
0
Fork
You've already forked hyperhive
0
hyperhive/docs/agent-lifecycle
Repository files (latest commit first)
Filename Latest commit message Latest commit date
atlas 0d619e215e agents: read the memory cap at boot, not from the build
An agent's memory cap was rendered into its flake (`memoryMaxBytes` →
`services.hyperhive.agent.claudeMemoryMaxBytes`), so the closure depended
on it and a changed cap reached the JSC heap ceiling and the subagent
`MemoryHigh=` only after a rebuild.

hive-c0re now writes the effective `MemoryMax=` in bytes to the agent's
runtime dir (`/run/hive/memory-max-bytes` inside) in `write_dropins`,
from the same value the drop-in gets. The file is removed for
`infinity` or a RAM percentage, and left alone when the drop-in is kept.

Inside the container, `nix/agent-modules/memory-cap.nix` reads it at
boot: an environment generator sets `BUN_JSC_forceRAMSize` (75%) for
every unit and `machinectl shell`, `/etc/set-environment` exports it in
login shells, and a unit generator writes `MemoryHigh=` (2/3) as a
drop-in for `hive-subagent-daemon`.

The render drops `memoryMaxBytes`, the agent option is removed (both
spellings fail eval with a removal message), and
`effective_memory_bytes_from` goes with its only caller.

Part of #5081 (slice S0-2).
2026-10-12 10:59:11 +02:00
..
agent-roster.md docs: scheduled prompts are swarm-level; the hive page is a read-only list 2026-10-04 21:23:31 +02:00
config-changes.md docs: the agent config meta-flake input is the local applied mirror, not forge git+http 2026-10-10 14:06:43 +02:00
persistence.md agents: read the memory cap at boot, not from the build 2026-10-12 10:59:11 +02:00