Saltar al contenido
Herramientas de IA

Guía de Claude AI: Consejos y Tutoriales Prácticos

Guía completa de Claude AI de Anthropic. Aprende a usar los modos Chat, Cowork y Code con consejos prácticos.

84 artículos

Ordena los artículos para encontrar lo que necesitas

The model returned no content: causas y solución, por qué el mensaje cambia de sentido según quién lo escribió

The model returned no content: causas y solución, por qué el mensaje cambia de sentido según quién lo escribió

Estás usando Claude, algo te frena y buscas el mensaje tal cual, pero no aparece nada: hay cadenas que se comportan así. The model returned no content because the response was blocked by content filtering, The response was blocked by the provider's content filter, Streaming response ended before any complete data was received, Could not locate the Claude CLI on PATH y Connection to Claude's response was lost. Claude may still be working son cinco ejemplos. Lo que tienen en común es que salieron mientras usabas Claude y, aun así, no aparecen en la documentación de Claude por más que la busques, o eso parece. El motivo es simple: el mensaje que tienes en pantalla no lo escribió necesariamente el programa que tú crees. Este artículo no explica desde cero cada causa concreta, sino que sirve de puerta de entrada para identificar quién escribió ese mensaje y derivarte al artículo correcto. Primero separa en cuatro las capas capaces de escribirlo: el backend que sirve el modelo, el propio Claude Code, el programa que lanza la CLI, extensión de IDE o envoltorio, y los clientes de terceros. Al cotejar de verdad, dos de los cinco figuraban como entradas de la referencia oficial de errores de Claude Code. La definición oficial de Streaming response ended es que las cabeceras volvieron pero el cuerpo no traía ningún mensaje de la API de Claude, así que no se trata de un corte a mitad. Could not locate the Claude CLI on PATH está colocado por la documentación oficial en un capítulo aparte, Wrapper and IDE errors, lo que imprime el programa que lanza la CLI. En cambio, los dos del content filter son vocabulario de terceros, y la incidencia 35736 de OpenCode reporta que tres fallos distintos, el 404 de Vertex, el socket cortado y el rechazo de verdad, se muestran todos con el mismo blocked by content filter. El mensaje solo es correcto en uno de los tres. La documentación oficial de GitHub también deja escrito que, al usar Claude, la entrada y la salida pasan por los filtros de contenido de GitHub Copilot, de modo que usar Claude no implica que quien te para sea el filtro de Anthropic. Del quinto no encontré la cadena ni en la referencia oficial de errores ni en la documentación de Remote Control, así que no pude identificar su origen, no doy ningún nombre y dejo cuatro pasos para que lo averigües en tu propio entorno. Lo confirmado y lo no confirmado van separados con etiquetas.

API Error: Connection lost mid-response: causas y solución, el error de conexión que v2.1.227 renombró

API Error: Connection lost mid-response: causas y solución, el error de conexión que v2.1.227 renombró

