Let Pi extensions pin a session that owns live background work, so long-running supervisors survive the idle release

[kesslerio]

TL;DR

Let a Pi extension tell T3 "this session owns live background work, keep it loaded". Then long-running supervisor agents can run inside T3 without being idle-released every 30 minutes.

Problem

Follow-up to #18090, which was closed as intended behavior.

A Pi provider session is idle-released after 30 minutes unless hasPendingBackgroundWork is true. For Pi that is pendingWake !== null, so it only counts once a wake is already queued. Even then the pin is capped at 4 hours (#17214 documents this).

Some Pi extensions are built around a background process that sleeps and only wakes the session when something needs attention. The case that hit this is an orchestrator whose extension arms a watcher. Between wakes, T3 sees no pending work, so after 30 quiet minutes it releases the session. Pi's session_shutdown stops the extension and the watcher dies, and no wake can ever arrive. In practice the supervisor goes blind every night: one gap ran 7.2 hours, until the user's next message brought the session back.

The current workaround is to run the supervisor outside T3. That works, but you lose T3 as the place to talk to it.

Proposed solution

1. An extension pin API. A Pi extension can set and clear a named pin, for example pin("watcher armed") and unpin(), through the extension API or an RPC event. The Pi driver includes any active pin in hasPendingBackgroundWork, the same way a queued wake counts today.
2. A per-thread residency limit. The 4-hour maxIdlePinMs cap becomes a per-thread (or per provider instance) setting, with "no limit" available for a thread the user explicitly marks as a long-running supervisor. The default stays as it is.
3. Visibility. The thread shows when it is pinned (with the pin's reason) and when it was released for idling. Today a released session looks the same as an idle-but-alive one.

Alternatives considered

• A configurable global idle timeout. Simpler, but it keeps every idle session loaded, not just the ones that need it.
• Keep-alive messages from a scheduled task. These work, but they read as user messages. For an agent that treats any user message as "the user is back", that breaks its away mode.
• Wake on command exit (Wake a thread when a command it started exits, even after its turn ends #16588). Related and useful, but a watcher that sleeps for hours by design never exits, so it doesn't cover this case.

Impact

• Who it affects: long-running supervisor or orchestrator agents hosted in T3 on the Pi provider. Other providers with similar extension mechanisms likely have the same need.
• Severity: it blocks unattended operation. The supervisor silently stops whenever the user is away for more than 30 minutes.
• Frequency: every quiet period over 30 minutes, which is every night.

Evidence

#18090 has the timeline from orchestration_events (each release about 30 minutes after the last turn) and the code references that were confirmed in the reply there.

[yazanabuashour]

I could use something similar. My Pi extension starts a command, lets the agent keep working, then wakes Pi when it exits. T3 has support for that type of wake.

The Pi adapter reports pending work only once the wake starts, not while the command runs. The session eligible for idle release.

Would you prefer a shared way for Pi extensions to report running jobs or extension-specific support like #17393?