Las Rutinas de Claude No Son un Cron de Razonamiento. Son un Subconjunto Centrado en Repositorios

11 min read

Una semana después de que Anthropic lanzara Routines, tres de mis cron jobs están funcionando en producción. Me tomó treinta minutos.

La revisión automática de PRs que consultaba GitHub cada media hora? Muerta. El script semanal que detectaba documentación desactualizada parseando commits con bash oxidado? Muerto. La actualización de datos SEO que llevaba posponiendo seis meses (sin tiempo, ya sabes cómo es)? Funcionando en cinco minutos.

Tres trabajos, treinta minutos, sin fricción. Convencido. Esa noche, fui por el cuarto.

Y entonces, nada. Ni un error, ni cuota excedida, ni YAML malformado. El job corre, el binario responde, pero el servicio que consulta vive en una IP que Routines no ve y nunca verá, por diseño. Los otros cuarenta y siete jobs en mi servidor están en la misma situación. Ni uno encaja. Y no es un problema que se pueda arreglar (es mecánico).

Desde que salió Routines, he visto principalmente demos. Todos muestran los tres jobs que funcionan. Nadie menciona el límite. Lo que sigue es cómo conectar esto a infraestructura de producción, incluyendo las partes donde Routines se detiene y tú tomas el control.

TLDR. Routines no es un cron con razonamiento universal. Es un cron con razonamiento que tiene un perímetro, y la mayoría de la automatización vive fuera de ese perímetro por razones que no puedes resolver con configuración. La pregunta no es si Routines es bueno. Es dónde se detiene, qué corre ahí en su lugar, y cómo mantener viva la mitad DIY sin tener que reloguearse cada mañana.

Los tres jobs que migré funcionan mejor en la nube de Anthropic que en mi servidor. La revisión de PRs se dispara con pull_request.opened en lugar de hacer polling. El script de documentación desactualizada ahora tiene contexto completo del repo, la salida pasó de revisable a útil. La actualización SEO simplemente corre, cada mañana, sin costo de configuración. Esa parte está resuelta.

El artículo trata sobre todo lo demás. Los cuarenta y siete jobs que traté de migrar después, por qué ni uno funciona, y el patrón DIY que sobrevive en 2026 una vez que aceptas de qué lado de la línea está tu trabajo.

Comparación de oficina en pantalla dividida: desarrollador abrumado rodeado de logs de errores y configuraciones impresas versus desarrollador tranquilo con escritorio limpio e interfaz de automatización simple.
Trabajos Cron vs. Rutinas: a una captura de pantalla de la cordura.

Qué Significa Realmente "Cron con Razonamiento"

Déjame definir de qué estamos hablando.

Un cron con razonamiento es un programador que llama a un LLM para pensar, no solo para ejecutar código determinístico. Lee contexto, toma decisiones, genera salida que depende de lo que acaba de ver. n8n, Make y Zapier enrutan datos (no piensan). Un cron de Python es rígido, se rompe cuando cambia el formato de entrada. Un cron con razonamiento se adapta.

Esa es la categoría. Routines pertenece a ella. También mi patrón DIY. También cualquier wrapper alrededor de claude -p o gpt o gemini. La categoría es real, la demanda es real, y que Anthropic lance un producto gestionado para esto es la decisión correcta.

Lo que es engañoso es llamar a Routines el cron con razonamiento. Es un cron con razonamiento con un perímetro fijo.

El perímetro tiene tres muros. Uno, Routines corre en la nube de Anthropic, no en tu máquina. Clona un repo de Git al inicio de cada ejecución y ese es todo el sistema de archivos que ve. Dos, habla con el mundo exterior a través de conectores gestionados (Slack, Linear, Jira, GitHub, GDrive) y una lista blanca HTTP (por defecto Trusted, que bloquea la mayoría de APIs externas). Tres, tiene una pizarra limpia en cada ejecución. Sin estado, sin cookies, sin sesión persistente.

La guía práctica de Nimbalyst llegó a la misma línea independientemente: usa Routines cuando el trabajo es centrado en repo, corre en horario, y no necesita tu entorno local. Mismo perímetro, palabras diferentes.

