La versión 2.1.260 de Claude Code, publicada el 3 de septiembre, trae dos novedades que van en direcciones opuestas: una es visible desde el primer segundo y la otra no se ve en absoluto, pero es la que te va a ahorrar dinero. La primera es un panel de diferencias a pantalla completa que se abre junto a la conversación. La segunda es que /cost y la línea de estado ahora te dicen por qué se ha invalidado la caché de prompts en lugar de limitarse a cobrártelo.
Completan la entrega /reload-plugins y una versión en texto de /advisor que por fin llega a las sesiones sin interfaz. Ninguna de las cuatro cosas es espectacular por separado; juntas describen bastante bien hacia dónde va el CLI: menos magia, más visibilidad sobre lo que está pasando por debajo.
Ver los cambios sin salir de la conversación
El nuevo panel se activa con /diff y se abre al lado de la conversación, en modo pantalla completa, mostrando los cambios sin confirmar mientras Claude edita. No es un git diff lanzado en una pestaña aparte: es la misma sesión, con el hilo a un lado y el árbol de modificaciones al otro, actualizándose según avanza el trabajo.
La diferencia práctica es de atención, no de información. Hasta ahora, revisar qué había tocado el modelo en una tarea de diez o quince ficheros implicaba romper el contexto: saltar a otra terminal o al editor, mirar, volver, reconstruir mentalmente en qué punto estaba la conversación. Con el panel al lado, la revisión pasa a ser continua en vez de a posteriori, que es justo lo que necesitas cuando estás dejando a Claude trabajar en modo semiautónomo y quieres cortar en cuanto veas que se está desviando.
Es especialmente útil en dos escenarios: refactors que tocan muchos archivos pequeños, donde el resumen textual del modelo tiende a aplanar detalles importantes, y trabajos sobre plantillas de WordPress o configuraciones donde una línea mal cambiada no rompe nada hasta que se despliega. Ver el cambio en crudo, mientras ocurre, es el tipo de mejora que no se nota en una demo y se agradece cada día.
La caché deja de fallar en silencio
Esta es la novedad menos vistosa y la más rentable. Hasta ahora, cuando la caché de prompts se invalidaba, lo único que veías era la consecuencia: la factura subía y las respuestas tardaban más, sin ninguna pista de por qué. A partir de la 2.1.260, tanto /cost como el campo prompt_cache de la línea de estado indican la causa probable del fallo.
- Cambiaron las definiciones de herramientas. Añadir, quitar o modificar una herramienta —un servidor MCP que entra o sale, un plugin que se recarga— altera el prefijo del prompt y tira la caché entera.
- Cambió el system prompt. Cualquier modificación en las instrucciones base, incluidos los ficheros de contexto del proyecto, produce el mismo efecto.
- Se superó el TTL de inactividad. Te levantaste a por un café, volviste y el bloque cacheado ya había expirado.
Saber cuál de las tres te ha tocado cambia por completo la reacción. Si el problema es el TTL, no hay nada que arreglar: es el precio de las pausas largas. Si el problema son las definiciones de herramientas, tienes un culpable concreto y accionable —normalmente un servidor MCP que se conecta tarde o un plugin que se recarga a mitad de sesión— y merece la pena ordenar el arranque para que todo esté cargado antes de la primera llamada. Y si es el system prompt, seguramente estés tocando ficheros de contexto durante la sesión sin darte cuenta del coste.
💡 Qué mirar en la próxima sesión larga
Lanza /cost a mitad de una sesión de trabajo real, no al final. Si la causa que aparece es un cambio de definiciones de herramientas y tú no has tocado nada, el sospechoso habitual es un servidor MCP conectándose o reconectándose. Estabilizar esa carga suele valer más, en dinero, que cualquier ajuste de modelo.
Esta transparencia llega además en una versión que corrige un fallo real de caché, no solo lo diagnostica: el contexto que se adjuntaba después de los resultados de herramientas no quedaba cubierto por la caché, de modo que se reenviaba como entrada sin cachear en cada turno con llamada a herramienta. En flujos con muchas herramientas —es decir, en casi cualquier flujo agéntico serio— eso se traducía en un sobrecoste constante y difícil de atribuir.
Una caché que falla en silencio no es un problema de rendimiento: es una factura sin desglosar.
Plugins recargables y advisor en sesiones sin interfaz
Las otras dos novedades son de fontanería, pero afectan directamente a quien automatiza. /reload-plugins permite recargar los plugins sin reiniciar la sesión, algo que hasta ahora obligaba a cerrar y volver a empezar perdiendo todo el contexto acumulado. Si estás desarrollando un plugin propio, el ciclo de iteración pasa de minutos a segundos.
La segunda es que /advisor llega en formato texto a las sesiones sin interfaz gráfica: modo -p, Agent SDK, aplicación de escritorio y Remote Control. Es el patrón que Claude Code viene repitiendo desde hace semanas: todo lo que funciona en la terminal interactiva acaba teniendo su equivalente utilizable desde un script. Para quien dispara Claude Code desde n8n o desde un runner de CI, cada función que cruza esa frontera es una cosa menos que hay que resolver a mano.
Qué hacer con esto hoy
Si trabajas a diario con el CLI, la actualización se justifica sola por el diagnóstico de caché: es información que antes no existía en ninguna parte y que apunta a gastos recurrentes que probablemente llevas meses pagando sin saberlo. La recomendación concreta es sencilla: actualiza, abre una sesión de trabajo normal y consulta /cost cuando lleves media hora. Si la causa señalada es de las evitables, tienes una optimización clara y medible por delante.
Y si sueles delegar tareas amplias, dale una oportunidad a /diff en modo pantalla completa antes de descartarlo como un adorno. La revisión continua no cambia lo que hace el modelo, pero cambia mucho la velocidad a la que detectas que se ha ido por otro camino, y ese suele ser el factor que decide si una sesión larga acaba en trabajo aprovechable o en un git checkout .
