Claude Code Routines: agentes 24/7 sin tu laptop

El 6 de mayo de 2026 Anthropic celebró su segundo Code with Claude en San Francisco y, contra lo que medio internet apostaba, no anunció un nuevo modelo flagship. La keynote completa giró alrededor de orquestación: managed agents, el Advisor que combina Opus como planificador con Sonnet como ejecutor, CI auto-fix, Remote Agents y — la pieza con la que más equipos van a tropezar antes de fin de mes — Claude Code Routines, agentes empaquetados que corren en la nube de Anthropic de forma scheduled, vía API o ante eventos de GitHub. Tu laptop puede estar cerrada. El routine sigue trabajando.

El cambio es más profundo de lo que parece. Hasta abril, “Claude Code” significaba un proceso en tu terminal: vos abrís la sesión, escribís el prompt, el modelo trabaja, vos cerrás. Los Routines rompen ese modelo: el agente vive en la cuenta, no en la máquina, y se dispara por reloj o por webhook. Es la misma diferencia conceptual que separa un script en tu MacBook de un cron en un servidor — solo que el servidor lo administra Anthropic y el ejecutor es un modelo. Esta guía cubre qué son exactamente, cómo crear el primero en menos de diez minutos, cuándo conviene frente a GitHub Actions o un cron propio, y los tres errores que vimos cometer a equipos en los primeros días.

Qué es un Routine, en una frase

Un routine es una configuración guardada de Claude Code — un prompt, uno o más repositorios y un conjunto de connectors — que se ejecuta automáticamente sin requerir que el desarrollador esté presente. Vos lo configurás una vez; después corre solo, hospedado en la infraestructura cloud de Anthropic.

Tres atributos que lo distinguen de cualquier flujo previo:

• No depende de tu máquina. A diferencia del CLI tradicional (sesión local) o de las tareas programadas del Desktop app (atadas a que el equipo esté encendido), los routines viven en la cuenta de Anthropic y corren contra sus servidores.
• Combina triggers heterogéneos. Un mismo routine puede dispararse por cron diario, por una llamada HTTP POST con bearer token, y por un evento de GitHub — los tres conviven sobre la misma configuración.
• Tiene memoria de cuenta, no de máquina. Los routines comparten el contexto persistente de tu cuenta de Anthropic: lo que un routine aprende de un repo queda disponible para otro routine sobre el mismo repo, sin reindexar.

Cómo se crean: tres superficies, una misma cuenta

Anthropic mantuvo la promesa de que cualquier ergonomía nueva debería estar disponible desde los tres canales que ya usan los desarrolladores. Los routines se crean indistintamente desde:

• La web, en claude.ai/code/routines. Es la interfaz más visual — formularios para el prompt, selector de repos, configuración de triggers paso a paso. Recomendada para el primer routine de tu vida.
• El CLI, con el comando /schedule dentro de cualquier sesión de claude-code. Es el camino más rápido si ya estás trabajando en un proyecto y querés convertir el prompt que acabás de iterar en un agente recurrente.
• El Desktop app (Claude para Mac / Windows), también desde la sección Routines del sidebar.

Los tres caminos escriben al mismo backend, así que un routine creado por CLI aparece inmediatamente en la web y viceversa. Es uno de esos detalles que parecen menores y resuelven una fricción real: vos prototipás en CLI, después un teammate revisa la configuración desde la web, y un PM lo monitorea desde el Desktop sin pisarse con nadie.

Los tres tipos de trigger, sin marketing

Cada routine puede tener uno o más triggers asociados. La elección del trigger define el modelo mental de uso.

Trigger 1: Scheduled (cron sencillo)

Cuatro presets predefinidos: hourly, daily, weekdays, weekly. Los horarios se ingresan en tu zona horaria local y Anthropic los convierte internamente a UTC.

preset: weekdays
hora: 08:00 (America/Guayaquil)
acción: revisar dependencias críticas del repo
        y abrir PR con bumps menores si los hay

Lo que no hay todavía: expresiones cron arbitrarias. Si necesitás “cada 17 minutos” o “el segundo martes del mes a las 03:42”, los presets se quedan cortos y vas a tener que combinar con un cron propio que dispare el trigger API. La omisión es deliberada — Anthropic quiere mantener el catálogo de schedules predecible para optimizar capacity planning del lado de servidor.

Trigger 2: API (HTTP POST con bearer token)

Cada routine expone un endpoint único: POST https://api.anthropic.com/v1/routines/{routine_id}/runs con un Authorization: Bearer <token> y un cuerpo JSON con variables que el prompt referencia.

