Claude Code "Request timed out": API_TIMEOUT_MS and Proxy Fixes

Wokey Team · 2026-09-24

Short answer: Request timed out means Claude Code got no response from the API before its deadline, which defaults to 10 minutes (API_TIMEOUT_MS=600000). Behind a gateway, the usual cause isn't a slow model. More often, something in between holds back the streamed response, or cuts connections that go quiet for too long. That might be a local proxy, a corporate network or the gateway itself. First check with curl that the stream arrives piece by piece, then decide whether to raise the timeout.

Which one are you seeing

Message Meaning
Waiting for API response · will retry in … · check your network under the spinner No data for 20 seconds. Claude Code is still waiting; this is not an error yet
Retrying in Ns · attempt x/y Automatic retries are running, up to 10 by default
Request timed out No response within API_TIMEOUT_MS
API Error: No response from API (waited …, then … on the retry) Two attempts passed without the first byte of a response
HTTP 504 with a Wokey JSON body Wokey timed out waiting for the upstream
HTTP 408 The request body uploaded too slowly, so the gateway stopped waiting for it

The first four come from Claude Code itself; the last two come from the server.

Wokey's timeout errors

Wokey's timeout errors are all 504s in the standard error format. The code tells you where the request stalled:

code Meaning
upstream_gateway_timeout The upstream's own gateway timed out before producing any output
official_exit_first_byte_timeout The upstream never started replying, including time spent retrying on other routes
provider_timeout The connection to the upstream dropped or timed out without a result

For example:

{"error":{"code":"upstream_gateway_timeout","message":"Upstream gateway timed out before producing a response.","type":"invalid_request_error"}}

If the timeout happens after the reply has started streaming, it arrives as an in-stream error event rather than an HTTP 504.

When there is no output for a long time, for example while the model thinks at length, Wokey periodically writes an SSE comment into the stream to keep the connection alive:

: wokey-transport-keepalive-v1

Clients ignore comment lines. If you see one while testing with curl, the connection is alive and the model is still working.

Troubleshooting steps

1. Check with curl that the stream arrives piece by piece.

curl -N https://api.wokey.ai/v1/messages \
  -H "Authorization: Bearer $ANTHROPIC_AUTH_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","max_tokens":300,"stream":true,"messages":[{"role":"user","content":"Count from 1 to 60"}]}'

-N turns off curl's own buffering.

  • event: and data: lines scroll by as they arrive: the whole path is fine.
  • Everything appears at once after a long wait: something in between is buffering the response, and Claude Code is prone to time out on that path.

2. Check your local proxy. Claude Code honours HTTPS_PROXY and the system proxy settings. TUN mode, rule-based proxies and corporate gateways can all buffer streamed responses or cut idle connections. If your network can reach api.wokey.ai directly, exclude that domain from the proxy and try again. If you must use a proxy, compare against a different node.

3. Raise the timeout. Once the path checks out and the requests really are long, raise the limit in the env block of ~/.claude/settings.json:

{
  "env": {
    "API_TIMEOUT_MS": "1200000"
  }
}
  • API_TIMEOUT_MS is the per-request timeout in milliseconds. The default is 600000 (10 minutes).
  • If a proxy on your network holds responses until they complete, Claude Code's error message suggests also raising CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS.
  • Detection of a stream that stalls midway is controlled by CLAUDE_STREAM_IDLE_TIMEOUT_MS. Values below 5 minutes are raised to 5 minutes, and the maximum is 30 minutes.

4. Shrink the context. A larger context uploads more slowly and delays the first token. Run /compact to condense the session, or start a new one.

5. If you get a 408. A 408 means the request body stopped arriving during upload and the gateway gave up waiting. It shows up almost only with very large contexts on unstable networks. A plain retry usually succeeds. If it keeps happening, check your proxy as in step 2, then shrink the request with /compact.

Timeouts in Codex

Codex's stream idle timeout defaults to 300000 ms (5 minutes). When it fires you see idle timeout waiting for SSE or stream disconnected before completion, and automatic retries show Reconnecting... n/max. These settings go in the provider table:

[model_providers.wokey]
name = "Wokey"
base_url = "https://api.wokey.ai"
env_key = "WOKEY_API_KEY"
wire_api = "responses"
stream_idle_timeout_ms = 600000
stream_max_retries = 10

stream_max_retries defaults to 5 and request_max_retries to 4; both are capped at 100. For the full setup see the Codex config.toml guide.

FAQ

What is Claude Code's default timeout?

Ten minutes per request, set by API_TIMEOUT_MS (default 600000). Raise it in the env block of ~/.claude/settings.json, for example "API_TIMEOUT_MS": "1200000".

How do I tell whether it is the network or the model?

Send a "stream":true request with curl -N. If data: lines arrive one by one, the path is fine. If everything appears at once after a long wait, something in between is buffering the response, and that path is prone to time out.

What does a 504 from Wokey mean?

All Wokey timeouts are 504s, and code says where it stalled: upstream_gateway_timeout means the upstream's gateway timed out, official_exit_first_byte_timeout means the upstream never started replying, and provider_timeout means the connection to the upstream dropped or timed out.

What is wokey-transport-keepalive-v1 in the stream?

It is an SSE comment Wokey writes when there has been no output for a while, to stop intermediaries from cutting the connection. Clients ignore it; seeing it means the connection is alive and the model is still working.

How do I change timeouts in Codex?

Set stream_idle_timeout_ms (default 300000) and stream_max_retries (default 5) in the provider table of config.toml.