Todo lo que cambió en Claude Code durante el verano de 2026

Claude Code publicó 81 versiones entre el 1 de junio y el 28 de agosto de 2026. Son casi tres al día laborable, y el changelog oficial no lleva fechas, así que resulta fácil perderse qué llegó cuándo. Este artículo cruza ese changelog con las fechas reales de publicación en npm y se queda con lo que cambia la forma de trabajar, no con la lista completa. La versión en inglés está en /en/claude-code-summer-2026/.

Puntos clave

• Del 1 de junio al 28 de agosto de 2026 salieron 81 versiones, de la 2.1.160 a la 2.1.251, con 149 líneas de novedades y 120 de cambios o retiradas.
• Claude Opus 5 llegó el 24 de julio en la versión 2.1.219 y pasó a ser el modelo Opus por defecto, con un millón de tokens de contexto y el mismo precio que Opus 4.8.
• Desde el 7 de agosto las sesiones de Claude Code se envían mensajes entre sí, incluso entre máquinas distintas, con SendMessage y ListAgents.
• Ese mismo día llegaron los entornos autoalojados: claude self-hosted-runner ejecuta sesiones de la web, el móvil y el escritorio dentro de tu propia red.
• El sandbox aprendió a enseñar un valor centinela en vez del secreto real y a sustituirlo en la salida, de modo que un token deje de aparecer en los registros.
• Conviene revisar lo retirado: el asistente /agents y la función ultraplan desaparecieron, y el modo de permisos «default» ahora se llama «Manual».

Un verano de 81 versiones

El ritmo importa para entender el resto. La ventana va de la 2.1.160, publicada el 1 de junio, a la 2.1.251 del 28 de agosto: 30 versiones en junio, 23 en julio y 28 en agosto. Sumadas, esas 77 entradas de changelog contienen 149 líneas que empiezan por Added y otras 120 que empiezan por Changed o Removed.

Esa segunda cifra es la que suele ignorarse y la que más tiempo hace perder. Un verano con 120 cambios de comportamiento significa que la configuración que funcionaba en mayo puede comportarse de otra forma en septiembre sin que nadie la haya tocado.

Claude Opus 5, el cambio más visible

La versión 2.1.219, del 24 de julio, lo resume en una línea: Claude Opus 5 pasa a ser el modelo Opus por defecto, con un millón de tokens de contexto y modo rápido a 10 y 50 dólares por millón de tokens. El precio estándar se queda en 5 dólares por millón de entrada y 25 por millón de salida, exactamente lo que costaba Opus 4.8.

En el anuncio, Anthropic lo sitúa así: «It’s the new default model on Claude Max, and the strongest model on Claude Pro». Las cifras que acompañan al lanzamiento son concretas: en Frontier-Bench v0.1 más que duplica el resultado de Opus 4.8, en ARC-AGI 3 triplica al siguiente modelo, y en CursorBench 3.2 se queda a menos del 0,5 % del máximo de Claude Fable 5 por la mitad de coste.

Dos detalles prácticos acompañan al cambio. El primero es que la misma versión retiró Opus 4.7 del modo rápido, así que /fast ahora aplica a Opus 5 y Opus 4.8. El segundo, más fácil de pasar por alto, es que unos días antes la 2.1.207 había puesto Opus 4.8 como predeterminado en Bedrock, Vertex y Claude Platform on AWS, de modo que el modelo por defecto depende de por dónde entres. Si te interesa el contexto de los modelos anteriores, en el sitio están los análisis de Opus 4.7 en tareas de horizonte largo y del equilibrio coste-calidad de Sonnet 4.6.

Las sesiones dejaron de estar solas

Este es el cambio conceptual del verano. Hasta agosto, cada sesión de Claude Code era una isla. Desde la 2.1.224, del 7 de agosto, una sesión puede enviar un mensaje a otra, incluso si vive en otra de tus máquinas, con SendMessage, y descubrir cuáles hay disponibles con ListAgents. De momento en macOS y Linux.

La versión 2.1.236 añadió encima algo que resuelve el problema evidente de coordinar dos sesiones: notify_when_idle pide a otra sesión un único aviso cuando quede libre. Es opcional, se dispara una sola vez y no hay sondeo de por medio, así que no se paga contexto por esperar.

