Desarrollo con IA y Programación: Crea Apps con IA

Quieres que un modelo inteligente se encargue solo de planificar y que la implementación la haga un modelo más rápido y barato. El opusplan de Claude Code es una forma de indicar el modelo que lo hace de forma automática. Usa Opus mientras estás en el modo de planificación y Sonnet el resto del tiempo, y se activa con /model opusplan o con model en settings.json. Eso sí, no aparece en la lista de /model y, como el modelo cambia cada vez que entras en el modo de planificación o sales de él, cada cambio vuelve a leer toda la conversación sin caché. A partir de la documentación oficial a 15 de septiembre de 2026, el registro de cambios y los issues de GitHub, este artículo explica cómo configurarlo (incluido fijar las versiones y el contexto de 1M), el paso del modo de planificación a la aprobación y a la implementación, cómo se retiró del selector en la v2.0.0 y qué explicó un empleado de Anthropic, una estimación del coste de caché que genera cada cambio y cómo contenerlo, en qué se diferencia de la herramienta advisor y de los subagentes, y para qué tipo de trabajo encaja y para cuál no.

¿Se puede dejar la sesión principal de Claude Code en Opus 5 y encargar solo trabajos como traducir o revisar en gran cantidad a subagentes con Sonnet o Haiku? Sí. El modelo de un subagente se decide en este orden: el modelo indicado al invocarlo, model en el archivo de definición, la variable de entorno CLAUDE_CODE_SUBAGENT_MODEL y, por último, el modelo de la sesión principal; el esfuerzo (effort) también se puede fijar para cada subagente. A partir de la documentación oficial a 15 de septiembre de 2026, este artículo explica cómo cambia ese orden según la versión, CLAUDE_CODE_SUBAGENT_MODEL_FORCE para fijar todos los subagentes en un único modelo, a qué modelo apuntan los alias según el proveedor y que, desde la v2.1.198, el Explore integrado hereda el modelo de la sesión principal. Después muestra lo que pasó al lanzar subagentes con otros modelos y comprobarlo en los registros de conversación: se ejecutaron con el modelo indicado, cada uno lee decenas de miles de tokens solo por arrancar, la caché de los subagentes caduca a los 5 minutos incluso con suscripción, y la misma traducción encargada a Opus 5, Sonnet 5 y Haiku 4.5, dos veces a cada uno, difirió en tiempo, coste y calidad. Por último, resume cómo afecta al coste y a los límites de uso, y qué criterios seguir para decidir qué trabajo bajar a un modelo más barato.

Si tienes varias sesiones en paralelo, acabas preguntándote cuál se está comiendo tu límite semanal. Sin embargo, el /usage de Claude Code solo muestra los números de la sesión actual y el consumo de todo el plan repartido por Skill, subagente, plugin y servidor MCP, y qué parte gastó cada sesión no aparece ni en el anillo de uso de la app de escritorio ni en la página de ajustes de claude.ai (a septiembre de 2026). La respuesta está en los registros de conversación guardados en tu máquina (los archivos JSONL de ~/.claude/projects), pero sumarlos tal cual da un resultado erróneo, porque una sola respuesta se escribe en varias líneas, una por bloque de contenido, y los registros de los subagentes están en archivos aparte. Medido en mi propia máquina, el total ingenuo salió aproximadamente el doble del valor correcto y, como el tamaño del error variaba de una sesión a otra, hasta cambió el orden. Este artículo explica qué muestran y qué no las pantallas oficiales, cómo contar bien los registros con un script de recuento de unas 50 líneas, el resultado medido en el que una sola sesión se llevó casi un tercio de todo el consumo, los límites de lo que pueden decirte los números y cómo configurar OpenTelemetry si quieres seguirlo a lo largo del tiempo.

«Si instalas demasiadas Skills, te comen la ventana de contexto»: la mitad es cierta y la otra mitad es falsa. Según la documentación oficial de Claude Code, el listado de Skills dispone de un presupuesto fijo del 1% de la ventana de contexto del modelo, y por muchas Skills que añadas la cosa se detiene ahí. En lugar de crecer, lo que ocurre es que dejan de invocarse: cuando el listado desborda el presupuesto, Claude Code elimina descripciones empezando por las Skills que menos se invocan y conserva solo sus nombres. Una Skill que ha perdido su descripción ya no se conecta con lo que pides, pero no aparece ningún error ni nada va más lento. Este artículo ordena en qué se diferencian las tres herramientas de medición (/context, /usage y /skill-doctor), la definición de fallo de caché en 5% y 2,000 tokens, cómo la vida útil de la caché pasa de una hora a cinco minutos según el tipo de contrato, por qué la CLI sigue pesando menos que MCP aunque las definiciones de herramientas se carguen ya de forma diferida por defecto, el fundamento para mantener CLAUDE.md por debajo de 200 líneas y, una vez medido, por dónde empezar a recortar, todo limitado a lo que puede comprobarse en la documentación oficial.

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.

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.

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.

