Primeros pasos con Claude Code: los fundamentos que no caducan

Claude Code cambia cada semana. Hay una página de changelog que lo publica, y conviene visitarla con la cabeza preparada: lo que aprendiste el mes pasado puede haberse movido. Un comando se renombra, una función entra en preview, un modelo nuevo desplaza al anterior.

Pero incluso aquí, en pleno vértigo de la IA, hay cosas que no se mueven. O que se mueven despacio, porque se han convertido en pilares. Este artículo va de eso. De los fundamentos que vas a seguir usando dentro de seis meses, separados de lo que caduca en quince días.

Y voy a presumir de ello: no te voy a dar comandos que mañana estén rotos. Te doy el modelo mental que aguanta, y el enlace al tip para el detalle de hoy.

Lo escribo desde la práctica. Soy ingeniero de software y uso Claude Code en producción, a diario, muchas horas. Y aunque usaré Claude Code como ejemplo, casi todo lo que verás tiene equivalente en otros harness de IA, así que el conocimiento te sirve más allá de esta herramienta.

Una cosa más, la que justifica el artículo entero. Claude es tan útil que llega al resultado rápido incluso cuando lo usas mal. Funciona, así que no te das cuenta de que lo estás usando mal. El día 1 no consiste en arrancarlo, eso es fácil. Consiste en aprender la fontanería invisible: dónde viven tus sesiones, cómo se resetea tu cuota, cómo el contexto se llena y se traga en silencio lo que le dijiste. Con un poco de estrategia, todo fluye mejor.

Empezar bien

CLI, Desktop, Extensión o ACP: elige por dónde entras

Mismo agente, mismas reglas, distinta puerta. Elige una vía y hazte experto en ella antes de saltar a otra.

No son productos distintos. No son agentes distintos. El núcleo es el mismo en todas las vías: el mismo agente, el mismo loop de herramientas, el mismo CLAUDE.md, los mismos hooks, la misma configuración de MCP, los mismos modelos. Lo único que cambia es la interfaz (cómo ves y revisas lo que el agente hace) y la gestión del workspace (cómo se organizan las sesiones y los archivos). Esto importa más de lo que parece el día 1: cambiar de superficie no es aprender una herramienta nueva. Tu configuración viaja contigo y tu intuición sobre cómo se comporta el agente viaja contigo. Lo que aprendas en una te sirve en las otras.

Hoy hay cuatro vías de entrada. La CLI del terminal, la más cercana al código. La app de escritorio (sus ventajas sobre la CLI), hoy en macOS y Windows, con pestañas Chat, Cowork y Code, pensada para revisar los cambios de forma visual. Una extensión dentro de tu editor: la de VS Code es la oficial y trae un panel nativo, pero no es la única. Y, lo más reciente, ACP (Agent Client Protocol), un estándar abierto que Anthropic implementa con un adaptador propio para que Claude Code corra dentro de editores que no tienen extensión oficial: Zed, Neovim, JetBrains o Emacs hablan con el agente por ese protocolo. La consecuencia práctica es que ya no dependes de que exista una extensión para tu editor favorito.

Por eso el consejo del primer día es elegir una vía y centrarte en ella. Como Claude funciona aunque lo uses mal, repartir tu atención entre varias interfaces te deja una fluidez superficial en todas sin enterarte: cada una te dará un resultado decente, ninguna te enseñará a sacarle partido de verdad. Dominar una bate a repartirte entre cuatro. Para elegir, mira dónde ya trabajas: terminal, app aparte, o el editor que ya tienes abierto. Esa es la pregunta, dónde te sientes en casa.

Instalación y primer arranque

El método con el que instalas Claude Code decide si se mantiene al día solo o se queda congelado. El instalador nativo se actualiza solo en segundo plano; un package manager (Homebrew, apt) y npm, no. Claude Code publica novedades cada pocas semanas (skills, subagents, comandos nuevos), así que instalar por el camino equivocado significa quedarte atrás sin enterarte: llevas meses sin ver una sola feature nueva y crees que la herramienta es así.

Por eso conviene la instalación nativa. Tanto npm como los package managers entregan un binario que no se actualiza solo; el instalador nativo entrega uno autocontenido que sí lo hace y que mantiene la compatibilidad con tu CLAUDE.md y tus settings entre versiones, de modo que el coste de estar al día es prácticamente cero. Es lo que recomienda Anthropic. Los pasos concretos cambian según tu sistema operativo (macOS, Windows o Linux) y no tiene sentido memorizarlos: los tienes en la guía de qué es Claude Code, y la mecánica de mantenerlo actualizado (auto-update, canales, qué hacer si lo instalaste con un package manager) está en el tip de cómo actualizar.

El primer arranque es más simple de lo que parece. Abres una terminal dentro de la carpeta de tu proyecto, ejecutas claude y te pide autenticarte con tu cuenta. A partir de ahí ya estás dentro de la sesión, en ese directorio. Que lances el comando desde dentro del proyecto importa, porque Claude Code trabaja sobre el directorio donde arranca y ahí es donde vivirá la conversación (lo de "por directorio" lo verás en detalle en el capítulo de sesiones). Para confirmar que todo está bien, claude --version te dice qué versión usas, y si algo se comporta raro al empezar, /doctor revisa la instalación, la versión y la configuración antes de que pierdas una hora buscando a tientas.

CLAUDE.md y /init: dale contexto al proyecto

Sin un fichero de memoria, Claude Code empieza cada sesión a ciegas. Lee el código que le señalas, pero sobre el resto adivina: qué framework usas, qué decisiones de arquitectura ya están tomadas. Y a veces adivina mal. El caso clásico es proponer o instalar Express en un proyecto que ya corre sobre Next, porque nada le dijo lo contrario. No es que la herramienta sea torpe. Es que le faltaba el contexto que tú dabas por obvio.

CLAUDE.md es ese contexto. Un fichero en la raíz del repositorio que Claude lee al arrancar cada sesión. Para generarlo ejecutas /init: analiza el codebase, detecta el build system, los frameworks y los tests, y te deja una primera versión que luego editas. La propiedad que lo hace imprescindible el día 1 es que CLAUDE.md se carga al inicio de cada sesión y sobrevive a la compactación. Cuando la ventana de contexto se llena y Claude resume lo viejo para hacer hueco, tus instrucciones del chat pueden diluirse o perderse. Las de CLAUDE.md no. Por eso es el sitio donde van las reglas que no quieres repetir nunca: las que deben seguir vigentes en el mensaje número uno y en el cien.

