No response from API · Retrying in 2m 25s · check your network

Nothing came back. Not an error, not a status code, not headers — the request went out and the silence that followed is the entire symptom. That rules out a whole category of things people check first: there is no status code to look up, no error.type to match against a table, and no request id to put in a support ticket, because a request id is minted by the service that processes the request. The interval in the message is doing more work than it appears to, and it is the reason this page exists.

Data as of 2026-09. Vendor limits and defaults change; check the official docs for current values before acting on any number below.

A retry interval of minutes means the failure is not fresh

Exponential backoff does not start at two and a half minutes. It starts small and doubles. By the time the countdown on your screen reads minutes, several attempts have already failed, spread across a window that is itself minutes long. What you are looking at is not the beginning of a problem. It is a progress report from the middle of one.

That reframes the only question worth asking. You are not deciding whether to retry — the tool has been retrying for a while and will carry on. You are deciding whether the loop is sampling a world that is changing, or repeating the same experiment against a condition that has been stable the whole time.

The wall-clock arithmetic is worse than the displayed intervals suggest, which is the part that catches people. Claude Code’s per-request timeout, API_TIMEOUT_MS, defaults to 600000 ms — so a single attempt can sit there for a long time before it even counts as a failure and starts the next countdown. The numbers you can see are only part of the elapsed time.

Silence and a labelled error are different failures

Claude Code words these two cases differently, and the difference is the most useful discriminator on this page.

When the server answered and the answer was an error, the retry line follows an error label — something naming a status or a condition. You have a status code, and everything you know about status codes applies: capacity, throttling, authentication, request shape.

When nothing answered, you get silence phrased as silence. There is a closely related state worth recognizing too: while a request is still pending and no data has arrived for twenty seconds, Claude Code shows a waiting line rather than a retrying one — at that point the request has not failed yet, it is merely quiet. A line that says it is retrying has passed that stage.

Why this matters for diagnosis: a saturated or broken service usually answers. It returns a status code, because something is up enough to generate one. Total silence is far more characteristic of the path than of the destination — a VPN, a corporate egress proxy, a TLS-inspecting middlebox, a captive portal, a DNS failure, a machine that just woke from sleep, or a gateway host of your own that is not there. The tool’s “check your network” suffix is boilerplate attached to this condition, but on this particular condition the boilerplate is usually pointing the right way.

What the retry loop’s existence already rules out

Two things, both free, because the tool decided them before printing anything.

It is not a TLS certificate validation failure. Those are reported on the first attempt and are not retried at all. If you are watching a countdown, the certificate chain was accepted. Cross that off before you go looking at corporate root certificates.

Nothing has been half-executed. Claude Code does not retry a server error, dropped connection or stalled stream that arrives after Claude completed a block of text or a tool call, precisely because re-running could execute the same tool calls twice. A request in the retry loop had produced nothing, so there is no duplicated work waiting to bite you when it finally succeeds.

Is retrying useful?

Yes — it is already happening, correctly, and the decision you own is when to stop watching it and start diagnosing.

Claude Code retries transient failures up to ten times with exponential backoff before showing a final error, so by the time you read anything the loop is well underway. For a genuine blip — a flapping VPN, a router rebooting, a laptop reattaching to a network — that loop is exactly right and will resolve without you.

The termination condition is where the judgement lives. Once the interval is in minutes, the remaining attempts will take longer than everything that has already happened, and each one is identical to the last. Retrying harder tests nothing new. Spend that waiting time on the checks below instead: a single curl while the countdown runs costs nothing and settles most of this.

One trap specific to a loop that seems never to end: CLAUDE_CODE_RETRY_WATCHDOG removes the retry cap and, on versions that support it, raises the retry count far beyond the default — the documentation describes capacity errors being retried indefinitely. If someone set that variable once to survive a bad afternoon and forgot it, a session that should have failed in minutes will grind for hours instead. Check whether it is set in the environment the tool actually runs in before you conclude the network is permanently broken.

Do not invent a wait of your own, either. The published guidance is exponential backoff, honouring retry-after when one is sent; no base delay is documented for you to copy.

Checks you can run while the countdown is going

Does anything answer at all? Send a plain HTTP request to the API host with curl from the same machine. Any response — even an error — moves this out of the silence category entirely and into whatever that status code means. No response at all confirms the path.
Does the hostname resolve? A DNS failure produces silence that looks identical to an unreachable service. Resolve the name explicitly before suspecting anything further away.
Does a different network work? A phone hotspot is the fastest experiment in networking. Clean on the hotspot and silent on the office network means the fault is local to that network, and no amount of waiting fixes it.
Are you pointed at your own gateway? Print the base URL actually in effect at runtime. If ANTHROPIC_BASE_URL names a relay, a proxy or an internal gateway, that host is the one going quiet, and the vendor’s status page is irrelevant to you.
Which credential is active? /status shows the active settings sources and which credential is in use. This is worth ten seconds because a request routed somewhere you did not intend explains silence that makes no sense otherwise.
Did it start at a moment? A VPN reconnect, a sleep/resume cycle, a new container image, a change to egress rules. Silence that began at a specific time usually began with a specific change.
Is anyone else seeing it? If the answer is yes and they are not on your network, stop looking at your machine and check the vendor’s status page.

Fix by scenario

curl is silent too — the fault is below your tool. Work outward: DNS, then the VPN or proxy, then the egress path. Nothing in the tool’s configuration can help while a plain HTTP client cannot reach the host either.
curl works and the tool does not — the tool is using a different route or different proxy settings than your shell. Compare HTTP_PROXY, HTTPS_PROXY and the base URL in the environment the tool actually runs in, which is not necessarily the shell you typed in.
A hotspot works and your network does not — an inspection proxy or firewall policy is dropping the traffic. Exempt the API host or route around it; that request is a conversation with your network administrators, not a configuration change you make alone.
Your own gateway is silent — restart it and check its logs. A relay that accepts connections but never answers is a different failure from one that refuses them outright, and its logs will say which.
The watchdog variable is set — unset it, restart, and let the tool fail honestly. An error you can see in two minutes is worth more than a spinner that hides the same error for hours.
It is upstream and general — stop, and come back. Long-running work is better off the synchronous path anyway: the SDKs validate that non-streaming Messages API requests are not expected to exceed a ten-minute timeout, and the docs recommend streaming or the Message Batches API beyond that.

How to confirm it’s fixed

Re-run the request on the same network path and require it to succeed twice in a row. A single success is indistinguishable from a flapping link happening to be up during the attempt, which is precisely the failure mode you are trying to rule out.

There is a second observable worth knowing, because it prevents a wrong conclusion. Backoff resets on a new failure, so a countdown that reappears starting from a short interval is a fresh incident, not the old one continuing. If you see a small interval after your change, your change did not fail — something failed again. Treat it as a new data point and note what was different.

If your fix was to the environment, prove it took effect rather than assuming: print the base URL and proxy variables from the running process. A file you edited and an environment a process inherited are two different things.

If the retry line follows an explicit error label rather than silence, you have a status code to work with and a different page applies — see API Error (Connection error.) with a retry countdown. If something in the path answered with an active refusal instead of going quiet, that refusal is a much sharper clue: upstream connect error with connection refused explains why a refusal points at a listener close to you.

If bytes did start arriving and then stopped, you are on the other side of the line this page draws, and a retry can duplicate work: connection closed mid-response and stream idle timeout with a partial response cover the failures that arrive after a successful status.

To place a network-shaped failure by layer before spending an afternoon on it, the AI coding error triage tool sorts them by the signals used here: whether anything answered, whether a status code exists, and whether any output had already been produced.