Proposal: Exclusive managed session connection leasing for long-lived clients

[KaspaPulse]

I'd like feedback on an opt-in routing primitive for long-lived managed clients: Exclusive Managed Session Leasing.

The proposed invariant is:

ONE ACTIVE MANAGED CLIENT/SESSION <-> ONE EXCLUSIVE ELIGIBLE OMNIROUTE CONNECTION

The lease is connection-scoped, not model-scoped. It is intended to preserve ownership across idle periods, tool calls, builds, and other gaps between inference requests.

The implementation reuses OmniRoute's existing:

• eligibility and allowedConnections
• quota, health, and cooldown logic
• routing strategy and fairness
• retry/fallback behavior
• session affinity and continuity

It does not introduce a second router, account pool, waiter daemon, duplicate quota/health store, or fixed client-to-connection mapping.

Activation is explicit through the lease:exclusive scope plus a non-empty allowedConnections list.

A Draft PR with the reference implementation is available in #10362.

What I'd like feedback on

1. Does connection-level exclusive lifecycle ownership fit OmniRoute as an opt-in generic routing primitive?
2. Is lease:exclusive + explicit allowedConnections the right boundary for enabling it?
3. Is the lifecycle API approach appropriate for long-lived managed clients?

Intended behavior

While a lease is active:

• one managed session owns one eligible connection exclusively
• the connection remains reserved during idle/tool/build periods
• foreign active leases are excluded before normal routing selection
• normal OmniRoute eligibility, health, quota, cooldown, and routing logic remain authoritative
• if ordinary eligible candidates exist but all are leased, the client receives WAITING_FOR_CAPACITY
• the implementation does not send model requests while waiting for capacity

The lease uses generation fencing so stale owners cannot renew, release, or use a newer lease.

Non-goals

This proposal intentionally does not include:

• client-specific launchers or adapters
• provider-specific behavior
• model-specific leasing
• model-scoped capacity sharing
• a replacement for session affinity
• a second account pool or routing subsystem

The core is intended to remain client-neutral, provider-neutral, and model-neutral.

I'm especially interested in whether this abstraction fits OmniRoute's existing routing architecture before taking the Draft PR further.

[diegosouzapw]

Hey @KaspaPulse! Thanks for the well-structured proposal.

Connection-scoped leasing for long-lived client sessions (ONE ACTIVE MANAGED CLIENT/SESSION <-> ONE EXCLUSIVE ELIGIBLE OMNIROUTE CONNECTION) makes a lot of sense for multi-turn agent sessions where state/context affinity reduces thundering herd and token cache misses.

[diegosouzapw]

Follow-up @KaspaPulse — I have opened issue #10514 to track the Exclusive Managed Session Leasing primitive and added a feature plan in the pipeline.

[diegosouzapw]

Follow-up @KaspaPulse — a status correction, since #10514 now shows as closed and "not planned", which misrepresents where this landed.

Exclusive managed session connection leasing was analyzed and cataloged in the implementation backlog, and the issue was closed to keep the tracker lean rather than because the proposal was rejected. The implementing PR will reference #10514 when it ships. GitHub only offers "completed" or "not planned" as closure reasons, and neither describes "queued in an internal pipeline", which is what actually happened.

Flagging it because a closed-as-not-planned issue is a reasonable thing to read as a no, and that is not the answer your proposal got.

[diegosouzapw]

@KaspaPulse A correction, and the good kind: my last reply said exclusive session leasing was still in the backlog and that "the implementing PR will reference #10514 when it ships". It had already shipped, in #10362 (merged 2026-08-18):

• Lease store + migration: src/lib/db/exclusiveConnectionLeases.ts, 157_exclusive_connection_leases.sql
• API: /api/v1/session-leases (src/app/api/v1/session-leases/route.ts)
• Selection policy and isolation: src/sse/services/exclusiveConnectionLeasePolicy.ts, src/lib/exclusiveLeaseIsolation.ts, wired into account selection in src/sse/services/auth.ts

Sorry for pointing you at the backlog. Closing this as resolved. If the behavior doesn't match your proposed invariant, open a new discussion that links this one.