# Medium Support Analysis Reasoning - Optimization ID: `medium-support-analysis-reasoning-2026-08-10` - Owner: auto-oncall-services support-analysis runner - Source reference: `APID-29265` and `APID-29232` staging acquisition traces - Implementation status: tested on staging and reverted to high - Effective status: `ineffective` ## Bounded problem The two recent high-reasoning Wetech acquisition turns completed in 174 and 196 seconds. Provider execution accounted for 62 and 72 seconds, while the agent spent about 80 to 90 seconds planning after a 13 to 19 second skill/reference-loading phase. Their turn-level usage reported approximately 223k and 201k input tokens, including 186k and 145k cached input tokens. Those numbers are cumulative across the internal model/tool cycles that make up one Codex turn; they are not a single 200k-token Jira prompt. Each cycle carries the existing system and prompt prefix, loaded skill/reference material, prior tool results, and the growing conversation. Repeated cached prefixes therefore still add to the reported turn input total. This record owns only the shared support-analysis reasoning effort. It does not change the model, prompts, skill contents, query selection, provider batch capacity, four-round quota, timeouts, Focus lifecycle, or Jira publication. ## Candidate change - Change `supportAnalysisReasoningEffort` from `high` to `medium`. - Keep every other diagnostic contract and runtime budget unchanged. - Replay `APID-29265` and `APID-29232` in read-only mode and compare with their existing high-reasoning baselines. - Reject the change if material evidence coverage or diagnosis quality falls, even when latency or token usage improves. ## Verification evidence [aisupport PR 713](https://github.com/tidbcloud/aisupport/pull/713) changed only the shared reasoning effort and passed all 703 TypeScript tests. Deployment [run 31362413292](https://github.com/tidbcloud/aisupport/actions/runs/31362413292) and [app-delivery PR 76648](https://github.com/tidbcloud/app-delivery/pull/76648) deployed image `af7de2e3b53ae231f3de83de0098b01e73792d2b` to staging. The live Pod reported `medium`, Ready, and zero restarts before both read-only replays. `APID-29265` run `9628d800-8c23-445d-907d-40cd31b08f5c` retained verified Wetech evidence and a bounded diagnosis in one round. Its acquisition turn fell from 173,754 ms to 137,516 ms, cumulative input from 223,281 to 174,696 tokens, and reasoning output from 2,750 to 1,308 tokens. The batch used ten queries, with seven complete and three empty results, in 50,643 ms. This case shows a useful per-turn reduction without an observed diagnosis regression. `APID-29232` run `002fdf0e-f6f6-4a9a-8b78-c48e5a956ae0` did not preserve that gain. The high-reasoning baseline completed in one acquisition round with ten queries and returned HTTP 200 in 403.8 seconds. Medium selected only seven queries in round one, then opened a five-query refinement round. The complete request took 561 seconds, about 39 percent slower. Scenario time increased from roughly 227 seconds for the high acquisition plus parent judgment to 379 seconds across the two medium rounds. The final draft also lost the prior bounded numeric explanation of CPU/request skew versus Region/Leader balance and reduced the response to a metric-semantics validation request. Both medium requests used `mode=read`. Jira, database, evaluation persistence, Feishu, and customer-visible writes were not requested. The mixed result and clear second-case latency and answer-quality regression make the shared medium action `ineffective`; the runtime is therefore restored to high rather than promoted as an optimization. [aisupport PR 715](https://github.com/tidbcloud/aisupport/pull/715) restored high reasoning and passed all 703 tests. Deployment [run 31364226476](https://github.com/tidbcloud/aisupport/actions/runs/31364226476) and [app-delivery PR 76661](https://github.com/tidbcloud/app-delivery/pull/76661) deployed current-main image `d1cd64bb99a5a36b9224fbda2f14e552fc418f67`. The live Pod reports `high`, Ready, zero restarts, and HTTP 200 from `/readyz`; polling is healthy, the worker is idle, and the Bot watchdog reports no timed out assignments. The traces also explain the large input totals. They are cumulative across all internal model/tool cycles in one turn, not one initial Jira prompt. Each later cycle carries the prior context and command outputs again. For example, the first medium replay's auth/bootstrap turn accumulated 283,545 input tokens after producing 162,789 bytes of command output; one broad recursive `rg` alone returned 101,525 bytes. Acquisition turns repeatedly loaded about 19 KB of skill text and included 29–46 KB provider batch output. Cached repeated prefixes are counted again in the turn totals. ## Unresolved gaps - A shared reasoning reduction is too coarse: it can shorten one acquisition while weakening another case's first-round query plan enough to add a full refinement round. - Auth/bootstrap performs avoidably broad discovery and can admit very large command output. That is a separate bounded optimization and is not fixed by changing reasoning effort. - Acquisition repeatedly reads the same skill/reference text and prints a sizable batch result into the agent context. Reducing those inputs requires a separate context/transport change with its own quality validation. - The read-only experiment did not change existing Jira internal comments. ## Next validation action Keep shared support-analysis reasoning at high. If input and latency are optimized further, separately bound auth/bootstrap discovery output and avoid reloading unchanged skill/reference material, while retaining the current first-round evidence coverage. Do not retry the same shared medium action without a materially different stage-specific design and multi-case gate.