Claude Code se detiene a media respuesta con «API Error: Connection lost mid-response. The response above may be incomplete.» y, al buscar ese texto tal cual, apenas aparece información. El motivo es que se trata de un nombre reciente: la referencia oficial de errores deja escrito que antes de v2.1.227 ese mismo mensaje se mostraba como Connection closed mid-response, y que en el mismo cambio Response stalled mid-stream pasó a ser The response stopped arriving y Connection closed while thinking, before producing a response pasó a ser Connection lost before a response was produced. Es decir, el fenómeno existía desde antes y lo único que cambió fue la palabra. Este artículo parte de ese renombrado y se apoya solo en la documentación oficial y en las incidencias públicas. Primero, la definición oficial de los cuatro mensajes de corte a media respuesta, Server error, Connection lost, Your computer went to sleep y The response stopped arriving, y el motivo por el que la salida ya emitida se conserva a propósito: reenviar la petición podría ejecutar dos veces la misma llamada de herramienta. De ahí que el procedimiento de recuperación sea responder continue. Después, por qué no se reintenta de forma automática, explicado con la bifurcación de Automatic retries de la documentación oficial: un corte antes de completar nada se reenvía hasta diez veces con retroceso exponencial, tras el razonamiento y antes de la salida se reenvía hasta dos veces y termina con Connection lost before a response was produced, y tras completar un bloque ya no se reenvía y aparece esta nota. Siguen las tres capas donde puede producirse el corte, el equipo y la línea, el camino con proxy y pasarelas, y el servidor con la reutilización de conexiones, más la relectura del material mTLS rotado desde v2.1.232, una lista de comprobación de nueve pasos, los valores por defecto de los cuatro temporizadores de vigilancia del flujo, 180 segundos para el primer byte, 300 para los eventos, 180 para los bytes y cinco minutos de inactividad del cuerpo, y las variables CLAUDE_CODE_MAX_RETRIES, CLAUDE_CODE_RETRY_WATCHDOG y API_TIMEOUT_MS, entre otras. También una tabla para distinguir los ocho mensajes parecidos y dos informes reales en los que el HTTPS puro pasa sin problemas y solo la CLI cae con ECONNRESET, el #86473 y el #85979. Se cierra separando por nivel de certeza lo que sí está documentado, síntoma, significado y recuperación, de lo que no: no hay explicación oficial de la causa y el renombrado no consta en el CHANGELOG. Y una advertencia previa: las versiones anteriores a v2.1.222 emitían este aviso incluso con la respuesta completa, así que conviene comprobar claude --version antes de diagnosticar nada.

Los 3 cambios incompatibles de Claude Fable 5.1: qué arreglar antes de migrar y qué significa la caché a la cuarta parte

Los 3 cambios incompatibles de Claude Fable 5.1: qué arreglar antes de migrar y qué significa la caché a la cuarta parte

Migrar a Claude Fable 5.1 no se acaba cambiando el ID del modelo. La documentación oficial deja escrito que tres de los cambios son incompatibles y, además, en dos de ellos el sitio donde salta el error queda lejos de la causa. 1) Forzar la llamada de herramienta devuelve 400: los valores any y tool de tool_choice responden con invalid_request_error. En un modelo que piensa siempre, forzarla se salta ese pensamiento y la calidad de los argumentos empeora. 2) El bloque de pensamiento queda ligado al modelo: las conversaciones que pasan de una generación anterior a Fable 5.1 conservan el razonamiento, pero en sentido contrario se pierde. Y por defecto los bloques ilegibles se descartan antes de llegar al modelo, no se cuentan en input_tokens y tampoco aparecen en la factura. En los montajes que cambian de modelo con enrutadores o mecanismos de respaldo, parece que todo funciona y lo único que se cae es el razonamiento. Para enterarte hace falta la cabecera beta thinking-binding-controls-2026-08-01. 3) Editar turnos pasados invalida todos los bloques de pensamiento posteriores: entran ahí reconstruir el prompt de system o el array tools, y la costumbre de insertar un recordatorio y luego borrarlo. Esta comprobación es obligatoria en las cuentas creadas a partir del 31 de agosto de 2026, así que puede darse la contradicción de que falle en un entorno de pruebas recién creado y no falle en producción. Conviene evitar también el malentendido sobre dónde encaja: Fable 5.1 no es un relevo del buque insignia, y la documentación oficial deja escrito que para la mayoría de los usos hay que empezar por Opus 5. No hay subida de precio; lo único que ha cambiado es la lectura de caché, que baja de 0.1 a 0.025 veces la entrada base. El efecto depende de cuántas veces se relea el mismo preámbulo, y la documentación oficial habla de alrededor de un 25% menos en cargas típicas y de hasta cerca de un 45% menos en trabajo marcadamente agéntico. Además, siete comportamientos cambian sin tocar el código (bajan las llamadas de herramienta en paralelo, habla menos de su progreso, con effort low tiende a responder de memoria, la prosa se vuelve más densa, formatea menos, no marca las citas al resumir y reescribe el texto entero aunque el arreglo sea mínimo). Se recogen también las cinco funciones añadidas y los cinco pasos de migración, todo a partir de la documentación oficial de Anthropic.

Claude Code Remote Control: maneja tu propio ordenador desde el móvil

Claude Code Remote Control: maneja tu propio ordenador desde el móvil