Hacer que un modelo alojado en tu propio PC escriba código dejó de ser solo autocompletado: entre finales de 2025 y 2026, los modelos abiertos alcanzaron el uso de tipo agente, ese en el que la herramienta lee el repositorio, corrige varios archivos y ejecuta los tests. Este artículo ordena, únicamente con fuentes primarias, hasta dónde se llega hoy de verdad y dónde te vas a atascar. La señal más clara del cambio es que los propios desarrolladores venden ya la programación de tipo agente: la tarjeta de modelo de Qwen menciona por su nombre a CLINE y describe un formato de function call diseñado a medida, y Mistral AI publicó Devstral Small 2 (24B) bajo Apache 2.0 junto a Devstral 2 (123B, Modified MIT). Antes de elegir modelo conviene separar dos herramientas que se confunden a diario: Continue reparte un modelo distinto por papel (chat, edit, apply, rerank, autocomplete) y pide poco hardware, mientras que Cline es un agente autónomo que exige contexto largo y llamadas a herramientas precisas. El escollo decisivo, y el motivo por el que muchas instalaciones parecen correctas pero se comportan de forma incomprensible, es que Ollama fija la longitud de contexto por defecto según la VRAM disponible: 4k con menos de 24 GiB, 32k entre 24 y 48 GiB y 256k a partir de 48 GiB. Un PC gaming corriente cae en la primera fila, el agente desborda esos 4k enseguida y la conversación se recorta en silencio, sin ningún error, de modo que olvidar instrucciones o repetir operaciones parece torpeza del modelo cuando en realidad es contexto tirado a la basura. La documentación oficial recomienda al menos 64000 tokens para programar, se configura con OLLAMA_CONTEXT_LENGTH al arrancar el servidor y hay que confirmar con ollama ps que el modelo sigue entero en la GPU, porque estirar el contexto aumenta la memoria necesaria y desplazar parte a la CPU cambia por completo la velocidad. La tabla de modelos recoge solo cifras publicadas por los desarrolladores: Qwen3.6-35B-A3B con 3B activos, 262,144 de contexto y 73.4 en SWE-bench Verified, y Devstral Small 2 con 68.0%. También se explica por qué la comparación del tipo "lo local está al X% de la nube" ya no se sostiene, dónde gana cada opción por razones estructurales, y por qué "gratis" es en realidad otra forma de coste que se invierte según si ya tienes el equipo.

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.

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.

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.

Una afirmación general no puede responder a la pregunta "si la IA puede editar las cosas directamente, ¿sigue haciendo falta un panel de administración?", porque la propia expresión "panel de administración" cubre un montón de funciones de naturaleza completamente distinta. Este artículo, apoyado en la experiencia de haber borrado entero el panel de administración de este sitio, sustituye esa pregunta por otra más afilada: ¿ofrece esa pantalla algo que la CLI y la IA no estén ofreciendo ya? Lo que reveló borrarlo todo es que la mayoría de las funciones retiradas no estaban "sin usar", sino "estructuralmente rotas". El CRUD de artículos nunca pudo funcionar, porque la fuente de verdad de los artículos vive en el código y cada despliegue sobrescribe la base de datos, así que todo lo editado en la pantalla se esfumaba en el siguiente despliegue. La cola de aprobación de comentarios estaba siempre vacía porque los mensajes se marcaban como aprobados al enviarlos, de modo que un comentario sin aprobar nunca llegaba a existir. Una función que nadie usa es una función cuya avería nadie puede detectar. La única capacidad que no podía irse era el borrado de comentarios, y ni siquiera esa tenía necesidad intrínseca de ser un panel de administración: un botón de borrar en la propia página del artículo resultó mejor, porque el comentario problemático se quita justo donde se está leyendo. La decisión se reduce a seis preguntas. Quién la opera (personal no técnico o un puesto que cambia de manos empuja hacia una interfaz; desarrolladores que viven en la terminal, no). Si es reversible (las acciones irreversibles necesitan una puerta). Si necesita un juicio humano (si existe una transición de estado de aprobar o rechazar). Si hay que separar permisos. Si quien opera sabe qué es posible (el listado hace de documentación). Si hay rastro de auditoría. Los permisos y el rastro de auditoría, en particular, parecen innecesarios en un proyecto en solitario y se convierten en lo primero que hace falta en cuanto llega una segunda persona. Los cambios hechos a través del código aterrizan en git, pero dejar que una IA escriba directamente en la base de datos no registra nada por defecto, y un registro de conversación conserva lo que se pidió, no lo que ocurrió. De los seis ejes, solo la reversibilidad carga un peso distinto. El 18 de julio de 2025, un agente de IA de Replit borró la base de datos de producción de SaaStr durante una congelación de código en vigor, fabricó 4.000 usuarios y afirmó erróneamente que la reversión era imposible, retrasando la recuperación (AI Incident Database #1152) — un caso que muestra menos el peligro de la IA que un problema de diseño en el que una acción irreversible podía alcanzarse sin pasar por una puerta humana. El artículo cubre además las tres cosas que hay que colocar antes de cargar el peso sobre la IA y la CLI (que los cambios dejen un rastro duradero, que haya un escalón delante de las acciones irreversibles y que el procedimiento esté escrito, porque borrar la interfaz borra también la lista de lo que es posible), una lista de comprobación previa a construir nada y la tercera opción de los productos de herramientas internas como Retool o Forest Admin en lugar de escribir un panel a mano.