Probé Projects de Claude Code: fortalezas y trampas de los hilos en paralelo tras encargarle una web entera

Projects, en Claude Code, es la función con la que Claude divide tu trabajo en hilos dentro de una sola conversación y los hace avanzar en paralelo en la nube. Cómo funciona y quién puede usarlo lo expliqué en Qué es Projects en Claude Code. Este artículo es la continuación: el registro de cuando le encargué de verdad una web entera.

Lo probé del 26 al 28 de septiembre de 2026, cuando Projects estaba todavía en beta pública (llegando poco a poco a Pro y Max; véase la documentación oficial). Es muy posible que las pantallas y el comportamiento cambien. Lo que cuento aquí es lo que pasó de verdad en ese momento, con cifras que he contrastado con las pantallas, el informe de uso y el historial del repositorio.

Resumido en una frase: el desarrollo avanza sorprendentemente bien sin que estés encima, pero lo que sale es un borrador y no un producto terminado, y publicar en un servidor al que solo se entra por SSH se queda atascado. A continuación cuento lo bueno y lo malo en el orden en que ocurrió.

1. Qué le encargué: las condiciones, y una confesión por adelantado

El tema fue una web de base de datos para consultar cuánta memoria necesitan los LLM locales. Para responder a «¿funcionará este modelo en mi ordenador?», recoge de Hugging Face los tamaños de los archivos cuantizados, calcula la memoria necesaria para cada longitud de contexto y permite buscar al revés a partir de la memoria de tu GPU o tu Mac. No es demasiado pequeña y se divide de forma natural en piezas que pueden avanzar en paralelo (recogida de datos, cálculo, páginas, búsqueda inversa, SEO), así que era un buen banco de pruebas para Projects.

2. Cómo se empieza, y los cinco sitios donde tropecé

Los pasos en sí son pocos: en la pestaña Code de la app de escritorio eliges Projects → New, escribes un nombre, un objetivo y un repositorio, y lo creas. Alrededor de esos pasos, sin embargo, tropecé en estos cinco sitios.

Sobre el punto ②: justo después de crearlo, la conversación mostraba el aviso «Up to $100 of initial usage, including the automatic setup, won't count towards your usage limits». Es decir, los primeros 100 $ de uso no cuentan contra tus límites normales, y la pantalla de uso también lo mostraba como un «crédito de configuración del proyecto» (con unas 24 horas hasta caducar). A 28 de septiembre, esta ventaja no aparece en la página de Projects de la documentación oficial. En la sección 6 muestro a qué ritmo se gastó de verdad.

Donde me perdí en la configuración de entornos fue al editar uno que ya existía. Si entras por «Add cloud environment» (añadir entorno), se abre la pantalla de un entorno nuevo, y al principio escribí los dominios permitidos en el campo del script de configuración. Para editar un entorno existente, pasa el ratón por encima de él en la lista y pulsa el engranaje que aparece (es exactamente lo que dice la documentación oficial, pero cuesta descubrirlo solo con la pantalla).

3. Unas 20 horas, paso a paso: qué pasó mientras dormía

Esta es la cronología desde la creación (hacia las 22:00 del 26 de septiembre) hasta la fusión del último PR (hacia las 17:30 del día siguiente, el 27). Todas las horas son de Japón (JST).

También hay que contar algo que no salió bien. Al montar la base de la recogida de datos, un hilo llamó a la API de Hugging Face 520 veces seguidas para averiguar cómo funcionaba el límite de peticiones del servicio externo. El hilo de revisión lo calificó de «no razonable» y dejó por escrito unas reglas para usar API externas, y el hilo de recogida de datos que vino después hizo solo 8 peticiones en todo su trabajo. Si lo dejas solo, no se preocupa por su cuenta de la carga que impone a servicios externos, así que vale la pena ponerlo en las instrucciones.

4. Aprobarlo todo o dejarle hacer

Como conté en la sección 1, la primera mitad funcionó con instrucciones que metían una aprobación humana en cada paso, y a las 17:00 del día 27 las reescribí para dejarle hacer. El comportamiento cambió con claridad.

