--- title: Give data-view generation an opencode-go overflow pool when the local engine saturates type: task status: cancelled description: >- League data-view generation is identity-gated to deepseek-v4-flash and cannot take the fleet capacity divert, so a saturated vllm-deepseek-v4-flash just makes generation slow. Give it a dedicated opencode-go overflow target, chosen by running the benchmark corpus rather than by spec sheet. base_uri: user:task/league/data-views/add-generation-overflow-inference-pool.md created_at: '2026-09-11T14:32:43.178Z' entity_id: fe6a15c1-3049-4f3c-8949-cebaf04c603a finished_at: '2026-09-11T14:39:34.397Z' observations: - ████████████████████████████████████████████████ - ████████████████████████████████████████████████ owner_identity_uri: █████████████████████████ priority: Medium public_read: true relations: - relates [[██████████████████████-████████-██-████-███-████-████-█████████████]] tags: - user:tag/league-xo-football.md updated_at: '2026-09-11T14:48:38.170Z' visibility_analyzed_at: '2026-11-05T23:48:42.733Z' --- League data-view generation is identity-gated to `deepseek-v4-flash` and cannot take the existing capacity divert, so when `vllm-deepseek-v4-flash` saturates, generation simply runs slow. Give it a dedicated overflow pool on opencode-go subscriptions instead. ## Why the existing divert cannot help `resolve_saturation_divert` (`repository/active/base/server/routes/threads.mjs:448`, applied at `:1770`) moves a saturated `deepseek-v4-flash` dispatch to a single hardcoded `SATURATION_DIVERT_MODEL`. It sits UNDER the session-option policy and must never turn a permitted request into a 403, so when the caller's identity does not permit that target it can only log and proceed — the message is at `:1796`. That is exactly this caller. `███████████████████████████████████████` permits `deepseek-v4-flash` and `deepseek-v4-flash-xhigh` and nothing else, so the divert has never once fired for generation. Verified 2026-09-11 by reading both the identity entity and the decline branch. ## Why this matters more than any prompt lever Engine concurrency is the largest single factor in generation latency and the agent cannot touch it. Decode on `vllm-deepseek-v4-flash` falls from 209 tok/s at one in-flight request to 30 at twelve. At job level with output volume flat: 38.4s at concurrency 1 (4,255 output tokens) against 196.0s at concurrency 8 (4,379). Under-30s runs sit at median concurrency 1.0, over-120s runs at 5.0. Full measurement context is in [[user:task/league/reduce-data-view-generation-latency.md]], which owns the prompt and tool levers and explicitly does NOT own this one. ## The complication that decides the shape opencode-go does not serve any deepseek model. `config/inference.json` has it serving `gpt-5.6-luna`, `grok-4.5`, `glm-5.3-flash`, `glm-5.3`, `glm-5.2`, `kimi-k3` and `hy3`. So this is not a matter of pinning the same model to a second backend — the overflow target is a DIFFERENT model, and picking it is a correctness question before it is a capacity one. ## Plan ### Choose the overflow model by measurement, not by spec sheet Run the generation benchmark corpus against the candidate opencode-go models and rank on correctness first, latency second. An overflow pool that is fast and wrong is worse than a slow one, because saturation is exactly when nobody is watching. Read the "Measurement hazards, all paid for" section of the latency task before running anything — particularly that the generation profile has `max_concurrent_threads: 1`, that ████████████'s league SHA must be recorded at sweep start, and that a single-sitting A/B measures arm order rather than the lever. Verify: a named model with a correctness figure from the corpus, against `deepseek-v4-flash` on the same instructions in both arm orders. ### Make the divert target configurable rather than constant `SATURATION_DIVERT_MODEL` is one hardcoded constant for the whole fleet. A per-caller or per-identity overflow target is what lets generation have a pool that differs from everyone else's. Keep the property that makes the current gate safe: it sits under the session-option policy and never converts a permitted request into a refusal. A configurable target must still decline rather than 403. Verify: a negative control where the configured target is NOT permitted for the caller still logs and dispatches as asked, paired against the permitted case so the two readings differ. ### Permit the chosen model on the generation identity Add it to `session_options.models.allowed` on `███████████████████████████████████████` via `base entity update`, leaving `default` as `deepseek-v4-flash` so the normal path is unchanged and only the divert reaches the new pool. Verify: a dispatch under that identity with the engine saturated lands on the overflow model; with the engine open it lands on `deepseek-v4-flash`. Two readings that differ. ### Confirm the pool actually absorbs load `base inference capacity deepseek-v4-flash` reads current occupancy and `base inference saturation deepseek-v4-flash --hours 12` reads it back at minute grain, which is where bursts are visible — hourly and daily percentiles dilute them past recognition. Run the latter on the host owning the engine. Verify: measured saturation events that previously produced a slow generation now produce a diverted one. ## Assumptions - opencode-go subscription capacity is available to spend on this; if a usage window refuses, the dispatch parks rather than failing, which is acceptable for an overflow path. - Deploys and any base-api restart stay human-gated.