Una vez que tienes esos tres muros en tu cabeza, lo que sigue no es opinión. Es consecuencia.

Donde Routines Gana (Tres Jobs Que No Voy a Tocar Otra Vez)

Concesión primero, porque la honestidad es más rápida que la retórica.

Estos tres jobs están mejor en Routines de lo que estaban en mi cron. No los voy a migrar de vuelta.

Revisión automática de PRs. Antes: un cron de Python que consultaba GitHub cada treinta minutos, ejecutaba una revisión con claude -p en cualquier PR nuevo, posteaba un comentario vía la API. El cron con polling se retrasaba con cada push. Después: una Routine disparada en pull_request.opened, corre en el momento que se abre un PR, postea vía el conector de GitHub. Mismo prompt, misma calidad de salida. Menos YAML, sin desperdicio de polling.

Documentación desactualizada semanal. Antes: un script bash que listaba commits desde el lunes pasado, los comparaba contra la carpeta docs, alimentaba ambos a claude -p, me enviaba un resumen por email. El resumen siempre estaba ligeramente mal porque el script no tenía contexto de todo el repo. El modelo solo veía lo que bash le pasaba con sed. Después: una Routine que obtiene el repo completo clonado, lee CLAUDE.md, la carpeta docs, y el log de commits nativamente, y escribe un doc de "qué cambió, qué está desactualizado" que realmente refleja el codebase. La salida pasó de revisable a útil.

Actualización de datos SEO. Sin Antes. Había querido configurar una extracción semanal de mi proveedor de analytics, pasar un modelo sobre los deltas, y postear un resumen a Slack. Cada vez que me sentaba a conectarlo, llegaba otra cosa y el YAML nunca se escribía. Después: una Routine, quince minutos de configuración, corre cada mañana. El job que nunca construí en seis meses ahora existe. Ese es el caso más fuerte para un producto gestionado (el trabajo que nunca te pondrías a hacer tú mismo).

Estos tres comparten cuatro características. Centrados en repo. La salida va a Slack o GitHub. La frecuencia es de al menos una hora. Nada en la cadena toca mi red local.

Ese es exactamente el perímetro de Routines. Mis otros cuarenta y siete jobs fallan en al menos una de esas cuatro. Ni uno de cuarenta y siete cumple las cuatro.

Seis Razones Por Las Que Routines No Puede Reemplazar Mis Cron Jobs

Seis razones mecánicas. No preferencias, no casos extremos. Cada una cierra la puerta antes de que termines de escribir el YAML.

1. Servidores MCP locales. Routines usa los conectores gestionados de Anthropic. Eso es todo. El servidor MCP que escribí yo mismo, el que vive en mi máquina y expone mis propios datos a mis sesiones de Claude Code, no está disponible. Routines no puede verlo, no puede hablar con él, no puede autenticarse contra él. Cualquier flujo donde el modelo necesite consultar algo que construí localmente está fuera.

2. Servicios en IPs privadas. Mesh de Tailscale. NAS en casa. Postgres en el servidor. Dashboards de monitoreo internos. Cualquier cosa en una dirección 100.x o una LAN 192.168. Routines corre en la nube de Anthropic. No sabe que mi mesh existe. El cuarto job de la introducción vive aquí, y también diecinueve otros en mi lista.

3. Frecuencia sub-horaria. El intervalo mínimo de Routines es una hora. Mi poller de estado corre cada quince minutos porque eso es lo que requiere la ventana de alerta. Cualquier job que necesite dispararse más rápido que una vez por hora, mecánicamente, no se puede mover.

4. Cuota diaria. Pro son 5 ejecuciones por día. Max son 15. Team son 25. Tengo cuarenta y siete jobs que necesitan correr por la noche, más los diarios, más los sub-horarios. Incluso si todas las otras restricciones desaparecieran, llegaría a la cuota antes de medianoche en un plan Max. La cuota no es un límite suave que puedas negociar (es el contrato).

