Si Claude Code muestra 500, varios 529 o avisa de que la respuesta puede estar incompleta, no vuelvas a enviar la tarea entera. Que se corte la respuesta no demuestra que no se hayan editado archivos, ejecutado comandos o escrito en un sistema externo. Repetir el prompt puede lanzar por segunda vez tool calls ya terminados.
Primero clasifica el error, espera a que se recupere la ruta del servicio, reanuda la misma sesión y reconcilia el estado real. Solo entonces envía continue. 500 corresponde a api_error; varios 529, a sobrecarga compartida; un aviso mid-response indica que se conservaron bloques completos, aunque el último bloque puede faltar.
La trampa principal es el 529. Claude Code lo documenta como sobrecarga, no como tu limite personal de uso, y no como algo que debas intentar comprar para salir del problema. Primero lee la linea exacta de terminal.
| Linea exacta | Tratalo como | Primer movimiento | Verificacion en la misma ruta | Pasa a detalle cuando |
|---|---|---|---|---|
500 antes de empezar la salida | error interno del servicio | Revisa Claude Status y espera un poco | Misma sesión, auth route y modelo | Persiste sin un incident publicado |
529 repetido antes de empezar la salida | sobrecarga de capacidad entre usuarios | Revisa status y espera; cambia /model solo si la tarea lo admite | Misma sesión y ruta tras el cool-down | Se repite tras revisar status y ruta |
Server error mid-response, conexión cerrada o stream detenido | parte del turno ya terminó | No repitas la tarea; lee lo conservado y comprueba el estado | Reanuda la misma sesión y envía continue tras reconciliar | No puedes demostrar si terminó un tool o una escritura externa |
429 | limite de API key o provider | Revisa ventana de espera, Console limits, model limits y active API path | Retry solo tras la ventana o path correction | Headers o Console aun muestran limits agotados |
Server is temporarily limiting requests, session limit, weekly limit | throttle o usage window de Claude Code | Cool down o revisar plan/session window | Retomar el mismo workflow tras cambiar la ventana | El mensaje nombra plan o reset window |
| El plan no coincide con tus limites | route override | Ejecuta /status y mira ANTHROPIC_API_KEY o proxy | Confirma subscription o API-key route prevista | La misma route falla con una rama limpia |
Primero la rama, no la teoria
La referencia de errores de Claude Code conecta runtime errors con codigos de Claude API. Tambien indica que Claude Code reintenta fallos transitorios antes de mostrar muchos mensajes. Cuando ves la linea, ya no estas al comienzo del incidente: estas en el punto donde toca elegir rama.
La pregunta util no es "Claude esta caido?" ni "se me acabo la cuota?". La pregunta util es a que clase documentada pertenece esa linea. 500 pide status, espera breve y un retry en la misma ruta. 529 repetido pide tratar capacidad como owner. 429 real pide revisar API key o provider limits. Un session o weekly limit pide mirar la ventana de uso. Una ruta rara pide /status antes de sacar conclusiones de plan.
La frontera de status debe llevar fecha. En la comprobación del 4 de agosto de 2026, Claude Status mostraba Claude API y Claude Code como operational, y el historial incluía incidents de modelos resueltos el 3 de agosto. Ese snapshot no determina la causa actual: status es el primer control, no el sustituto de revisar sesión y estado.
Rama 500: status, espera breve, un retry
Los Anthropic API docs asignan HTTP 500 a api_error. La referencia de Claude Code muestra API Error: 500 Internal server error como un problema del lado de infraestructura, no como una consecuencia directa de tu prompt, settings o cuenta.
La secuencia segura es pequena:
- Revisa Claude Status.
- Espera poco y repite el mismo command o message una vez.
- Mantén el mismo model y auth route durante la verificacion.
- Si no hay incident publicado y la misma ruta falla, conserva detalles y usa
/feedbacko support route.
Si tu sintoma exacto es API Error: 500 persistente, sigue con la guia de Claude Code API Error 500. Esta rama solo evita tratar 500 como limite o como 529.
Rama 529: sobrecarga, no tu limite de uso
Claude Code es directo con 529 repetido: la API esta temporalmente al limite de capacidad entre usuarios, Claude Code ya reintento antes de mostrarlo, y 529 no es tu usage limit ni cuenta contra quota.
El primer movimiento no es upgrade.
- Revisa si status muestra capacity notices.
- Espera unos minutos.
- Usa
/modelsolo si la tarea puede aceptar otro model. - Verifica la misma session y route despues del cool-down.
Si 529 sigue volviendo tras esas comprobaciones, pasa a la guia de Claude Code overloaded error. No llames rate limit al 529: 529 overloaded_error y 429 rate_limit_error llevan a acciones distintas.
Reanuda la sesión original en vez de reconstruir la tarea
La referencia actual de errores de Claude Code separa los fallos que ocurren después de empezar la respuesta. Con un server error mid-response, una conexión cerrada o un stream detenido, Claude Code conserva los bloques completos y descarta el bloque final interrumpido. El aviso existe porque reenviar puede ejecutar los mismos tools dos veces.
Si la interfaz sigue abierta, lee la respuesta conservada. Un edit, un resultado de command, un test o un paso de deployment terminado es evidencia que debes contrastar; no demuestra que todo el plan posterior se completara. Cuando vuelva el servicio, no pegues de nuevo la tarea antes de esa comprobación.
Si el proceso terminó, vuelve al directorio del proyecto donde empezó el trabajo:
bashclaude --continue claude --resume
claude --continue abre la sesión más reciente del directorio actual; claude --resume abre el selector. La documentación de sesiones indica que se restaura el historial, incluidos tool calls y resultados. Es mejor evidencia que contar de memoria lo ocurrido en una sesión nueva.
No reanudes la misma sesión en dos terminales. Los mensajes pueden intercalarse en un solo transcript. Si necesitas otra ruta, crea un fork o branch deliberado.
Reconcilia los efectos antes de enviar continue
La conversación muestra lo que se intentó; cada system of record muestra lo que ocurrió.
| Posible efecto | Evidencia que debes mirar | Decisión segura |
|---|---|---|
| Edit directo de un archivo | git status --short, git diff -- <path>, contenido | Conserva o revierte de forma consciente; no pidas el mismo edit otra vez |
| Bash cambió archivos | working tree, generados, output, timestamps | Trátalo como posiblemente terminado porque checkpoint puede no cubrirlo |
| Test, build o migration sigue activo | terminal, proceso, lock, informe, tabla de migraciones | Espera o detén de forma explícita; no lances una copia |
| Commit o branch | git status, branch actual, git log -1 --oneline | Continúa desde el estado Git observado |
| CI, deployment, ticket, API o database write | run/deployment/request ID, registro, idempotency key | Comprueba al owner externo; un stream roto no significa rechazo |
En Git, empieza con una inspección read-only:
bashgit status --short git diff --stat git diff git log -1 --oneline
Eso no demuestra el estado remoto. Si el turno pudo crear un PR, deployment, registro, mensaje o pago, mira la plataforma correspondiente. Abrir otra sesión local no cancela una operación que un servicio externo ya aceptó.
Después de reconciliar, da una instrucción limitada a la sesión recuperada:
textPrimero enumera los tool calls completados en el turno interrumpido y compáralos con el working tree actual y el estado externo que te facilite. No repitas commands ni hagas cambios externos. Propón un único paso siguiente y espera mi confirmación.
Un checkpoint es undo local, no un registro de transacciones
El checkpointing guarda snapshots de los cambios hechos por tools directos de edición y los conserva con la sesión, por lo que /rewind sigue disponible después de reanudar. Sirve cuando ya has identificado un edit incorrecto.
No cubre archivos cambiados por Bash, la mayoría de edits de subagents en background, cambios manuales concurrentes ni ciertos paths enlazados. Tampoco revierte deployments, APIs, bases de datos, mensajes o pagos. Usa Git para el historial de archivos y el audit trail de cada servicio para efectos remotos.
Identifica qué quieres deshacer antes de usar rewind. Un blind rewind seguido de un blind replay crea otro duplicado.
Ramas de limite: 429, temporary limiting, ventanas de plan
"Limite" puede significar al menos tres cosas dentro de Claude Code.
La primera es API 429 rate_limit_error real. Esta rama pertenece a API key, provider project, model-specific limits, concurrency y retry-after. Para ella, usa la guia de Claude Code rate limit.
La segunda es el mensaje Server is temporarily limiting requests (not your usage limit). Tratalo como un throttle corto: espera, revisa status si se repite y vuelve a probar la misma route. No prueba que tu plan este agotado.
La tercera es una ventana de uso real: session limit, weekly limit, Opus limit o reset time. Esa rama pertenece a /usage, reset timing y plan window. Para continuar, usa rate-limit reached o usage limits diagnosis.
Rama route override: revisa auth antes de culpar al plan
La ayuda de Claude Code sobre API key environment variables dice que ANTHROPIC_API_KEY tiene prioridad sobre una authenticated subscription, y que /status puede mostrar el auth method activo. Por eso la verificacion de route forma parte de la recuperacion.
Haz una comprobacion sin exponer secretos:
- Ejecuta
/statusdentro de Claude Code. - Comprueba si
ANTHROPIC_API_KEYesta configurado, sin pegar la key en ningun sitio. - Confirma si usas subscription auth, direct Anthropic API, Bedrock, Vertex o proxy.
- Repite la misma request en la route que querias usar.
Si corregir la route cambia el resultado, el problema real era route mismatch. Si la intended route sigue fallando con la misma rama, ya tienes evidencia mas limpia.
Guarda evidencia antes de escalar
Los errores de Anthropic API pueden incluir request_id, y las respuestas pueden incluir header request-id. Claude Code tambien ofrece /status, /model, /usage y /feedback.
Guarda un paquete corto:
- linea exacta de terminal con
500,529,429o el mensaje completo de limite; - hora y timezone;
- resultado de Claude Status en ese momento;
- active route desde
/status; - model usado y si cambiaste
/model; - resultado del same-path retry;
- request ID o feedback context, si existe.
Cuando ya clasificaste la rama, hiciste la accion minima y la misma ruta sigue fallando, deja de improvisar. Mas retry al azar destruye la evidencia.
Preguntas frecuentes
Claude Code 529 es un rate limit?
No. Claude Code documenta 529 repetido como overload. El rate limiting real de API es 429 rate_limit_error; temporary limiting y plan-window messages son ramas aparte.
Que hago primero con Claude Code API Error 500?
Revisa Claude Status, espera poco y repite el mismo command o message una vez. Si no hay incident y la misma ruta falla, guarda detalles y pasa a la guia de 500 o a /feedback.
Y si Claude Status esta verde pero Claude Code falla?
Un status verde solo descarta la rama de live incident publicado. Aun debes comprobar error exacto, active auth route, model y same-path retry.
Como se si una API key esta sobrescribiendo mi subscription?
Ejecuta /status en Claude Code y comprueba si ANTHROPIC_API_KEY esta definida en tu shell o environment. No pegues la key.
Debo mejorar el plan cuando veo 529?
No como primer movimiento. Un 529 repetido es una rama de overload. Upgrade solo encaja con mensajes explicitos de plan-limit o usage-window.
¿Puedo repetir la misma tarea después de una caída?
No si aparece el aviso de respuesta incompleta. Reanuda la misma sesión, revisa los bloques conservados y reconcilia el estado local y remoto antes de enviar un continue limitado.
¿/rewind deshace comandos shell y deployments?
No. Los checkpoints cubren edits directos compatibles, no Bash ni efectos remotos. Git, procesos, CI, deployments, APIs y bases de datos se comprueban por separado.