Más largo no es mejor. Un CLAUDE.md enorme se ignora a medias: cada línea innecesaria gasta contexto y entierra las instrucciones que de verdad importan. Mantenlo conciso (la regla práctica son unas 200 líneas) y reserva el espacio para lo que Claude no puede inferir leyendo el código: decisiones de negocio, convenciones propias del equipo, el porqué detrás de cada regla. Lo que ya está en tu package.json o en la estructura de carpetas no necesita estar aquí. Cómo redactarlo, qué quitar y cómo modularizarlo con imports lo tienes paso a paso en el tip sobre configurar tu CLAUDE.md.

Sesiones

Viven por directorio (y cómo recuperarlas)

Tus conversaciones no se pierden: viven ancladas a la carpeta donde nacieron. claude --resume las trae de vuelta.

La primera confusión de casi todo el mundo es la misma. Trabajas una tarde entera con Claude Code, cierras el terminal, al día siguiente vuelves desde otra carpeta y la conversación no está. Ni la última, ni el historial. Parece que se ha perdido. No se ha perdido nada: las conversaciones viven atadas al directorio donde las arrancaste. Si haces cd a otra parte del proyecto, o abres el terminal en otro punto, Claude Code mira ahí y no encuentra lo que dejaste en la carpeta anterior. Está, pero no donde estás buscando.

Cada sesión se guarda en local, en disco, en ~/.claude/projects/<proyecto>/<id>.jsonl, un fichero por conversación. No es memoria volátil que se evapora al cerrar; es un transcript que persiste. La sesión no se borra cuando sales, se queda indexada bajo el directorio en el que la abriste. Esto no es un capricho: es lo que permite que el contexto de un proyecto no se mezcle con el de otro. El precio es esta confusión del día 1, que desaparece en cuanto sabes que el directorio es la llave.

Recuperarlas es trivial. claude --continue retoma la última conversación de la carpeta en la que estás. claude --resume abre un selector con todas las de ese directorio para que elijas. Y como las sesiones viven por carpeta, el selector trae atajos para ampliar la búsqueda más allá de donde lanzaste el comando: a todos los worktrees del repo, a todos los proyectos de la máquina, o filtrando por rama. Cuando eliges una que vive en otra carpeta, te lleva a ella (o te deja el comando listo para pegar) sin que tengas que acordarte de la ruta. Las teclas concretas y las demás puertas de entrada (por nombre, desde un PR) están en el tip de reanudar sesiones, que se mantiene al día con los atajos actuales.

Ninguna conversación se pierde: todas están en disco, y la forma de volver a una es decirle a Claude Code en qué directorio (o worktree, o proyecto) buscar. El día que interiorizas que el directorio es el índice, dejas de dar sesiones por muertas.

Renombra y colorea para distinguirlas

La gestión de sesiones es una de las áreas más flojas de Claude Code. Por defecto, todas las sesiones se ven iguales: la misma prompt bar, el mismo color, sin título. Una sesión no tiene marca propia. Mientras trabajas en una sola, no importa. En el momento en que abres una segunda, el problema aparece.

Cuando ejecutas varias sesiones en paralelo (una refactorizando autenticación, otra escribiendo tests, otra revisando un PR), todas son indistinguibles. Cambias de pestaña de terminal y tardas un par de segundos en recordar dónde estás. Multiplica eso por cada cambio de contexto a lo largo del día y entiendes por qué importa. Lo mismo ocurre días después: cuando buscas una conversación antigua para retomarla, "¿cuál era?" es un ejercicio de memoria que no deberías estar haciendo.

La solución es darle a cada sesión una identidad visual. Un nombre descriptivo la convierte en texto buscable cuando la quieres recuperar. Un color hace que la reconozcas de un vistazo, sin leer, solo por el borde de la prompt bar. No arregla el problema de raíz (la gestión de sesiones sigue siendo limitada), pero convierte "cuál de estas tres es" en saberlo al instante. Es la diferencia entre navegar por memoria y navegar por reconocimiento.

Los comandos exactos para renombrar y dar color, nombrar al arrancar y recuperar una sesión por su nombre están en el tip. Una advertencia que conviene saber de antemano: hoy el color se aplica a la sesión en curso y no persiste al retomarla, así que trátalo como una pista del momento, no como una etiqueta permanente.

Pide un resumen cuando vuelves

Te levantas a una reunión, comes, atiendes a un compañero. Cuando vuelves al terminal, la sesión sigue abierta pero tú ya no estás donde la dejaste. Lo caro no es el tiempo de ausencia, es lo que perdiste mientras estabas fuera: el conjunto de cosas que tenías en la cabeza. Qué archivo estabas tocando, qué quedaba a medias, por qué habías descartado la otra opción. Ese estado mental no está escrito en ninguna parte, así que para recuperarlo subes por la conversación y relees. Y releyendo recuperas mal: ves lo que se hizo, no lo que faltaba por hacer, que es justo lo que necesitas para seguir.

Un resumen de sesión cubre exactamente ese hueco. En lugar de reconstruir el contexto a mano, te recoloca en una línea: dónde ibas y qué quedaba pendiente. No es el historial completo (eso ya lo tienes subiendo por la conversación), es la síntesis de tu punto de retorno. La diferencia entre las dos cosas es la diferencia entre volver al hilo y volver a empezar. Cuando la sesión te entrega el "estabas migrando esto, faltan los tests", retomas en segundos en vez de en minutos, y lo haces sin el riesgo de creer que ya está hecho algo que no lo estaba.

El concepto importa más que el comando porque la pieza no es exclusiva de Claude Code: cualquier herramienta con la que trabajes en sesiones largas tiene el mismo problema de reentrada, y cada vez veo más herramientas que lo resuelven igual. La mecánica concreta sí cambia (hoy puede aparecerte solo al volver tras un tiempo fuera, o lo pides tú a demanda; eso se mueve entre versiones). Cuando llevas tiempo sin mirar la sesión, no empieces releyendo, empieza pidiendo el resumen. Toda la letra pequeña (cuándo salta solo, cómo lo invocas, cómo lo apagas si te estorba) está en el tip de el resumen de sesión.

Bifurcar (/branch) no es rebobinar (/rewind)

/branch copia la conversación para explorar otro camino; /rewind deshace el estado dentro de la misma sesión. No los confundas.

Suenan parecido y hacen cosas opuestas. Bifurcar copia la conversación; rebobinar la deshace. Esa es toda la diferencia, y conviene tenerla clara antes de tocar cualquiera de los dos, porque uno preserva tu trabajo y el otro lo descarta.

