›_ Claude Code Issues
Claude Code Issues / #39906

[BUG] Claude Code Cannot Handle API Requests >5 Minutes Long

Status Fixed / completed
Reported on v2.1.84
Maintainer reply None cached
Workaround ✓ Mentioned in description ↑
Activity 7 comments · opened Mar 27, 2026 · closed Apr 9, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Using Claude Code with backends that are a little bit slow, I've been getting consistent timeouts once the context window causes responses from the v1/messages/ endpoint to take >=5 minutes.

It took me a little while to figure out how to fix this - at first I thought it was a bug in Ollama, but the same thing happens with other backends such as llama.cpp and LM Studio, and I didn't see any error responses over Wireshark - it looks like Claude is closing the connection after a preset timeout.

None of the environment variables I could find worked to adjust this timeout. I tried $BASH_DEFAULT_TIMEOUT_MS, $BASH_MAX_TIMEOUT_MS, $API_TIMEOUT_MS, $CLAUDE_CODE_STALL_TIMEOUT_MS_FOR_TESTING...nothing.

So I asked Claude to debug itself, and it was able to pick apart the claude binary and figure out what was going wrong.

It looks like there's a hardcoded timeout in the Bun middleware that can be disabled or configured, but Claude is calling it in a way that accepts the default. So for v2.1.84, I had to run the following patch to fix the issue:

sed -i 's/if\(H\?\.forAnthropicAPI\)\{let T=process\.env\.ANTHROPIC_UNIX_SOCKET;if\(T&&typeof Bun<"u"\)return\{unix:T\}\}/if(H?.forAnthropicAPI){return{timeout:!1} }/g' /path/to/claude

And that actually seems to work. It's minified code, but it should point you to where it could be fixed in the actual claude repo. This was also suggested, and I ran it first but it didn't actually fix things. Still, it might be a prereq?

sed -i 's/this\.requestTimeout = 300000/this.requestTimeout = 900000/' /path/to/claude

So anyways, I'd like to avoid needing to do this with a slightly different patch every time Claude updates, so if y'all could add a configurable timeout with an env var like $CLAUDE_SOCKET_TIMEOUT_MS or something, that would be greeeeat. Thank you!

What Should Happen?

Claude should be able to wait more than 5 minutes for its next thought to arrive.

I know the kids are all about instant gratification these days, but come on.

Error Messages/Logs

The most relevant error logs are just:

`Request timed out`

When I set `$API_TIMEOUT_MS` to a nondefault value, it prints this instead:

`Request timed out (API_TIMEOUT_MS=1800000ms, try...`

But that's about it. Even the debug logs don't provide much more info, so I had to dig into Wireshark and guess from the backend request logs (and ask an LLM) to figure out what was going on.

Steps to Reproduce

  1. Run a local LLM backend, set it to CPU-only inference to slow things down and make the bug easier to trigger.
  2. Talk with Claude for awhile to build up a non-trivial context window.
  3. Eventually, when the chat API requests start taking 5 minutes to return, API request timeouts will start to occur. Progress becomes blocked until a new context window is started, but it happens for me around 2-10k tokens so...it's a tough bug to work around.

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.84

Platform

Other

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

I did find a fix to patch the binary - it's one or both of these:

sed -i 's/this\.requestTimeout = 300000/this.requestTimeout = 900000/' /path/to/claude
(this was a first attempt that didn't work, probably isn't the culprit)