POST /v1/routines/rt_8f3...c2/runs HTTP/1.1
Host: api.anthropic.com
Authorization: Bearer sk-rtn-...
Content-Type: application/json

{
  "input": {
    "issue_id": 4827,
    "priority": "p1"
  }
}

Este trigger es el que cambia las reglas. Cualquier sistema que sepa hacer un HTTP POST puede invocar a Claude Code: un job de tu pipeline interno, un bot de Slack, un webhook de Stripe, un cron job de tu propio servidor cuando el preset no alcanza. Es la API que convierte a Claude Code en una pieza de tu infraestructura, no solo en un editor.

Trigger 3: GitHub (eventos del repo)

Requiere instalar la Claude GitHub App sobre el repo objetivo — el flujo de creación del routine te lo propone automáticamente la primera vez. Eventos soportados al momento de publicar este post: pull_request, issue_comment, release, push, workflow_run, con filtros sobre branch, label, autor y path.

trigger: github
repo: empresa/saas-core
event: pull_request
filters:
  - opened
  - reopened
  - labels: ["needs-review"]
acción: analizar el diff, dejar comentarios y proponer
        cambios si encontrás regresiones obvias

Esto compite directamente con GitHub Actions custom — pero corre sin runner provisionado, sin yaml, sin marketplace de acciones de terceros y con el modelo razonando sobre el diff completo en vez de ejecutar un script. Más adelante en este post comparamos los dos enfoques en una tabla.

Tu primer routine en 10 minutos

Un caso útil que casi cualquier equipo puede instalar hoy: un routine que cada noche analiza los issues abiertos del repo, los clasifica por severidad, propone labels y deja un comentario con un plan tentativo. Cuesta poco, libera tiempo de triage y demuestra el valor del modelo sin riesgo de tocar código.

Paso 1: Definí el prompt

En claude.ai/code/routines clickeá New routine y pegá un prompt explícito sobre el objetivo, los criterios y los límites:

Sos un triage agent. Cada noche revisás los issues abiertos
en este repositorio creados o modificados en las últimas 24 horas.

Para cada issue:
1. Clasificalo en severidad: p0 (caída), p1 (bug crítico),
   p2 (bug normal), p3 (mejora), p4 (idea).
2. Sugerí labels relevantes del label set existente del repo.
3. Si el issue tiene suficiente contexto, dejá un comentario
   con un plan de 3-5 pasos para resolverlo.
4. Si falta información, dejá un comentario amable pidiendo
   exactamente lo que falta (logs, repro, captura).

No cierres issues. No asignes a nadie. No mezcles severidades
distintas en un mismo comentario.

La regla de oro: cuanto más explícito el prompt sobre lo que NO debe hacer, menos sorpresas en la primera ejecución.

Paso 2: Conectá el repo

Seleccioná el repositorio sobre el que el routine va a trabajar. Si no aparece, instalá la Claude GitHub App desde el botón inline — toma 30 segundos y solo pide permisos sobre repos específicos (no toda tu organización).

Paso 3: Agregá el trigger scheduled

Preset: daily. Hora: 22:00 en tu zona horaria. Eso asegura que cuando llegues a la oficina al día siguiente, los issues nocturnos ya tienen su comentario inicial y vos arrancás con el triage avanzado.

Paso 4: Probá manualmente antes de dejarlo correr solo

Antes del primer run automático, clickeá Run now y observá el resultado en la pestaña Runs. Vas a ver el log completo: qué archivos leyó, qué llamadas a la GitHub API hizo, qué decisiones tomó. Es el momento de ajustar el prompt antes de que se ejecute sin supervisión.

Paso 5: Configurá las notificaciones

En la pestaña Notifications elegí dónde querés ver el resumen diario — Slack, email, webhook a tu propio sistema. La práctica más útil: un canal de Slack #triage-bot con el resumen del trabajo de cada noche, para que el equipo pueda ver de un vistazo si el routine se descarriló.

Total: 10 minutos si ya tenés la cuenta de Anthropic configurada, 20 si tenés que instalar la GitHub App por primera vez.

Routines vs GitHub Actions vs cron propio

La pregunta inmediata de cualquier equipo con infraestructura existente: ¿por qué no GitHub Actions, que ya conocemos? La tabla siguiente recoge los criterios que realmente diferencian a las tres opciones.

