Regression: httpIdleTimeoutMs no longer respected for self-hosted OpenAI-compatible provider (v0.80.6, worked fine in v0.80.3)

[hoho51]

What happened?

After upgrading from v0.80.3 to v0.80.6, requests to my self-hosted model (via vLLM, OpenAI-compatible API) now fail with Error: The operation timed out after only a few minutes, even though httpIdleTimeoutMs is explicitly set to a much larger value in /settings.

Downgrading back to v0.80.3 resolves the issue completely — same model, same settings, same request. This strongly suggests a regression introduced somewhere between v0.80.3 and v0.80.6.

This looks related to a previously fixed issue (#5294 / v0.78.1 changelog: "Fixed HTTP timeout setting not being respected for non-Codex providers, e.g., llama.cpp via OpenAI-compatible API"). It's possible that fix was reverted or broken by a later change.

Environment

• Pi version: v0.80.6 (regression; not present in v0.80.3)
• Provider: self-hosted model via vLLM, OpenAI-compatible API
• /settings → HTTP timeout (httpIdleTimeoutMs): 6000000 (6,000,000 ms)

Steps to reproduce

1. Configure Pi to use a self-hosted OpenAI-compatible endpoint (vLLM backend)
2. Set httpIdleTimeoutMs to 6000000 via /settings
3. Ask the agent to write a test file / generate code that takes the local model several minutes to produce (self-hosted model is slower than cloud APIs)
4. Wait — after a few minutes, the request fails with Error: The operation timed out, even though the configured idle timeout is far larger than the elapsed time
5. Reproduced consistently across multiple attempts on v0.80.6
6. Downgrading to v0.80.3 with identical settings/model/prompt — no timeout, works as expected

Expected behavior

The request should not time out before httpIdleTimeoutMs (6,000,000 ms) elapses, consistent with v0.80.3 behavior.

Version

v0.80.6

[github-actions]

This issue was auto-closed. All issues from new contributors are auto-closed by default.

Maintainers review auto-closed issues daily and reopen worthwhile ones. Issues that do not meet the quality bar in CONTRIBUTING.md will not be reopened or receive a reply.

If a maintainer replies lgtmi on one of your issues, your future issues will stay open. If a maintainer replies lgtm, your future issues and PRs will stay open.

See CONTRIBUTING.md.

[hoho51]

Can confirm a related data point: on my setup (self-hosted OpenAI-compatible backend via LiteLLM/vLLM), installing pi via npm does not hit this timeout, but running the official released binary reliably reproduces it on the same task/settings. Might be worth checking whether the Bun-compiled binary build path handles the fetch dispatcher differently than the npm/Node build.

[davidbrai]

maybe related: oven-sh/bun#33647

@hoho51 I was able to reproduce on v0.80.6 with the bun packaged binary on mac. but I got the same issue for v0.80.3
are you sure it doesn't happen on v0.80.3 for you? which os are you running on?

[davidbrai]

@badlogic bun has a built in 5 min http idle timeout.
our configureHttpDispatcher function doesn't affect it because it doesn't have undici.install
as a temporary workaround, users can use BUN_CONFIG_HTTP_IDLE_TIMEOUT to override it. it was recently introduced so we need to bump the bun version, see PR: #6503

this fix was recently merged which will allow a more elegant way to configure the timeout from code. once it's out we can update configureHttpDispatcher to configure it for bun too

[hoho51]

maybe related: oven-sh/bun#33647

@hoho51 I was able to reproduce on v0.80.6 with the bun packaged binary on mac. but I got the same issue for v0.80.3 are you sure it doesn't happen on v0.80.3 for you? which os are you running on?

My “v0.80.3 works” data point was via npm install, not the bun-packaged binary. I haven’t tested v0.80.3 with the bun binary specifically, so there’s no actual contradiction with what you found — we may have both been right, just testing different install paths. And my os is centos8