Probablemente ejecutes Claude Code en una terminal de tu propio portátil. Esa sesión depende del portátil de tres maneras:
- Comparte tu árbol de trabajo, por lo que dos sesiones en un mismo repositorio pueden editar los mismos archivos y pelearse por el mismo puerto.
- Se ejecuta con tus credenciales.
- Se detiene cuando tu computadora se suspende o se cae el Wi-Fi.
Una sesión en la nube ejecuta Claude Code en una máquina propia. Cada tarea recibe una máquina virtual nueva con tu repositorio clonado en una rama nueva y la configuración de tu entorno ya realizada.
Puedes iniciar una desde claude.ai/code, la app móvil de Claude, la aplicación de escritorio, tu terminaly Slack. Luego puedes seguirla desde el navegador, la app móvil y la aplicación de escritorio. Cuando el trabajo termina, queda en una rama que puedes convertir en un pull request.
Las sesiones en la nube vienen incluidas en tu plan Pro, Max, Team o Enterprise sin costo adicional: no hay cobro separado por la máquina en la nube, y las sesiones consumen los mismos límites de uso que el resto de Claude Code. Dependiendo de tu plan, puede que el propietario de la organización necesite activar las sesiones en la nube primero.
Crédito de cortesía para sesiones en la nube. Los suscriptores individuales existentes de Pro y Max pueden reclamar un crédito de cortesía único para sesiones en la nube, además de los límites de su plan: $100 en Pro y $250 en Max. Reclámalo antes del 7 de octubre en claude.ai/code/claim-credit o con /claim-credit en Claude Code. El crédito expira el 4 de noviembre. Una vez usado o expirado, se aplica el uso regular de tu plan. No es elegible para Projects ni Routines. Consulta los Términos de la Oferta de Crédito Promocional.
Para esta guía ejecuté cuatro sesiones reales en la nube sobre un pequeño repositorio de muestra. Sus transcripciones, diffs y tiempos aparecen a lo largo del artículo. El repositorio y el usuario de las capturas de pantalla son ficticios. El trabajo, el resultado y las cifras provienen de esas sesiones.
Una de las principales ventajas de las sesiones en la nube es que puedes ejecutar varias tareas a la vez sin que se estorben entre sí. Aquí hay tres que inicié en un intervalo de 16 segundos, cada una en su propia máquina. En mi portátil, las habría ejecutado una tras otra, o habría gastado mi tiempo evitando que se estorbaran.
TRES TAREAS, UN REPOSITORIO, TRES MÁQUINAS
El repositorio de ejemplo es tidepool, una pequeña API de Node que predice las mareas para tres puertos ficticios. Tenía tres problemas corrientes: una prueba fallaba aproximadamente una de cada cuatro ejecuciones, la documentación de la API describía parámetros que el código ya no leía, y el logger construía sus líneas concatenando cadenas.
Inicié tres sesiones en la nube dentro de 16 segundos entre sí, una por problema. Las inicié programáticamente, y como tidepool no está en GitHub, cada sesión primero recreó el repositorio a partir de los archivos en su prompt. Con un repositorio real omitirías ese paso, y desde una terminal cada sesión es un solo claude --cloud comando. Acortados, los tres prompts fueron:
claude --cloud "npm test fails maybe one run in four. Find the flaky test, fix the root cause in the code (not the test), and prove it by running the suite at least 30 times in a row." claude --cloud "docs/API.md is out of date with src/server.js. Rewrite it so every endpoint, parameter, default and response shape matches the code. Start the server and run each curl example to check it." claude --cloud "Make src/logger.js emit one JSON object per line, keep LOG_LEVEL, and log method, path, status and duration_ms as fields. Add a test for the logger."
Las sesiones duraron 61, 65 y 72 segundos, y las tres terminaron 87 segundos después de que la primera comenzara. Recrear el repositorio tomó aproximadamente un tercio hasta un poco más de la mitad de cada ejecución. Estos son los resultados.
- La prueba inestable. Claude encontró una condición de carrera en
TtlCache.get. La caché almacenaba un valor solo después de que el loader terminaba, así que una segundagetpara la misma clave durante una carga volvía a llamar al loader. Claude cambió la caché para almacenar la promesa en curso, descartó la entrada cuando una carga falla, y ejecutónpm test40 veces seguidas con cero fallos. - La documentación. Claude inició el servidor, ejecutó un curl contra cada endpoint y encontró cinco formas en que la documentación antigua estaba mal. Listaba campos que la API nunca devuelve, documentaba un
daysparámetro que el código ignora, daba alturas en pies cuando son metros, omitía el endpoint/next-high, y dejaba fuera las respuestas de error. También descubrió que un valorfrom=malformado devuelve una lista vacía con un 200, y lo documentó como una advertencia en lugar de cambiar código del servidor que no le habían pedido tocar. - El logger. Claude escribió el logger JSON, movió el registro de solicitudes a campos estructurados y añadió cinco pruebas. Su commit entró con una prueba fallando, así que Claude volvió a ejecutar la prueba de caché ocho veces, la vio fallar en cinco de ellas, y rastreó el fallo hasta la misma condición de carrera que la primera sesión estaba arreglando. Propuso el mismo arreglo, dejó la caché intacta porque estaba fuera de su tarea, y dijo en su resumen que la suite no estaba limpia.
El resultado del logger muestra por qué las sesiones en la nube se adaptan al trabajo en paralelo. Cada sesión tenía su propia copia del repositorio, sus propios procesos y su propia rama. La sesión de docs y la sesión del logger iniciaron cada una el servidor de API para probar contra él, y ninguna afectó a la otra. En un solo portátil, dos agentes que trabajaran en un mismo checkout editarían los mismos archivos y colisionarían en un puerto a menos que cada uno eligiera el suyo.
Debido a ese aislamiento, la sesión del logger no tuvo acceso a la corrección de caché que estaba haciendo la primera sesión. Divida las tareas paralelas según los límites de los archivos, fusione las ramas en un orden sensato, y espere que una sesión informe de problemas que otra sesión ya está corrigiendo.
BAJO EL CAPÓ DE UNA SESIÓN CLAUDE CODE EN LA NUBE
Una sesión en la nube es una sesión de Claude Code que se ejecuta en infraestructura gestionada por Anthropic, o en las máquinas de su propia organización con un entorno autoalojado. La figura muestra las partes. Las cuatro conclusiones que la siguen son las que cambian su forma de trabajar.
- Cada tarea obtiene su propia máquina. Una VM nueva con su repositorio clonado en una rama nueva, de modo que las sesiones no puedan tocar los archivos ni los puertos de las demás. Vea qué está instalado.
- Su token de GitHub nunca entra en la VM. Un proxy lo retiene, y la sesión recibe una credencial de corta duración que solo puede hacer push a su propia rama de trabajo. Vea el proxy de GitHub.
- La configuración de Claude del repositorio viaja con él. La suya personal no.
CLAUDE.md, rules, skills, agents y commands viajan con el repositorio, y su~/.claudese queda en su portátil. Vea configuración en sesiones en la nube. - Las VM inactivas se reclaman. Vuelva a abrir la sesión y obtendrá una VM nueva con la conversación restaurada, así que haga commit del trabajo que le importe. Vea caducidad del entorno.
Para las especificaciones, modos de permisoy niveles de red, consulte el documentación de entornos en la nube.
¿LOCAL O EN LA NUBE?
Las sesiones en la nube no reemplazan a las locales, y la mayoría de las personas usa ambas. La tabla muestra en qué se diferencian, y los párrafos posteriores indican cuándo es adecuada cada una.
| Sesión local | Sesión en la nube | |
|---|---|---|
| Se ejecuta en | Tu máquina | Una VM nueva para cada tarea |
| Portátil en suspensión o sin conexión | La sesión se detiene | La sesión continúa |
| Varias tareas en un mismo repositorio | Worktrees, puertos y cuidado separados | Una VM y una rama por tarea |
| A qué puede acceder el agente | Todo lo que pueda tu cuenta de usuario, incluidas las claves SSH, las CLIs de nube y ~/.claude | El repositorio, el nivel de red que configures, los conectores que habilites y una credencial de GitHub con alcance de sesión |
| Iniciar o continuar desde | Esa máquina, o tu teléfono mediante el control remoto | Navegador, teléfono, escritorio, terminal, Slack, una llamada a la API o una programación |
| Aprobaciones | Cualquier modo, incluido por comando | Auto, Accept edits o Plan |
| Termina con | Cambios en tu árbol de trabajo | Una rama, y un pull request cuando lo quieras |
| Cómputo | Tu máquina | Sin cargo de cómputo separado; usa los límites de tu plan |
Quédate en local cuando la tarea necesite algo que solo tu máquina tiene. Eso cubre una base de datos con datos locales reales, un servicio al que llegas por VPN, una GPU, un simulador de teléfono o hardware en tu escritorio. Quédate en local también para ciclos visuales ajustados donde quieras ver cada cambio en tu propio navegador en cuestión de segundos, y cuando tu organización opera con Zero Data Retention, que desactiva las sesiones en la nube.
Dos características se sitúan entre las opciones. Remote control mantiene la sesión en tu máquina y te permite dirigirla desde tu teléfono o navegador. Self-hosted environments, en beta para Team y Enterprise, ejecutan sesiones en la nube en la propia infraestructura de tu organización, de modo que pueden alcanzar redes privadas.
Si nada de eso aplica, la tarea es buena candidata para la nube. La siguiente sección cubre los flujos de trabajo donde eso rinde más.
SIETE FLUJOS DE TRABAJO QUE CONVIENEN A LAS SESIONES EN LA NUBE
Estos flujos de trabajo ponen en práctica las diferencias de la tabla: una máquina separada para cada tarea, sesiones que siguen ejecutándose mientras estás ausente y una rama al final para que la revises.
1. Despeja un backlog en paralelo
Digamos que tienes cinco correcciones pequeñas y no relacionadas. En local, las harías una tras otra, o configurarías cinco worktrees y mantendrías sus puertos e instalaciones separados. En la nube, iniciarías cinco sesiones y revisarías cinco ramas.
CODEShellclaude --cloud "Fix the flaky test in auth.spec.ts" claude --cloud "Update the API documentation" claude --cloud "Refactor the logger to use structured output"
claude --cloud clona tu remoto de GitHub en tu rama actual, así que primero envía tus commits locales. Mientras la VM arranca, la CLI muestra una lista de verificación en vivo de los pasos de configuración y encola todo lo que escribas.
Escribe cada tarea como un ticket autosuficiente que indique qué está mal, cómo se ve hecho y cómo probarlo. El prompt de la prueba inestable nombró su prueba: ejecutar la suite al menos 30 veces seguidas. La sesión la ejecutó 40 veces.
Cuando las tareas pertenecen a un esfuerzo mayor, un project (beta pública para Pro y Max) ejecuta una conversación de coordinación que inicia y rastrea las sesiones en la nube por ti. Luego las agrupa por estado: trabajando, esperándote y listas para revisión.
2. Déjalo demostrar la corrección
Una prueba inestable es el caso más claro de trabajo que requiere prueba repetida: hay que ejecutar la suite una y otra vez, y no quieres que ese bucle ocupe la máquina en la que trabajas. En la nube, Claude parcheó la caché y ejecutó la suite completa 40 veces en un solo comando.
La VM no tiene coste de cómputo y su CPU no es la tuya, así que pide pruebas exhaustivas. Ejecuta la suite 200 veces, biseca una regresión a lo largo de 50 commits, corre el nivel de integración lento, o arranca la app y pégale con curl como hizo la sesión de documentación.
Cada turno de Claude sigue contando para tu plan, pero una ejecución larga de tests dentro de un solo comando cuesta muy poco. Los comandos en primer plano agotan el tiempo de espera tras 2 minutos por defecto (10 como máximo) y luego siguen ejecutándose en segundo plano hasta 30 minutos más. Puedes subir los valores por defecto con BASH_DEFAULT_TIMEOUT_MS y BASH_MAX_TIMEOUT_MS en las variables del entorno.
3. Planifica en tu escritorio, compila en la nube, termina en tu terminal
Para un cambio más grande, acuerda primero el enfoque donde el ir y venir es barato. Inicia Claude en modo plan, elabora el plan juntos, haz commit del plan y haz push.
CODEShellclaude --permission-mode plan # ...agree on the plan, save it to docs/migration-plan.md, commit and push... claude --cloud "Execute the migration plan in docs/migration-plan.md"
Mientras la sesión en la nube compila, tu terminal queda libre para otro trabajo. Cuando termina, baja la sesión para terminarla a mano.
CODEShellclaude --teleport # pick a cloud session claude --teleport <session-id>
Teleport comprueba que estás en el mismo repositorio, obtiene la rama de la sesión, la hace checkout y carga toda la conversación en tu terminal. Necesitas un árbol de trabajo limpio (ofrece hacer stash), y la rama debe estar subida. Desde dentro de Claude Code, /teleport (o /tp) abre el mismo selector, y /tasks entonces t también funciona. La app de Desktop va en el otro sentido, y su menú Open in envía una sesión local a la nube.
4. Revisa desde tu teléfono
La pestaña Code en la app de Claude se conecta a las mismas sesiones. Desde tu teléfono puedes iniciar una tarea, seguirla, dirigirla, responder una pregunta que Claude hizo, o decirle a Claude que vigile un pull request.
Un teléfono sirve para las preguntas que olvidarías para cuando llegues a un teclado. Le di a una cuarta sesión el tipo de pregunta que escribirías en uno: cómo predice tidepool las mareas, y cómo podría equivocarse en los bordes de una ventana de tiempo. Ejecutó código para verificar su respuesta y encontró un bug real. El bucle nunca examina la primera ni la última muestra, por lo que la API omite una marea alta que cae exactamente al inicio de la ventana.
5. Entrégale a Claude los fallos de CI y los comentarios de revisión
Con la Claude GitHub App instalada en un repositorio, una sesión en la nube puede vigilar un pull request y actuar según lo que le suceda. Desde la barra de CI en una sesión en claude.ai/code, activa Auto-fix. También puedes ejecutar /autofix-pr en la rama del PR en tu terminal, pedirle a la app móvil que vigile el PR, o pegar la URL del PR en una sesión.
Claude envía soluciones claras para los checks fallidos y los comentarios de revisión, y explica qué cambió. Te pregunta sobre cualquier cosa ambigua o arquitectónica. Las respuestas en los hilos de revisión se publican bajo tu nombre de usuario de GitHub, etiquetadas como Claude Code. Claude no recibe notificaciones sobre conflictos de fusión con la rama base, así que pídele que haga rebase. Sus comentarios también pueden activar automatizaciones basadas en comentarios, como Atlantis.
6. Empieza el trabajo sin empezar tú mismo
Una routine (vista previa de investigación) es un conjunto de recursos guardados diseñados para cumplir una tarea, como un prompt, repositorios, conectores y un entorno. Cada ejecución es una sesión en la nube, iniciada por un trigger. Los triggers pueden ser un horario (como mucho cada hora), una llamada HTTP al endpoint propio de la routine, o un evento de GitHub como la apertura de un pull request o un release. Crea una en claude.ai/code/routines, en la app de Desktop, o con /schedule en la CLI. Las routines se ejecutan sin solicitudes de aprobación y, por defecto, envían cambios a ramas con el prefijo claude/.
Dos herramientas más pequeñas ayudan aquí. Puedes poner en cola un seguimiento en una sesión en ejecución desde cualquier máquina donde tengas la sesión iniciada, incluido un trabajo de CI.
CODEShellclaude -p "The integration tier is green now; rebase on main and push" --cloud <session-id>
También puedes guardar en marcadores una sesión prellenada. Una URL como claude.ai/code?prompt=Triage+the+newest+issues&repositories=acme-labs/tidepool abre claude.ai/code con el prompt y el repositorio ya rellenados.
7. Ejecuta código en el que no confías del todo
El pull request de un colaborador, el script de instalación de una nueva dependencia o un repositorio que clonaste hace cinco minutos pueden ejecutar código que no has leído. En tu portátil, ese código se ejecuta junto a tus claves SSH, tus sesiones CLI de la nube y tu perfil del navegador. En una sesión en la nube se ejecuta en una VM desechable sin nada de eso, con una credencial de GitHub de alcance limitado a la sesión y una red que puedes restringir.
Configura el acceso de red del entorno en None para la ejecución más estricta, o déjalo en Trusted, que permite los registros de paquetes, GitHub y los hosts principales de SDK de nube. Incluso en None, Claude Code sigue enviando solicitudes a la API de Anthropic, por lo que los datos pueden salir de la VM por esa vía, y la sesión aún puede hacer push a su propia rama. Todo el tráfico saliente pasa por un proxy que registra los nombres de host.
CONECTAR GITHUB SIN QUEDARSE ATASCADO
Si tu primera sesión en la nube sale mal, la causa más probable es GitHub. La mayoría de los problemas provienen de que las sesiones en la nube necesitan dos permisos de GitHub separados.
- Iniciar sesión con GitHub le dice a Claude quién eres.
- Instalar la Claude GitHub App en una cuenta u organización define qué repositorios privados puede ver Claude allí.
Los repositorios públicos funcionan solo con lo primero. Los repositorios privados necesitan lo segundo, en la cuenta u organización que los posea. Si conectaste GitHub y falta un repositorio privado, normalmente la App no está instalada en la cuenta u organización que lo posee.
| Lo que has conectado | Repos públicos | Tus repos privados | Repos privados de una org | Corrección automática, activadores de GitHub, proyectos |
|---|---|---|---|---|
| Solo sesión iniciada con GitHub | Sí | No | No | No |
| + App en tu cuenta personal | Sí | Sí | No | Tus repos |
| + App en la organización (el propietario aprueba) | Sí | Solo si también está en tu cuenta | Sí | Repos de la organización |
/web-setup (tu gh token) | Sí | Sí | Todo lo que tu token pueda alcanzar | No, necesita la App |
Camino A: conectar en el navegador (recomendado)
Conecta tu cuenta de GitHub en claude.ai/connect-github, luego instala la Claude GitHub App en la cuenta u organización propietaria de tu repositorio. Para una organización, normalmente un propietario tiene que aprobar la instalación. La quickstart recorre cada paso.
Si GitHub no te devuelve a claude.ai/code, la página de conexión en claude.ai/connect-github puede mostrar una breve lista de verificación para las causas habituales. Una de ellas es el paso de inicio de sesión único, que oculta los repositorios de una organización si lo omites.
La corrección automática, las rutinas activadas por GitHub y los proyectos también dependen de la App, así que instálala incluso si te conectas de otra manera.
Camino B: conectar desde tu terminal con /web-setup
Si ya usas el gh CLI, ejecutar /web-setup dentro de Claude Code para enviar tu gh token a tu cuenta de Claude. Las sesiones pueden entonces acceder a cualquier repositorio al que ese token pueda, con o sin la App. Ver Conéctate desde tu terminal para el tutorial. En los planes Team y Enterprise, un propietario debe activar Configuración rápida primero.
Camino C: omitir GitHub para un uso único
Ejecutar claude --cloud en un repositorio que no tiene un remoto de GitHub, o en uno donde la App no está instalada, y Claude Code sube un paquete de tu repositorio en lugar de clonarlo. La sesión solo puede hacer push si tu conexión de GitHub tiene acceso de push a ese repositorio. La documentación lista lo que el paquete incluye y lo que deja fuera.
Si usas la versión Team o Enterprise
Un propietario tiene una lista de verificación breve: activar el conector de GitHub en claude.ai/admin-settings/connectors, permitir sesiones en la nube en el Configuración de administración de Claude Code, instala la Claude GitHub App en los repositorios de la organización (o aprueba las solicitudes de los miembros) y decide si activar Configuración rápida. Las organizaciones con listas de permisos de IP o GitHub Enterprise Server tienen un paso adicional. Consulta la documentación sobre listas de permisos de IP y GitHub Enterprise Server.
Cuando todavía no funciona
| Lo que ves | Por qué | Solución |
|---|---|---|
| Falta un repositorio privado en el selector | La App no está instalada en la cuenta u organización que la posee, o su acceso a repositorios lo excluye | Instala la App allí, o añade el repositorio al Repository access de la App en tu configuración de GitHub |
| Un error que dice que debes ser propietario de la organización para vincularla | La organización bloqueó una verificación de membresía, generalmente debido a una solicitud de permiso de App pendiente, una lista de permitidos de IP o inicio de sesión único SAML | Un propietario acepta la solicitud de permiso pendiente en la configuración de GitHub App de la organización, activa la herencia de la lista de permitidos de IP para las GitHub Apps instaladas, o (bajo SAML) otorga a Claude acceso a la organización |
| Los repositorios de una organización no aparecen justo después de conectarla | La organización usa inicio de sesión único SAML, y su paso de autorización fue omitido | En el paso "Single sign-on to your organizations" de GitHub, haz clic en Authorize junto a cada organización antes de continuar. Si ya lo omitiste, autoriza a Claude para esa organización en tu configuración de GitHub y luego vuelve a conectarla |
| Cada sesión en la nube falla con un error de autenticación | Tu organización de Claude usa listas de permitidos de IP | Pide a soporte que exima los servicios alojados por Anthropic |
Para cualquier otra cosa, consulta solución de problemas en la documentación, incluido que no aparezcan repositorios después de conectar GitHub. Para desconectar GitHub por completo, usa claude.ai/customize/connectors.
DA A LAS SESIONES LO QUE NECESITAN PARA VERIFICAR SU PROPIO TRABAJO
Una sesión que puede ejecutar tus pruebas verifica su propio trabajo antes de devolverlo. Sin eso, revisas cambios que nadie ha ejecutado. La mayor parte del valor en las demostraciones de esta guía vino de Claude ejecutando cosas: la suite 40 veces, el servidor y sus curls, el cálculo de mareas en el borde de la ventana. Diez minutos de configuración del entorno le dan a Claude una forma de ejecutar esas comprobaciones.
- Comienza con el entorno Default. Usa Trusted network access, sin variables ni script de configuración, lo que es suficiente para la mayoría de los repositorios de JavaScript, Python, Go y Rust.
- Usa un script de configuración para la máquina. Se ejecuta como root antes de que Claude Code arranque, así que
apt installfunciona. Debe salir con 0 o la sesión no arrancará, y debería terminar en unos cinco minutos para que el entorno se almacene en caché. Después de eso, las nuevas sesiones parten de una instantánea con tus herramientas en disco. La caché se reconstruye cuando cambias el script o los hosts permitidos, y aproximadamente cada siete días. - Usa un hook SessionStart para el proyecto. Coloca
npm instally pasos similares en un hook en el.claude/settings.jsondel repositorio, para que se ejecuten igual localmente y en la nube. CompruebaCLAUDE_CODE_REMOTEsi un paso debe ejecutarse solo en la nube. Los hooks del repositorio se cargan en sesiones de un solo repositorio. - Inicia los servicios por sesión. La caché almacena archivos. Los procesos que estaban en ejecución no sobreviven. Pide a Claude que ejecute
service postgresql start, o hazlo en un hook de SessionStart. - Elige el nivel de red más estrecho que funcione. Trusted cubre los registros comunes. Usa Custom para añadir un registro privado, y Full solo cuando la tarea necesite el internet abierto. Los cambios llegan a las sesiones en ejecución en aproximadamente un minuto.
- Mantén los secretos fuera de las variables compartidas. Las variables de entorno son visibles para cualquiera que use el entorno. En Pro y Max, las credenciales de API de un entorno adjuntan una clave a las solicitudes de los hosts que indiques, fuera de la VM, de modo que la clave nunca queda en una variable.
- Pon los comandos en CLAUDE.md. Tu archivo personal
~/.claudeno llega a la VM en la nube. Si Claude necesita saber cómo ejecutar las pruebas de integración, el repositorio debe indicarlo.
HÁBITOS QUE DAN RESULTADO
- Una tarea, una sesión. Las sesiones pequeñas y separadas son más fáciles de revisar y más baratas de descartar.
- Pide evidencia. Nombra el comando que demuestra que la tarea está completa, y lee el resumen de Claude antes del diff.
- Haz push antes
claude --cloud. La VM clona desde GitHub, por lo que los commits sin push no llegan a ella. - Haz commits a medida que avanzas en tareas largas. Las VM inactivas pueden ser reclamadas.
- Revisa en la vista de diff. Los comentarios en línea se agrupan en tu siguiente mensaje, y Create PR puede abrir un PR completo, un borrador o la página de redacción de GitHub.
- Guía a Claude mientras trabaja. Los mensajes que envías mientras Claude trabaja se ponen en cola, y puedes retirar uno de la cola.
- Comparte la sesión. En Team y Enterprise, establece la visibilidad de una sesión en Team para que un revisor pueda leer cómo se hizo el cambio. Los commits de sesiones en la nube llevan un trailer
Claude-Sessionque enlaza de vuelta con la transcripción. - Vigila tus límites. Las sesiones paralelas consumen los límites de tu plan en paralelo, por lo que cinco sesiones los usan aproximadamente cinco veces más rápido que una. Las rutinas tienen sus propios topes por hora, y los projects pueden iniciar hasta 200 nuevos hilos al día.
PREGUNTAS FRECUENTES
¿Quién puede usar las sesiones en la nube? Los planes Pro, Max y Team, y los usuarios Enterprise con un asiento premium o un asiento Chat + Claude Code, con sesión iniciada mediante una cuenta de claude.ai. No están disponibles con una clave de API de Console ni con un proveedor externo. Consulte la documentación de las sesiones en la nube.
¿A dónde van mis datos? Anthropic almacena la transcripción de la sesión, y su tiempo de conservación depende de su plan y de la configuración de mejora de modelos. Las VM se recuperan tras la inactividad, y eliminar una sesión borra sus datos. Consulte uso de datos y seguridad.
¿Claude entrenará con los datos de mis sesiones en la nube? Las sesiones en la nube siguen la misma política que el resto de Claude Code. En Team, Enterprise y la API, Anthropic no entrena modelos con su código ni sus mensajes, salvo que su organización lo autorice. En Free, Pro y Max, depende de su configuración de mejora de modelos. Consulte uso de datos.
¿Gestionará mi repositorio grande? La VM tiene aproximadamente 4 vCPUs, 16 GB de RAM y 30 GB de disco. Coloque las instalaciones pesadas en un script de configuración para que se ejecuten una sola vez y queden en la instantánea en caché.
¿Y GitLab o Bitbucket? claude --cloud puede cargar un bundle desde cualquier repositorio git, pero la sesión no puede enviar cambios de vuelta a esos hosts. GitHub Enterprise Server es compatible con Team y Enterprise. Consulte las restricciones de plataforma.
¿Qué ocurre cuando hay ramas paralelas en conflicto? Las sesiones no se conocen entre sí. Fusiona una rama y luego envía un seguimiento a la siguiente sesión como claude -p "rebase on main and fix any conflicts" --cloud <session-id>.
¿Perderé mis herramientas locales? La configuración a nivel de usuario no viaja, así que mueva lo que el equipo necesita al repositorio: confirme skills y comandos en .claude/, añada servidores MCP con ámbito de proyecto a .mcp.jsony documente los comandos de prueba en CLAUDE.md. Configuración en sesiones en la nube enumera lo que lee cada sesión.
COMIENZA EN CINCO MINUTOS
La configuración toma unos cinco minutos. Después de eso, puedes entregar una tarea, cerrar tu computadora portátil y volver a una rama lista para revisión.
- Abre claude.ai/code, o ejecuta
/loginen Claude Code con tu cuenta de claude.ai. - Conecta GitHub e instala la Claude GitHub App donde se encuentra tu repositorio.
- Elige el repositorio y el entorno Default.
- Dale a Claude una tarea de tu backlog, con un comando que demuestre que está terminada.
- Cierra la pestaña. Revisa desde tu teléfono más tarde, luego revisa el diff y crea el pull request en claude.ai/code.