Al dejarle hacer hubo dos cosas a tener en cuenta. La primera es que las instrucciones reescritas no llegan a los hilos que ya están en marcha. El propio coordinador lo explicó: «Este hilo empezó antes de que se reescribieran las instrucciones, así que no puede ver las nuevas». La segunda es que los hilos no podían borrar las reglas antiguas que quedaban en la memoria del proyecto. Una tarea que intentó reescribir una nota antigua que decía «solo una persona fusiona» fue bloqueada por una comprobación de seguridad. Las notas antiguas tiene que borrarlas una persona desde la configuración → «Memory» (memoria).

Este es el esqueleto de las instrucciones con el que me quedé al final.

Este proyecto construye y mantiene [tu web].
Cómo avanzar lo decides tú: el coordinador puede decidir qué hilos abrir, cuántos, con qué modelos y en qué orden.
Puedes fusionar los PR que pasen la CI. Resuelve tú mismo los conflictos.

Pregunta a una persona solo en estos casos:
- Cualquier cosa que cueste dinero (API de pago, servicios de pago)
- Cuando haga falta información secreta (claves de API, contraseñas)
- Desplegar en producción o cambiar datos de producción
- Cuando haya que elegir entre opciones que tengan sentido las dos
- Cuando no puedas llegar a algo que necesitas (no rellenes con suposiciones ni con datos ficticios)

Respeta los límites de peticiones de las API externas y no las llames en masa para investigar.

Dicho esto, con lo que aprendí después, recomiendo añadir «los cambios en la configuración de la CI y en los scripts de despliegue los aprueba una persona». Los hilos a los que dejas hacer también pueden cambiar la configuración de la CI, y combinado con un mecanismo de despliegue eso abre un camino para que los cambios lleguen a producción sin que nadie los revise (sección 7).

5. La calidad que descubrí al publicar: todas las pruebas pasaban

Lo que había construido el proyecto se lo pasé a mi Claude Code local de siempre y lo llevé a producción. Mi primera impresión justo después de publicar fue «pues… es normalita». No había ni una sola página de modelo. Al buscar la causa apareció un hueco propio del desarrollo en paralelo.

Diez hilos, más de cien pruebas, las revisiones con Opus y la CI: nada de eso detectó la omisión, porque cada hilo tenía razón dentro de su propio encargo. Si nadie hace el papel de mirarlo todo de punta a punta, se abren huecos en las fronteras entre encargos.

Al cargar datos reales aparecieron otros dos problemas.

• Las tablas de cuantización incluían archivos que no eran el modelo principal. Los modelos auxiliares para decodificación especulativa (MTP, EAGLE, etc.) y los archivos LoRA se contaban como cuantizaciones del modelo principal, así que la tabla de un modelo de 12B empezaba con una fila que decía «Q8_0 0.47GB» (el Q8_0 real ocupa 12,7 GB). Tras corregirlo, 195 archivos de 56 repositorios pasaron a clasificarse como auxiliares.
• En los modelos más nuevos y más buscados, la memoria necesaria salía como «no calculable». La fórmula tal como se escribió al principio no contemplaba las arquitecturas de nueva generación (como las que guardan la memoria de forma distinta según la capa). El principal atractivo de la web faltaba justo en las páginas más visitadas.

Las dos cosas solo salieron a la luz al meter datos reales en producción, porque las pruebas se habían construido solo con datos de muestra. Esto es lo que corregí con Claude Code en local y el tiempo que me llevó (el 28 de septiembre, de 17:21 a 22:54, en 13 commits).

También hubo aspectos claramente buenos. Las páginas cargaban rápido (unos 0,1 segundos las principales), los tamaños de archivo eran los valores reales de Hugging Face y la memoria necesaria de los modelos compatibles cuadraba con la fórmula. El trabajo de SEO —títulos, datos estructurados, sitemap, llms.txt— estaba ahí desde el principio. Mi valoración general: el esqueleto y los detalles estaban bien hechos; lo que faltaba eran las «juntas» entre las piezas y los datos reales.

6. Uso y coste: en qué se fueron 191,8 millones de tokens

La pantalla «Usage» (uso) de la configuración del proyecto muestra los tokens por hilo y por modelo. Con un botón arriba a la derecha puedes copiarlo todo como texto. El informe a las 11:47 del 27 de septiembre decía lo siguiente.

190 millones parece mucho, pero el 97,7 % fueron lecturas de caché. Un hilo vuelve a leer toda la conversación anterior en cada acción, así que cuando uno hace cientos de acciones sale esta forma. El coordinador añadió solo un 2 %, de modo que el coste de gestión fue pequeño.