Bifurcar con /branch (o --fork-session al arrancar) crea una copia independiente de la conversación a partir del punto en el que estás. La sesión original queda intacta, exactamente donde la dejaste, y tú pasas a la copia para probar otro camino. Es lo que quieres cuando Claude propone una solución y dudas: en lugar de comprometerte, bifurcas, exploras la alternativa en la copia, y si no convence vuelves a la original sin haber perdido nada. Tienes las dos versiones a la vez. En el selector de sesiones las bifurcaciones aparecen agrupadas bajo su sesión raíz, así que el árbol de caminos que has explorado no se te pierde de vista.

Rebobinar con /rewind (hoy, Esc dos veces con el prompt vacío) hace lo contrario: vuelve atrás el estado dentro de la misma sesión. Puedes rebobinar el código, la conversación, o ambos, a un checkpoint anterior. Aquí no hay copia ni segundo camino: deshaces, el estado al que vuelves sustituye al actual y lo que había hacia delante desaparece. Es el botón de pánico para cuando Claude se ha desviado y prefieres retroceder a un punto bueno antes que seguir corrigiendo sobre algo ya torcido.

La pregunta que decide cuál usar es si quieres conservar las dos versiones o no. Si quieres comparar dos enfoques y quedarte con el mejor, bifurca: te llevas las dos. Si el estado actual está mal y solo quieres el de antes, rebobina: te quedas con una. El atajo concreto de cada uno puede cambiar entre versiones, pero esa distinción (copiar para conservar frente a deshacer para descartar) no se mueve.

Contexto

/context: mira qué ocupa tu ventana

El contexto es la memoria de trabajo de la sesión, y es finita. Todo lo que Claude tiene presente en un momento dado vive ahí dentro: tu conversación, los ficheros que ha leído, la salida de cada herramienta que ha ejecutado, las skills que se han cargado, las reglas de tu CLAUDE.md. No es un almacén infinito al que vas añadiendo cosas sin coste. Es un espacio cerrado, y cuando se llena, algo tiene que salir.

El problema del día 1 no es quedarte sin espacio. Es que se gasta en silencio. Buena parte de la ventana se consume antes de que escribas tu primer mensaje (las herramientas del sistema, los agentes que tengas definidos, los MCP que tengas conectados), y luego cada fichero que abres y cada comando que corre recortan lo que queda. Nadie te avisa. Un día notas que Claude "se ha vuelto tonto" a mitad de tarea, y lo que ha pasado es que el contexto se llenó y la información que necesitaba quedó fuera.

/context es la radiografía. Te enseña, por categoría, qué está ocupando espacio ahora mismo y cuánto te queda libre. No lo ejecutas para hacer nada con él directamente, lo ejecutas para dejar de trabajar a ciegas: ver de un vistazo qué categorías te están comiendo la ventana antes de empezar, o que llevas tanta conversación acumulada que conviene cortar y empezar de cero. La relevancia se degrada antes de tocar el límite, así que un contexto medio lleno de cosas que ya no importan trabaja peor que uno vacío.

Los números concretos (cuánto ocupa cada categoría, dónde está hoy el techo de la ventana, cuándo salta la compactación automática) cambian con cada versión y según tu plan. Por eso no los memorices: ejecuta el comando y mira los tuyos. El desglose completo, qué significa cada fila y cómo actuar sobre lo que ves, está en el comando /context.

/compact frente a /clear

/clear entre tareas que no tienen que ver, /compact cuando necesitas conservar el hilo. Lo que no puede perderse va en CLAUDE.md.

Cuando la conversación se llena, Claude no se para: compacta. Resume lo viejo para hacer hueco a lo nuevo, y en ese resumen se pierde detalle. Eso que el principiante vive como "se ha vuelto torpe" o "se le ha olvidado lo que le dije" casi nunca es un fallo. Es la ventana de contexto llenándose y el modelo cambiando precisión por sitio. Entender esto el día 1 te ahorra horas de pelearte con un Claude que parecía listo y de repente repite errores que ya habías corregido.

Tienes dos formas de gestionarlo, y no hacen lo mismo. /compact resume a mano: le puedes pasar un foco (/compact céntrate en el bug del login) para que el resumen conserve lo que importa y suelte el resto. El auto-compact es el que salta solo al acercarse al límite: hoy, primero limpia los outputs viejos de herramientas, que ocupan mucho y aportan poco, y solo si hace falta resume la conversación. /clear es otra cosa. No resume: vacía la sesión entera y arranca de cero. No la borra (queda guardada y la puedes retomar después), pero el contexto activo desaparece.

/clear entre tareas no relacionadas, /compact cuando importa la continuidad. Si terminas de arreglar un bug y vas a tocar algo que no tiene nada que ver, no resumas el hilo anterior, límpialo. Arrastrar contexto que ya no sirve no te ayuda, te ensucia las respuestas y te consume cuota. En cambio, si sigues dentro de la misma tarea larga y necesitas que Claude recuerde las decisiones que has tomado, compacta y dale el foco. Ahí sí quieres conservar el hilo.

Lo que no puede perderse no lo confíes ni al compact ni a tu memoria: ponlo en el CLAUDE.md raíz. Ese archivo se reinyecta en cada arranque y sobrevive a la compactación, así que las reglas que tienen que aplicarse pase lo que pase viven ahí, no en el prompt que un resumen puede recortar. No todo vuelve igual de una compactación, y conviene saber qué sobrevive a la compactación y qué no antes de que te frene a media tarea. Y como CLAUDE.md es solo uno de los sitios donde dejar contexto, mira también las cinco formas de dar contexto y cuándo usar cada una.

Drifting y el espejismo del 1M

Más contexto no es mejor: la relevancia se degrada mucho antes de llegar al límite.

El drifting es la deriva del contexto: lo que le dijiste al principio de la sesión deja de estar presente. No es que Claude lo ignore. Es que ya no lo tiene delante. La ventana de contexto es finita y se va rellenando con todo lo que pasa en la conversación, y cuando se acerca al límite se recarga o se compacta. En esa recarga, lo más antiguo es lo primero que se resume o se descarta. Tu encargo original se diluye en un resumen, y a partir de ahí el modelo trabaja sobre una versión empobrecida de lo que pediste. El síntoma típico: a mitad de una tarea larga el agente "se olvida" de una restricción que diste hace media hora y empieza a hacer cosas que ya habíais descartado.