sed -i 's/if\(H\?\.forAnthropicAPI\)\{let T=process\.env\.ANTHROPIC_UNIX_SOCKET;if\(T&&typeof Bun<"u"\)return\{unix:T\}\}/if(H?.forAnthropicAPI){return{timeout:!1} }/g' /path/to/claude
(this fixed the issue, after the prior patch was run but I think it's probably unrelated. Not sure if the extra spaces are really needed to preserve file length/addresses)

You'd probably want a more comprehensive fix that doesn't break unix socket support and makes the timeout configurable, but that should at least point to where the problem _is_.

So hopefully this would be pretty quick to fix. Please and thank you!

View original on GitHub ↗

7 Comments

github-actions[bot] · 5 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/35327
  2. https://github.com/anthropics/claude-code/issues/1999
  3. https://github.com/anthropics/claude-code/issues/15446

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

WRansohoff · 5 months ago

I don't think this is a duplicate.
The behavior is similar to #35327, but I don't see a "API Error: terminated" message anywhere so I suspect the root cause is different.
#1999 looks different, fixed by using $API_TIMEOUT_MS (which doesn't fix this bug)
#15446 mentions a 10+-minute timeout, different from this bug and also possibly fixable by changing the default 10-minute $API_TIMEOUT_MS

(also, I didn't see a working solution in any of those issues)

rehevkor5 · 4 months ago

Claude Code doesn't show that this is happening within its UX, either, which leads to frustrating UX where the work effectively hangs for ~55 minutes or such, until all the 5 minute retries are exhausted. That wastes a lot of time waiting for something which will never succeed.

zqushair · 4 months ago

I'm having the same issue that you described with Ollama serving qwen3.5:35b on a halo strix 395+ 128GB. Monitoring Ollama I see this in the log (journalctl -u ollama -f). The first few times it hits 5mins, it still returns 200 and works fine but then as the context grows a bit more (same as what the OP said, around 10-12k tokens, so not that big for the memory that I have) and the responses are more than 5mins long, I start getting 500 error responses. I have to stop what it is doing and start it all over again.

...
Apr 14 13:51:55 strixbu ollama[452334]: [GIN] 2026/04/14 - 13:51:55 | 200 | 3m55s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 14:00:24 strixbu ollama[452334]: [GIN] 2026/04/14 - 14:00:24 | 200 | 3m58s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 14:04:30 strixbu ollama[452334]: [GIN] 2026/04/14 - 14:04:30 | 200 | 4m3s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 14:09:40 strixbu ollama[452334]: [GIN] 2026/04/14 - 14:09:40 | 200 | 5m8s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 14:14:31 strixbu ollama[452334]: [GIN] 2026/04/14 - 14:14:31 | 200 | 4m51s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 14:19:00 strixbu ollama[452334]: [GIN] 2026/04/14 - 14:19:00 | 200 | 4m28s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 14:23:35 strixbu ollama[452334]: [GIN] 2026/04/14 - 14:23:35 | 200 | 4m34s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 14:28:38 strixbu ollama[452334]: [GIN] 2026/04/14 - 14:28:38 | 200 | 5m2s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 14:34:14 strixbu ollama[452334]: [GIN] 2026/04/14 - 14:34:14 | 200 | 5m35s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 14:39:15 strixbu ollama[452334]: [GIN] 2026/04/14 - 14:39:15 | 200 | 5m1s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 14:44:20 strixbu ollama[452334]: [GIN] 2026/04/14 - 14:44:20 | 200 | 5m4s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 14:49:07 strixbu ollama[452334]: [GIN] 2026/04/14 - 14:49:07 | 200 | 4m47s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 14:54:15 strixbu ollama[452334]: [GIN] 2026/04/14 - 14:54:15 | 200 | 5m8s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 14:59:25 strixbu ollama[452334]: [GIN] 2026/04/14 - 14:59:25 | 200 | 5m9s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 15:04:31 strixbu ollama[452334]: [GIN] 2026/04/14 - 15:04:31 | 200 | 5m6s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 15:09:31 strixbu ollama[452334]: [GIN] 2026/04/14 - 15:09:31 | 500 | 5m0s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 15:14:33 strixbu ollama[452334]: [GIN] 2026/04/14 - 15:14:33 | 500 | 5m0s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 15:19:08 strixbu ollama[452334]: [GIN] 2026/04/14 - 15:19:08 | 500 | 4m34s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 15:24:35 strixbu ollama[452334]: [GIN] 2026/04/14 - 15:24:35 | 200 | 4m59s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 15:29:37 strixbu ollama[452334]: [GIN] 2026/04/14 - 15:29:37 | 500 | 5m0s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 15:34:39 strixbu ollama[452334]: [GIN] 2026/04/14 - 15:34:39 | 500 | 5m0s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 15:39:40 strixbu ollama[452334]: [GIN] 2026/04/14 - 15:39:40 | 500 | 5m0s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 15:44:43 strixbu ollama[452334]: [GIN] 2026/04/14 - 15:44:43 | 500 | 5m0s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 15:49:49 strixbu ollama[452334]: [GIN] 2026/04/14 - 15:49:49 | 500 | 5m0s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 15:54:59 strixbu ollama[452334]: [GIN] 2026/04/14 - 15:54:59 | 500 | 5m0s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 16:00:19 strixbu ollama[452334]: [GIN] 2026/04/14 - 16:00:19 | 500 | 5m0s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 16:05:53 strixbu ollama[452334]: [GIN] 2026/04/14 - 16:05:53 | 500 | 5m0s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 16:11:27 strixbu ollama[452334]: [GIN] 2026/04/14 - 16:11:27 | 500 | 5m0s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 16:17:02 strixbu ollama[452334]: [GIN] 2026/04/14 - 16:17:02 | 500 | 5m0s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 16:22:37 strixbu ollama[452334]: [GIN] 2026/04/14 - 16:22:37 | 500 | 5m0s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 16:28:19 strixbu ollama[452334]: [GIN] 2026/04/14 - 16:28:19 | 500 | 41.42303517s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 16:28:46 strixbu ollama[452334]: [GIN] 2026/04/14 - 16:28:46 | 500 | 7.798046749s | 10.0.33.100 | POST "/v1/messages?beta=true"
Apr 14 16:28:46 strixbu ollama[452334]: time=2026-04-14T16:28:46.584+03:00 level=INFO source=runner.go:922 msg="aborting completion request due to client closing the connection"

At this stage I interrupted Claude and started with a new prompt.

yuanjize · 4 months ago

Is there any update？changelog of v2.1.101 say had fix this issue. But it seems not (in my test)

CaesarMordred · 4 months ago

sed -i 's/if\(H\?\.forAnthropicAPI\)\{let T=process\.env\.ANTHROPIC_UNIX_SOCKET;if\(T&&typeof Bun<"u"\)return\{unix:T\}\}/if(H?.forAnthropicAPI){return{timeout:!1} }/g' /path/to/claude
I use this command to resolve the issue. And I believe v2.1.101 didn't resolve the problem, this is still a bug.
Thanks for the solution, it's quite helpful

github-actions[bot] · 4 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

This issue appears in the ranked issue list on this topic page, alongside a backlog trend for the whole topic.

Context window & memory limits →

Browse all Claude Code issue topics →