[Bug] Web Search/Vision Sidecar Backend Fixed to OpenAI·Anthropic - Routing Turns Fail with 499/502 When Limits are Exhausted #398

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   on Jul 24, 2026
2. github-actions

   changed the title [-][Bug] 웹 검색/비전 사이드카 백엔드가 openai·anthropic으로 고정 — 한도 소진 시 타 provider(GLM 등) 라우팅 턴 전체가 499/502로 실패[/-] [+][Bug] Web Search/Vision Sidecar Backend Fixed to OpenAI·Anthropic - Routing Turns Fail with 499/502 When Limits are Exhausted[/+] on Jul 24, 2026
3. github-actions commented on Jul 24, 2026

   

   github-actionsbot

   on Jul 24, 2026 – with GitHub Actions

   Contributor

   More actions

   English translation (original: ko)

   Client or integration

   Codex CLI (opencode-go session, glm-5.2 max routing)

   Area

   Proxy and routing (directly related to Provider adapter area)

   Summary

   The backend of the web search sidecar and vision sidecar is fixed to only two values: openai / anthropic. Therefore, when the main routing model is a provider other than OpenAI·Anthropic (e.g., z.ai GLM-5.2), the turns requiring search/vision must necessarily be executed through the OpenAI (ChatGPT forward) or Anthropic (stored OAuth) sidecar.

   At this time, if the ChatGPT/Claude account limit is exhausted, the sidecar call hangs for about 200 seconds, and the entire turn fails with 499 / 502 (rarely 504). Other provider models cannot be specified as the sidecar backend, and there is no graceful degradation like "proceeding with the turn without the search/vision results only for that turn" when the sidecar backend is unavailable, causing the work to stop completely.

   The observed dashboard log (201,434ms below) is almost identical to the web search sidecar's default timeout DEFAULT_TIMEOUT_MS = 200,000, suggesting that overload/exhaustion of the sidecar backend (ChatGPT forward) is likely a direct cause of the failure. (The exact final attribution needs to be verified whether that turn actually called web search/vision via the sidecar/forward account logs.)

   Reproduction

   1. Set a different provider as the routing model (e.g., z.ai GLM, adapter: "anthropic", defaultModel: "glm-5.2"). Since GLM does not support vision, force the vision sidecar with noVisionModels: ["glm-5.2"].
   2. Sidecar backend defaults to openai → relies on ChatGPT forward account + login.
   3. Exhaust the limits of the ChatGPT (and/or Anthropic OAuth) account to make the sidecar backend unavailable/unhealthy.
   4. Execute an opencode-go turn that triggers web search with glm-5.2 max (or paste an image to trigger the vision sidecar).
   5. Observation: After about 130–201 seconds hanging, it returns 499 (client cancel) or 502 (upstream error). No graceful skip.

   Version

   2.7.35 (same constraints confirmed from main (at) 2.7.39 source)

   Operating system

   Ubuntu 24.04 (WSL2)

   Provider and model

   z.ai / glm-5.2 (routing model). Sidecar backend: OpenAI (ChatGPT forward) by default.

   Logs or error output

   5:31:38 PM  unreported  glm-5.2 max  opencode-go  ocx-mryoljdv-sc  499   130,206 ms
   5:28:17 PM  unreported  glm-5.2 max  opencode-go  ocx-mryoh7rt-sb  502   201,434 ms

   • 201,434 ms ≈ web search sidecar default timeout DEFAULT_TIMEOUT_MS = 200,000 (src/web-search/index.ts).

   Root cause (source evidence)

   • The sidecar backend type is fixed to openai | anthropic only:
     • src/types.ts:413 webSearchSidecar?: { backend?: "openai" | "anthropic"; model?: string }
     • src/types.ts:415 visionSidecar?: { backend?: "openai" | "anthropic"; model?: string }
     • src/types.ts:667(OcxVisionSidecarConfig) / src/types.ts:685(OcxWebSearchSidecarConfig) are the same.
   • The dashboard management API (PUT /api/sidecar-settings) explicitly rejects any backends other than the above values with a 400:
     • src/server/management/config-routes.ts — "webSearch.backend must be openai, anthropic, or null", "vision.backend must be openai, anthropic, or null".
   • The backend composition only includes these two values:
     • src/web-search/index.ts resolveSidecarBackend() → either explicitly "anthropic" or "openai".
     • src/vision/index.ts resolveVisionBackend() → explicit value / availability of anthropic OAuth / else "openai".
     • The OpenAI backend requires ChatGPT forward provider + login, and the anthropic backend requires stored anthropic OAuth. There is no selector to route the sidecar to other providers like GLM. (model field comment: "must be a native ChatGPT model.")
   • Sidecar/routing-model failures propagate as the entire turn’s HTTP status:
     • src/web-search/loop.ts:319/341 → LoopError(499, "client closed request during web-search")
     • src/web-search/loop.ts:343 → LoopError(502, "Provider unreachable: …")
     • src/web-search/loop.ts:378 → RoutedModelInactivityError → LoopError(504, …)
     • src/web-search/loop.ts:379/380/389 → LoopError(502, "Provider stream error…" / terminal error)
   • The background of this limitation: sidecar executor implements the provider-native server-side functionality (OpenAI-hosted web_search, Anthropic web_search_20250305 / vision) directly. The devlog 260630_native-sidecar-parity/00_research.md also records, "The web search sidecar runs the actual hosted web_search from the ChatGPT forward /responses backend."

   Expected behaviour

   1. Graceful degradation: When the sidecar backend is unavailable/exhausted, instead of failing the entire turn, only the tools (search/vision) should fail-close, and the turn should continue to progress with an explicit indication similar to the existing vision stripImagesInPlace marker ("[image omitted: … vision sidecar is unavailable …]").
   2. Arbitrary provider specifying (or documentation): The sidecar backend can be specified to an established provider (GLM/Gemini/Grok/DeepSeek, etc.) or, if the routing model’s own provider supports search/vision capabilities, delegate the sidecar to that provider. If not possible, state in the README/sidecar document that "the sidecar is coupled with OpenAI/Claude account limits."

   Redacted configuration

   {
     "providers": {
       "glm-zai": {
         "adapter": "anthropic",
         "defaultModel": "glm-5.2",
         "noVisionModels": ["glm-5.2"]
       }
     },
     "webSearchSidecar": { "backend": "openai", "model": "gpt-5.6-luna" },
     "visionSidecar": { "backend": "openai", "model": "gpt-5.4-mini" }
   }

   Screenshots and supporting files

   Dashboard capture (refer to the body Logs table). Additional attachments can be provided if necessary.

   Additional context

   • Related existing issue search results: [Bug]: Vision sidecar is unusable from Codex App - noVisionModels catalog should advertise image input so images reach the proxy #349 (Codex App pre-checks / noVisionModels catalog metadata — separate from sidecar backend limitation), Claude Code WebSearch fails for routed GPT models with empty domain filters #381 (Routing GPT's WebSearch domain filter — separate). This issue addresses the separate defect/limitation of "backend fixed to openai·anthropic + entire turn 499/502 upon limit exhaustion."
   • Impact: Users who route to other providers like GLM/DeepSeek to conserve OpenAI/Claude limits are exactly the ones getting blocked at the moment of limit exhaustion during search/vision turns. Vision is further vulnerable due to overlap with the image client pre-check ([Bug]: Vision sidecar is unusable from Codex App - noVisionModels catalog should advertise image input so images reach the proxy #349 reference).

   Checks

   • I searched existing issues and documents. (Checked [Bug]: Vision sidecar is unusable from Codex App - noVisionModels catalog should advertise image input so images reach the proxy #349, Claude Code WebSearch fails for routed GPT models with empty domain filters #381 — separate defects.)
   • I removed secrets, tokens, account information, request credentials, and personal information.
4. github-actions commented on Jul 24, 2026

   

   github-actionsbot

   on Jul 24, 2026 – with GitHub Actions

   Contributor

   More actions

   Possibly related issues:

   • [Bug]: Vision sidecar is unusable from Codex App - noVisionModels catalog should advertise image input so images reach the proxy #349
   • [Bug]: Claude settings - Search/Vision Sidecar dropdowns clipped by container boundary, bottom options unselectable #340
   • The call speed is super slow, but calling the GPT model directly without OpenCodex is very fast #338

   Reason: The new issue discusses problems related to the Vision Sidecar feature, which aligns closely with existing issues regarding the usability and configuration of Vision Sidecar in the Codex App.

   Detected automatically via GitHub Models.
5. lidge-jun commented on Jul 24, 2026

   

   lidge-jun

   on Jul 24, 2026

   Owner

   More actions

   Thanks for the precise report — the 201,434ms observation was the key.

   Root cause

   The web-search sidecar's per-search deadline defaulted to 200s (DEFAULT_TIMEOUT_MS = 200_000 in src/web-search/index.ts). The executors already degrade an HTTP error or timeout into a failed tool result (they are "never throws"), but when the backend simply hangs on an exhausted account, one search burned the full ~200s. The client then cancels first (the turn surfaces as 499), or the forced answer-without-search routed iteration fails afterward (502). So the 499/502 was a symptom of the 200s wait, not a direct sidecar emission.

   Fix (dev)

   • Lowered the default sidecar search deadline 200s → 60s (hosted-search p90 is ~43s, so 60s bounds hangs while leaving tail margin). webSearchSidecar.timeoutMs still overrides it. The routed-model body-inactivity budget (routedModelStallTimeoutMs) is unchanged.
   • Added a defensive guard around the sidecar dispatch so an unexpected throw degrades to a failed tool result, while a genuine client cancel still maps to 499.
   • Redacted the Anthropic executor's echoed HTTP error body (it could contain header/token material).
   • Docs synced (config reference EN + zh-CN, structure/04). Regression tests cover the 60s default and thrown-sidecar degradation (with a secret-non-leak assertion).

   With this, a limit-exhausted/unavailable search backend degrades to a normal no-search answer within ~1 min instead of hanging the whole turn.

   Follow-ups (the other half of your report)

   You also asked for search backends beyond the fixed openai/anthropic pair — split into two tracked issues:

   • feat(sidecar): add Exa and other search providers as web-search sidecar backends #414 — add Exa and other dedicated search providers as sidecar backends.
   • feat(sidecar): investigate search-API-capable providers (e.g. Gemini) as web-search sidecar backends #415 — investigate/enable provider-native search APIs (Gemini grounding first) as sidecar backends.

   If you can still reproduce a >60s hang after updating, please attach the dashboard per-request timing and whether the search or vision sidecar was active on that turn.
6. lidge-jun

   added 3 commits that reference this issue on Jul 24, 2026

   fix(web-search): bound sidecar search deadline to 60s + defensive deg…

   ...

   99d73f1

   docs(devlog): WP2 #398 A-gate folds (60s deadline, post-await abort, …

   ...

   895b3d4

   fix(web-search): bound sidecar search deadline to 60s + graceful degr…

   ...

   6a0f5b5
7. lidge-jun commented on Jul 24, 2026

   

   lidge-jun

   on Jul 24, 2026

   Owner

   More actions

   Fixed by #416 (bound sidecar search deadline to 60s + graceful degradation). Merged to dev — will ship in the next release.
8. lidge-jun

   closed this as completedon Jul 24, 2026
9. lidge-jun

   added a commit that references this issue on Jul 24, 2026

   docs(devlog): PR/Issue triage 260725 — tier analysis + priority matrix

   ...

   2c68d2f
10. agentHits

    added 2 commits that reference this issue on Sep 17, 2026

    fix(web-search): bound sidecar search deadline to 60s + graceful degr…

    ...

    6e29e4e

    docs(devlog): PR/Issue triage 260725 — tier analysis + priority matrix

    ...

    7380436