El veredicto realista: no son competidores directos. Los Actions siguen ganando en build/test/deploy clásicos donde la precisión determinística importa más que la inteligencia. Los Routines ganan en tareas que requieren entender el repo — triage, análisis de dependencias, redacción de release notes, auditoría de seguridad sobre PRs, propuestas de refactor. Y un cron en tu propio servidor sigue siendo el único camino cuando necesitás SLA estricto y control total del runtime.

Managed Agents: la pieza más grande que casi nadie nombró

Detrás de los routines hay una arquitectura más amplia que Anthropic llamó Managed Agents y que vale la pena entender por separado. Los managed agents son runtimes hospedados que ejecutan workflows multi-step de Claude por cuenta de un usuario o aplicación, sin que tengas que provisionar la infraestructura del agente. Anthropic gestiona la orquestación, las llamadas a tools, el estado, y la recuperación frente a fallos.

En términos prácticos: los routines son la primera categoría de managed agents que Anthropic ofrece — el caso de uso “agente recurrente sobre un repo”. Otros managed agents que están en pipeline o ya disponibles:

• Remote Agents: agentes invocables desde una superficie de chat o un trigger programado, pensados para correr workflows sobre tu cuenta desde el teléfono. El usecase canónico que mostró Anthropic en la keynote: “iniciar desde el celular un agente que arregla un build roto mientras vas en el bus”. Lo cubrimos parcialmente en nuestra revisión de Claude para el desarrollo móvil — la lógica que ahí aplicaba a OpenAI ahora la replica Anthropic con piezas propias.
• Advisor: una herramienta nueva en research preview que pareja a Opus como planificador con Sonnet como ejecutor, dejando que la inteligencia más cara solo se gaste en decisiones, no en producción línea por línea de tokens. Cubrimos su impacto sobre la economía del agente en el comparativo de Cursor 3 vs Windsurf 2026.
• CI auto-fix: workflow programable que detecta builds rotos y propone el fix antes de que el dev abra el laptop por la mañana.

Es el patrón que ya predijimos hace dos semanas cuando Anthropic empujó Fast mode para Opus 4.7: el próximo año de ventaja competitiva no viene del modelo, viene de la orquestación. Code with Claude 2026 lo confirmó saltándose la presentación del modelo.

Precios, límites y permisos

Anthropic mantiene la regla simple: los routines consumen tokens contra tu cuenta como cualquier otro uso de Claude Code. No hay un fee aparte por el “servicio routine”. Lo que sí cambió favorablemente:

• Doblaron el límite de 5 horas de Claude Code para clientes Pro, Max y Enterprise. Eso significa que un routine puede correr hasta diez horas continuas antes de cortarse — más que suficiente para el 99% de los casos de uso reales.
• Cache diagnostics en public beta: una nueva pestaña en la consola que explica por qué tu prompt no está hiteando el cache. Para routines que corren muchas veces sobre el mismo repo, optimizar el cache hit rate baja el costo entre 60-90%.
• Fast mode para Opus 4.7 disponible en research preview: misma calidad, generación más rápida. Útil para routines que necesitan respuesta sub-minuto.

Los permisos del routine sobre tu repo se configuran en la Claude GitHub App: read-only por default, write opcional para escribir comentarios, push opcional para abrir PRs. La práctica mínima razonable: read + commenter para empezar, y subir a push cuando tengas confianza en el comportamiento después de dos o tres semanas de observación.

Cuándo NO usar Routines (tres anti-patrones que ya vimos)

En la primera quincena post-lanzamiento ya emergieron tres usos donde los routines defraudan. Vale la pena anticiparlos.

1. Como reemplazo de un cron crítico de producción. Anthropic no ofrece SLA del 99.99% sobre la ejecución de routines. Si tu billing nocturno depende de que el job se ejecute a tiempo, dejalo en tu infraestructura. Los routines son excelentes para tareas “best effort” — triage, análisis, drafts — no para procesos donde la pérdida de una corrida cuesta dinero.

2. Para tareas determinísticas que ya tenés en Actions. Si tu workflow es “correr eslint, fallar el build si hay errores”, no hay razón para meterle un modelo en el medio. Vas a pagar tokens por una decisión que un linter resuelve por cero. El modelo aporta cuando hay juicio involucrado.

3. Como vector único de cambios en el repo. Hay equipos que delegaron al routine la apertura de todos los PRs de mantenimiento. El problema: cuando algo sale mal, el debugging es tortuoso porque el “autor” del cambio es opaco. Mejor patrón: el routine propone, un humano (o un segundo agente de revisión) aprueba.

Tabla resumen