Si Claude Code muestra API Error: 529, no empieces suponiendo que se te acabo tu cuota personal. En los Anthropic API docs, 529 aparece como overloaded_error. Eso cambia la primera pregunta. Antes de pensar en plan, billing o upgrade, hay que decidir si estas ante un live incident, si el status esta en verde pero la misma ruta sigue devolviendo 529, si en realidad estas viendo 429, o si Claude Code esta usando una auth route distinta de la que creias.
Primero revisa Claude Status. Despues usa /status junto con tus environment variables para confirmar que ruta esta usando Claude Code de verdad. Si el status sale en verde, eso no te autoriza a cambiar varias cosas a la vez. Lo mas util suele ser un retry corto sobre la misma ruta o un route check puntual, y mirar solo ese resultado.
Si ya revisaste status y route y la misma ruta sigue devolviendo 529, deja de tratarlo como un ajuste local que se arregla con un poco mas de prueba y error. Guarda el texto exacto del error y cualquier request_id, y escala con una historia limpia. Los error docs de Anthropic, la ayuda de Claude Code y la pagina de status se volvieron a comprobar el 11 de abril de 2026; en ese momento el status publico estaba en verde. Esa fecha no elimina la rama de sobrecarga. Solo estrecha el diagnostico.
Tablero de rutas en 30 segundos
API Error: 529 es un problema de enrutamiento antes que un tema teorico. La pregunta no es "que puede fallar en Claude Code en general", sino "en que rama estoy ahora y cual es el movimiento minimo correcto". Empieza corrigiendo el codigo. Si el log realmente dice 429, no deberias seguir este playbook de sobrecarga. Si de verdad dice 529, entonces si conviene seguir por la ruta de overload.
| Lo que ves ahora | Quien probablemente es el owner | Primer movimiento mas seguro | Que verificar en la misma ruta | Cuando escalar |
|---|---|---|---|---|
En realidad ves 429 o un usage warning, no 529 | Rama de rate limit o usage, no de sobrecarga real | Cambia al diagnostico de limits / usage y no sigas haciendo retry como si fuera 529 | Confirma el codigo exacto y si el problema real es plan o API usage | Despues de corregir la lectura, el codigo sigue siendo 529 |
| Claude Status esta en rojo o hay un incident activo | Sobrecarga o degradacion del lado de Anthropic | Deja de tocar la configuracion local y espera la recuperacion | Repite la misma ruta despues de que termine el incident | El status vuelve a verde y esa misma ruta sigue con 529 |
| El status esta en verde pero la misma ruta sigue con 529 | Sobrecarga transitoria o localizada | Haz un bounded retry corto sobre la misma ruta | Comprueba si esa ruta exacta se recupera sin cambiar otras variables | Varios retry cortos sobre la misma ruta siguen dando 529 |
| Claude Code puede estar usando API key, proxy u otra provider route | ANTHROPIC_API_KEY, proxy path o auth owner mal interpretado | Revisa /status, env variables y route config primero | Compara la misma solicitud en la intended route | Vuelves a la intended route y aun asi sigue 529 con evidencia actual |
Esa tabla es el centro del articulo. El resto solo existe para ayudarte a elegir bien la fila y no perder tiempo en la rama equivocada. La mayoria de los retrasos no vienen de falta de consejos, sino de entrar demasiado pronto en la rama incorrecta.
Que significa 529 y por que no es 429
Los API error docs de Anthropic separan los codigos con claridad: 429 es rate_limit_error y 529 es overloaded_error. Para el lector ambos pueden sentirse como "Claude Code ya no me deja seguir". A nivel operativo, no piden el mismo primer paso.
Si el codigo realmente es 529, lo mas prudente es tratarlo primero como saturacion del servicio. Eso significa que primero vienen status, route estable y retry corto; la teoria sobre cuotas y billing viene despues. Si en realidad es 429, entonces la historia ya es de limits o usage. En ese caso ayudan mas la guia de Claude Code token usage o la guia mas estrecha de Claude Code rate limit reached.
Lo importante aqui no es la sensacion de estar bloqueado, sino el codigo exacto. 529 no prueba por si solo que agotaste tu limite personal. 429 tampoco se convierte en overload solo porque el servicio parezca ocupado.
Si Claude Status muestra un incident ahora mismo
Status va primero porque puede ahorrarte una ronda entera de depuracion local inutil. Si Claude Status aparece en rojo para Claude API, Claude Code, login o componentes cercanos, el movimiento mas seguro suele ser esperar.
Como el error aparece en tu terminal, es facil sentir que el problema tiene que estar en tu entorno. Aun asi, mientras un incident siga activo, reinstall, cambios de route, re-login y rotacion de credentials suelen generar mas ruido que senal.
En esta rama hace falta guardar muy poco: el texto exacto del error, la hora y, si lo tienes, el request_id. Anthropic explica en sus docs que las error responses incluyen request_id. Cuando el incident se cierre, vuelve a probar la misma ruta. Sin esa same-path verification no sabras si el incident era toda la historia o solo una parte.
Pero esta rama no debe convertirse en la explicacion universal. Cuando el status vuelve a verde, la pregunta ya no es "esta caido Anthropic", sino "por que esta ruta exacta no se recupero".
Si el status esta en verde pero la misma ruta sigue devolviendo 529
Un status en verde no significa que debas empezar a cambiar plan, auth method o configuracion local al azar. Solo significa que la rama de live incident pierde fuerza. La rama de overload no desaparece.
Esta es la rama mas frustrante: el codigo oficial apunta a sobrecarga, el status publico parece sano y el terminal sigue fallando. Aqui sirven issues como #3558 y #3572. No prueban una causa universal, pero si muestran que una secuencia de 529 repetidos en Claude Code puede coexistir con un status que el lector percibe como saludable.
El primer movimiento correcto aqui es un bounded same-path retry. Espera un poco y repite la misma accion sobre la misma route. No cambies a la vez model, billing path, auth route y session state. Si haces todo eso junto, dejas de saber si la ruta original se recupero sola o si simplemente escapaste hacia otra rama.
El error comun aqui es aplicar demasiado pronto un arreglo grande: reinstall, upgrade, cambios masivos de config. Antes de eso hay una pregunta mas importante y mas pequena: esa misma ruta se recupero despues de una pausa corta o ya tienes un fallo lo bastante estable como para escalarlo?
Si en realidad estas en una usage route o en una API-key route
Otra razon por la que 529 se diagnostica mal es que el lector suele asumir que Claude Code esta usando la auth route que cree estar usando. La ayuda de Anthropic para usuarios Pro / Max dice que, si ANTHROPIC_API_KEY esta definido, Claude Code usa esa key en lugar de la autenticacion de la suscripcion. Esa sola linea explica bastantes diagnosicos equivocados.
Puedes creer que estas probando la route de tu suscripcion y, sin embargo, tener ANTHROPIC_API_KEY exportado en el shell. Por eso conviene fijar primero el active route con /status y el entorno. Si interpretas mal la route, tambien interpretaras mal el resto.
Lo mismo vale para proxy, wrapper o alternate provider route. El primer paso seguro no es ir de compras de provider. Primero vuelve a la intended route, limpia los supuestos viejos y compara la misma solicitud ahi. Si al quitar una API key inesperada o al volver a la auth path prevista desaparece el 529, la rama real era route mismatch. Si la intended route sigue devolviendo 529, overload sigue siendo la mejor lectura.
Esta seccion tambien debe mantenerse estrecha. Si el problema real termina siendo usage exhaustion o shared-plan drain, conviene derivar a la guia de diagnostico de Claude Code usage limits. Si el sintoma real era 500, la derivacion correcta es la guia de Claude Code API Error 500.
Como verificar el arreglo y cuando escalar
La recuperacion de 529 se vuelve mas rapida cuando dejas de preguntar "cambio algo?" y empiezas a preguntar "esta ruta concreta se recupero despues de este movimiento concreto?". Por eso la same-path verification importa tanto. A la vez te protege de blind retries, cambios involuntarios de rama y support reports debiles.
Antes de escalar, recoge al menos esto desde la misma failing path:
- el texto exacto del error, incluyendo
529ooverloaded_error - cualquier
request_idorequest-id - que mostraba Claude Status en ese momento
- si fallo tras un bounded retry, si fallo aun despues de volver a la intended route, o si la route ya estaba mal desde el inicio
- reproduction steps minimos o el
/statusrelevante
La lista es corta a proposito. Support necesita una historia reproducible y limpia, no un diario larguisimo de pruebas. "Status en verde, misma ruta, retry corto, sigue 529, request_id adjunto" es un buen reporte. "Cambie muchas cosas y sigue raro" es un reporte debil.
La frontera para escalar tambien puede ser corta: status checked, route checked, bounded retry done, y la misma ruta sigue con 529. En ese punto vale mas un clean handoff que otra improvisacion.
Frequently Asked Questions
API Error: 529 de Claude Code y 429 rate_limit_error son lo mismo?
No. Anthropic los define como error types distintos en sus API error docs. 429 pertenece a rate limits; 529 pertenece a overload.
Por que sigo viendo 529 si Claude Status esta en verde?
Porque un status publico en verde solo debilita la rama de live incident. No garantiza que tu Claude Code path concreto ya se haya recuperado. El siguiente paso util es same-path retry o route check.
Si veo 529, deberia cambiar de plan enseguida?
No como primer movimiento. 529 primero significa overload. Antes conviene confirmar el codigo y la route activa.
Que debo mirar si yo creia estar en la route de suscripcion?
Comprueba si ANTHROPIC_API_KEY esta definido y usa /status con tus environment variables para fijar la route activa. Anthropic indica que esa key anula la auth de suscripcion.
Que deberia enviar a support?
El texto exacto del error, cualquier request_id, el estado de Status, la ruta que probaste y los reproduction steps minimos. El objetivo no es contar toda la historia, sino quitar ambiguedad.
Working Rule
API Error: 529 en Claude Code es mas seguro si se trata como un problema de overload-first recovery y no como una sospecha inmediata sobre tu limite personal. Primero Status, luego mantener la route estable, hacer un bounded move, verificar sobre esa misma ruta y, si sigue fallando, escalar con evidencia.