Qué es Projects en Claude Code: cómo reparte Claude los hilos, quién puede usarlo, el requisito de GitHub y lo que cuesta en tokens

El 17 de septiembre de 2026, Anthropic anunció que había reconstruido Projects en Claude Code. El nombre no es nuevo: es la misma palabra que el chat de claude.ai usa para la caja donde se guardan juntas las conversaciones y los archivos de referencia. El nuevo Projects conserva ese nombre y sustituye todo lo que hay detrás. El subtítulo de la entrada oficial del blog es, por sí solo, la respuesta entera: «de la carpeta a la conversación».

En una frase, lo que ha cambiado es que el trabajo de repartir las tareas ha pasado de ti a Claude. Tú sueltas una petición en la conversación, Claude la divide en «hilos», los hilos se ejecutan en paralelo en la nube y cada uno abre un pull request y te informa cuando termina. Cerrar el portátil no los detiene.

Antes de lanzarte, conviene comprobar tres cosas: las cuentas que pueden usarlo siguen siendo limitadas, GitHub es un requisito en la práctica y el ritmo al que se come tu límite de uso no se parece en nada al de una sola sesión. Este artículo vuelve a las fuentes primarias, la documentación de Claude Code y el blog oficial, para repasar si puedes usarlo y qué ocurre una vez que lo haces.

1. Ya no es una carpeta, sino una sola conversación

El nuevo Projects se construye con dos piezas: la conversación del proyecto, donde Claude hace de coordinador, y los hilos que esa conversación pone en marcha.

La conversación es una sesión de larga duración. Lee lo que le envías, responde en el momento cuando basta con una respuesta y separa en un hilo todo lo que equivale a trabajo. No está mirando lo que ocurre dentro de esos hilos. Solo ve lo que le informan.

Los hilos son donde ocurre el trabajo. Cada uno es una sesión en la nube independiente, con su propia ventana de contexto. Trabaja en su propia rama, abre un pull request cuando toca e informa a la conversación al terminar. La documentación describe los estados de los hilos alineados en una lista llamada Overview, así.

Lo que conviene retener aquí es que trabajar en paralelo no es la novedad. Claude Code ya tenía subagentes, agent view, agent teams y dynamic workflows. Lo que Projects añade no es el paralelismo, sino otras dos cosas: ya no eres tú quien reparte y hace el seguimiento, y el trabajo no se esfuma cuando cierras la máquina. La documentación lo dice tal cual, al afirmar sin rodeos que poder ejecutar cosas en paralelo no es para lo que está Projects.

2. El mismo nombre, pero no es el Projects de antes

Lo confuso es que el chat de claude.ai también tiene «Projects». Aquel es un contenedor de conversaciones y archivos, sin hilos y sin coordinador. El nombre idéntico invita a la confusión, pero la documentación los trata como funciones distintas.

3. Quién puede usarlo: cómo saber si ya te ha llegado

A 19 de septiembre de 2026 es una beta pública que se despliega por fases. Las condiciones están escritas con bastante detalle, así que aquí van, casi literalmente.

La segunda es la más fácil de pasar por alto. Cuantos más proyectos antiguos hayas acumulado en el lado del chat, más tarde te llegará el nuevo Projects. El blog oficial dice que los proyectos existentes siguen funcionando de momento y que se irán actualizando a medida que se amplíe el despliegue. Dicho de otro modo, los primeros no son los usuarios intensivos: son las cuentas que parten de cero.

Si no está en tu barra lateral, es que no te ha llegado el turno. En ese caso puedes apuntarte a la lista de espera. Mirar en el sitio correcto importa más de lo que parece: aparece del lado de Code, en la barra lateral de claude.ai/code o en la pestaña Code de la aplicación de escritorio. Por mucho que rebusques en la barra lateral del chat, lo que encontrarás allí es el Projects antiguo.

4. Necesita GitHub, y aquí es donde mucha gente se queda fuera

Esta es la restricción que más duele en la práctica. El único código que un hilo puede tocar es el que está en github.com, y la Claude GitHub App tiene que estar instalada en ese repositorio. La documentación enumera las condiciones así.

• El código vive en github.com. GitHub Enterprise Server, GitLab y Bitbucket quedan fuera
• La cuenta de GitHub conectada tiene permiso de push en ese repositorio
• La Claude GitHub App está instalada en ese repositorio. Un token que hayas añadido con /web-setup sirve para otras sesiones en la nube, pero no basta para los hilos de un proyecto
• En los repositorios de una organización, solo un propietario de la organización puede completar la instalación (a cualquier otra persona le sale una solicitud de aprobación)

Lo que significa que quien programa por su cuenta desde un repositorio bare en su propio servidor git o en un alojamiento compartido queda fuera de alcance tal como están hoy las cosas. Lo mismo vale para una API detrás de la VPN corporativa, una base de datos en tu portátil, un emulador de dispositivos o un servidor de producción al que llegas por SSH: los hilos viven fuera de tu máquina, así que no pueden tocar nada de eso.

