Claude Code can sometimes stop responding and eventually display an error such as:
API Error: No response from API (waited 3m, then 10m on the retry)
This message is frustrating because your internet connection may appear to be working normally. In some cases, the first request waits for several minutes, the retry waits again, and the turn fails without producing an answer. A separate report describes a particularly specific pattern: the error appears on the first request after a computer changes networks, while restarting Claude Code on the new network makes the next request respond normally.
The important distinction is that “No response from API” describes a request that did not receive response headers within its deadline; it does not, by itself, prove that Anthropic’s service is down or that your API key is invalid. The right fix depends on whether the cause is a stale connection, a proxy or gateway, a temporary service problem, or a genuinely slow response.
This guide explains how to diagnose the error, which settings can help, and what the latest public evidence does—and does not—establish.
What does “No response from API” mean?
Claude Code sends a streaming request and waits for the API to begin responding. If no response headers arrive before the first-byte deadline, the client aborts that attempt. It may then retry once, depending on its retry budget. If the retry also receives no response before its deadline, Claude Code displays the error.
The two waiting periods in the message refer to two separate attempts. They do not necessarily mean the API spent that entire time generating an answer. The request may not have started successfully, or a connection between the client and the API may have stopped making progress.
According to the Claude Code error documentation, the first attempt’s deadline and the retry’s timeout are controlled by different settings in relevant configurations. The retry is normally governed by API_TIMEOUT_MS, while CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS can set the deadline for the first response byte on supported connection paths.
That distinction matters: reducing one timeout may shorten an unproductive wait, but it does not repair a broken connection. Increasing a timeout may help a slow but healthy connection, but it can make a dead connection take longer to fail.
First, identify which situation you have
Before changing environment variables, work through these checks in order.
1. Retry the same conversation once
If the message appears only once, send the prompt again. The previous prompt is usually still in the conversation, so you can type “try again” rather than pasting a long request again.
If the second attempt succeeds immediately and the error does not return, it may have been a temporary network or service interruption. If it repeatedly fails, continue with the steps below rather than retrying indefinitely.
2. Check Anthropic’s service status
Open the Anthropic Status page and look for an incident affecting Claude or the API. A confirmed incident is a reason to wait for service recovery rather than repeatedly changing local settings.
A status page showing normal operation does not rule out every problem. Regional routing issues, account-specific problems, network intermediaries, or a small-scale defect may not appear as a broad incident.
3. Determine whether the failure follows a network change
Ask yourself when the error began:
- Immediately after moving from one Wi-Fi network to another?
- After connecting or disconnecting a VPN?
- After a laptop woke from sleep?
- On every request, even when the network has not changed?
- Only when using a corporate proxy, gateway, or custom API endpoint?
The answers help separate a connection-specific symptom from a general timeout. If the problem appears immediately after changing networks, start with a fresh Claude Code process on the new network.
Fix 1: Restart Claude Code after changing networks
A public report in the Claude Code issue tracker, issue #99524, describes a Linux user whose next request could wait around three minutes after the machine changed networks. The report says a newly started Claude Code process on the same network responded normally. Other comments describe similar symptoms, including cases not clearly tied to a network change.
This is evidence of a reproducible symptom, not proof of the underlying cause. The issue report discusses a possible stale or dead connection, but that explanation has not been confirmed as the root cause by Anthropic.
If you are affected by this exact pattern:
- Save any work outside the terminal that you do not want to lose.
- Exit the current Claude Code process normally.
- Confirm the computer is connected to the intended network.
- Start Claude Code again and submit a short test prompt.
- If the fresh process works, continue working but record whether the issue returns after the next network change.
Do not delete your project, remove configuration files, or reinstall the application as a first response. Those steps are more disruptive and are not established fixes for this particular report.
Fix 2: Shorten the first-response wait when the connection is hanging
The issue report documents a workaround using the CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS environment variable. It changes how long Claude Code waits for the first response byte on connection paths where that deadline applies.
On Linux or macOS, you can launch a new process with a 30-second deadline:
CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS=30000 claude
In Windows PowerShell, use:
$env:CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS = "30000"
claude
The value is in milliseconds, so 30000 means 30 seconds. This is a temporary workaround for reducing the wait, not a fix for the connection itself. In the issue report, lowering the deadline reduced the time spent waiting before the retry, but did not prevent the initial failure.
There is an important trade-off. A shorter deadline can make a dead connection fail faster, but it can also interrupt a legitimate request that simply takes longer to begin responding. Do not set it to an extremely low value, and do not assume that 30 seconds is the best setting for every provider or network.
If your connection is genuinely slow and the retry usually succeeds, the official guidance may point in the opposite direction: increasing the first-byte deadline can prevent an otherwise healthy but slow first attempt from being aborted too early. Choose the direction based on the observed pattern rather than copying a setting blindly.
Fix 3: Adjust the retry timeout only when a proxy or gateway needs it
Claude Code’s error message may suggest increasing API_TIMEOUT_MS or CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS if a proxy or gateway holds responses until generation completes.
For example, on Linux or macOS, a longer retry timeout can be set for one launch:
API_TIMEOUT_MS=900000 claude
In PowerShell:
$env:API_TIMEOUT_MS = "900000"
claude
Here, 900000 milliseconds is 15 minutes. This setting may be relevant when your network intermediary delays streaming headers or buffers a response. It is not a universal fix for a dead connection after switching networks. A longer timeout can simply make you wait longer when no response will arrive.
Only try this if you use a proxy, gateway, or provider setup that could reasonably need a longer response window. Change one variable at a time, test, and revert it if it does not improve the result.
Fix 4: Test the network path without exposing credentials
If restarting Claude Code does not help, check whether the API endpoint can be reached from the same machine and network.
For a basic connectivity check, you can run:
curl -I --max-time 15 https://api.anthropic.com
An HTTP response—even an error response—can show that a connection reached the server. A timeout or DNS failure may point toward a network path problem. However, this command is only a basic reachability check: it does not perform an authenticated Claude API request, and a successful result does not prove that streaming requests will work.
If you use a VPN, corporate firewall, proxy, or custom endpoint, check whether it is required by your organization. Do not bypass workplace security controls without permission. If policy permits, compare the behavior on another trusted network. Never paste API keys, authorization headers, or private environment-variable dumps into public issue reports.
Anthropic’s API connection troubleshooting guidance recommends checking firewalls, network restrictions, and VPN configuration when connection errors occur.
Fix 5: Update Claude Code and record the exact version
Run:
claude --version
Then consult the official Claude Code documentation and the official release history for changes relevant to errors, networking, streaming, and retries.
The public issue discussed above reported that the behavior was still present in Claude Code 2.1.296, with a comment dated October 13, 2026. That is useful evidence for the reported case, but it does not establish that every user or configuration is affected. Nor does it establish the status of versions released after the report.
If you update, test the same short prompt on the same network and note whether the behavior changes. Avoid downgrading to an older release unless you have a specific, verified reason and understand the security and compatibility implications.
Fix 6: Collect useful diagnostics if the error persists
If the issue keeps returning, collect enough information to make a bug report actionable:
- Claude Code version and operating system.
- Whether the error follows a network switch, sleep/wake, VPN change, or proxy change.
- The exact error text, including both wait durations.
- Whether a fresh Claude Code process on the same network works.
- Whether the first attempt fails but the retry succeeds.
- Whether the same symptom appears on a second trusted network.
- Relevant debug output with secrets and private project information removed.
You can consult the Claude Code error reference for documented diagnostic behavior. If you report the issue on GitHub, search for an existing report first and add your evidence there when it describes the same behavior. Avoid claiming that a suspected stale connection is the confirmed root cause unless the maintainers establish that.
Which fix should you use? A quick decision table
| Symptom | Best next step | What to expect |
|---|---|---|
| One isolated failure | Retry once and check service status | May resolve a transient interruption |
| Failure immediately after changing Wi-Fi or network | Restart Claude Code on the new network | May clear the problematic session |
| First attempt waits several minutes, but retry succeeds | Test a carefully chosen first-byte timeout | Can reduce or prevent premature aborts, depending on the cause |
| Proxy or gateway delays response headers | Review gateway behavior and consider a longer API_TIMEOUT_MS | May accommodate legitimate buffering |
| Failure persists on every network and every new session | Update, gather diagnostics, and check official reports | May require a vendor-side fix |
| API returns explicit 401, 403, 429, or 5xx status | Follow the guidance for that status code | These errors have different causes from a missing first response |
Is there a confirmed permanent fix?
As of October 14, 2026, the public evidence cited here does not confirm a permanent fix for the specific network-change behavior in issue #99524. The report remained open in the latest evidence reviewed for this article, and the proposed stale-connection explanation remains a hypothesis rather than an official root-cause finding.
The practical approach is therefore to restart the session after a network change, use timeout adjustments only when they match the observed failure, and check the issue and release notes for verified updates. Do not treat lowering a timeout as proof that the connection problem has been solved.
If Anthropic publishes a fix or the issue is closed with a confirmed resolution, this guide should be updated to distinguish the permanent fix from the temporary workarounds.
Frequently asked questions
Does “No response from API” mean my API key is invalid?
Not necessarily. The message means Claude Code did not receive the expected response headers before the deadline. Invalid credentials usually produce an explicit authentication error, such as a 401 response, rather than this exact no-response timeout.
Should I always set CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS to 30000?
No. That value is useful only as a diagnostic workaround when reducing the wait is the goal. If your request is slow but healthy, a shorter deadline can cause more failures. Choose the setting based on whether the first attempt is hanging or simply slow.
Will reinstalling Claude Code fix the problem?
There is no evidence in the cited report that reinstalling is a reliable fix. Try restarting the process, checking the network path, and updating to a current release before considering a reinstall.
Does this happen only on Linux?
The primary issue describes Linux, but comments mention similar symptoms in other environments. The evidence is not enough to establish a single platform-specific cause or to estimate how widely the issue occurs.
Where can I check for a confirmed fix?
Watch issue #99524 on GitHub, review the Claude Code releases, and consult the official error documentation. Look for a maintainer-confirmed resolution rather than relying on a workaround alone.