El error frecuente es pensar que el problema se arregla con más espacio. Existe la ventana de 1M de tokens, mucho más grande que la anterior (hoy unas 5x), y la intuición dice que cuanta más capacidad, mejor. Es falso. Más contexto no es mejor contexto. La precisión del modelo no se mantiene plana hasta el límite y luego cae de golpe: se degrada mucho antes. Cuanto más lejos queda una información del punto actual de la conversación, peor la recupera el modelo, aunque técnicamente siga dentro de la ventana. Un millón de tokens no es un millón de tokens útiles. Es un techo, no un objetivo.

Gran parte del contexto no lo consumen tus mensajes, lo consume la lectura de ficheros. Cada vez que Claude abre un archivo para entender el código, ese contenido ocupa sitio en la ventana. En sesiones reales, leer el codebase consume mucho más espacio que la propia conversación, y es justo eso lo que empuja la ventana hacia el límite y fuerza la compactación que dispara el drifting. Por eso la solución no es tener más espacio sino gastar menos: que el modelo lea solo lo que necesita, cerrar la sesión y empezar limpio entre tareas que no tienen nada que ver, y dejar las reglas que no se pueden perder donde sobrevivan a la compactación (el CLAUDE.md raíz, como ya vimos), no en un mensaje suelto que el resumen se lleva por delante. Las cifras concretas (qué modelo trae el millón hoy, en qué planes, cuándo salta la auto-compactación) cambian release tras release y viven en el tip enlazado; no llenes el contexto solo porque puedas.

Modelos y cuota

Elige modelo según la tarea

No todas las tareas piden la misma potencia. El razonamiento profundo solo se justifica cuando diseñas arquitectura, evalúas alternativas o desenredas un bug que no cede. El resto del día, escribir una función, añadir un test, leer archivos para entender el codebase, no lo necesita. Usar siempre el modelo más capaz no te da mejores resultados en esas tareas; lo que hace es vaciarte la cuota mucho más rápido. Por eso elegir el modelo es la palanca número uno de tu consumo: pesa más que cualquier otro hábito de ahorro.

Hoy los nombres son estos (y van a cambiar, así que fíjate en el rol, no en la etiqueta): sonnet es el sensato por defecto, el que cubre el grueso del trabajo diario; reservas opus para lo difícil, donde un mal razonamiento te cuesta horas; y haiku para lo rápido y barato, búsquedas y lecturas donde la velocidad importa más que la profundidad. La regla no caduca aunque los aliases sí: asigna potencia donde de verdad cambia el resultado y baja un escalón en todo lo demás.

Cambiar de modelo es inmediato y puedes alternar a media sesión según lo que estés haciendo, sin perder el hilo de la conversación. Lo que sí cuesta es alternar a mitad de una tarea: rompe la caché y la siguiente respuesta reprocesa toda la historia sin ella, así que ese turno te sale mucho más caro (lo explico en prompt caching). La idea de elegir bien el modelo está desarrollada en su tip, con la estrategia completa de planificar, ejecutar y explorar. Si en lugar de decidir en cada sesión prefieres fijar tu modelo por defecto, ese otro tip cubre cómo se cambia y cómo queda fijado, y por qué a veces se resetea de forma inadvertida.

Effort: cuánto razona

El modelo no piensa siempre con la misma intensidad. El effort controla cuánto delibera antes de actuar: cuántos tokens de razonamiento gasta en entender el problema, sopesar opciones y planear la respuesta. No es un interruptor de inteligencia ni un límite duro de tokens. Es una señal de comportamiento: cuánto esfuerzo le pides que invierta antes de empezar a escribir.

Todo se reduce a un intercambio. Más effort significa razonamiento más profundo, pero también más tokens y más lentitud. Menos effort responde rápido y barato, a costa de pensar menos. El effort va de la mano de la elección de modelo y pesa sobre la cuota: subirlo en un modelo pesado vacía el pool mucho más rápido. La habilidad del día 1 es ajustar el effort a la dificultad real de la tarea, no dejarlo siempre arriba por inercia. Súbelo para arquitectura, debugging difícil o lógica que no perdona errores. Bájalo para renombrados, formateo o cambios mecánicos donde razonar de más solo cuesta dinero.

Los niveles disponibles hoy son low, medium, high, xhigh y max, y high es el valor por defecto en la mayoría de modelos (los nombres concretos y los defaults por modelo pueden cambiar, así que confirma los tuyos). Tienes un dial entre velocidad/coste y profundidad de razonamiento, y decides tú dónde ponerlo según lo que tengas entre manos.

Para la mecánica actual (cómo mover el slider sobre la marcha, fijarlo por variable de entorno o en settings.json, y verlo en tu status line) está el nivel de effort explicado paso a paso.

/usage: tu medidor de cuota

El medidor de cuota es invisible por defecto, y esa invisibilidad ya es parte del problema. No ves cuánto llevas gastado, así que el cerebro reptiliano acapara. Trabajas con miedo, racionas mensajes, culpas a la herramienta cuando te corta. /usage apaga ese ruido. Te enseña el bloque de la sesión actual (tokens y duración) y, debajo, las barras de tu plan: cuánto has consumido y cuánto te queda antes de tocar el límite. Pasas de adivinar a leer un número.

Lo que de verdad cambia tu forma de trabajar no es la barra, sino el desglose. /usage reparte el consumo por skill, por subagent y por MCP. Un "mensaje" no tiene un coste fijo (depende del modelo, del contexto que arrastras y de las herramientas que dispara), así que ver de dónde sale el gasto te dice qué optimizar. Ese MCP que tienes conectado y no usas, el subagent que está gastando más de lo que esperabas. Sin el desglose optimizas a oscuras.

El importe en dólares es una estimación calculada en local, solo de esta máquina. No cuenta lo que gastas desde otro dispositivo ni desde claude.ai, y tu cuota real es un pool compartido entre todas esas superficies. Por eso a veces la terminal te muestra margen de sobra y aun así te corta: el contador de tu portátil no ve lo que quemaste esta mañana en el móvil. Trátalo como una orientación, no como la verdad de tu cuenta.

La mecánica fina cambia. Hoy el panel alterna entre 24 horas y 7 días con las teclas d y w, pero eso puede moverse en cualquier release. Debajo de esa interfaz hay una idea fija: tienes un comando que convierte la cuota invisible en barras que puedes leer antes de quedarte fuera. El paso a paso, con /stats y /context al lado para la foto completa, lo tienes en /usage y /stats.