¿Eso deja sin nada a quien no usa GitHub? No del todo. Se puede crear un proyecto sin repositorio. Subir una carpeta de contratos o una exportación de tickets de soporte, darle a un hilo un encargo del tipo «enumera los diez errores de integración que más se repiten aquí dentro» y recoger el resultado en la pestaña Library es un uso que la documentación contempla de forma explícita. Los archivos que subes se pueden leer desde un hilo en /mnt/project-files.

Si el trabajo es código y necesita tu propio entorno, a lo que hay que recurrir es a ejecutar sesiones locales en paralelo en agent view. Eso corre en tu propia máquina, así que tu VPN, tu base de datos local y tu SSH siguen funcionando.

5. Con qué arranca un hilo

Un hilo no empieza de cero cada vez. Arranca con el contexto que le da el proyecto, y son cuatro las cosas que lleva consigo.

• Los repositorios y los archivos del proyecto: cada repositorio registrado se clona siempre, lo toque la tarea o no
• Las instrucciones del proyecto: un briefing común que llega a todos los hilos. El tope son 16.000 caracteres
• La memoria del proyecto: notas que Claude escribe para sí mismo. Lee el índice MEMORY.md al arrancar y abre los archivos sueltos cuando los necesita
• El entorno en la nube: qué destinos de red están permitidos, las variables de entorno, las credenciales de API y las herramientas instaladas de antemano

De todo ese equipaje, la parte que más papeletas tiene de provocar un accidente es esta: los archivos de configuración de un repositorio se tratan de forma distinta según el proyecto tenga uno o varios repositorios. Ordenando la tabla de la documentación queda lo siguiente.

La razón es sencilla: los permisos, los hooks y las variables de entorno solo se leen del .claude/settings.json que hay en el directorio donde ha arrancado el hilo. Con más de un repositorio, el hilo arranca un nivel por encima de los clones, así que la configuración de ningún repositorio queda en un sitio que se lea. Añadir un solo repositorio más apaga tus hooks en silencio, y nada te avisa. Para los proyectos con varios repositorios, lo que la documentación recomienda es poner las reglas comunes en las instrucciones del proyecto y las variables de entorno en el entorno en la nube.

Sobre MCP, ya que estamos: los servidores MCP que puede usar un hilo son los conectores de tu cuenta de claude.ai. Un servidor MCP instalado solo en tu máquina nunca le llega. Y la conversación del proyecto no tiene ningún conector, así que el trabajo que necesite uno hay que llevarlo a un hilo en lugar de pedirlo en la conversación.

6. Cuánto más cuesta en tokens

Es la pregunta que casi todo el mundo se hace antes de activarlo. La documentación es tajante: un proyecto consume tus límites más deprisa que una sola sesión y, en Pro sobre todo, cuenta con alcanzar el límite antes los días que ejecutes uno. El aumento viene de varias cosas que se suman.

El ④ merece especial cuidado. Cuando el hilo de un proyecto abre un pull request, vigila ese PR con auto-fix activado por defecto. Aunque hayas desactivado auto-fix para tus demás sesiones en la nube, los hilos de un proyecto se tratan aparte. Arreglará la CI que falle, responderá a los comentarios de revisión e informará cuando todo pase, y a cambio seguirá comiéndose tu consumo mientras lo dejes ahí. Para pararlo, dile a ese hilo que deje de vigilar el PR.

¿Cuánto más es, entonces? Para Projects no se ha publicado ningún multiplicador, pero para los agent teams, que funcionan con la misma idea de repartir una tarea entre varias sesiones, la documentación sitúa la cifra en unas siete veces una sesión estándar cuando los compañeros de equipo se ejecutan en modo plan. Ejecutar cosas en paralelo es una forma de comprar velocidad, no de ahorrar, y eso sí lo tienen en común.

También conviene saber dónde están los frenos y hasta qué punto aguantan.

• No hay tope para cuántos hilos se ejecutan a la vez. Puedes decir «no pases de dos», pero la documentación es explícita en que eso es una instrucción que Claude intenta seguir, no un ajuste que se imponga. El único límite duro son 200 hilos al día (sumando todos los proyectos)
• Un hilo que alcanza tu límite de uso espera por su cuenta y se reanuda automáticamente en cuanto el límite se reinicia. Déjalo estar y empezará a gastar la siguiente ventana sin preguntar (para pararlo, pulsa Stop en el hilo o pausa el proyecto). La excepción es un hilo lanzado por una rutina, que da error en lugar de esperar
• Las máquinas virtuales de la nube no cuestan nada aparte. Lo único que sube son los tokens
• Un proyecto inactivo, sin hilos en marcha, sin PR vigilados y sin mensajes nuevos, no consume nada de tu cuota

7. Cómo elegir entre las cinco formas de trabajar en paralelo

Claude Code tiene ya cinco formas de sacar trabajo adelante en paralelo. Projects es una de ellas, y lo que la separa del resto es quién reparte el trabajo y dónde se ejecuta. Reordenando la comparativa de la documentación en torno a cómo elegirías de verdad queda esto.