Para comparar, calculé «tokens leídos ÷ tokens generados» y lo puse frente a Claude Code en local (los últimos tres días en mi propio PC): unos 330 en el proyecto y unos 340 en local. El consumo por unidad de trabajo fue más o menos el mismo que en una sesión local. Si Projects parece más pesado, lo más probable es que sea porque todo avanza en paralelo a la vez y el gasto se concentra en poco tiempo (el trabajo no era el mismo, así que tómalo como una comparación aproximada).

En cuanto al coste, pude seguir cómo se iba gastando el crédito de configuración (100 $).

Este crédito se comportaba de forma muy parecida a un importe calculado con los precios de la API. Si valoro el informe de las 11:47 con los precios oficiales de Anthropic (Pricing: Sonnet 5 a 2 $ de entrada, 10 $ de salida y 0,20 $ de lectura de caché; Opus 5.5 a 4 $ de entrada, 20 $ de salida y 0,20 $ de lectura de caché, todo por millón de tokens), sale por unos 58–65 $, lo que cuadra más o menos con lo que mostraba la pantalla en ese momento (78 % = 78 $). Es decir, «100 $» significa la cantidad que costaría 100 $ si la pagaras por la API, que dentro de un plan Max de tarifa plana no es tanto. Por otro lado, un crédito aparte que se repartía para las sesiones en la nube (250 $ en Max) decía en su pantalla de canje que «Projects no es elegible», y efectivamente no se gastó ni un dólar de él.

7. Por qué se atascó el paso a producción

Lo más difícil fue llevar a producción lo que se había construido, porque el destino era un hosting compartido al que solo se entra por SSH.

• Los hilos en la nube no llegan al servidor de producción (la clave SSH solo está en mi PC).
• Para trabajar en el PC local se usa la opción «Work locally» (trabajar en local) del proyecto. Por debajo es Remote Control, y exige activar en la app de escritorio «Use this computer from your phone and claude.ai» (usar este ordenador desde el móvil y claude.ai).
• El problema es que ese ajuste se aplica a la lista de todas las carpetas que hayas abierto hasta entonces con Claude Code, que se reúne sola. En mi caso eran 22, y una de ellas era una carpeta padre con decenas de proyectos dentro. Mientras está activado, en todas ellas se puede empezar a trabajar en remoto, y además los nombres de carpeta, las rutas y las URL de los repositorios se envían a Anthropic. Para limitarlo a una sola carpeta hay que ir por otra vía: abrir un terminal en esa carpeta y ejecutar claude remote-control.

Así que estudié varias formas de publicar.

Al final, archivé el proyecto y pasé lo construido a mi flujo habitual con Claude Code en local. Consideré más seguro subirlo al mismo sistema de publicación que mis otras webs que añadir un mecanismo nuevo.

Mirándolo con perspectiva, parece mejor pensar en Projects como algo pensado para combinarse con un hosting que publica automáticamente al fusionar en GitHub. Con Vercel, por ejemplo, basta con conectarlo a GitHub para que los cambios lleguen hasta producción, así que el callejón sin salida en que me metí no ocurriría. Eso sí, el plan gratuito Hobby de Vercel está limitado al uso no comercial, y para poner anuncios como los de Google AdSense hace falta el plan de pago Pro (desde 20 $ al mes) (Fair Use Guidelines). Además, no encaja bien con una web en PHP y MySQL como esta. Lo importante es decidir juntos, desde el principio, la tecnología y dónde se va a publicar.

Los riesgos de dejar que tu propio PC se maneje en remoto, y en qué se diferencia de Claude Code en el día a día, pienso tratarlos en detalle en otro artículo. Cómo manejar tu sesión local desde el móvil lo explico en el artículo sobre Remote Control.

8. Para qué trabajos sirve y para cuáles no

Con lo aprendido en esta prueba, esto es lo que comprobaría antes de empezar.