5. Sesión persistente de navegador. Routines levanta un entorno limpio en cada ejecución. Sin cookies, sin localStorage, sin transferencia de sesión. Si tu job necesita loguearse a un sitio una vez y reusar la sesión, automatización con Playwright contra un servicio que requiere auth, no puedes. Nate Herk documentó esto en Skool cuando trató de ejecutar una automatización de comunidad en Routines. El login muere entre ejecuciones. El job es estructuralmente imposible.

6. Estado persistente local. Un job que escribe a un SQLite local entre ejecuciones, o mantiene una cola basada en archivos, o añade a un log de larga duración. Routines empieza fresco cada vez. Lo que sea que tu job escribió la ejecución pasada se fue. Puedes usar las salidas de los conectores como estado (tickets de Linear, issues de GitHub), pero si tu estado vive en disco donde vive el cron, eso no es portable.

Un comentario de la comunidad bajo el post de lanzamiento de Anthropic en Threads lo puso sin rodeos: otra vez características centradas en github. Esa es la lectura desde afuera, y es correcta, pero también incompleta. Routines no es solo GitHub, los conectores hacen más que eso. El encuadre honesto es: Routines está centrado en repos y conectores gestionados, y si tu trabajo pasa fuera de ese perímetro, la herramienta no tiene nada que ofrecerte.

Seis casos. No seis opiniones.

El Patrón DIY Que Sobrevive en 2026

Si tu job vive fuera del perímetro de Routines, lo construyes tú mismo. Lo que sigue es el patrón que sobrevive, las partes que nadie documenta en la docena de tutoriales "Routines acaba de salir" saturando el feed la semana pasada.

Usa redirección de shell, no spawn-with-stdin.

claude -p "Summarize the input as JSON" < input.txt

echo "$LARGE_INPUT" | claude -p "Summarize"

El deadlock del pipe es el asesino silencioso. Sin error, sin timeout, solo un proceso colgado en un stdin bufferizado que nunca se cierra. Perdí un fin de semana en esto antes de rastrearlo. La redirección de shell desde un archivo es la única forma confiable de alimentar input grande al binario en modo no interactivo.

Desactiva ANTHROPIC_API_KEY en tu entorno cron.

unset ANTHROPIC_API_KEY
claude -p "..."

Si ANTHROPIC_API_KEY está configurada cuando llamas claude -p, el binario la usa y factura a tu cuenta API. Silenciosamente. La precedencia de auth está documentada pero es fácil de pasar por alto. Piensas que estás corriendo en tu suscripción, y en realidad cada ejecución de cron está pasando por pago por token. Desactívala explícitamente. Tu billetera te lo agradecerá.

Restringe la salida JSON vía prompt, no flag.

No confíes en --output-format json para hacer el trabajo pesado. Dile al modelo qué esquema quieres, en el prompt, luego valida downstream:

claude -p 'Respond ONLY with valid JSON matching: {"status": "ok|fail", "items": [...]}. No prose, no fences.' < input.txt | jq -e .status

Si jq -e falla, reintenta una vez. Si el reintento falla, alerta. El contrato a nivel de prompt se mantiene mejor que el flag en mi experiencia, y obtienes modos de falla limpios cuando el modelo se desvía.

Esta es también la razón por la que el patrón DIY no desaparece cuando MCP se vuelve más rico. El binario CLI se mantiene predecible, determinístico a nivel de shell, y se compone con todo lo demás que tienes. Hice el argumento más largo para CLIs sobre MCP en stacks de agentes hace unas semanas, y Routines no cambia la conclusión. Los CLIs se componen. Los programadores gestionados no, por diseño.

Genera un token OAuth de larga duración con claude setup-token.

Esta es la parte que falta en cada tutorial de cron-con-Claude que he leído.

El repo de GitHub claude-code está lleno de la misma queja. Los tokens OAuth expiran en 8 a 24 horas en modo --print, el refresh falla silenciosamente, la automatización muere. El post de la comunidad DEV "Building Claudio: My Always-On Claude Code Box" camina exactamente por este dolor. V1 duró dos semanas antes de que expiraran los tokens. V2 abandonó cron completamente y pivoteó a una herramienta de escritorio.

Hay un comando incorporado que resuelve esto. Ejecútalo una vez, interactivamente, en la máquina donde originalmente te logueaste:

