Cuando trabajas con varios proyectos en Claude Code — una terminal por workspace en WSL — surge una duda razonable: ¿la ventana de contexto se comparte entre instancias? Si el pool de 1M tokens fuera a nivel de cuenta, cuatro sesiones significarían 250K por sesión. Es una restricción importante que vale la pena entender antes de abrir terminales a lo loco.
La respuesta: cada instancia de Claude Code recibe su propia ventana de contexto independiente de 1M tokens. No se reparte ni se diluye. Los rate limits, en cambio, sí se comparten entre todas las sesiones de tu cuenta — más sesiones significa alcanzar ese techo más rápido.
Cómo funciona el contexto con múltiples instancias
Cuando lanzas Claude Code en una terminal, se crea una sesión completamente independiente. Esa sesión recibe su propia ventana de contexto — hasta 1 millón de tokens en Opus 4.6 y Sonnet 4.6.
Si abres otra terminal en un proyecto diferente y lanzas otra sesión de Claude Code, esa también recibe su propia ventana de 1M tokens. Las dos sesiones no saben que la otra existe. No comparten memoria, historial de conversación ni estado de contexto.
En concreto:
- 4 sesiones activas = 4 ventanas de contexto de 1M independientes
- Cada sesión carga su propio CLAUDE.md, archivos del proyecto e historial de conversación
- Auto-Compaction ocurre de forma independiente en cada sesión
- Ejecutar
/compacto/clearen una sesión no afecta en nada a las demás
No es como dividir un pastel — cada sesión recibe un pastel entero.
Lo que sí se comparte: los rate limits
Aquí viene la confusión. Aunque las ventanas de contexto son independientes, los rate limits se comparten en toda tu cuenta.
Tu suscripción Pro o Max tiene un solo pool de uso. Cada sesión de Claude Code, cada chat en claude.ai, cada sesión de Cowork — todos consumen del mismo pool. Anthropic lo controla con una ventana rodante de 5 horas y un tope semanal.
Cuando ejecutas múltiples instancias simultáneamente:
- El consumo de tokens se multiplica. Si una sesión típica usa 50K tokens por interacción, tres sesiones al mismo tiempo consumen 150K tokens de tu rate limit en el mismo período
- Los límites de throughput se acumulan. Cada llamada API de cada sesión cuenta contra el límite de requests por minuto. Tres sesiones simultáneas triplican tu tasa de requests
- Opus es el cuello de botella más estrecho. Opus tiene límites de throughput mucho más estrictos que Sonnet o Haiku. Dos sesiones de Opus en paralelo pueden superar fácilmente los límites de requests concurrentes
Con cuatro sesiones simultáneas, consumes tu rate limit a 4x de velocidad. La calidad del contexto no cambia — pero el tiempo disponible se reduce.
Pro vs Max: cómo manejan las sesiones paralelas
La diferencia entre planes importa mucho cuando ejecutas múltiples instancias.
| Pro ($20/mes) | Max 5x ($100/mes) | Max 20x ($200/mes) | |
|---|---|---|---|
| Multiplicador de uso | 1x | 5x | 20x |
| Sesiones Opus en paralelo | 1 práctica | 2-3 cómodas | 4-5+ cómodas |
| Sesiones Sonnet en paralelo | 2-3 | 5-8 | 10+ |
| Reset de rate limit | 5h rodante | 5h rodante | 5h rodante |
Con Pro, dos sesiones de Opus en paralelo agotan los límites en minutos. Max 5x da margen suficiente para 2-3 sesiones concurrentes de Opus sin throttling constante.
Estrategias prácticas para múltiples instancias
El contexto es independiente, los rate limits son compartidos. Con eso en mente, estos son patrones prácticos para manejar múltiples sesiones.
Estrategia 1: Distribuye el uso de modelos
No lo ejecutes todo en Opus. Reserva Opus para la sesión que hace trabajo arquitectónico complejo y usa Sonnet o Haiku para el resto. Puedes configurar el modelo por sesión o globalmente.
# Terminal 1: Refactoring complejo — usa Opus
claude --model opus
# Terminal 2: Escribir tests — Sonnet va sobrado
claude --model sonnet
# Terminal 3: Arreglar errores de lint — Haiku es suficiente
claude --model haiku
Esto reduce drásticamente la presión sobre los rate limits porque el throughput de Opus es el cuello de botella.
Estrategia 2: Rota en vez de paralelizar
En lugar de cuatro sesiones simultáneas, trabaja en bloques enfocados:
- Inicia una sesión para el Proyecto A, dale una tarea compleja
- Mientras trabaja, cambia a la sesión del Proyecto B
- Cuando A termine, revisa el output y asigna la siguiente tarea
- Revisa el progreso de B
Dos sesiones en rotación suelen ser más productivas que cuatro compitiendo por throughput.
Estrategia 3: Monitorea con la línea de estado
La línea de estado de Claude Code ejecuta un script personalizado que muestra información en tiempo real en la parte inferior de cada sesión — nombre del modelo, costo en tokens, porcentaje de contexto usado y más. Configúrala para ver cuánto está consumiendo cada sesión.
Si notas que el costo de una sesión sube rápido, es tu señal para pausar las sesiones menos críticas antes de que llegue el throttling.
Estrategia 4: Separa trabajo pesado y ligero
Agrupa tu trabajo por intensidad:
- Sesiones pesadas (lectura masiva de archivos, generación de código, contexto largo): Limita a 1-2 simultáneas
- Sesiones ligeras (preguntas rápidas, ediciones menores): Puedes tener más sin gran impacto
Agent Teams vs instancias separadas
La función Agent Teams de Claude Code permite lanzar sub-agentes desde una sesión principal. También tienen contextos independientes, pero incluyen mecanismos de coordinación. Por ahora es una función experimental — necesitas habilitarla con CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1.
Diferencias clave con abrir terminales por separado:
| Terminales separadas | Agent Teams | |
|---|---|---|
| Aislamiento de contexto | Sí | Sí |
| Comunicación entre sesiones | Ninguna (copy-paste manual) | Mensajería integrada |
| Coordinación de tareas | Manual | Lista de tareas compartida con dependencias |
| Impacto en rate limits | Mismo pool | Mismo pool |
| Esfuerzo de configuración | Cero | Requiere configuración del equipo |
Si tus múltiples sesiones son para proyectos totalmente independientes, abrir terminales separadas es más simple. Si necesitan coordinarse en el mismo codebase, Agent Teams ofrece canales de comunicación que las terminales separadas no tienen.
¿Cuántas instancias deberías ejecutar?
Una guía práctica según tu plan y carga de trabajo:
1 instancia — Ideal para usuarios de Pro, o cuando haces trabajo profundo y enfocado en un solo proyecto. Todo el presupuesto de rate limit para una sesión significa menos interrupciones y respuestas más rápidas.
2 instancias — El punto óptimo para usuarios de Max 5x. Ejecuta tu proyecto principal en Opus y una tarea secundaria en Sonnet. Rara vez tocarás los rate limits, y la ganancia de productividad por paralelismo es real.
3-4 instancias — Solo práctico con Max 20x. Incluso así, mantén como máximo una en Opus. Los rendimientos decrecientes aparecen rápido — empiezas a gastar más tiempo cambiando entre sesiones del que ahorras con el paralelismo.
5+ instancias — Territorio de rendimientos decrecientes incluso en Max 20x. A este nivel, tu limitación no es Claude — es tu propia capacidad para revisar y dirigir tantas conversaciones simultáneas.
Si además de los rate limits tienes errores de context window exceeded, la solución real es mejorar la higiene de sesiones, no agregar más. Revisa la guía para reducir el consumo de tokens un 50%, el análisis profundo sobre por qué Claude Code olvida tus instrucciones, y el cheatsheet de comandos de Claude Code para referencia rápida sobre /compact, /clear y otros comandos de gestión de sesiones. Para problemas generales, consulta la guía de troubleshooting.
FAQ
¿Cada instancia recibe la ventana completa de 1M tokens?
Sí. Cada sesión de Claude Code se ejecuta con su propia ventana de contexto independiente de 1M tokens (en Opus 4.6 y Sonnet 4.6). Ejecutar múltiples instancias no divide ni reduce la ventana de contexto de ninguna sesión individual.
¿Las múltiples instancias comparten rate limits?
Sí. Todas las sesiones de Claude Code, chats de claude.ai y sesiones de Cowork en la misma cuenta comparten un solo pool de rate limits. Tres sesiones simultáneas consumen tu cuota tres veces más rápido que una sola.
¿Ejecutar dos sesiones hace que cada una sea más lenta?
No directamente — la velocidad de procesamiento de contexto de cada sesión no se ve afectada. Sin embargo, si la tasa combinada de requests de ambas sesiones supera el límite de throughput de tu plan, verás throttling (respuestas más lentas o errores temporales) en ambas.
¿Puedo usar Claude Code en VS Code y en la terminal al mismo tiempo?
Sí. Una sesión en VS Code y otra en la terminal se tratan como dos instancias separadas con ventanas de contexto independientes. Ambas consumen del mismo pool de rate limits.
¿Es mejor una sesión de Opus o dos de Sonnet?
Depende de la tarea. Para decisiones arquitectónicas complejas y refactoring multi-archivo, una sesión de Opus da mejores resultados. Para tareas independientes en paralelo como escribir tests y arreglar errores de lint, dos sesiones de Sonnet son más eficientes porque Sonnet tiene límites de throughput más generosos.
¿Agent Teams cuenta contra los mismos rate limits?
Sí. Los Agent Teams son sesiones de Claude Code separadas internamente. Cada compañero consume tokens del mismo pool de la cuenta. La ventaja es la coordinación, no el aislamiento de rate limits.
¿Si alcanzo el rate limit en una sesión, afecta a las demás?
Sí. Los rate limits se aplican a nivel de cuenta, así que alcanzar el límite en una sesión significa que todas las demás también se verán throttled hasta que la ventana rodante se reinicie.
¿/compact en una sesión libera rate limits para las otras?
No. /compact reduce el tamaño del contexto dentro de esa sesión, lo que ayuda a evitar errores de context window exceeded. No afecta al consumo de rate limits de toda la cuenta — esos tokens ya fueron contabilizados cuando se enviaron originalmente.
Conclusión
El modelo mental es simple: el contexto es por sesión, los rate limits son por cuenta.
Cada instancia de Claude Code es un proceso completamente independiente con su propia ventana de contexto de 1M tokens. Ejecutar múltiples sesiones no divide, diluye ni degrada la calidad del contexto de ninguna sesión. Lo que sí hace es consumir el presupuesto de rate limits de tu cuenta más rápido.
Para la mayoría de desarrolladores, dos sesiones concurrentes en un plan Max es el balance ideal — suficiente paralelismo para multitarea, suficiente moderación para evitar throttling constante. Si estás en Pro, una sesión enfocada a la vez suele ser lo más productivo.
La verdadera pregunta no es "¿cuántas sesiones puedo ejecutar?" sino "¿cuántas sesiones puedo dirigir productivamente al mismo tiempo?" En mi experiencia, el cuello de botella humano llega mucho antes que el técnico.