La cuota: varios relojes a la vez (la pieza que cuesta entender)

No es un contador, son varios relojes a la vez. Aprende la estructura, porque las cifras cambian.

Casi todo el mundo se pierde justo aquí, y con razón. La cuota de un plan de suscripción no es un contador único que baja hasta cero. Son varios relojes corriendo a la vez, cada uno con sus propias reglas. Mientras lo lees como "me quedan X mensajes", parece aleatorio: te corta a media tarde sin que nada lo justifique. En cuanto separas los relojes, deja de ser un misterio.

El primero es la franja de 5 horas, lo que verás llamado "sesión". Es una ventana móvil: empieza a contar con tu primer mensaje y se renueva cinco horas después de ese arranque. No es reloj de pared, no resetea a medianoche ni en punto a cada hora, son cinco horas desde que empezaste. Por encima corren uno o dos topes semanales (según tu plan), y la diferencia es esta: los semanales resetean a una hora fija asignada a tu cuenta, no se mueven, y cada ciclo recibes la cuota entera. Móvil contra fijo: ese es el concepto que casi nadie tiene claro el día 1. Y son independientes, cualquiera de ellos te puede frenar aunque te sobre margen en los demás.

Hay otra cosa que descuadra la cuenta: el plan es un solo pool compartido. Lo que gastas en claude.ai, en la app de escritorio y en Claude Code sale del mismo sitio, así que consumir mucho en uno deja secos los demás. A eso se suma que el /usage del CLI va por detrás del contador del servidor, ese desfase local que ya vimos, por el que a veces te corta antes de lo que muestra la terminal. Y no todos los turnos pesan igual: el modelo es la palanca mayor (hoy, Opus consume mucho más que Sonnet por el mismo trabajo), seguido de las sesiones largas y romper la caché a mitad de tarea.

La estructura aguanta: varios relojes, uno móvil y los semanales fijos, un pool compartido, todo visible en /usage. Las cifras exactas por plan sí cambian, y no se publican: las suben de vez en cuando, así que mira siempre las tuyas. Para los nombres de las barras de hoy, qué las vacía con detalle y cómo leer cada reset, escribí una pieza entera sobre los límites de uso: la franja de 5 horas y el tope semanal.

Prompting y permisos

Un buen prompt: concreto y verificable

Un buen prompt reduce lo que Claude tiene que adivinar: el qué, si está bien hecho y lo que de verdad querías.

La tentación del primer día es escribir como le escribirías a un compañero que ya conoce el proyecto: "arréglame el login". Claude Code no conoce tu proyecto salvo lo que le des. Un buen prompt no es una orden corta y elegante, es un encargo con suficiente contexto para que el resultado se parezca a lo que tienes en la cabeza. Tres ideas sostienen todo lo demás, y ninguna va a caducar con la próxima versión.

Sé concreto de entrada. Nombra los ficheros sobre los que quieres trabajar, en lugar de dejar que los adivine leyendo medio repositorio. Di las restricciones que importan: "no toques la API pública", "mantén el patrón de los otros componentes", "no añadas dependencias nuevas". Si ya existe un ejemplo de cómo se hace algo en tu código, señálalo: "haz el endpoint de pagos siguiendo el de usuarios". Cada dato que le das de entrada es una decisión que no tiene que inventar, y cuando inventa es cuando se desvía. La diferencia entre "añade validación al formulario" y "añade validación al formulario de RegisterForm.tsx usando el esquema de auth/schemas.ts, igual que en LoginForm.tsx" es la diferencia entre revisar su trabajo y rehacerlo.

Dale algo con lo que verificar. Claude rinde mejor cuando puede comprobar su propio trabajo en lugar de entregarte algo a ciegas. Eso significa darle un criterio objetivo de "esto está bien": un test que tiene que pasar, la salida exacta que esperas de un comando, un screenshot de cómo debería quedar la pantalla, un mensaje de error que tiene que desaparecer. Con un objetivo verificable, ejecuta, mira el resultado, corrige y vuelve a intentarlo sin que tengas que intervenir en cada vuelta. Sin él, te trae código que parece correcto y descubres el fallo tú, más tarde, cuando ya cuesta más arreglarlo. Si tienes tests, menciónalos. Si no, describe en una frase cómo sabrás que funciona.

Es una conversación, no un disparo único. El error de principiante es intentar condensarlo todo en un único mega-prompt perfecto y aceptar lo que salga. Funciona mejor al revés: empiezas con lo que quieres, miras lo que hace y lo refinas con follow-ups. "Bien, pero extrae esa lógica a un hook." "Te has dejado el caso de la lista vacía." "Renómbralo, ese nombre no encaja con el resto." No estás corrigiendo a una máquina que falló, estás dirigiendo un proceso que es iterativo por naturaleza. Si una tarea es grande o tiene decisiones de diseño, el plan mode te deja acordar el plan antes de que escriba una sola línea, y ahí es más barato cambiar de rumbo que sobre el código ya hecho.

El hilo que une las tres: reduces lo que Claude tiene que adivinar. Concreto reduce lo que adivina sobre el qué. Verificable reduce lo que adivina sobre si está bien hecho. Y conversar le quita la última adivinanza, la de lo que querías de verdad. Un prompt vago también produce algo, y casi siempre algo que parece terminado. Por eso este es el hábito que más rendimiento te devuelve el primer día. Si quieres las reglas concretas que Anthropic sigue para esto, las cinco están en prompts en Claude Code: las 5 reglas que sigue Anthropic.

Parar y redirigir un turno

Esc interrumpe sin destruir: conserva lo hecho y te devuelve el control. /stop es para sesiones en background, no para esto.

Cuando Claude Code arranca un turno y ves que va por mal camino (está editando el archivo equivocado, ha entendido mal la tarea, se ha lanzado a reescribir medio módulo cuando solo querías un ajuste), tu primer instinto suele ser malo: matar el proceso entero con Ctrl+C y empezar de cero. Es tirar a la basura el contexto y el trabajo ya hecho. La forma correcta de cortar un turno en marcha es Esc: interrumpe la respuesta o la llamada a herramienta en curso, conserva todo lo que Claude llevaba hecho hasta ese instante, y te devuelve el control para que escribas la corrección. No reinicia la conversación. No pierde lo avanzado. Solo para y espera tu siguiente instrucción. Lo desgloso con cada atajo y cuándo usar cada uno en parar y reconducir a Claude mientras trabaja.