Remote Control conecta la app móvil de Claude o claude.ai/code con una sesión de Claude Code que ya se está ejecutando en tu propia máquina, y el punto que casi todas las explicaciones pasan por alto es que nada se traslada a la nube: la ejecución de código y el acceso a los archivos siguen siendo locales todo el tiempo, y el móvil es solo una ventana a esa sesión. Este artículo repasa qué te da ese diseño y qué te cuesta. Tu sistema de archivos local, los servidores MCP, las herramientas y la configuración del proyecto siguen disponibles (escribir @ autocompleta rutas del proyecto local), la conversación y el progreso de los subagentes se mantienen sincronizados entre terminal, navegador y móvil, y un portátil que se suspende o una conexión que se cae son recuperables porque Claude Code se reconecta y entrega las actualizaciones encoladas al volver. Los requisitos son más estrictos de lo que parecen: Pro, Max, Team o Enterprise (las claves de API no valen), inicio de sesión en claude.ai en lugar de un setup-token, conexión directa a api.anthropic.com y ninguna de las cuatro variables de entorno que desactivan la telemetría, que es la razón por la que a quien define DO_NOT_TRACK por privacidad le dicen que la función no está activada en su cuenta. Se cubren las tres puertas de entrada (/remote-control para arrastrar la conversación actual, claude --remote-control y el modo servidor con sus opciones --spawn, --capacity 32 y --continue), junto con la separación entre los comandos de barra que funcionan en remoto y los que son solo locales, como /resume, la caducidad de cinco minutos de los diálogos que no se aplica a las peticiones de permiso y los dos interruptores de notificaciones push. En seguridad el artículo es deliberado: nunca se abre un puerto de entrada, así que la superficie de ataque de red casi desaparece y el riesgo se muda a la cuenta, el código QR es un atajo y no una autenticación, y la puerta por defecto es exactamente una cuenta con la sesión iniciada, lo que convierte la passkey en el paso de mayor valor. La retención de las transcripciones (5 años o 30 días), qué hacer si pierdes el móvil, Trusted Devices con su ventana de 18 horas, el tiempo de espera de diez minutos del modo servidor, las cuatro horas para recuperar sesiones, la obligación de usar tmux en máquinas remotas, una tabla de diagnóstico guiada por los mensajes de error reales y una comparación con Dispatch completan el recorrido.

Pensamiento adaptativo vs extendido en Claude: qué cambió

Pensamiento adaptativo vs extendido en Claude: qué cambió

La forma de pensar de Claude atravesó un relevo generacional. El antiguo pensamiento extendido te hacía especificar un presupuesto de tokens en cada petición — thinking: {"type": "enabled", "budget_tokens": N} —, pero el presupuesto adecuado difiere según la tarea y no puede adivinarse de antemano, y cambiarlo invalida la caché de prompts. El pensamiento adaptativo actual es una sola línea, type: "adaptive": si pensar y con qué profundidad es decisión del propio modelo según lo difícil que parezca la petición. La migración fue escalonada: budget_tokens quedó obsoleto en Opus 4.6 / Sonnet 4.6 y se rechaza con un error 400 desde Opus 4.7 en adelante. Este artículo condensa las reglas por modelo en una tabla: Fable 5 piensa siempre (no puede desactivarse), Opus 5 y Sonnet 5 traen el pensamiento activado por defecto (en Opus 5 desactivarlo solo se permite con effort high o inferior), Opus 4.8 / 4.7 requieren un ajuste adaptive explícito, y los modelos antiguos como Sonnet 4.5 / Haiku 4.5 siguen usando budget_tokens como su único modo. El control de la profundidad pasó a output_config: {"effort": ...} con cinco niveles (high por defecto), y cambiar effort rompe la caché igual que antes lo hacía cambiar el presupuesto. La visibilidad la gobierna display: el valor por defecto de la nueva generación es "omitted" (bloques de pensamiento vacíos), y se facturan todos los tokens de pensamiento en cualquier caso — mídelo con usage.output_tokens_details.thinking_tokens; ningún ajuste devuelve la cadena de pensamiento en bruto. Desactivar el pensamiento en Opus 5 conlleva efectos secundarios documentados (llamadas a herramientas escritas como texto plano, fugas de etiquetas internas), así que bajar effort es la palanca de coste más segura. El pensamiento intercalado — razonar entre llamadas a herramientas — es automático con adaptive, sin necesidad de la vieja cabecera beta. Y cuando necesitas velocidad, fast mode ejecuta el mismo Opus a unas 2.5x por el doble de precio (solo Opus 5/4.8, se alterna con /fast en Claude Code). Todo se apoya en la documentación oficial de Anthropic: Thinking, Extended thinking y Fast mode.