claude setup-token

Genera un token OAuth de larga duración (un año, scope solo de inferencia) diseñado para CI y scripts desatendidos. Lo pones en CLAUDE_CODE_OAUTH_TOKEN. El binario lo respeta, sin baile de refresh, sin re-login diario.

No pego el token en mi entorno cron. Lo almaceno en un gestor de secretos (uso Infisical, Vault y Doppler y AWS Secrets Manager hacen el mismo trabajo), y el cron lo extrae en tiempo de ejecución vía una identidad de máquina con scope a ese único servidor:

#!/usr/bin/env bash
set -euo pipefail

TOKEN=$(infisical secrets get CLAUDE_CODE_OAUTH_TOKEN --plain)
export CLAUDE_CODE_OAUTH_TOKEN="$TOKEN"
unset ANTHROPIC_API_KEY

claude -p "$(cat prompt.txt)" < input.json | jq -e . > output.json

unset CLAUDE_CODE_OAUTH_TOKEN

El token se queda en memoria por la duración de la ejecución, luego desaparece. Si el servidor se compromete, revoco la identidad de máquina y roto esa. El token OAuth de Claude mismo no tiene que moverse. Eso es lo que mantiene un stack de cron DIY corriendo sin re-logins diarios o fallas silenciosas.

Una Palabra Rápida Sobre Términos de Servicio

Anthropic aclaró la política en febrero de 2026: usar el CLI de Claude Code en tu propia máquina, daemon, cron job, todo bien. El CLI en tu propia máquina, llamando al binario oficial, está bien.

Lo que se cortó en abril de 2026 fue diferente. Herramientas de terceros suplantando el cliente Claude Code y usando auth de suscripción para potenciar productos externos tuvieron su acceso revocado. Viví eso y reconstruí mi configuración la semana después. El patrón DIY en este artículo no está del lado equivocado de esa línea. Es el binario oficial, en mi máquina, haciendo lo que el binario está diseñado para hacer.

Routines es una vista previa de investigación. La lectura actual de ToS podría cambiar, las cuotas podrían cambiar, la lista de conectores podría cambiar. Revisa los docs cada par de meses si estás construyendo algo que dependa de ello. Eso aplica a mi patrón también. Cron local con el binario oficial ha estado permitido por dos años y la posición se reafirmó hace tres meses, pero "actualmente permitido" no es "permanente."

Tres Preguntas Que Deciden Dónde Va Tu Job

Tres preguntas binarias. Respuestas honestas. La decisión sale sola.

1. ¿El job vive en un repo Git que pusheas a GitHub?
No "podría." ¿Lo hace, hoy, naturalmente? Si no: DIY.

2. ¿Necesita algo fuera de los conectores de Anthropic?
Un MCP local, una IP privada, una base de datos personal, una sesión persistente de navegador, tu propio estado de sistema de archivos entre ejecuciones. Si sí: DIY.

3. ¿Corre más de una vez por hora, o más que tu cuota diaria?
Polls sub-horarios, docenas de jobs nocturnos, cualquier cosa pasando el techo del plan. Si sí: DIY.

Tres noes: Routines, sin dudas, sin culpa. Correrá ese job mejor que tu cron DIY, y te ahorrarás el mantenimiento.

Un sí: quédate local. Usa el patrón DIY. La mitad DIY no desaparece.

En realidad, no, déjame ponerlo diferente. Routines no es Make, Zapier, o n8n (no son la misma herramienta). Routines es un programador con un perímetro. Un repo Git, los conectores de Anthropic, un mínimo de una hora entre ejecuciones. Lo que vive fuera de ese perímetro no es peor Routines 😅

Los devs que shipean conocen la diferencia. No pones un poll de quince minutos en un programador con mínimo de una hora. No pones un job que habla con tu mesh privado en una nube que no ve tu mesh privado. No pones un job con estado en un entorno de pizarra limpia. Eso no es gusto. Eso es aritmética.

Empareja la herramienta con el trabajo. Routines es excelente dentro de su perímetro. Útil, pero no la respuesta definitiva.

Fuentes