Esto es el día a día de "dirige, no dispares". Un turno no es un comando que lanzas y ves de lejos. Es una ejecución que estás supervisando, y supervisar incluye intervenir. Pulsas Esc, lees lo que hizo, y le dices "no, ese no es el archivo" o "para, primero quiero ver el plan". Claude retoma desde donde lo dejaste con la corrección incorporada, no desde el principio. Cuanto antes interrumpas, menos trabajo equivocado tienes que deshacer después: cortar a los diez segundos es barato, dejarlo terminar y luego revertir cinco archivos no lo es.

Tres atajos parecen lo mismo y no lo son. Esc interrumpe el turno y mantiene el trabajo. Ctrl+C es otra cosa: si Claude está trabajando, lo interrumpe; pero si no hay nada en marcha, la primera pulsación te limpia el prompt que tengas escrito y la segunda cierra Claude Code (lo mismo que Ctrl+D). Y existe /stop, que sí es un comando real, pero sirve para terminar una sesión que corre en segundo plano (la vista de agentes), no para cortar el turno que tienes delante. Para lo de cada día, el que usas es Esc. Estos atajos pueden cambiar de comportamiento entre versiones, así que si alguno no responde como esperas, hoy lo confirmas en la documentación oficial de Claude Code, que mantiene la tabla de teclas al día.

Una variante útil del mismo principio: a veces no quieres parar el turno, solo preguntar algo en mitad del trabajo sin interrumpirlo. Para eso, /btw te abre una pregunta lateral que Claude responde con todo el contexto de la sesión a la vista, sin leer archivos ni ejecutar nada, sin entrar en el hilo y sin frenar lo que está haciendo. Dirigir no siempre significa cortar; a veces significa preguntar mientras avanza. Pero cuando de verdad va por mal sitio, Esc y rediriges. Sin reiniciar, sin empezar de cero.

Plan mode: revisa antes de ejecutar

El error de principiante más caro no es escribir un mal prompt. Es dejar que Claude empiece a tocar archivos antes de saber si va en la dirección correcta. El agente es tan rápido que ya ha modificado ocho ficheros cuando te das cuenta de que entendió otra cosa. Y revertir ocho cambios entrelazados cuesta más que el cambio original. Plan mode existe para que eso no ocurra.

En plan mode, Claude trabaja en modo solo lectura. Explora el código, lee los archivos relevantes, ejecuta comandos que no escriben nada, y a partir de ahí propone un plan paso a paso. No toca un solo fichero hasta que tú apruebas. Lo importante no es que Claude planifique mejor (un agente sin restricciones también podría planificar), sino que el plan se convierte en un punto de control donde decides tú. Lo lees, ves qué archivos piensa tocar, detectas que va a modificar un util compartido que no esperabas, lo corriges, y solo entonces se ejecuta. La dirección equivocada se descubre en treinta segundos de lectura, no en veinte minutos de deshacer.

Conceptualmente, plan mode separa dos cosas que la prisa tiende a fundir: decidir qué hacer y hacerlo. Cuando las juntas, apruebas a ciegas y descubres el problema con el código ya escrito. Cuando las separas, el coste de equivocarte cae a casi cero, porque el error vive en un plan que aún no ha tocado nada. Por eso compensa incluso para cambios que parecen triviales. Una pregunta inocente puede arrastrar más superficie de la que imaginas, y el plan te lo enseña antes, no después. El coste de planificar es bajo y fijo. El coste de no planificar es indefinido.

Se cicla con Shift+Tab, que rota entre los modos de permisos hasta llegar a plan. Hay varias formas de entrar (un solo turno, una sesión entera, o por defecto en un proyecto crítico). Cuando el plan está listo, Claude ofrece un menú de cinco opciones: unas aprueban directamente (en auto, aceptando ediciones, o revisando cada cambio a mano), y las demás iteran o refinan el plan antes de tocar nada. Aparte del menú, antes de aprobar puedes pulsar Ctrl+G para abrir el plan en tu editor, anotarlo y reordenarlo. La mecánica concreta y el flujo completo (cómo combinarlo con una revisión del propio plan antes de implementar) está en el tip sobre el plan mode.

Permisos sin fatiga (Shift+Tab)

El día 1, Claude te pide permiso antes de cada edición y cada comando. Es lo correcto cuando no confías todavía en la dirección, pero a los diez minutos cansa: confirmas, confirmas, confirmas. De ahí la tentación de irse al otro extremo y desactivarlo todo. El error es creer que solo hay dos opciones, vigilar cada movimiento o dejarlo suelto sin red. La autonomía no es un interruptor, es un dial. Tú decides en qué punto te sientas, y lo ajustas según la tarea.

Shift+Tab cicla los modos sin salir de la sesión. El que resuelve la fatiga el día 1 es acceptEdits: Claude crea y edita archivos sin preguntar, y también aprueba los comandos básicos del sistema de archivos. El resto de comandos (tus tests, git push, curl) sigue pidiendo permiso. Las ediciones fluyen, lo que de verdad importa revisar se sigue parando. Es el mismo Shift+Tab con el que entras en plan mode, así que con una sola tecla recorres los modos básicos, de revisar cada cambio a dejar que itere solo sobre el código.

La otra mitad de la fatiga viene de los comandos que ejecutas cien veces al día. Para eso están las reglas allow: preapruebas comandos concretos (tus tests, tu git add) y dejan de preguntar, mientras todo lo demás sigue pidiendo confirmación. Es la diferencia entre quitar la red de seguridad y recortarla a tu medida. Las dos piezas juntas, acceptEdits para las ediciones y las reglas allow para los comandos, matan la fatiga sin convertir a Claude en un proceso sin supervisión.

Hoy hay más modos que estos dos, desde mirar sin tocar hasta autonomía casi total, y cada uno aprueba cosas distintas (lo que confunde a casi todo el mundo es qué tapa exactamente cada uno). El conjunto completo y la mecánica de cada modo están en el tip sobre los modos de permiso. Por debajo de los modos de hoy, una sola idea: la fricción de permisos es un dial, y tú lo controlas.

El mapa de extensibilidad

Qué es cada cosa: orquestador, subagente, skill, plugin, hook, MCP

Hook corre solo y siempre; skill es conocimiento que el modelo trae cuando hace falta; subagente es un worker con su propio contexto; MCP añade herramientas externas; plugin empaqueta varios.