GPU process gone: por qué se cuelga Claude Desktop y arrastra todas tus sesiones de Claude Code

GPU process gone: por qué se cuelga Claude Desktop y arrastra todas tus sesiones de Claude Code

Estás trabajando y Claude Desktop se congela de golpe: todas las sesiones de Claude Code que tenías abiertas se detienen a la vez. Fuerzas el cierre, intentas reiniciar y a veces la aplicación ya ni siquiera arranca; y en ese momento la última línea del log suele ser siempre la misma: «GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }». Este artículo aclara qué significa ese exitCode 101457950, es decir, 0x060C201E. Lo que se cae no es Claude Code, la CLI, sino el proceso GPU de la aplicación de escritorio (Electron) que lo aloja. Comprobarlo solo exige mirar el final de main.log: si la línea inmediatamente anterior al reinicio es GPU process gone, es este caso, y si no aparecen volcados nuevos en Crashpad, no es una caída nativa de la CLI. Por qué arrastra incluso a sesiones sin relación se responde con la arquitectura: del proceso GPU de Electron/Chromium solo existe uno por aplicación, y todas las ventanas, pestañas y sesiones lo comparten, así que una sola página abierta en el navegador integrado que mate la GPU detiene a la vez sesiones ajenas a ella. Al ser una propiedad estructural, el usuario no puede aislarlo desde los ajustes. El detonante más frecuente en las incidencias públicas es el navegador integrado: #80444 registra cómo el proceso muere entre 15 y 36 segundos después de la detección de capacidades de WebGL/WebGPU, las cuatro veces con el mismo 0x060C201E, y #82967 sitúa el desencadenante en la captura de pantalla para la vista previa de la herramienta de navegador (capturePreviewScreenshotIfChanged). Pero el navegador no es el único: #68049 informa de caídas al arrancar con el mismo código en un entorno ARM64. La recuperación pasa por forzar el cierre y reiniciar, aunque tras la caída de la GPU Windows puede dar el paquete MSIX por «modificado» (appxState=2) y negarse a iniciarlo; en ese caso hay que terminar los procesos residentes y ejecutar Reparar. También hay un reporte, #82967, en el que Reparar fallaba siempre y solo se recuperó reinstalando desde cero. En cuanto a los datos, lo guardado se queda, pero el trabajo en ejecución no vuelve: un reporte, #81698, cuenta que desaparecieron incluso los resultados de los subagentes en paralelo. Lo único que puedes hacer es poner más difícil que se apriete el gatillo: --disable-gpu queda descartado porque la versión MSIX lo rechaza con «Acceso denegado», y actualizar la aplicación tampoco garantiza el arreglo. Anthropic no ha publicado sobre este síntoma ni una explicación oficial de la causa ni un aviso de corrección.

El Dispatch de Claude — cómo tu móvil pone a trabajar tu propio ordenador y hasta qué punto es seguro

El Dispatch de Claude — cómo tu móvil pone a trabajar tu propio ordenador y hasta qué punto es seguro

