[Feature]: Keep a JEV combo on one target per session so provider prompt caches stay warm #7525

What are you trying to accomplish?

Keep provider-side prompt caching effective when a strategy: jev combo (jev-auto) is used for long agent sessions. Today JEV re-decides the target on almost every request, so consecutive turns of one conversation land on different providers and each switch starts with a cold prompt cache.

What prevents this today?

• JEV has no notion of session affinity. The only pinning knob, stickyLimit, is accepted only for strategy: round-robin (src/cli/combo.ts: --sticky applies only to round-robin).
• Related but broader: [Feature]: Demand-level routing for JEV combos — orchestrator-chosen levels, per-session pinning, probability escalation (opt-in series on #6364) #6665 (demand-level routing, per-session pinning). This issue is the narrow cache-stability case and can be satisfied by a plain per-session pin.

Observed on a single-operator hub, last 24 h, jev-auto usage ledger (aggregated, no request bodies):

Six different targets appear within a single day. In the OPENCODEX_CACHE_DEBUG=1 fingerprints (171 records, 36 min), the first divergent block is instructions[0] in 117 of 171 records, so consecutive requests from the same client often diverge at the very start of the prefix. Part of that is a separate problem (see "Related observation" below), part is switching targets.

What should OpenCodex do?

• Add a JEV combo option, for example stickyTurns / sessionPin (default off), that keeps the last successful target for a session key (caller prompt_cache_key, or the existing session derivation) for N turns or T minutes.
• Break the pin only on: upstream error or 429 that exhausts retries, the target being removed or disabled, or the request exceeding that target's context window.
• Expose the pin decision in the decision/usage record (jevDecision.pinned: true, pinReason) so the ledger shows it.
• Default behaviour must stay exactly as today.

Example usage or interface

Proposed interface (does not exist today):

ocx combo set jev-auto --strategy jev --session-pin 20m --json

{ "id": "jev-auto", "strategy": "jev", "sessionPin": { "ttlMs": 1200000 } }

Alternatives or workarounds

• Shrink the JEV target list to providers with high cache reuse. Works, but loses the cross-provider escalation JEV exists for.
• Split combos per client so each combo's instructions prefix stays stable. Helps the instructions[0] divergence, does not fix target churn.

Related observation (separate, for triage)

Direct test through the hub, openai/gpt-6.1-sol, identical ~13.5k-token instructions repeated 3–4 times at 2 s and 20 s spacing, store: false:

• with prompt_cache_key forwarded (verified inbound == outbound in the cache-debug record): cached_tokens = 0 on every request;
• without the key: cached_tokens = 0 on every request;
• all requests were served by the same pooled account.

So the forwarded key did not produce a hit in this run. It is unclear whether this is expected for pooled ChatGPT-backed accounts, or whether caching only engages for some accounts. Production shows partial OpenAI cache reads (18–33%), which suggests account-dependence. Happy to provide the exact request body and fingerprints on request; no keys included.

Related: #6665, #4546, #6520, #6627, #6481.