El diseño se tomó en serio el riesgo. Los mensajes dirigidos a una sesión que se ejecuta con los permisos saltados no se entregan solos: quedan retenidos para tu aprobación, gobernados por los ajustes crossSessionInbound y dialogExpiry. A finales de agosto, la 2.1.248 extendió la mensajería a Bedrock, Vertex, Foundry y a las instalaciones con la telemetría desactivada.

Tu propia infraestructura para las sesiones de la nube

El segundo titular del 7 de agosto son los entornos autoalojados. El comando claude self-hosted-runner convierte tus máquinas o contenedores en el sitio donde se ejecutan las sesiones que arrancan desde la web, el móvil y el escritorio. Está en beta pública para los planes Team y Enterprise y viene desactivado: lo tiene que habilitar un Owner desde la administración.

El modelo mental es el de un runner de integración continua, y son tres piezas: un environment que es un destino con nombre, los runners que son procesos dentro de tu red, y las sessions. Cuando alguien elige tu entorno, el plano de control de Anthropic pone la sesión en una cola, un runner la reclama, clona el repositorio y arranca un proceso hijo de Claude Code en tu máquina.

Lo importante es la dirección del tráfico. Todo son conexiones HTTPS salientes hacia api.anthropic.com, y la documentación lo dice sin rodeos: «Anthropic never connects into your network».

Ahora la letra pequeña, que conviene leer antes de planificar nada:

• Qué se queda dentro: los checkouts del repositorio, los artefactos de compilación, los secretos y cualquier fichero que cree la sesión.
• Qué sale igualmente: la conversación entera, con sus prompts, respuestas y resultados de herramientas, viaja a api.anthropic.com para la inferencia, y Anthropic guarda la transcripción. Autoalojar mueve la ejecución, no el modelo.
• Incompatibilidades: no está disponible para organizaciones con Zero Data Retention, y la inferencia no puede ir por Bedrock, Vertex, Foundry ni una pasarela propia.
• Repositorios: las sesiones se traen el código de GitHub.
• Aritmética de flota: un runner se bloquea al primer propietario que reclama una sesión y solo sirve a ese hasta que termina, así que el tamaño mínimo de la flota es el número de personas que esperas activas a la vez.

Si lo que quieres es manejar tu propia máquina desde el móvil sin montar nada de esto, la respuesta sigue siendo Remote Control, que está en Pro y Max.

El sandbox aprendió a esconder credenciales

De todo lo que llegó este verano, este es el mecanismo que más me ha gustado, porque ataca un problema real que casi nadie mide: el token no se filtra por la red, se filtra en el registro de un comando.

La versión 2.1.187 introdujo en junio sandbox.credentials, que permite denegar el acceso a ficheros de credenciales y variables de entorno. El problema de denegar es que rompe la herramienta: sin GH_TOKEN no hay gh que funcione. La solución llegó con el modo mask, que en agosto se extendió a ficheros en Linux y WSL.

Funciona así: el comando dentro del sandbox ve un valor centinela distinto en cada sesión, nunca el secreto. Cuando su petición sale hacia uno de los hosts que hayas autorizado, el proxy del sandbox cambia el centinela por el valor real. El comando autentica correctamente y ni él ni sus registros llegan a tocar la credencial.

{
  "sandbox": {
    "network": {
      "tlsTerminate": {},
      "allowedDomains": ["api.github.com", "registry.npmjs.org"]
    },
    "credentials": {
      "envVars": [
        { "name": "GH_TOKEN", "mode": "mask", "injectHosts": ["api.github.com"] },
        { "name": "NPM_TOKEN", "mode": "mask" }
      ]
    }
  }
}

Hay tres condiciones que conviene tener claras. La primera es que el proxy necesita ver el contenido de la petición para sustituir el centinela, así que network.tlsTerminate es obligatorio; sin él el enmascarado falla, pero falla de forma segura, porque el centinela llega intacto al servidor y la autenticación se cae, con un aviso al arrancar. La segunda es que estos ajustes solo se leen de la configuración de usuario, la gestionada o la que pases con --settings: un .claude/settings.json dentro de un repositorio se ignora, que es exactamente lo que quieres. Y la tercera es que no existe ninguna lista negra por defecto, de modo que solo queda protegido lo que enumeres tú.