Dispatch es la función con la que mandas una instrucción desde el móvil y Claude ejecuta el trabajo en tu propio ordenador (en beta, planes Pro y Max). No corre en la nube: se mueve tu máquina real, y de ese único hecho salen a la vez todo su valor y todo su peligro. La ayuda oficial dice que puedes escribir a Claude desde el móvil y que trabaje en tu ordenador de escritorio, usando los mismos connectors, plugins y acceso a archivos que ya tengas configurados en Cowork, dentro de lo que Anthropic plantea como una única conversación continua a la que se llega desde cualquiera de los dos dispositivos. Para que funcione, el ordenador tiene que estar despierto y con la aplicación de escritorio abierta, y el computer use solo está disponible en macOS y Windows, nunca en Linux. Mecánicamente trabaja bajando por tres niveles de prioridad: un connector si lo hay, la navegación por el navegador si no lo hay, y la interacción directa con la pantalla como último recurso, tomando capturas por el camino para entender lo que se ve. La valoración empieza justo ahí. Los puntos donde se detiene están diseñados: el computer use viene desactivado por defecto y se activa en Ajustes, General; el permiso se pide para cada aplicación nueva; borrar un archivo de forma permanente exige permiso explícito; y las plataformas de inversión y trading y las aplicaciones de criptomonedas quedan vetadas por defecto. Pero también hay puntos donde no se detiene. Las acciones concretas dentro de una aplicación ya aprobada no se te confirman, y la redacción oficial es que Claude hace clic, escribe y navega por tu pantalla directamente, sin las comprobaciones de permisos que sí filtran las demás herramientas de Cowork. La documentación añade que no hay ningún sandbox entre Claude y lo que hay en tu pantalla, y que las acciones tomadas en una aplicación pueden afectar a otras. El riesgo mayor es la prompt injection, que Anthropic describe con sus propias palabras: el contenido web es un vector principal de ataques de prompt injection, y una instrucción manipulada, un comando inesperado o un enlace de phishing abierto en tu navegador podrían encadenarse hasta acciones difíciles o imposibles de deshacer. Anthropic afirma que escanea las activaciones del modelo para detectar ese comportamiento, pero eso baja la probabilidad sin quitarte a ti la obligación de trazar una línea, y la guía sigue diciendo que pases a la aprobación manual siempre que una tarea toque archivos, cuentas o sitios sensibles. Anthropic nombra el límite sin rodeos: no des permiso de computer use a aplicaciones sensibles, como las de banca, sanidad o administración pública, y evita las cuentas financieras, los documentos legales, la información médica y los datos personales. El artículo cubre también el lado del móvil. Lo que se escapa si lo pierdes no son los datos guardados en el teléfono, sino la capacidad de dar órdenes a tu ordenador, más el contenido de la conversación que sigue viva; y la ayuda oficial de Dispatch no documenta cómo desemparejar un dispositivo ni qué hacer si lo pierdes, así que los remedios vienen del lado de la cuenta: cerrar esa sesión concreta en Ajustes, Cuenta, Sesiones activas; cerrar todas las sesiones desde claude.ai, algo que no está disponible en las aplicaciones móviles y que por tanto exige un navegador web; o simplemente cortar por el lado del ordenador cerrando la aplicación de escritorio o dejando que la máquina se suspenda, que en realidad es lo más rápido porque Dispatch necesita el ordenador despierto y la aplicación abierta. Cierra separando Dispatch y computer use como dos interruptores distintos, distinguiendo ambos del agent view de Claude Code (al que la documentación oficial también llama dispatch) y trazando una línea práctica: empieza por el trabajo que puedes deshacer.

El agent view de Claude Code — cómo se ejecutan las sesiones en paralelo y por dónde se escapa el aislamiento

El agent view de Claude Code — cómo se ejecutan las sesiones en paralelo y por dónde se escapa el aislamiento

