Skip to main content

Project Memory

How Daintree manages the memory behind open projects: warm and cold views, the skeleton and hover prefetch, eviction versus freeze, freeing memory, auto-closing idle projects, and what happens across system sleep and wake.

Reviewed

Project-level session state

Switching projects saves the outgoing project's state (terminal layout, active worktree, panel sizes) and swaps in the incoming one. What that swap feels like depends entirely on whether the target project's renderer is still warm.

Warm and cold

Daintree keeps a small number of recently used project views alive in memory. The number scales with your machine's RAM, because a warm view is only worth holding if there is room for it:

System memoryCached views
64 GB or more5
32 GB or more4
16 GB or more3
Below 16 GB2

The cap counts the active view, so a cap of 4 means three warm background projects. It can be set explicitly, within a floor of 1 and a ceiling of 5.

  • A warm switch re-attaches a view that is already built. It reveals in roughly 60 milliseconds.
  • A cold switch rebuilds the renderer: 100 to 500 MB of process, and a React boot measured in seconds rather than milliseconds.

The skeleton

A cold switch used to mean staring at the old project for the whole boot. Now the outgoing view detaches as soon as the incoming one paints a themed skeleton, which happens within a few hundred milliseconds, well before React mounts. You get a branded, correctly themed placeholder almost immediately instead of the previous project sitting there for a second or more. The skeleton is opaque over the view's own themed background, so there is still no blank frame anywhere in the transition.

Switches are serialized: clicking through several projects quickly queues them in order rather than racing. A cold start that stalls doesn't hang the UI: the paint gate has a soft and a hard budget, both scaled by the active resource profile, and falls through to the new view rather than waiting indefinitely.

Hover prefetch

While the project switcher is open, hovering a row primes that project before you click. Daintree waits 150 ms after the pointer settles, then reads that project's saved state from disk (app state, terminal snapshots, panel layout, active worktree, focus mode, terminal config, agent settings), so it's in memory by the time you select it.

Prefetch is mouse-only; touch and pen pointers are ignored, as are the active project and any project flagged missing. The primed state is cached for 30 seconds and consumed once, on the click that follows; the renderer's own freshness gate skips a re-read within 15 seconds of a successful prime.

Note
Hover prefetch is best-effort. If you click faster than the 150 ms delay, or the cache has expired, the switch reads from disk on click instead: same result, not as fast. Prefetch errors are swallowed and never block a switch.

Eviction and freeze

When a project's view leaves the warm cache, it goes one of two ways:

  • Eviction destroys the Chromium renderer, freeing roughly 100 to 500 MB. Returning to that project pays a cold rebuild.
  • Freeze keeps the view in memory but suspends it: timers and the event loop paused through the page lifecycle API. It still costs RAM, and it comes back instantly.

Which one happens depends on why Daintree is under pressure. Only memory pressure that actually contributed to the resource profile destroys views; when the efficiency profile engages for other reasons (battery, thermal, sustained CPU), views are frozen instead, so they return the moment the pressure lifts. Freeze entry is debounced on the trailing edge, so a quick glance at another project doesn't freeze the one you just left; freeze exit is immediate.

Eviction under memory pressure steps down rather than falling off a cliff. Above the warning threshold your configured cap stands; below the critical threshold the cache collapses to the active view alone; between them the cap drops by one view per equal slice of the band, so warm switching degrades gradually instead of vanishing in a single pass. Within a pass, eviction is least-recently-used, with one protection: idle views go before views with an active agent.

Note
Freeze and eviction act on a project's view: the UI layer. They are automatic and silent, and the terminals, PTYs and agents behind the view keep running either way. Reclaiming the processes themselves is what Free memory and auto-close do, and both are things you opt into.

Free memory

Free memory, in a background project's context menu in the project switcher, reclaims that project's resident memory without losing your place in it. It tears down all three reclaimable tiers: a graceful, session-preserving kill of the project's PTYs, the cached renderer, and the workspace host process. Session ids are written back into the saved panel snapshots and journaled, hibernation markers are written so scrollback replays with an explanatory banner, and the layout is left alone.

The project stays in the switcher, its row reading Suspended to free memory, and reopening it restores the panels rather than starting cold. The action is only offered for a project that is not on screen in any window and still holds resources: the active project owns a live renderer, and an already-reclaimed one has nothing to free.

Auto-close idle projects

The same reclaim can run on a timer. Settings > General > Auto-close idle projects closes background projects that have been idle past a threshold, and it is the thing that actually reclaims memory over a long session.

  • Off by default. It changes project lifecycle, so it is opt-in.
  • Threshold: 15 minutes (default), 30 minutes, 1 hour, or 2 hours.
  • Swept every 5 minutes, with a quiet period after startup and after waking from sleep so it doesn't fire into a machine that is still settling.
  • Gated on zero terminals. Any live terminal at all means the project is skipped: the sweep never destroys agent scrollback silently.
  • Never the foreground project, in any window. The check reads every window's active project, not just the last-focused one.

Closed projects stay in the switcher and reopen where you left them.

System sleep and wake

Daintree hooks into your OS power management. While agents are actively working, it prevents the system from sleeping. When the system sleeps anyway (you close the lid), Daintree pauses PTYs, pauses workspace polling, and pauses its own main-process watchdog. That last one matters: without it, a long sleep would bank enough missed heartbeats for the watchdog to conclude the main process was hung and kill it on wake.

On wake, Daintree waits two seconds before doing anything, then re-arms the watchdog first, resumes PTYs, and refreshes worktree state to pick up anything that changed outside the app. Workspace polling only resumes if a window is focused: a machine that wakes overnight while you're away stays quiet until you come back to it. A forge token health probe is forced immediately, so a credential that expired during a long sleep is caught then rather than at the next scheduled probe.