Explanation
Why a session is a child process
A session starts its subprocess only when a message needs answering, and stops it once nothing does.
Turret does not keep a session's engine running for as long as the session exists. It starts a subprocess — the running copy of the engine — when a message needs answering, and stops that subprocess again once nothing does.
A live engine costs real memory: enough that keeping every session's subprocess running at once would use it up fast. Starting a stopped subprocess back up costs a short delay. Turret spends that delay on the sessions that need it, rather than holding memory behind sessions nobody is using right now.
What starts a subprocess
Opening a session, or moving between sessions in the sidebar, starts nothing. Turret reads a session's transcript straight off disk, which costs no subprocess and stays fast no matter how many sessions are open. Sending a message is the only thing that starts a subprocess. A session with no subprocess spawns a fresh subprocess to answer it; a session already holding a live subprocess answers straight away.
That is why a session already open answers at once, and a session picked up after a pause takes a moment before it does.
Why an idle session gives up its subprocess
A session that has finished a turn, with nothing waiting for it, is idle. Turret leaves an idle session's subprocess running for a short wait, then stops it, and the session goes back to having none.
That wait is long enough to cover the pause between reading a reply and writing the next message. It is short enough that memory does not build up behind sessions sitting untouched.
What closing the window does not change
A reader might expect closing a session's window to end that session. It does not. The subprocess belongs to Turret itself, and quitting Turret is what actually stops it, alongside the idle timeout above.
A session's subprocess lives with Turret, and a window only subscribes to it once it opens. Rebuilding or reloading the window costs the window itself, and touches no session's subprocess. A turn already running keeps running through a reload, and the window picks its stream back up once it returns.
See What a session leaves on disk for the files a session writes while its subprocess runs, and what is still there once it stops.