El agent view de Claude Code, que se abre con claude agents, es la función para lanzar sesiones independientes en segundo plano una tras otra y gestionarlas todas desde una sola pantalla. La documentación oficial llama dispatch a la operación que realizas ahí, y ese nombre choca con la función homónima de la aplicación de escritorio, así que lo primero es distinguirlas. Los documentos describen el agent view como la función que permite despachar y gestionar muchas sesiones de Claude Code desde una única pantalla, y se trata de una research preview que exige la v2.1.139 o posterior. Este artículo se ciñe a la mecánica y al modelo de seguridad. La primera sorpresa es que cada prompt que escribes en el cuadro de entrada arranca su propia sesión nueva: escribe un segundo y tendrás una segunda sesión al lado de la primera, no una instrucción añadida a la anterior. Las instrucciones posteriores pasan por el peek panel, que se abre con la barra espaciadora y muestra la última salida o la pregunta que la sesión está esperando, no la transcripción entera. El corazón del modelo de seguridad es el aislamiento por worktree. Antes de editar ningún archivo, una sesión en segundo plano se traslada a un git worktree aislado bajo .claude/worktrees/, de modo que las sesiones paralelas leen el mismo checkout pero cada una escribe en el suyo: lecturas compartidas, escrituras separadas. Todo lo que llegaría al checkout principal queda cortado por tres comprobaciones: las ediciones de archivos con Edit, Write y NotebookEdit; los directorios de trabajo de comandos que resuelven al checkout principal o que no se pueden verificar como externos a él; y los intentos de redirigir git con git -C, --git-dir, GIT_DIR, GIT_WORK_TREE o un cd colocado antes de la llamada a git. La decisión se toma a propósito del lado seguro, rechazando lo que no puede verificar, y la misma protección la heredan todos los subagents que la sesión genere. Aun así no es un muro a nivel de sistema operativo: los archivos de fuera del repositorio y la red quedan fuera de alcance, y los comandos de PowerShell solo reciben la comprobación del directorio de trabajo. Los permisos tampoco se eligen en el momento del dispatch: se heredan del defaultMode de ese directorio, o del permissionMode del frontmatter de un subagent despachado, lo que significa que cuanto más laxa sea tu configuración habitual, más sesiones desatendidas con permisos laxos creas de golpe. Después hay tres cosas que se escapan del aislamiento. Elegir "Sí, no volver a preguntar" guarda la regla en el .claude/settings.local.json del checkout principal, así que se aplica en el checkout principal y en todos los demás worktrees, y sobrevive a la eliminación del worktree donde se concedió. Borrar una sesión en el agent view borra con ella el worktree que creó Claude, de modo que el trabajo sin commit desaparece, y Ctrl+X detiene en la primera pulsación y borra en la segunda. Y .worktreeinclude copia en cada worktree nuevo los archivos ignorados por git, como .env, multiplicando tus credenciales por el número de sesiones que despachas. Encima, la cuota se consume en proporción al paralelismo (diez agentes la gastan unas diez veces más rápido) y las sesiones se ejecutan en local: sobreviven a la suspensión, pero se detienen al apagar la máquina. El artículo cierra situando el agent view entre las cuatro formas oficiales de paralelizar, junto a los subagents, los agent teams y los flujos de trabajo dinámicos, y da una rutina concreta para antes, durante y después de un dispatch.

¿Hay que ejecutar /compact periódicamente en Claude Code? Cuándo pulsarlo según la especificación oficial

¿Hay que ejecutar /compact periódicamente en Claude Code? Cuándo pulsarlo según la especificación oficial

Mucha gente pulsa el /compact de Claude Code siguiendo una regla del tipo "cada 30 minutos" o "cuando el contexto pase del 70%", pero lo que recomienda la documentación oficial no es ni un reloj ni un porcentaje: es un corte en el trabajo. Ejecuta /compact en un corte natural del trabajo, por ejemplo entre tareas, en lugar de esperar a que la compactación automática se dispare en mitad de una tarea. Este artículo toma como fuente primaria la documentación de Claude Code a fecha de 8 de agosto de 2026 (última versión v2.1.226) y resuelve la cuestión de la compactación manual desde la especificación. Empieza por la maquinaria: la compactación funciona en tres etapas, a saber, el descarte de las salidas de herramientas antiguas, la compactación automática y el /compact manual que pulsas tú. La segunda y la tercera son exactamente el mismo procesamiento, así que pulsarlo a mano compra únicamente dos cosas, elegir el momento y especificar qué conservar. Pulsarlo más a menudo no ahorra contexto adicional. Después llega una tabla de qué sobrevive. El CLAUDE.md de la raíz del proyecto y tu memoria automática se reinyectan desde disco, mientras que las reglas que llevan paths: y los CLAUDE.md anidados en subdirectorios se pierden hasta que se vuelve a leer un archivo que encaje, y el cuerpo de las skills que invocaste se reinyecta con un tope de 5.000 tokens por skill y 25.000 en total, descartando primero las más antiguas. Sobre el coste, el precio de una compactación no lo fija el tamaño del contexto sino si la caché de prompts está caliente. Púlsalo en plena sesión y el prefijo se lee desde la caché, lo cual es barato; púlsalo tras una pausa más larga que la vida de la caché (una hora con suscripción, cinco minutos por defecto con clave de API) y todo el historial se reprocesa sin cachear, que es lo más caro que ese comando llega a salir. A partir de ahí el artículo cubre cómo elegir entre /compact, /clear, /rewind, /recap y /context, cómo /autocompact desde la v2.1.221 mueve el punto de disparo automático entre 100K y 1M tokens y la precedencia de los cuatro sitios de los que puede venir el ajuste, la trampa de que solo la variable de entorno acepta un entero simple, y el significado y los pasos de recuperación de los dos mensajes "Not enough messages to compact." y "Autocompact is thrashing: the context refilled to the limit...".