• Destino de publicación: ¿se publica automáticamente al fusionar en GitHub? Si hace falta SSH, decide de antemano algo como que sea el servidor quien vaya a buscar los cambios.
• Permisos de GitHub: el alcance con que instalas la Claude GitHub App. Usa una cuenta dedicada o limita los repositorios.
• Hasta dónde le dejas hacer: en las instrucciones del proyecto, escribe solo lo que hay que preguntar a una persona. Haz que los cambios en la configuración de la CI y del despliegue requieran aprobación.
• Red: si usas API o webs externas, pon en la lista de permitidos tanto el dominio principal como sus subdominios.
• Comprobación con datos reales: no te confíes porque pasen las pruebas con datos de muestra. Al final, abre un hilo cuyo papel sea pasar de punta a punta datos iguales a los de producción y mirar el resultado.
• Límites de uso: revisa el modelo por defecto de los hilos. Durante las primeras 24 horas hay un crédito de configuración de 100 $.

Resumen

Projects de verdad te quita de encima el trabajo de repartir tareas, perseguirlas y volver a explicar el mismo contexto. Tres tareas avanzaron en paralelo durante la noche, los hilos se coordinaron entre sí y, cuando le dejé hacer, tomó él solo las decisiones sobre las fusiones y el siguiente paso. Los tokens por unidad de trabajo tampoco fueron distintos de los de Claude Code en local.

Por otro lado, lo que sale es un borrador. Al dividir el trabajo en paralelo se abren huecos en las fronteras entre encargos. Todas las pruebas con datos de muestra pueden pasar y aun así los datos reales sacan fallos. Y no se lleva bien con los servidores a los que solo se entra por SSH. Si lo usas, tres cosas deberían ahorrarte los rodeos que di yo: elegir un destino con integración con GitHub, dejar por escrito al principio hasta dónde le dejas hacer y, al final, abrir un hilo cuyo papel sea comprobarlo todo de punta a punta con datos reales.

Preguntas frecuentes

P. ¿Cuánto cuesta Projects?

R. No tiene un cargo aparte: consume de los límites de uso normales de Pro o Max. Además, esta vez tuve un «crédito de configuración» por el que hasta 100 $ de uso durante aproximadamente las primeras 24 horas no contaban para mis límites (según la pantalla; a 28 de septiembre no aparece en la documentación oficial). El trabajo, 10 hilos y 11 PR, consumió unos 190 millones de tokens y agotó ese crédito. A precios de la API, equivale a unos 100 $.

P. ¿De verdad sigue avanzando si cierro el PC?

R. Sí. Los hilos que funcionan en la nube siguieron avanzando tanto si cerraba el PC como si lo ponía en reposo. En esta prueba, tres tareas terminaron durante unas 7 horas de noche. Eso sí, los hilos que pones a funcionar en tu propio PC con «Work locally» solo avanzan mientras el PC está despierto.

P. ¿Se puede usar con repositorios que no estén en GitHub?

R. Los hilos que trabajan con código dan por hecho un repositorio de github.com con la Claude GitHub App instalada. Yo gestionaba este proyecto en mi propio servidor git, así que creé una cuenta de GitHub solo para Claude, empecé allí y al final lo devolví todo a mi entorno local.

P. ¿Qué pasa si cambio las instrucciones del proyecto a mitad de camino?

R. El coordinador las recoge enseguida, y su forma de trabajar cambió sin que tuviera que decirle nada. Pero no llegan a los hilos que ya están en marcha, así que, si hace falta, haz que el trabajo siga en un hilo nuevo. Las reglas antiguas que quedaban en la memoria del proyecto tuvo que borrarlas una persona desde la configuración.

P. ¿Es seguro «Work locally»?

R. La única comunicación es una conexión cifrada de salida desde tu PC; no se abre ningún puerto a la escucha. Sin embargo, al activar el ajuste de la app de escritorio, la lista de carpetas reunida a partir de tu historial de uso (22 en mi caso, incluidas decenas de proyectos dentro de una carpeta padre) pasa a ser un sitio donde se puede empezar a trabajar en remoto. Hacen falta hábitos como activarlo solo mientras lo usas y comprobar que la cuenta con la que inicias sesión tiene la verificación en dos pasos.

P. ¿Se puede usar tal cual lo que construye?

R. En mi caso, no. El esqueleto y el trabajo de SEO estaban bien hechos, pero faltaba por completo la lógica de las fronteras entre encargos, y había fallos que solo aparecían con datos reales. Antes de publicar hace falta un paso en el que se cargan datos reales y se comprueba todo de punta a punta.