Claude Code ahora tiene cuatro superficies distintas para automatizar trabajo repetido, y la primera pregunta aquí no es cómo escribir el trigger. La primera pregunta es quién debe ser dueño del runtime. Routines es la rama cloud: el workflow puede seguir corriendo dentro de un clone gestionado por Anthropic incluso cuando tu portátil ya está cerrado. Desktop scheduled tasks se queda en tu máquina, /loop se queda dentro de la session actual y GitHub Actions se queda en CI.
Mirado así, el tema es bastante más simple que el ruido típico de un lanzamiento. Si el workflow debe seguir ejecutándose sin tu portátil y puede vivir dentro de un repo runtime en la nube, Routines es una ruta razonable. Si depende de archivos locales, apps locales o un browser local, conviene Desktop scheduled tasks. Si basta con la session de Claude Code que ya tienes abierta, conviene /loop. Si la automatización pertenece al repositorio, al pipeline y a los logs de CI, conviene GitHub Actions. Cuando el trabajo depende de tu máquina, de una conversación abierta o de un contrato claramente CI-owned, Routines no es el owner correcto aunque la tarea sea recurrente.
Anthropic lanzó Routines en research preview el 14 de abril de 2026. Lo importante aquí no es solo la fecha, sino que el contrato actual sigue siendo más estrecho de lo que sugieren muchos titulares. Routines ya soporta triggers por schedule, API y GitHub, pero el CLI /schedule solo crea la variante programada, y el API trigger no usa el patrón normal de Anthropic API key, sino un per-routine bearer token.
“Nota de evidencia: este artículo se apoya en las páginas vigentes de Anthropic sobre routines, scheduled tasks y
/fire, revisadas el 16 de abril de 2026. Los datos sobre daily caps, beta headers y preview status deben leerse como hechos fechados.
La forma más rápida de decidir
Antes de pensar en prompts, cron o webhook payloads, decide qué runtime debería ser el owner del workflow.
| Si el workflow necesita... | El owner más natural es... | Por qué gana esa ruta | Por qué no Routines |
|---|---|---|---|
| seguir corriendo cuando el portátil ya está cerrado | Routines | Anthropic lo despierta dentro de un cloud clone y puede lanzarlo por schedule, API o GitHub events | Si la tarea depende de estado local, el cloud clone no ve ese mismo entorno |
| acceso directo a archivos locales, apps locales o browser local | Desktop scheduled tasks | La dependencia vive en la máquina, así que la automatización también debería quedarse allí | El runtime cloud no comparte ese mismo estado local |
| polling corto o watch-work dentro de la session actual | /loop | Es más ligero, puede correr por minutos y mantiene como owner la session abierta | Es session-scoped y los recurring loops expiran a los siete días |
| automatización de CI con logs de build, policy checks y semántica repo-owned | GitHub Actions | El workflow pertenece al repositorio y a CI | Routines no se convierte en “mejor CI” por ser más nuevo |
Quédate con esta tabla. El error importante aquí no es no saber configurar algo. El error importante es entregar el workflow al owner equivocado.
Qué posee realmente Routines
Cuando se oye la palabra automation, es fácil pensar que estas cuatro superficies solo se diferencian por el tipo de trigger. En realidad la diferencia empieza antes: cambian la ubicación de ejecución y el ownership. En las docs actuales de Anthropic, un routine se parece más a un workflow guardado de Claude Code con prompt, uno o varios repositorios, connectors y entorno, que luego se ejecuta automáticamente sobre infraestructura cloud gestionada por Anthropic.
Eso tiene consecuencias bastante concretas. Primero, un routine no es “control remoto de tu Claude Code local”. Es otra superficie de ejecución. Las docs actuales de Anthropic explican que el repositorio se clona en cada run, que normalmente se parte de la default branch y que las acciones contra sistemas externos se ven como acciones del usuario ligado a la cuenta claude.ai.
Segundo, Routines tiene un entorno más definido que muchos workflows locales de Claude Code, pero también más acotado. Anthropic usa cloud environments para network access, environment variables y setup scripts. Eso lo hace valioso cuando el trabajo debe continuar después de que te vayas. Pero por la misma razón deja de encajar cuando la tarea depende de un browser profile local, software de escritorio, un mounted drive o una credential path específica de tu máquina.
Tercero, Routines no es un unattended shell sin límites. Anthropic sigue restringiendo por defecto los pushes a ramas con prefijo claude/, salvo que habilites unrestricted branch pushes en el repo. Esa frontera importa porque muestra que Routines fue diseñado como un bounded cloud automation surface, no como reemplazo universal del scheduler local, del desktop automation y de CI.
Cuándo sí encaja Routines
Routines empieza a resultar convincente cuando “dejar el portátil abierto” deja de ser una condición aceptable. Por ejemplo: revisar cada mañana un repositorio, ver stale issues, mirar PR nuevos y devolver una lista corta de next actions. O hacer checks recurrentes de docs drift, backlog triage o workflows que se despiertan por eventos de GitHub y hacen trabajo útil desde el lado del repo cloud.
Los ejemplos públicos de Anthropic van justamente por ahí: issue triage, research, recurring repo work. La razón para elegir Routines no es que sea la superficie más flexible. La razón es que el workflow gana cuando el owner deja de ser tu máquina o tu session abierta y pasa a ser una cloud session acotada.
También encaja cuando otro sistema tiene que despertar el trabajo de forma remota. Aquí conviene usar el mental model correcto. No es simplemente “llamar a Claude desde código”. Es más útil pensar en “disparar un workflow cloud ya configurado con un payload pequeño”. Ese modelo es más estrecho, pero también más limpio para procesos estables.
Igual de importante es mantener visible el caso negativo. Routines no es la respuesta por defecto a cualquier recurring job. Si el workflow solo tiene sentido dentro de una Claude Code session viva o si depende de la máquina local, añadir una capa cloud trae más complejidad que valor.
Cuándo convienen más Desktop scheduled tasks, /loop o GitHub Actions
Rechazar Routines suele ser la decisión correcta. Por eso las otras tres rutas no pueden quedar como nota al pie.
Desktop scheduled tasks: lo machine-bound debe quedarse en la máquina
Si el workflow depende de archivos locales, aplicaciones locales o un browser profile local, la decisión suele estar tomada antes de hablar de triggers. El job debe quedarse donde vive la dependencia. Desktop scheduled tasks vale precisamente porque ve el estado local que el cloud clone de Routines no puede ver.
Aquí entra otra frontera práctica: el cadence local por debajo de una hora. Si necesitas una frecuencia local más fina y además la dependencia sigue siendo local, Desktop scheduled tasks es una ruta mucho más natural que forzar Routines.
/loop: es una superficie para live session, no para cloud persistence
/loop es más ligero que Routines porque su alcance es menor. Las docs actuales de Anthropic lo describen como session-scoped scheduling: puede correr por minutos, pero los recurring loops caducan a los siete días. Eso lo vuelve muy útil para watch-work y polling corto dentro de una coding session ya abierta.
Una confusión muy común es pensar que /loop y Routines son la misma idea en dos grados de madurez distintos. No es así. /loop sirve cuando la session abierta sigue siendo el owner adecuado. Routines sirve cuando ya no quieres que esa session abierta sea el owner porque el workflow debe sobrevivirla.
Si el problema real no es unattended automation sino la fricción de approvals en una sesión local larga, el sibling más cercano es Claude Code Auto Mode, no Routines. Auto Mode cambia el comportamiento de approvals dentro del workflow local. Routines cambia dónde vive ese workflow.
GitHub Actions: lo que es de CI debe seguir en CI
GitHub Actions debe tratarse como una sibling route seria, no como una reliquia que Routines viniera a reemplazar. Si la automatización pertenece a repository policy, builds, test gates, mantenimiento programado de CI o logs auditables, GitHub Actions sigue dando un contrato más limpio. Los logs quedan donde vive el historial de CI. Los permisos quedan donde viven los permisos de automatización del repo.
Sí, Routines puede despertarse desde GitHub events. Pero eso no lo convierte en “mejor GitHub Actions”. Solo lo convierte en otra execution surface que puede arrancar desde un evento del repo. Si el evento es solo la señal de arranque y el valor real está en una cloud Claude Code session, tiene sentido. Si el workflow en sí pertenece a CI, no lo saques de GitHub Actions.
Y si al final decides que el trabajo debe quedarse local, el siguiente problema suele ser tool access, no scheduling. En ese caso ayuda más los mejores MCP Servers para Claude Code que otro tutorial sobre routines.
Límites actuales: preview, auth y frecuencia de ejecución
Routines ya es suficientemente real como para usarlo, pero el contrato actual todavía cambia decisiones. Según los launch materials de Anthropic, a fecha de 16 de abril de 2026 los included routine runs son 5/day para Pro, 15/day para Max y 25/day para Team o Enterprise. Además, esos routine runs salen del mismo subscription usage pool que las interactive Claude Code sessions. No hace falta convertir eso en la personalidad de la página, pero sí cambia qué workloads merece la pena mover primero.
El auth model importa igual de mucho. Las /fire docs actuales dicen con claridad que el API trigger usa un per-routine bearer token y el beta header anthropic-beta: experimental-cc-routine-2026-04-01. No es simplemente otra forma de usar tu Anthropic API key habitual.
La configuración de triggers también tiene su frontera. Routines soporta schedule, API y GitHub triggers, y un mismo routine puede combinarlos. Pero el CLI es más estrecho que la surface completa: claude --schedule solo crea el routine programado, mientras que API y GitHub triggers se configuran desde el web editor. Ese dato importa después del route choice, no antes.
Hay otra frontera silenciosa pero decisiva: cloud routines requiere un intervalo mínimo de una hora. Si necesitas polling por minutos, Routines ya queda descartado por contrato. Ahí el terreno es /loop, la ruta local o CI.
Si después del route choice necesitas el contexto más amplio de plans y usage, conviene saltar a la guía de precios de Claude Code. Para esta página importa otra cosa: cómo preview caps y shared usage pools cambian la elección del owner.
Cuál es el primer routine más seguro
El mejor primer routine suele ser algo deliberadamente aburrido. Debe ser lo bastante estrecho como para que puedas medir rápido su valor, y lo bastante seguro como para que un error no deje cleanup work en tres sistemas a la vez.
Una forma muy razonable es un routine matinal de single-repo triage:
- Empieza con un solo repositorio, no con cinco.
- El primer día usa solo schedule trigger; no mezcles API, GitHub y schedule a la vez.
- Haz que revise stale issues, open PR y failing checks, y que devuelva una summary corta o una branch-scoped draft action list.
- Mantén los pushes dentro de las branch boundaries por defecto y no abras más write power de la necesaria.
Ese patrón es bueno porque prueba exactamente lo que Routines debería probar: si la cloud persistence sirve para empujar trabajo útil de repo mientras tú no estás. No depende del estado local y no finge que CI deba desaparecer.
El mal primer routine suele tener la forma contraria: demasiados repos, demasiados triggers, demasiado write power y demasiada fe en que automation significa “meterlo todo en una sola surface”. Primero deja que la surface se gane su sitio con un workflow bounded.
FAQ
¿Routines es lo mismo que /schedule o scheduled tasks?
No. Routines es la surface más amplia y actual, que incluye schedule, API y GitHub triggers. El camino --schedule del CLI solo crea la variante programada.
¿Cuándo debería elegir Desktop scheduled tasks?
Cuando el job depende de archivos locales, apps locales, browser local o cualquier machine-bound state. También cuando necesitas cadence local por debajo de una hora. Si la dependencia vive en la máquina, el owner más natural sigue siendo la máquina.
¿Cuándo basta con /loop?
Cuando el trabajo pertenece a la Claude Code session actual y solo necesita repetición corta. /loop puede correr por minutos, pero sigue siendo session-scoped y sus recurring loops caducan a los siete días.
¿Routines reemplaza a GitHub Actions?
No. Si el workflow pertenece a CI, repository policy, build automation o pipeline logs auditables, GitHub Actions sigue siendo la mejor ruta. Routines es una sibling route.
¿Cómo se autentica el routine API trigger?
Las docs actuales de Anthropic indican que usa un per-routine bearer token y el header anthropic-beta: experimental-cc-routine-2026-04-01. No comparte el mismo auth flow que una integración normal con Anthropic API key.
¿Cuáles son hoy los daily routine-run limits?
A fecha de 16 de abril de 2026, los launch materials de Anthropic indican 5/day para Pro, 15/day para Max y 25/day para Team o Enterprise. Léelos como facts de preview con fecha.
La pregunta útil sigue siendo quién debe ser dueño del runtime
Routines importa no porque Claude Code haya recibido “un scheduler más potente”, sino porque Anthropic separó una ruta de cloud-persistent automation como surface propia. Si tu workflow debe seguir vivo dentro de un cloud clone cuando tú ya no estás, esa ruta tiene un sentido muy claro.
Pero eso no la vuelve la respuesta correcta para todo workflow recurrente. Si el trabajo pertenece a tu máquina, a tu live session o a CI, otro owner será más natural. En cuanto miras el tema así, Routines deja de parecer un scheduler universal y pasa a verse como una rama bien delimitada dentro del automation stack de Claude Code.