Trazar la línea para tu propia situación se reduce más o menos a dos preguntas. ¿El trabajo necesita tu propio entorno (una base de datos local, una VPN, SSH)? Si lo necesita, Projects no es una opción. ¿El trabajo va a quedar terminado hoy? Si va a quedar, llevarlo a la nube te aporta poco y con agent view basta. Para la diferencia entre los subagentes y los agent teams, hay un artículo aparte que compara ambos en detalle.

8. Qué hacer antes de mandar el primer lote

La documentación enumera cuatro cosas que hacer «antes de tu primer lote», y todas ellas salen caras de arreglar después.

1. Escribe las instrucciones del proyecto: de qué rama partir, qué ejecutar antes de dar algo por terminado, qué necesita tu aprobación previa. El ejemplo oficial le pide a un hilo que diga exactamente a qué no consigue llegar en su primer mensaje y que se detenga ahí, en lugar de sustituir, simular o adivinar.
2. Manda exactamente un trabajo real y luego ábrelo y léelo: comprueba cómo informa y qué ha dejado de verdad en la rama
3. Revisa el modelo y el nivel de esfuerzo: dejar el Opus en high que viene por defecto es la vía más rápida para fundirte el límite
4. Di «propón antes de empezar» y «no pases de unos pocos hilos a la vez»: quítalos cuando unas cuantas rondas vuelvan como esperabas

Una cosa más, menos vistosa pero que conviene saber. El sandbox de un hilo se pausa entre turnos y se reanuda para el siguiente. Si no consigue reanudarse, el trabajo vuelve a empezar desde un clon nuevo, lo que significa que los cambios sin commit se pueden perder. En los trabajos largos, lo que recomienda la documentación es decirle al hilo que vaya haciendo commit y push sobre la marcha.

Resumen

El nuevo Projects no es «una función que te permite ejecutar cosas en paralelo», sino «una función que te quita de encima la lata de ejecutar cosas en paralelo». Repartir, perseguir y volver a explicar el mismo contexto cada vez desaparecen. Si tienes trabajo que se alarga, vive en github.com y estás en Pro o en Max, las probabilidades de que encaje bien son altas.

Encaja mal, en cambio, con el trabajo que necesita tu propio entorno, con tu propio servidor git y con los encargos puntuales que terminan hoy. Y lo que se cumple en todos los casos es que el paralelismo compra velocidad gastando tokens. Por defecto es Opus en high, no hay tope impuesto sobre cuántos hilos corren a la vez y los hilos que vigilan un PR se despiertan solos. Ejecuta un proyecto durante un día sin saber esas tres cosas y la caída de tu cuota te sorprenderá. Baja primero los ajustes, mantén pocos hilos a la vez y hazte a la herramienta con una sola ida y vuelta antes de ampliar. Es la forma más segura de entrar.

Si quieres convertir los resultados de una investigación realizada en un proyecto en una propuesta o un procedimiento que puedas volver a consultar, lee nuestra guía de Claude Docs. Usa Projects para el trabajo continuo y Docs para crear y editar documentos, según lo que necesites hacer.

Preguntas frecuentes

Q1. ¿Qué pasa con los proyectos que ya tengo en el chat?

De momento siguen funcionando como hasta ahora. El blog oficial dice que los proyectos existentes de Pro y Max se pueden seguir usando y que se irán actualizando a medida que el despliegue se amplíe al chat y a Cowork. Ojo, eso sí, con que el nuevo Projects está llegando primero a las cuentas sin proyectos existentes: cuantos más tengas acumulados, más tarde te tocará.

Q2. ¿Puedo usarlo desde Claude Code en el terminal?

No. Los tres sitios donde funciona son claude.ai/code, la pestaña Code de la aplicación de escritorio y la aplicación móvil. El acceso a través de Amazon Bedrock, de Agent Platform de Google Cloud o de Microsoft Foundry también queda fuera de alcance. El comando claude project de la CLI, por cierto, es otra función que solo comparte el nombre.

Q3. No uso GitHub. ¿Qué opciones tengo?

Para ejecutar código de verdad hay dos, por ahora. Poner el repositorio en github.com e instalar la Claude GitHub App, o usar agent view, que corre en tu propia máquina. Dicho esto, un proyecto sin repositorio se puede crear sin GitHub en absoluto: sube tu material, haz que los hilos investiguen o redacten a partir de él y recoge los resultados en la pestaña Library.

Q4. ¿Es realista con el plan Pro?

Sí, pero baja los ajustes antes de empezar. La propia documentación avisa de que en Pro sobre todo hay que contar con alcanzar el límite antes los días que ejecutes un proyecto. Un proyecto nuevo viene con los hilos en Opus en high, así que baja eso primero, mantén bajo el número de hilos que corren a la vez y ve ampliando mientras miras lo que gastas de verdad en los ajustes de Usage del proyecto.