El principiante mezcla seis términos porque intenta separarlos por lo que hacen, y por ese eje no se separan bien. El eje que de verdad los distingue es otro: qué los dispara. Quién decide que esa pieza entre en juego. Una vez fijas ese eje, el mapa se ordena solo. Si quieres la mecánica de cada uno en detalle, está en los 6 mecanismos de extensión que todos confunden.

El orquestador (el agente main) es el loop principal, con el que hablas tú. No es una pieza que añades: es Claude Code en sí, el que lee tu prompt, llama herramientas y decide los pasos. Todo lo demás cuelga de él. Un subagente es un trabajador aparte que ese main lanza cuando una tarea conviene aislarla, y su rasgo definitorio es que tiene su PROPIO contexto: una ventana separada de la tuya. Lo dispara el orquestador, no tú directamente. Una skill no es un agente ni ejecuta nada por su cuenta: es conocimiento (un SKILL.md) que el modelo CARGA en contexto cuando lo considera relevante, o que invocas tú con un slash. De hecho los slash commands se han fusionado con las skills, así que un slash command no es una pieza distinta, es solo una forma de invocar: un prompt guardado que disparas a mano.

Las tres siguientes cambian quién aprieta el gatillo. Un hook lo dispara el sistema, solo, de forma determinista, ante un evento del ciclo de vida (PreToolUse, PostToolUse, Stop). El modelo no decide si corre: corre siempre que se cumple la condición. Suele ser un comando de shell, aunque puede ser HTTP, MCP, un LLM o un subagente. MCP juega en otra categoría: no es algo que se dispare, es un protocolo que conecta a Claude con herramientas y datos EXTERNOS (por stdio o HTTP), una base de datos, una API, tu Notion. Le da manos para llegar fuera de su sandbox. Y un plugin no dispara nada por sí mismo: EMPAQUETA varias de las piezas anteriores (skills, commands, agents, hooks y configuración de MCP) en una unidad instalable que se distribuye por un marketplace, como un paquete de npm pero para extender Claude Code.

El hook corre solo; la skill es conocimiento que el modelo trae; el subagente es un trabajador con su propio contexto; MCP son herramientas externas; el plugin empaqueta varias piezas; y el slash command es un prompt guardado. Los nombres de los eventos y la estructura exacta de cada archivo pueden moverse de una versión a otra (eso es lo volátil, míralo hoy en el tip), pero estas seis categorías y lo que dispara a cada una llevan tiempo estables y no es probable que cambien.

Productividad del día 1

Status line: tu estado de un vistazo

El primer día trabajas a ciegas sobre tu propia sesión. No sabes qué modelo está activo, cuánto contexto te queda, cuánto llevas gastado ni en qué rama estás escribiendo. Toda esa información existe, pero está repartida entre comandos como /model, /context o /usage, y la rama la ves aparte en git o en tu prompt. En el momento en que dejas de mirarlos vuelves a la oscuridad. La status line es la barra inferior de Claude Code, y resuelve eso: en lugar de preguntar, lo tienes siempre delante.

Esa barra no la decide Anthropic. La pinta un script tuyo. Claude Code te pasa los metadatos de la sesión y tu script decide qué mostrar y cómo. Por eso puedes poner ahí exactamente lo que a ti te duele perder de vista: el modelo, el porcentaje de contexto ocupado, el coste, la rama de git. Esa es la idea que no caduca, aunque cambien los nombres de modelo o el formato de los datos: tú controlas qué información de la sesión está visible de forma permanente, sin tener que pedirla.

Y conecta con casi todos los problemas del día 1 que ya hemos visto. El medidor invisible que te hace acaparar cuota deja de ser invisible. El contexto que se llena en silencio hasta que salta la compactación lo ves subir antes de que se llene. El modelo caro que activaste sin querer aparece en pantalla en vez de verlo reflejado en la factura. La status line no es un adorno, es el panel de instrumentos que convierte la fontanería invisible en algo que miras de reojo mientras trabajas. Pequeña, pero se nota desde el primer día.

Montar una status line son unas pocas decenas de líneas de bash, o ni eso si dejas que Claude te la genere. La mecánica concreta (qué datos llegan, cómo se activa, cómo encargarla en lenguaje natural) está en el tip, que se actualiza cuando el formato cambie. Tu estado, siempre a la vista, decidido por ti.

La cheat sheet de slash commands

Un slash command es lo que escribes empezando por /: /clear, /context, /model. Unos son nativos de Claude Code, otros son prompts guardados que defines tú o instalas con un plugin. No es magia ni una sintaxis aparte. Es la forma de invocar algo concreto sin redactarlo en lenguaje natural cada vez. El día 1 el problema no es entender qué son, es que hay muchísimos y no sabes cuál existe para lo que quieres hacer.

La documentación oficial los lista en orden alfabético. Sirve cuando ya sabes el nombre. No sirve cuando lo que sabes es la intención ("quiero vaciar el contexto", "quiero ver cuánto me queda de cuota") pero no recuerdas el comando. Por eso vale la pena tener la cheat sheet de slash commands a mano: los agrupa por lo que quieres conseguir, no por la inicial. No la necesitas para memorizarla. La necesitas para los primeros días, mientras el mapa todavía no está en tu cabeza.

No hace falta que te aprendas ninguno. Escribe / solo, sin nada más, y Claude Code te despliega el menú filtrado por tu plan y tu plataforma. Sigue escribiendo letras y filtra en tiempo real. Esa es la red de seguridad. El cuántos hay (hoy rondan los 80, y puede cambiar en cualquier release), cuáles se han añadido y cuáles se han retirado es justo lo que se mueve cada semana, y por eso vive en el tip y no aquí. Si no te acuerdas del nombre, escribe / y deja que el menú te lo recuerde.

Bash mode con !

Escribes ! delante de un comando y se ejecuta en tu shell sin salir de Claude Code. ! git status, ! npm test, ! ls -la. No es Claude quien lo interpreta ni quien pide permiso: va directo a tu terminal, igual que si lo hubieras tecleado tú. Es un atajo cómodo para no abrir otra pestaña, sí.

Pero lo que de verdad cuenta es que la salida del comando se queda en la conversación, y Claude la ve. Un terminal normal te devuelve el resultado a ti y ahí muere. El bash mode lo convierte en contexto: ejecutas ! npm test, fallan tres tests, y la siguiente pregunta ya puede ser "arregla esto", sin pegar el stack trace. El agente trabaja sobre lo que acaba de pasar de verdad en tu máquina, no sobre tu resumen de lo que pasó. Esa es la diferencia que no cambia entre versiones: el shell deja de ser una herramienta aparte y pasa a ser parte de lo que el agente sabe.