Para valores con estructura, la 2.1.224 añadió extract, una expresión regular que sustituye solo el grupo capturado, útil cuando la variable es una cadena de conexión y la herramienta necesita el resto para funcionar. También llegaron decode: "jwt" con maskClaims para enmascarar reclamaciones concretas de un JWT, y el refirmado de peticiones AWS SigV4. Quien venga de aislar agentes con contenedores encontrará el planteamiento familiar; en el sitio está la comparación con E2B como sandbox de código para agentes.

Frenos después de la era del fan-out

Julio trajo límites, y su historia enseña algo sobre cómo se está calibrando esto. El 16 de julio, la 2.1.212 puso un tope de 200 subagentes por sesión y otro de 200 búsquedas web, ambos pensados para cortar bucles desbocados.

Tres semanas después, el 7 de agosto, la 2.1.224 retiró el tope de subagentes por sesión: las sesiones largas volvían a rechazar agentes nuevos sin motivo. Los límites de concurrencia y profundidad se quedaron, que eran los que de verdad importaban. Si leíste sobre ese tope en julio, ya no está.

Lo que sí sigue vigente es más interesante que un número:

• Los subagentes ya no generan subagentes anidados por defecto desde la 2.1.217. Hay que subir CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH para permitirlo.
• El tope de subagentes simultáneos se queda en 20, ajustable con CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS.
• Los workflows dinámicos apuntan por defecto a menos de 15 agentes desde la 2.1.219, como orientación y no como límite duro.
• El tope de 200 búsquedas web por sesión sigue ahí.

La lectura de fondo es que la profundidad se cerró y la anchura se dejó abierta con un aviso. Tiene sentido: un subagente que genera subagentes multiplica el gasto sin que nadie lo vea venir.

El coste y la caché por fin se ven

Agosto fue el mes de la contabilidad. La 2.1.243, del 24 de agosto, permite separar por primera vez la duración de la caché de prompt entre la conversación principal y los subagentes, con promptCacheTtl y subagentPromptCacheTtl: una hora en la conversación larga mientras los subagentes se quedan en cinco minutos, que es justo el reparto que quieres cuando la sesión dura toda la tarde.

Esa misma versión añadió modelPricing, para que una organización con tarifas contratadas vea sus precios reales en /cost, en la status line y en la telemetría en lugar del precio de lista, y un desglose de bucles en /usage con ejecuciones, tokens totales y tokens por ejecución. Cuatro días después, la 2.1.251 sumó a /cost una línea de caché por sesión con el ratio de aciertos, los fallos y los tokens recacheados.

Para quien afina el gasto, la combinación cierra un hueco viejo: hasta este verano se podía sospechar que la caché no estaba funcionando, pero no comprobarlo desde dentro de la sesión.

Lo que desapareció o cambió de nombre

Esta lista ahorra más tiempo que ninguna otra, porque son cosas que buscarás y no encontrarás:

• El modo de permisos «default» ahora se llama «Manual» en la línea de comandos, en --help, en VS Code y en JetBrains, desde la 2.1.200.
• El asistente /agents ya no existe desde la 2.1.198. Se le pide a Claude que cree el subagente, o se editan los ficheros de .claude/agents/ directamente.
• La función ultraplan se retiró en la 2.1.222.
• /deep-research solo arranca si lo invocas tú; Claude ya no lo lanza por su cuenta.
• /code-review pasó a ejecutarse como subagente en segundo plano, de modo que la revisión ya no llena la conversación.
• /commit-push-pr dejó de autoaprobar órdenes de git con banderas peligrosas como --force, --amend o --no-verify.

Detalles pequeños que se agradecen a diario

Fuera de los titulares hay un puñado de cosas que se notan en el uso. --safe-mode, desde la 2.1.169, arranca sin ningún fichero CLAUDE.md, plugin, skill, gancho ni servidor MCP, que es el primer paso obvio cuando algo se comporta raro y no sabes qué lo provoca. Esa misma versión trajo /cd, que cambia el directorio de trabajo sin invalidar la caché de prompt a mitad de sesión.

