Las últimas versiones de Claude Code traen dos añadidos pequeños que se van a notar más de lo que su tamaño sugiere. La versión de Claude Code 2.1.237 incorpora un nuevo estilo de salida, Concise, que va directo al resultado sin preámbulos ni narración innecesaria y se activa desde /config. La 2.1.235, por su parte, suma un corrector ortográfico opcional en el prompt —que aprovecha aspell, hunspell o ispell si los tienes instalados— y mejora el renderizado de listas anidadas. Ninguna de las dos cambia lo que la herramienta es capaz de hacer; las dos cambian cuánto cuesta usarla durante ocho horas seguidas.
Un estilo de salida no es una preferencia estética
Conviene entender qué es lo que se está tocando aquí. Un estilo de salida no es un tema de colores ni una plantilla de formato: define cómo se comunica el modelo contigo mientras trabaja. Cuánto explica antes de actuar, cuánto resume después, cuánta narración intercala entre paso y paso.
Por defecto, esa narración es abundante, y no por capricho: cuando alguien empieza con la herramienta, saber qué está a punto de pasar y por qué es exactamente lo que permite confiar en ella. El problema es que esa misma verbosidad, útil la primera semana, se convierte en ruido puro a los dos meses. Quien lleva tiempo usando Claude Code ya no lee el párrafo que explica que va a modificar tres archivos: salta hasta el diff. Y saltar cuesta atención, que es el recurso que de verdad escasea en una sesión larga.
La explicación que te da confianza el primer día es la que te obliga a hacer scroll el día doscientos.
Hay además un efecto secundario que no se suele mencionar: la narración ocupa contexto. Cada explicación intermedia consume espacio en la ventana de la conversación, y en sesiones largas ese espacio es finito y valioso. Una salida más compacta no solo se lee más rápido; deja más sitio para lo que importa antes de que la sesión empiece a olvidar el principio.
Dónde Concise ayuda y dónde te va a estorbar
La elección no es «más rápido siempre es mejor», y merece la pena pensarla por tipo de tarea antes de dejarlo fijo. Concise encaja bien cuando ya sabes lo que quieres: tareas repetitivas, cambios acotados que vas a revisar igualmente en el diff, ejecuciones encadenadas donde lo único que necesitas saber es si funcionó. En ese modo, la explicación no te aporta información, te aporta desplazamiento vertical.
Estorba, en cambio, en el escenario contrario: cuando estás explorando código que no conoces, cuando el modelo va a tomar decisiones de diseño que quieres poder discutir, o cuando trabajas sobre algo delicado y el razonamiento intermedio es justo lo que te permite frenar a tiempo. Ahí, quitar la narración es quitarte a ti la oportunidad de detectar que ha entendido mal el problema antes de que toque nada.
💡 Cómo probarlo sin arrepentirte
Actívalo desde /config y úsalo primero en tareas de mantenimiento que ya dominas: actualizaciones rutinarias, cambios pequeños en sitios que conoces de memoria, ejecuciones repetidas. Deja el estilo por defecto para proyectos nuevos o código ajeno. Si al cabo de unos días no echas de menos las explicaciones, ya sabes dónde dejarlo fijo.
Un corrector que corre en tu máquina, no en la nube
El corrector ortográfico de la 2.1.235 parece la típica comodidad menor, y lo interesante está en cómo se ha implementado. No se apoya en un servicio remoto ni añade una llamada al modelo: usa los binarios que ya tengas instalados en el sistema —aspell, hunspell o ispell—, tres correctores de toda la vida presentes en prácticamente cualquier entorno Unix.
Esa decisión de diseño tiene tres consecuencias que se agradecen. La primera es de privacidad: lo que escribes en el prompt se revisa localmente, sin salir de tu máquina, algo nada trivial cuando el prompt puede contener nombres de clientes, rutas internas o descripciones de sistemas privados. La segunda es de coste: no consume tokens, porque no interviene el modelo. Y la tercera es de latencia: la corrección es instantánea, sin esperar a ninguna respuesta.
El beneficio práctico va más allá de escribir bien. Un prompt con erratas —un nombre de función mal tecleado, una ruta con un carácter cambiado— puede llevar al modelo a interpretar mal la petición y hacer trabajo inútil que luego hay que deshacer. Detectar eso antes de pulsar Enter no es una cuestión de pulcritud: es evitar un ciclo entero de ida y vuelta. Y para quien trabaja en español dando instrucciones sobre código en inglés, mezclando ambos idiomas en la misma frase, es todavía más útil.
Merece la pena subrayar que es opcional y que depende de que tengas alguno de esos binarios instalado. Si trabajas en Windows sin un entorno tipo Unix, es probable que no tengas ninguno de los tres y que la función simplemente no aparezca; instalarlos es trivial, pero es un paso que hay que dar a mano.
Listas anidadas: el arreglo pequeño que se nota cada día
La misma versión mejora el renderizado de listas anidadas en el terminal, y es de esas correcciones que no aparecen en ningún titular y se agradecen en cada sesión. Una lista con subniveles mal representada obliga a reconstruir mentalmente la jerarquía: qué punto depende de cuál, qué es un paso y qué es un detalle de ese paso. Cuando lo que estás leyendo es un plan de acción antes de aprobarlo, esa jerarquía no es decorativa: es la información.
Vistas juntas, las tres novedades apuntan en la misma dirección, y es una dirección reveladora sobre en qué fase está la herramienta. Ninguna amplía capacidades; las tres reducen fricción para quien pasa horas dentro del terminal. Eso solo se prioriza cuando el uso intensivo y prolongado ya es el caso normal, no la excepción. Son cinco minutos de configuración y ninguna de las tres te va a cambiar la semana, pero si Claude Code es donde trabajas todos los días, es un rato que se recupera rápido.
