Você manda um prompt no Claude Code, o spinner gira por três minutos e termina assim: API Error: No response from API (waited 3m, then 10m on the retry). Isso significa que a API não devolveu nem os cabeçalhos da resposta dentro do prazo de primeiro byte, o Claude Code abortou, tentou de novo uma vez e a segunda tentativa também ficou sem resposta.
Este guia mostra o que cada número da mensagem quer dizer, o que fazer em ordem e quais variáveis de ambiente mudam o comportamento. Tudo foi conferido na documentação oficial do Claude Code em 11/10/2026.
O que significa "No response from API (waited 3m, then 10m on the retry)"?
Significa que o Claude Code enviou uma requisição em streaming e a API não devolveu os cabeçalhos da resposta antes do prazo de primeiro byte. Em vez de esperar os 10 minutos de API_TIMEOUT_MS, o Claude Code aborta e reenvia no máximo uma vez. Se o reenvio também fica sem resposta, o turno termina com a mensagem completa:
API Error: No response from API (waited 3m, then 10m on the retry). If a proxy or gateway on your network holds responses until they complete, raise API_TIMEOUT_MS or CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS to wait longer.Os dois tempos da mensagem são as duas esperas: a da primeira tentativa (3m) e a do reenvio (10m). Antes de terminar, você pode ver por alguns segundos a linha No response from the API after 3m · retrying once, waiting up to 10m, que é o aviso de que o reenvio começou.
Quanto tempo o Claude Code espera antes de abortar?
Na API direta da Anthropic, 180 segundos na primeira tentativa, mais 1 segundo para cada 32KB de corpo da requisição. O reenvio espera um segundo a menos que API_TIMEOUT_MS, ou seja, quase 10 minutos por padrão.
| Item | Valor padrão | Como mudar |
|---|---|---|
| Primeira tentativa, API direta da Anthropic | 180 s + 1 s por 32KB de requisição | CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS (limitado entre 10 s e 30 min) |
| Primeira tentativa, outros provedores | 300 s + 1 s por 32KB | mesma variável |
| Reenvio | API_TIMEOUT_MS menos 1 s (cerca de 10 min) | API_TIMEOUT_MS |
Atrás de um gateway via ANTHROPIC_BASE_URL | o prazo de primeiro byte não roda | não se aplica |
A variável CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS exige o Claude Code v2.1.242 ou mais novo, e a mensagem com as duas durações aparece a partir da v2.1.261. Antes da v2.1.242, o Claude Code esperava os 10 minutos inteiros antes de falhar.
O que fazer quando o erro aparece?
Reenvie a mensagem. A sua mensagem original continua na conversa, então em um prompt longo basta digitar try again em vez de colar tudo de novo. Se o erro se repete, trate como problema de rede ou de proxy.
- Digite
try againe veja se a resposta chega. - Se repetir, teste a conexão com a API fora do Claude Code (por exemplo,
curl -I https://api.anthropic.com) para separar problema de rede de problema do Claude Code. - Se há proxy ou gateway na sua rede que segura a resposta até ela terminar, aumente o tempo do reenvio:
export API_TIMEOUT_MS=900000 - Se a primeira tentativa sempre estoura e o reenvio passa, ajuste o prazo de primeiro byte:
export CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS=300000
No PowerShell, a sintaxe é $env:CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS = "300000". Defina as variáveis antes de abrir o Claude Code.
O erro aparece depois de trocar de rede ou de Wi-Fi?
Há um relato aberto exatamente nesse cenário. Na issue #99524, aberta em 04/10/2026 com o Claude Code 2.1.293 no Linux, o autor descreve que depois de trocar a máquina de rede o próximo prompt fica cerca de 3 minutos sem resposta, e que o reenvio funciona em até 3 segundos. Um Claude Code recém-aberto, na mesma rede, responde na hora.
O mesmo relato diz que, com CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS=30000, a espera cai de 180 para 30 segundos e o reenvio passa em seguida: a variável encurta a espera, mas não evita. A issue segue aberta, e a hipótese de que a conexão antiga fica pendurada vem do autor, não da Anthropic.
Um segundo usuário comentou ter o mesmo sintoma em rede estável, sem troca de Wi-Fi, VPN nem proxy, em um nó de cluster Linux com o 2.1.289, e usou CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS=60000 para depurar com claude --debug. Ou seja, a troca de rede não é a única causa possível.
Devo aumentar ou diminuir CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS?
Depende do que está acontecendo, e a documentação e os relatos apontam em direções opostas.
| Situação | Ajuste | Fonte |
|---|---|---|
| A primeira tentativa estoura e o reenvio passa, com a resposta demorando de verdade | Aumentar CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS | Documentação oficial |
| Proxy ou gateway segura a resposta até o fim | Aumentar API_TIMEOUT_MS | Documentação oficial |
| Conexão morta depois de trocar de rede | Diminuir a variável (ex.: 30000) para perder menos tempo, ou abrir uma sessão nova | Relato na issue #99524, não oficial |
Lembre do limite: o valor é ajustado para ficar entre 10 segundos e 30 minutos. Um valor baixo demais pode fazer o Claude Code abortar uma resposta que só estava demorando para começar.
Como ver o que está acontecendo por baixo?
Abra o Claude Code com claude --debug. O log mostra quando a requisição saiu e quando o prazo de primeiro byte estourou, o que separa "a rede não entrega" de "a API está lenta".
Se o que trava o seu trabalho é o limite do plano e não a rede, a Verboo Code tem tokens ilimitados.