No se puede abrir esta aplicación: Claude Desktop no arranca en Windows y cómo repararlo sin perder las sesiones

No se puede abrir esta aplicación: Claude Desktop no arranca en Windows y cómo repararlo sin perder las sesiones

Intentas abrir Claude Desktop en Windows y lo que aparece es un cuadro de diálogo titulado «No se puede abrir esta aplicación» que te pide ir a las opciones avanzadas de Claude y elegir Reparar; y hacer exactamente lo que dice funciona. Sin desinstalar nada y sin recurrir a Restablecer, que sí tira tus datos a la basura. Hay, eso sí, un paso intermedio en el que la gente se atasca de verdad, y es el centro de este artículo. Al pulsar Reparar puedes encontrarte con un aviso de que la aplicación sigue en ejecución, aunque no tengas ninguna ventana de Claude abierta por ninguna parte. La causa es que Claude Desktop se queda residente en la bandeja del sistema después de que cierres su ventana, y mientras ese proceso mantiene abiertos los archivos del paquete la reparación no puede completarse. La solución es sencilla: cierra los procesos de forma explícita y después pulsa Reparar. Y ese hecho apunta a la causa del fallo en sí, porque el mismo proceso rompió la actualización y luego bloqueó la reparación. El artículo responde además a lo que casi todo el mundo pregunta primero: ¿se borran tus sesiones? La respuesta se divide en tres. Tu historial de conversaciones de claude.ai está en los servidores de Anthropic y no se toca. Las sesiones de Claude Code viven en %USERPROFILE%\.claude\projects\, fuera del paquete de la aplicación, así que sobreviven a una reparación, a un restablecimiento e incluso a una desinstalación (un equipo real acumulaba 2.977 archivos, unos 3,0GB, repartidos en 52 proyectos). Lo único en riesgo son los ajustes del lado de la aplicación en %APPDATA%\Claude, y Reparar conserva incluso eso: Windows deja escrita la diferencia en la propia pantalla, donde junto a Reparar advierte de que los datos de la aplicación no se verán afectados y junto a Restablecer, de que se eliminarán. A partir de ahí cubre la comprobación de estado en PowerShell de solo lectura, una rutina de copia de seguridad, una escalada por pasos cuando la aplicación sigue sin abrirse (revisar que vmcompute y hns estén en marcha, reinstalar con -PreserveApplicationData), la causa deducida de un MSIX registrado a medias junto a las incidencias de GitHub (#55465, donde la instalación fue correcta pero no se creó ningún punto de entrada, más #50285 y #48437, todas cerradas como closed as not planned y sin corrección oficial), cómo reducir las probabilidades de que se repita y una comparación con la versión del instalador antiguo, donde la última entrega MSIX y un equipo con el formato antiguo medían ambos 1.24012.9.

API Error: Connection closed mid-response en Claude Code: causas y solución

API Error: Connection closed mid-response en Claude Code: causas y solución

Claude Code se detiene a mitad de una respuesta con «API Error: Connection closed mid-response. The response above may be incomplete.» No es un problema de prompting: la conexión que transportaba la respuesta en streaming se cerró mientras la respuesta todavía llegaba. Este artículo se apoya únicamente en la referencia de errores oficial, el changelog oficial y reportes respaldados por capturas de paquetes. Empieza por las definiciones oficiales: Connection closed significa que el enlace se cortó, Response stalled que se quedó en silencio y Server error que llegó un 5xx a mitad de stream; y explica por qué la salida parcial se conserva deliberadamente (reenviar podría ejecutar dos veces las mismas llamadas a herramientas) y que el paso de recuperación documentado es responder continue. Después separa las tres capas donde puede originarse el cierre (tu equipo y la suspensión, un corte por inactividad en un proxy o VPN, o un cierre iniciado por el servidor) y presenta las mediciones publicadas por quien reportó el issue #67766: los diez incidentes fueron cierres limpios del servidor, el error salió entre 3 y 105 ms después del FIN, ya se habían entregado entre 7 y 20 KB de la respuesta, el cuerpo de la petición pesaba entre 1 y 2,5 MB, una conexión nueva funcionó en unos 20 ms y aparecieron 200 errores en 171 incidentes a lo largo de 23 días de transcripciones, 87 de ellos a menos de cinco segundos de la llamada anterior. El núcleo práctico es una cronología de entradas reales del changelog —2.1.179 conserva lo parcial, 2.1.185 pasa el aviso de estancamiento de 10 a 20 segundos, 2.1.198 reintenta los cortes transitorios con backoff, 2.1.199 conserva lo parcial ante errores de servidor a mitad de stream y 2.1.214 desactiva el pool keep-alive tras un error de conexión obsoleta— contrastada con las versiones de los reportes (2.1.173, 2.1.181 y 2.1.183), todas anteriores a la 2.1.198. Cierra con las condiciones que suben la probabilidad, una lista de comprobación de ocho pasos, seis pautas para desarrolladores, cómo distinguirlo de Unable to connect y Prompt is too long, y una separación clara entre lo confirmado oficialmente y lo que no.

Claude Opus 5: en qué se diferencia de Opus 4.8 y Fable 5

Claude Opus 5: en qué se diferencia de Opus 4.8 y Fable 5

Anthropic lanzó Claude Opus 5 el 24 de julio de 2026 y su propia documentación lo describe como un salto cualitativo, no como una mejora incremental sobre Opus 4.8. Aun así, el precio no se mueve: $5 de entrada y $25 de salida por millón de tokens, exactamente la mitad que el buque insignia Fable 5 ($10 / $50). Este artículo contrasta el anuncio oficial y la documentación con varias informaciones de prensa y repasa las especificaciones principales (claude-opus-5, una ventana de 1M de tokens que es a la vez el valor por defecto y el máximo, 128K de salida máxima y un corte de conocimiento en mayo de 2026), el precio incluidas las tarifas de caché y el modo rápido (unas 2.5 veces la velocidad al doble de precio, solo en la Claude API), los benchmarks (Anthropic afirma en su propio texto que Frontier-Bench es más del doble que Opus 4.8, que CursorBench 3.2 se queda a menos de un 0.5% de Fable 5, que ARC-AGI 3 triplica al segundo clasificado y que OSWorld 2.0 supera a Fable 5 a alrededor de un tercio del coste; entre las cifras leídas de las gráficas por la prensa están Frontier-Bench 43.3%, ARC-AGI-3 30.2%, GDPval-AA 1,861 y OSWorld 70.6%) y también los terrenos donde sigue perdiendo (68.8% frente al 72.7% de GPT-5.6 Sol en DeepSWE v1.1, la seguridad ofensiva y la investigación biológica de largo recorrido donde lidera Mythos 5, y escenarios en los que el effort max puntúa por debajo de niveles inferiores). Después aborda los dos cambios de la API que rompen compatibilidad (el thinking viene activo por defecto, así que los presupuestos ajustados de max_tokens acaban truncados, y desactivarlo solo se permite con effort high o inferior, porque xhigh o max devuelve un error 400), cómo elegir entre los cinco niveles de effort, novedades como el cambio de herramientas a mitad de conversación, el mínimo de caché de 512 tokens y el modo de reserva por defecto, y el giro de personalidad hacia respuestas más largas, más narración, más delegación y autoverificación no solicitada, con la regla de oro de que migrar consiste en quitar texto del prompt y no en añadirlo. Cierra con quién debería migrar ya y una lista de seis pasos para hacerlo.