El día 1 esto cierra una grieta concreta. Lo normal cuando empiezas es tener Claude Code en una ventana y un terminal en otra, saltando entre las dos: ejecutas algo en el terminal, lees el error, vuelves, se lo describes con tus palabras. En esa traducción se pierde información y se cuela ruido. Con el bash mode el bucle es uno solo. Verificas y avanzas en el mismo sitio donde estás conversando.

Los detalles de uso (mandar un build largo al background, autocompletar comandos desde tu historial del proyecto) los cubro en el tip de el bash mode con !. El ! no es solo correr un comando, es darle al agente los ojos sobre tu shell.

/doctor cuando algo va raro

Cuando algo se rompe el día 1, lo difícil no es arreglarlo, es saber de quién es la culpa. ¿Falla tu prompt, falla Claude, o falla tu configuración? El instinto del principiante es ir a buscar el síntoma a un foro y perder cuarenta minutos en hilos que no van a ningún sitio. /doctor existe para cortar eso de raíz. No depura tu código, audita tu instalación y tu configuración: revisa que el binario esté bien, que tus settings.json sean válidos, que tus MCP conecten, que tus hooks y permisos no estén mal puestos. Todo eso que no se ve y que, cuando está roto, hace que Claude se comporte de forma rara sin decirte por qué.

El valor real está en lo que te dice el informe, no en sus detalles. Si algo sale mal, ya sabes exactamente dónde mirar antes de tocar nada más. Y si sale todo limpio, acabas de descartar tu setup como sospechoso: el problema está más arriba (el servicio, la red, un bug del día), y te has ahorrado la búsqueda sin rumbo. Esa lógica de triage lo convierte en reflejo de día 1, no en comando de emergencia. Antes de buscar tu error fuera, pregúntale a la propia herramienta si el problema lo tiene ella.

La mecánica concreta (qué chequea exactamente, cómo lees el informe, cómo dejar que Claude arregle lo que encuentra, y la variante que corre incluso cuando el CLI no arranca) la tienes paso a paso en el tip de /doctor. Eso puede cambiar de versión a versión. El hábito no: ante cualquier comportamiento extraño, /doctor primero.

Día 2: cuando ya te mueves

La vista de agentes

Cuando ya tienes soltura con una sesión, el siguiente paso es trabajar en paralelo. Lanzas un bug fix en una terminal, una revisión de PR en otra, una investigación de un flaky test en una tercera. A los veinte minutos tienes media docena de pestañas abiertas, no recuerdas cuál se quedó esperando una respuesta tuya, y alguna ha muerto porque cerraste la terminal sin querer. La vista de agentes (claude agents) resuelve ese caos de pestañas: una sola pantalla, una fila por sesión, y el estado de cada una a la vista. Cuál sigue trabajando, cuál te pregunta algo, cuál ya terminó. Es la capa de supervisión que el paralelismo necesita para no convertirse en caos.

Va en el día 2 y no en el núcleo del día 1 porque cada sesión consume cuota de forma independiente. Diez agentes en paralelo gastan diez veces. Si todavía estás aprendiendo a leer tus propias franjas de uso, abrir varios frentes a la vez es la forma más rápida de quemar tu cuota, incluido el límite semanal que te deja fuera durante días. Primero entiende cómo se vacía tu cuota con una sola sesión. Cuando eso lo tengas interiorizado, el paralelo deja de ser una trampa y pasa a ser una palanca.

Hoy la vista de agentes es research preview (v2.1.139+) y la interfaz puede cambiar de un release a otro, así que los atajos y los detalles concretos viven en el tip, que se actualiza por su cuenta. La idea de fondo aguanta por encima de la UI: en cuanto trabajas con más de un agente a la vez, necesitas un panel único que te diga el estado de cada uno sin tener que ir pestaña por pestaña. Esa necesidad seguirá ahí aunque la UI de mañana no se parezca a la de hoy.

Worktrees para tareas paralelas

Una rama de git, normalmente, vive en un solo directorio de trabajo. Cambias de rama y el directorio entero muta debajo de tus pies: archivos que aparecen, archivos que desaparecen, el estado de uno se pierde mientras editas el otro. Los worktrees rompen esa restricción. Un worktree es un directorio de trabajo adicional, vinculado al mismo repositorio, con su propia rama y su propio estado de archivos. Comparten el .git; no comparten nada más. Eso es lo que no cambia, y es lo único que necesitas entender para usarlos.

El valor aparece cuando dejas de pensar en una tarea cada vez. Tienes una feature a medias, entra un bug urgente. Sin worktrees, paras la feature y arrastras la rama por el ritual del stash: guardas, cambias, arreglas, vuelves, recuperas y confías en que nada se haya cruzado. Con un worktree abres el arreglo en su propio directorio, en su propia rama, y la feature se queda exactamente donde la dejaste. Llevado a Claude Code, cada worktree puede tener su propia sesión: dos tareas avanzando en paralelo, en el mismo repo, sin pisarse. El aislamiento es el punto, no la cantidad de instancias.

Esto es día 2 por una razón. No es un concepto difícil, pero ocupa atención, y el día 1 la cabeza la tienes en otra parte (dónde viven tus sesiones, cómo no quemar la cuota, qué sobrevive a una compaction). Los worktrees no resuelven ninguno de esos problemas. Resuelven uno que solo notas cuando ya te mueves con soltura y empiezas a estorbarte a ti mismo: estar esperando a que termine una cosa para arrancar la siguiente. El día que esa espera te moleste, ya tienes los fundamentos automatizados, y ese es el momento de mirar esto.

La mecánica concreta (el flag con el que Claude Code los crea, dónde los coloca, cómo los limpia al salir) la cubre el tip paso a paso. Esos detalles son los que pueden moverse entre versiones; el concepto, una rama aislada en su propio directorio compartiendo el mismo repo, no.

El resumen que no caduca

La estructura no cambia: las sesiones viven por directorio, el contexto se llena y se compacta, la cuota son varios relojes (uno móvil y los semanales fijos), y eliges modelo según la tarea. Las cifras y los nombres sí cambian, y por eso el detalle vive en los tips, que actualizo por mi cuenta. De eso presumo: esto sigue siendo cierto dentro de seis meses.

La curva es alta al principio. Persevera, y apóyate en la documentación de Anthropic, que es muy buena. Escribo un tip de Claude Code cada día por si quieres estar al tanto sin perseguir el changelog tú solo.