[efenex]

Problem

providerSignal gives every Claude passthrough request an implicit AbortSignal.timeout(180000), and that deadline covers the whole streamed response. The launcher never passes timeoutMs, so every claude-multi session gets it. Any Claude turn whose stream runs past 3 minutes is aborted mid-response:

• In an interactive session this shows up as "API Error: Server error mid-response". We hit it reliably at the first real server-side advisor call (advisorModel set). Short advisor calls succeed, which made it look advisor-specific.
• With claude-multi -p ... --output-format json, the truncated text comes back with subtype: "success" and is_error: false. Headless automation gets a silently cut response.

The OpenAI and Zen routes were already changed to follow the client connection rather than an absolute timer. Claude passthrough kept the fixed 3-minute limit.

Change

When no explicit timeoutMs is configured, Claude passthrough follows the client connection, the same as OpenAI and Zen. An explicit timeoutMs still bounds every route, and client disconnects still abort upstream requests. Claude Code applies its own request timeout. The unit test now asserts no implicit timer for Claude passthrough, and that an explicit limit bounds both routes. CHANGELOG has an entry under Unreleased.

Validation

• npm run check: 515/515 pass (Node 26.10, macOS).
• Live, with the same long single Opus response (claude-multi -p, advisor off) through the 0.2.1 gateway:
  • before: cut mid-sentence at duration_api_ms 180018, reported as success. Plain claude with the same prompt was still streaming at 487 s.
  • after (this patch applied to the installed 0.2.1 gateway): completed normally after 633 s (duration_api_ms 633140).
• I did not run the provider opt-in live suites. This change only touches the Claude passthrough deadline.

🤖 Generated with Claude Code