Las reglas de permisos ganaron precisión en la 2.1.178 con la sintaxis Tool(param:value), que permite cosas como Agent(model:opus) para impedir que los subagentes usen Opus. Y desde la 2.1.208 existe un modo para lectores de pantalla, con renderizado en texto plano, que se activa con claude --ax-screen-reader o con el ajuste axScreenReader.

## Arrancar sin ninguna personalización para diagnosticar un problema
claude --safe-mode

## Cambiar de directorio dentro de la sesión sin perder la caché de prompt
/cd ../otro-repositorio

## Impedir que los subagentes usen Opus, en .claude/settings.json
## "deny": ["Agent(model:opus)"]

GitLab también se puso a la altura de GitHub durante agosto: marketplaces de plugins desde repositorios de GitLab, URLs de merge request en --worktree y en la vista de agentes, una insignia de MR en el footer y la redacción automática de nueve familias de tokens de GitLab en los registros. Si trabajas con un Gitea o un GitLab propio, como es el caso de bastantes montajes autoalojados, esa paridad se agradece.

Preguntas frecuentes

¿Merece la pena montar un entorno autoalojado?

Solo si tu red, tus herramientas o tu normativa lo exigen. La propia documentación recomienda los entornos gestionados por Anthropic para la mayoría de equipos, porque autoalojar implica construir y mantener la imagen del runner, operar la flota y controlar su red. Y hay que entender qué resuelve: los checkouts y los artefactos se quedan en tu infraestructura, pero la conversación sale igualmente hacia la API para la inferencia. Si lo que buscas es que ningún dato salga, esto no es la respuesta.

¿El enmascarado de credenciales protege también fuera del sandbox?

No. sandbox.credentials afecta únicamente a los comandos que se ejecutan dentro del sandbox de Bash. Para retirar las credenciales de Anthropic y de los proveedores de nube de todos los subprocesos, con sandbox o sin él, existe la variable CLAUDE_CODE_SUBPROCESS_ENV_SCRUB. Y en macOS el enmascarado de ficheros no está disponible: cae a denegación, que rompe la herramienta pero no expone nada.

¿Qué modelo uso ahora por defecto?

Depende de la puerta de entrada. En la API de Anthropic, Claude Opus 5 es el Opus por defecto desde el 24 de julio. En Bedrock, Vertex y Claude Platform on AWS el predeterminado es Opus 4.8 desde la 2.1.207. Si quieres fijarlo tú, la 2.1.236 añadió ANTHROPIC_DEFAULT_MODEL, que marca el modelo con el que arrancan las sesiones nuevas mientras una elección manual con /model sigue teniendo prioridad y persiste entre reinicios.

Conclusión

Si hubiera que resumir el verano en una frase, sería que Claude Code dejó de comportarse como un programa que ejecutas y empezó a comportarse como una flota que operas. Las sesiones se hablan, pueden vivir en tu propia infraestructura, tienen límites de concurrencia y profundidad, y por fin enseñan lo que cuestan y cómo va su caché.

El siguiente paso razonable no es probarlo todo. Es abrir /config, mirar en qué modo de permisos estás ahora que «default» se llama «Manual», y decidir si alguna de las tres piezas de este verano resuelve un problema que ya tenías: coordinar sesiones largas, sacar la ejecución a tu red, o dejar de tener tokens en los registros. Para lo demás, el changelog seguirá creciendo tres veces al día. Si estás comparando herramientas antes de decidir, el análisis con tareas medidas de Claude Code frente a Cursor y Copilot sigue siendo un buen punto de partida, igual que la guía de ingeniería de contexto para agentes.

Fuentes

1. CHANGELOG oficial de Claude Code
2. Fechas de publicación de @anthropic-ai/claude-code en npm
3. Introducing Claude Opus 5 (Anthropic)
4. Entornos autoalojados (documentación de Claude Code)
5. Configurar el sandbox de Bash (documentación de Claude Code)