Claude Code Routines, que Anthropic lanzó en abril de 2026, es una configuración guardada de Claude Code: un prompt, uno o más repositorios y conectores, empaquetados una sola vez y ejecutados automáticamente en la infraestructura en la nube administrada por Anthropic. La documentación oficial describe tres tipos de activadores: cadencia programada, API (HTTP POST con token de portador) y eventos de GitHub. GitHub Actions, en contraste, ejecuta los scripts que escribes en corredores alojados en GitHub. Ambos pueden ejecutar agentes de IA en un horario. No son lo mismo, y elegir el incorrecto te cuesta dinero u horas de lucha con YAML. Este artículo mapea la decisión, recorre el worker de cola de blog y cubre recuperación de fallos.
Elige Cloud Routines, Desktop, Session Loops o Actions
Existen cuatro opciones de alojamiento. No son intercambiables.
Cloud Routines se ejecuta en la infraestructura de Anthropic sin importar si tu laptop está encendida. Según la documentación, cada rutina puede llevar un activador programado, un activador de API o un activador de evento de GitHub, y puedes combinar los tres en una rutina. El trade-off: cada ejecución hace un clon nuevo, por lo que los archivos locales nunca están disponibles.
Las tareas programadas de Desktop se ejecutan en tu máquina. Tienen acceso completo a tu sistema de archivos local, bases de datos locales y archivos .env. Si la máquina está apagada, la tarea no se ejecuta. Simple.
La programación con alcance de sesión (las herramientas CronCreate, CronList, CronDelete) opera solo dentro de una sesión CLI abierta. Estas son herramientas de programación de sesión, no la API de rutinas en la nube. Desaparecen cuando termina la sesión.
GitHub Actions con un activador cron es un archivo de flujo de trabajo YAML que GitHub ejecuta en un corredor alojado. Gratuito para repos públicos, barato para privados, determinista e integrado profundamente con tu base de código. El overhead es real si no vives ya en GitHub, pero para desarrolladores que sí, es mínimo.
Entonces: ¿cómo eliges?
- ¿La tarea se ejecuta sin importar si tu máquina está encendida y necesita razonamiento genuino de IA (resumir, redactar, clasificar)? Cloud Routine.
- ¿La tarea necesita tu
.envlocal, una base de datos local o herramientas locales? Tarea programada de Desktop. - ¿La tarea es una tubería de CI/CD, un manejador de evento de PR o un script determinista que llama a una API y publica en Slack? GitHub Actions, posiblemente con un script Python corto y sin LLM en absoluto.
- ¿La tarea es exploratoria y vive dentro de una sola sesión que ya estás ejecutando? Session loop.
El desglose de AI Magicx lo pone claramente: si tu rutina es "llamar a una API, transformar, publicar en Slack," GitHub Actions con un script Python de 10 líneas es más barato y simple. Routines se convierte en la opción correcta cuando el trabajo se beneficia genuinamente del razonamiento de Claude: decidir qué reportar, escribir una narrativa, revisar calidad.
Persistencia, Archivos Locales y Credenciales por Host
Aquí es donde los operadores se queman. La tabla de abajo usa información de la documentación oficial e investigación comunitaria, no resultados de pruebas reclamadas.
| Host | Archivos locales | .env | Credenciales | Sobrevive laptop cerrada |
|---|---|---|---|---|
| Rutina en la nube | No (clonación fresca) | No | Variables de entorno de rutina | Sí |
| Tarea programada de escritorio | Sí | Sí | Configuración local | No |
Bucle de sesión (CronCreate) | Sí (alcance de sesión) | Sí | Alcance de sesión | No |
| GitHub Actions | Solo archivos del repositorio | No | GitHub Secrets | Sí |
El write-up 2026 de Shareuhack señala un detalle específico que vale la pena citar:
"Toda ejecución de Rutina en la nube realiza una clonación fresca en el entorno en la nube de Anthropic, no puede acceder a tu .env.local local, bases de datos locales u otro estado local."
Y uno más: el acceso de red en rutinas en la nube por defecto es "trusted", que algunas APIs rechazan directamente. Si estás alcanzando ClickUp u otra API que rechaza solicitudes en modo trusted, cambia a acceso de red "full" en la configuración de entorno de la rutina. Hay un pequeño compromiso de seguridad, así que sopésalo contra la sensibilidad de tu repositorio.
Para GitHub Actions, los secretos viven en la configuración de Secrets del repositorio e se inyectan como variables de entorno en tiempo de ejecución. La acción anthropics/claude-code-action@v1, que está construida sobre el Claude Agent SDK, los recoge automáticamente. Pasas --model, --max-turns y --allowedTools mediante la entrada claude_args para controlar qué es lo que el agente realmente puede hacer.
Lee el Lector de Cola de Blog Actual
El lector de cola de blog es una rutina (o trabajo programado equivalente) que toma un post de una cola, genera contenido y lo marca como completado. Aquí está la estructura tal como está, con advertencias claras sobre qué hace realmente el código versus qué podrías asumir.
La afirmación condicional: el lector verifica si un post ya está reclamado antes de tomarlo. Eso previene que dos ejecuciones tomen el mismo elemento simultáneamente, al menos en el camino feliz. Lo que el código actual no tiene es recuperación de reclamo obsoleto. Si un lector muere en medio de la ejecución con un post marcado "en progreso", ese post permanece reclamado hasta que alguien lo reinicie manualmente. No describas esto como entrega exactly-once o como garantía de un post por día; ambas afirmaciones van más allá de lo que el código soporta.
El diagrama del worker se ve más o menos así:
- Fetch queue, filtrar por
status = queued - Reclamar el primer post disponible (set
status = in_progress, escribir un timestamp) - Ejecutar el prompt de generación contra los metadatos del post reclamado
- Si tiene éxito: set
status = published, escribir la ruta de salida - Si falla: incrementar retry_count, resetear
status = queued(si quedan reintentos) o setstatus = failed
El paso 5 es donde la mayoría de equipos subreinvierten. La lógica de reintentos necesita vivir en el prompt rutinario o el script wrapper, porque la infraestructura cloud en sí misma no vuelve a ejecutar una rutina que sale con un error.
Si estás construyendo content pipelines así y quieres que la capa agentic se maneje por ti, el trabajo que hacemos en agentic engineering cubre exactamente este patrón.
Programar trabajos vencidos y manejar reintentos
Programar una rutina vía CLI requiere Claude Code v2.1.225 o posterior. Antes de v2.1.211, el CLI reportaba un tiempo de próxima ejecución fantasma (año 1) para rutinas sin trigger de schedule. Vale la pena saber si estás leyendo logs antiguos.
Una rutina con solo triggers de API o GitHub event no tiene un próximo tiempo de ejecución. El CLI no muestra nada. Ese es el comportamiento correcto, no un bug.
Para manejar reintentos, tienes dos opciones:
- Reintentar dentro del prompt. Escribe el prompt para reintentar el paso fallido hasta N veces antes de marcar el trabajo como fallido. El razonamiento de Claude puede distinguir entre un error transitorio de red y un problema genuino de contenido.
- Reintentar vía una rutina scheduled separada. Una rutina "requeue" ligera corre cada hora, escanea posts donde
status = queuedyretry_count < 3, y re-dispara el main worker vía su trigger de API (un POST al endpoint por-rutina con un token bearer).
El segundo patrón es más limpio a escala. Desacopla la política de reintentos del prompt de generación, y puedes ajustar límites de reintentos sin tocar la rutina principal.
Los caps de ejecución diaria y el uso de suscripción compartida son una restricción real para equipos, como señala el write-up enterprise de Arcade. Su recomendación: agrupar trabajo en una única rutina "meta-orchestrador" diaria y reservar triggers en tiempo real solo para eventos de alta prioridad.
Para el lado de recuperación de palabras clave SEO de un content pipeline, el automation stack que documentamos en DataForSEO + Claude Code maneja eso por separado y vale la pena leer antes de que diseñes el schema de queue.
Detectar reclamaciones atascadas y verificar salida publicada
Las reclamaciones stale son el asesino silencioso de los pipelines basados en queue. Un post que ha estado in_progress durante seis horas casi con seguridad está atascado, no ejecutándose.
Una rutina de detección puede ser tan simple como:
- Query para posts donde
status = in_progressyclaimed_at < now() - 2 hours - Resetear esos a
status = queued, anular el identificador del worker, loguear el reset - Alertar vía Slack o un webhook si el conteo de reset excede un umbral
Ejecuta esto como una rutina separada de baja frecuencia (cada dos horas está bien) en lugar de integrarla en el worker principal. La separación de responsabilidades importa aquí: el worker principal no debe ser responsable de limpiar después de sí mismo.
Verificar el output publicado es un problema diferente. "Publicado" como un flag de estado significa que se escribió la base de datos. No significa que el post apareció correctamente en el sitio, pasó una verificación de legibilidad, o fue indexado. Un paso de verificación debe:
- Obtener la URL en vivo y confirmar que devuelve un 200
- Verificar el recuento de palabras o una señal de calidad ligera contra un umbral definido (elige tu propio número y etiquétalo como una heurística del equipo, no como un estándar universal)
- Si la verificación falla, revierte el estado a
queuedcon unretry_countincrementado y un flagverification_failed
El pipeline humanizador que describimos en AI Content Humanizer Pipeline ejecuta una verificación post-publicación similar y vale la pena hacer referencia cruzada si estás construyendo esa capa.
Costo operativo y propiedad
Aquí es donde la narrativa "las rutinas son más simples" se encuentra con fricción.
Cloud Routines se ejecuta en la infraestructura de Anthropic y consume límites de sesión de Claude Code de la misma manera que lo hace una sesión interactiva. El preview de investigación lo hace explícito: las rutinas agotan tus límites. Para un pequeño operador independiente ejecutando tres o cuatro rutinas al día, probablemente esté bien. Para un equipo procesando 20+ ejecuciones diarias, alcanzarás el límite y necesitarás diseñar una arquitectura alrededor de ello.
GitHub Actions es gratuito para repos públicos y tiene precio por minuto para los privados. Una ejecución de agente Claude Code dentro de Actions vía anthropics/claude-code-action@v1 sigue consumiendo tokens de API (facturados a tu tarifa de API de Anthropic), pero controlas el runner, el timeout y toda la lógica de reintentos. Esa propiedad es el punto.
La división de propiedad en la práctica:
- Las Routines son dueñas de: tareas que requieren mucho criterio que necesitan el razonamiento de Claude, tareas que deben ejecutarse desatendidas sin overhead de infraestructura, revisiones de PR desencadenadas por GitHub y triaje de Sentry/logs.
- GitHub Actions es dueño de: pipelines de CI/CD, manejo de eventos de PR e instalación de flujos, secuencias deterministas construir-probar-desplegar, y cualquier tarea donde un script Python de 10 líneas genuinamente hace el trabajo.
Ninguno reemplaza al otro. El artículo de Shareuhack lo plantea bien: "La combinación óptima permite que GitHub Actions maneje CI/CD mientras Routines maneja las partes intensivas en razonamiento". Ese planteamiento es correcto, y es el límite de decisión que vale la pena marcar.
FAQ
¿Puede una Cloud Routine escribir de vuelta en mi repositorio?
Sí. Las Routines se conectan a uno o más repositorios, y pueden hacer push de commits y abrir pull requests a través del repo conectado. Lo que no pueden hacer es acceder a archivos que solo existen en tu máquina local. Todo lo que la rutina necesita debe estar en el repo o configurarse como una variable de entorno en la configuración del entorno en la nube de la rutina.
¿Qué sucede si una Cloud Routine alcanza un límite de velocidad a mitad de la ejecución?
La rutina en sí no reintenta automáticamente en errores de límite de velocidad. Si sale con un error, permanece fallida hasta la próxima ejecución programada o hasta que la actives manualmente a través del endpoint de la API. Construir lógica de reintentos en el prompt (detectar una respuesta de límite de velocidad, esperar, reintentar) o usar una rutina de requeue separada son ambas mitigaciones razonables.
¿Es la instalación de la GitHub App separada del comando de configuración web de la CLI?
Sí, y esto sorprende a la gente. Ejecutar /web-setup en la CLI otorga acceso de clonación a la rutina pero no instala la GitHub App. La entrega de webhook para desencadenadores de eventos de GitHub requiere la instalación separada de la GitHub App. El flujo de configuración de rutina te guía a través de esto, pero los dos pasos son distintos.
¿Tienen límites de velocidad los desencadenadores de eventos de GitHub en Routines durante el preview de investigación?
Según la documentación oficial de routines, los eventos webhook de GitHub están sujetos a límites por hora por rutina y por cuenta durante el preview de investigación. Los eventos más allá del límite se descartan hasta que la ventana se reinicie. Planifica en consecuencia si esperas ráfagas de actividad de PR.
¿Puedo usar skills dentro de un flujo de trabajo de GitHub Actions con `anthropics/claude-code-action`?
Sí. La entrada de prompt acepta invocaciones de skills como /skill-name . Necesitas un paso actions/checkout antes de la acción para que los archivos de skills en .claude/skills/ estén presentes en el runner. Skills y commands son conceptos distintos en Claude Code; revisa la documentación oficial de skills antes de confundirlos.
La advertencia más importante de todo lo anterior: Cloud Routines consume tus límites de sesión de Claude Code exactamente como lo hacen las sesiones interactivas, y el worker de cola actual no tiene recuperación de reclamos obsoletos integrada. Diseña para ambos antes de enviar algo a producción.