Keep the OpenCode server warm after the 30-minute idle release (the next turn waits 2–3 s for it to boot)

[nkoynov]

On a self-hosted T3, the first OpenCode turn after 30 idle minutes waits for a new OpenCode server to boot. Two hard-coded timers cause it, and neither has a setting:

• ProviderSessionManager releases a thread's provider session after DEFAULT_IDLE_TIMEOUT_MS (30 minutes): ProviderSessionManager.ts#L56. The shipped layer is layerWithOptions() with no options (L2479), so idleTimeoutMs is only set in tests.
• When the last session on an OpenCode instance is released, OpenCodeServerOwner closes that instance's server after OPENCODE_SERVER_IDLE_TTL = "30 seconds": OpenCodeServerOwner.ts#L11, used at L141.

So unless some thread on the instance ran in the last 30 minutes, the next prompt starts opencode serve from scratch. Both values are the same on main today (9c16146, nightly 20261018.3315).

What it costs (nightly 3218, OpenCode 2.0.31, Linux):

• Our host, 9.7 h of T3 server trace on a quiet day, 18 turns. The 5 turns that started a new server took 1.9–3.1 s from the run's requested_at to OpenCode's user message. Turns on a running server and an unloaded machine took 0.22–0.47 s. All 5 were the first turn after a pause of over 30 minutes.
• In those 5 the trace shows openSession taking 0.6–0.9 s (its first GET /api/model is slow every time), then the prompt POST another 0.6–1.6 s while OpenCode is still loading plugins and providers.
• 8 GB VM, same thread, server killed before each cold turn: warm handoff p50 0.06 s / p90 0.51 s, cold 2.10 s / 3.36 s. With memory pressure on the VM, cold went to 6.4 s / 11.0 s.

The workaround is to run opencode serve yourself and point the instance's serverUrl at it, but then T3 no longer manages the process (password, environment, cleanup).

Possible shapes, smallest first:

1. A server setting for how long an idle OpenCode server stays up after its last session is released (default 30 s, as now). It only keeps an idle process around. Provider sessions are still released at 30 minutes with the existing pinning, so it can't keep a dead session or reap live work, which was the concern when feat(server): make provider session reaper timing configurable #5525 was closed. It could live with the backgroundActivity overrides, since it trades idle memory for latency.
2. Keep each instance's server up while a client is connected to T3, and close it 30 s after the last client leaves.
3. A setting for the session idle timeout as well. Most of the cost above is the server boot, so 1 or 2 should cover most of it; we haven't measured a session reopen on a warm server.

Happy to send a PR for 1 if that shape works for you.

Model: Claude Opus 5.5 (1M). Harness: OpenCode 2 in T3 Code.