Claude Routines y Opus 4.7: Mi Primer Registro de Implementación

Claude Routines y Opus 4.7: Mi Primer Registro de Implementación

Era viernes, 6:47 AM, y mi teléfono estaba boca abajo en la mesita de noche. En la cocina, algo que yo no había ejecutado, en una máquina que no era mía, estaba leyendo mis últimos 24 horas de correos electrónicos, clasificándolos en tres pilas, redactando respuestas para los cinco que lo necesitaban y dejando un resumen en Slack, en el canal #morning-brief, con los asuntos y una puntuación de urgencia de una línea para cada uno.

Cuando entré a por café, el resumen ya llevaba 31 minutos en Slack. Dos borradores de respuesta ya estaban en mi carpeta de borradores de Gmail, y solo requerían unas nueve palabras de edición cada uno antes de enviar. Un tercer borrador fue marcado por la propia rutina como "requiere tu contexto — no enviar". El portátil sobre mi escritorio llevaba cerrado desde las 11:14 PM de la noche anterior.

Esta es la primera semana en la que puedo decir esa frase —"algo se ejecutó mientras dormía en una máquina que no era mía"— sobre un flujo de trabajo que construí yo mismo, en menos de tres minutos, sin escribir una línea de sintaxis cron ni desplegar una instancia EC2. Eso es lo que logré enviar cuando Anthropic lanzó Claude Routines el 14 de abril de 2026, dos días antes de publicar Opus 4.7 el 16 de abril. Ambos lanzamientos son inseparables. Routines es el contenedor. Opus 4.7 es lo que hace que el trabajo dentro del contenedor sea realmente útil en vez de simplemente programado.

Ahora he ejecutado seis Routines en siete días. Dos las lancé a producción. Dos las reconstruí desde cero tras fallos que no estaban advertidos en la documentación. Una la eliminé por completo. Y otra está ejecutándose ahora mismo, en segundo plano, mientras escribo esta frase.

Lo que viene no es otro anuncio. Si buscas la nota de prensa, la publicación oficial de Anthropic es suficiente. Lo que viene es cómo se siente realmente construir con Claude Routines sobre Opus 4.7 en su primera semana de existencia: los patrones que funcionaron, los modos de fallo con los que me topé, el enfoque de seguridad a decidir antes de conceder acceso programado a tu bandeja de entrada, y los flujos de trabajo concretos que construiría después si tuviera otro fin de semana libre.

Déjame empezar explicando qué son realmente las Routines, porque la mitad de la cobertura que he leído esta semana sigue fallando en ese detalle.

Qué son realmente las Routines (y qué no son)

Una Routine es una configuración guardada de Claude Code — un prompt, un conjunto de repositorios, un conjunto de conectores y un desencadenante (trigger) — que se ejecuta en la propia infraestructura de Anthropic según una programación, una llamada API o un evento webhook de GitHub. Cuando se activa el trigger, Anthropic inicia una nueva sesión de Claude Code, le envía tu prompt guardado, le otorga acceso a los conectores que aprobaste, deja que se ejecute hasta completarse y, después, elimina la sesión. Tu máquina local no interviene en ningún momento. Tu portátil puede estar cerrado. Puedes estar en un avión con el modo avión activado.

Ese último punto fue el que cambió mi manera de pensar sobre estas herramientas. Todo flujo de trabajo de IA programado que construí antes — cada cron job que envolvía un script Python llamando a una API, cada GitHub Action que lanzaba Claude a través del SDK — dependía de que una máquina de mi propiedad estuviera encendida, conectada y operativa. Con Routines, por primera vez, esa dependencia desaparece para mí.

Ahora, veamos qué no son las Routines. No son un reemplazo de n8n. No buscan destronar a Zapier. No son un constructor visual de flujos de trabajo en el que arrastras cajas y conectas flechas. Son un prompt guardado, más desencadenantes, más permisos de herramientas, más un espacio donde Claude puede ejecutarse durante el tiempo que tome el trabajo. La interfaz visual es el panel de Routines en la app de escritorio. La inteligencia real es lo que Claude decida hacer cuando se activa el trigger y lee tu prompt.

Esa distinción es importante porque detrás de cada producto hay una filosofía de diseño distinta. Un flujo de Zapier falla en el mismo instante en que la respuesta de una API cambia de forma. Una Routine, en teoría, lee la nueva forma y se adapta. Si lo hace así en la práctica es justo donde entra en juego Opus 4.7.

Triggers, herramientas y los tres números que definen la función

Routines admite exactamente tres tipos de desencadenantes, y cada uno tiene matices importantes que hay que comprender antes de confiarle un flujo de trabajo.

Triggers de schedule se ejecutan con una cadencia estilo cron, con una restricción clave: el intervalo mínimo es de una hora. Puedes elegir entre cuatro preajustes en la interfaz — cada hora, diariamente, días hábiles, semanalmente — y si necesitas una cadencia personalizada como "cada dos horas" o "el primer lunes de cada mes", ajustas el preajuste más cercano y luego ejecutas /schedule update en la CLI para definir la expresión cron específica. Cualquier programación más frecuente que una hora es rechazada. Si esperabas ejecutar una Routine cada cinco minutos en modo polling, hoy no es posible hacerlo dentro de Routines.

Triggers de webhook se disparan cuando tu Routine recibe una llamada API con la clave correcta. Este es el que más suelo usar. Significa que cualquier herramienta que pueda hacer POST a una URL puede lanzar una Routine — tu CRM, tu panel de proyectos, tu formulario de contacto, tus propios scripts. Es la vía de escape universal. Si la cadencia programada no te cuadra, casi cualquier problema de programación se puede resolver haciendo que otro sistema envíe el webhook según el horario que realmente deseas.

Triggers de GitHub se disparan ante eventos webhook de GitHub — pushes, apertura de PR, comentarios, releases — sobre los repositorios que conectes mediante la Claude GitHub App. Durante el research preview, estos eventos están sujetos a límites horarios tanto por routine como por cuenta. Si haces diez pushes en cinco minutos, no necesariamente las diez activarán la Routine; algunas se omitirán hasta que se reinicie la ventana horaria. Es importante saberlo antes de montar un flujo tipo "Claude revisa cada PR" y preguntarte por qué la mitad no se revisan.

Tres números definen cuánto puedes aprovechar Routines, según tu plan. Las cuentas Pro pueden ejecutar hasta 5 Routines al día. Las cuentas Max pueden ejecutar 15. Las de Team y Enterprise pueden ejecutar 25. El exceso de uso puede facturarse si se activa la opción. Estos límites son por día, no por Routine; un usuario Pro que ejecute cinco Routines distintas una vez al día ya está en el límite. Un Pro con una Routine que se ejecute cada hora alcanzará el tope antes de las 11 de la mañana.

Este último cálculo es el error típico que comete la mayoría la primera vez que quiere escalar una Routine más allá de una demo. Si tienes Pro y buscas ejecución horaria, solo tienes 5 ejecuciones diarias; en la práctica, un trabajo verdaderamente horario no es posible en Pro sin activar la facturación por exceso de uso. Es una limitación propia del research preview, casi seguro temporal, pero de momento es la que hay.

Aquí es donde la función se vuelve interesante — y aquí es donde el modelo detrás empieza a ser más importante que la simple infraestructura.

Opus 4.7 Es La Razón Por La Que Las Routines Son Realmente Útiles

Anthropic lanzó Claude Opus 4.7 el 16 de abril de 2026, dos días después de que se abriera la vista previa de investigación de Routines. No creo que sea una coincidencia. Todos los benchmarks publicados apuntan en la misma dirección: Opus 4.7 es mejor que cualquier modelo anterior para trabajos extensos, de múltiples pasos y con gran uso de herramientas. Las Routines, por diseño, consisten precisamente en ese tipo de tareas: largas, por pasos y apoyadas en herramientas.

Los números en los que más confío, porque provienen de las propias evaluaciones de socios de ingeniería de Anthropic y no de gráficas de marketing, son los siguientes. En las evaluaciones internas de producción de Box, Opus 4.7 logró una reducción del 56% en llamadas al modelo y una reducción del 50% en llamadas a herramientas comparado con Opus 4.6, respondió un 24% más rápido en las mismas evaluaciones y empleó un 30% menos de AI Units en labores de extremo a extremo. En el benchmark de desarrollo en producción de Rakuten, Opus 4.7 resuelve aproximadamente tres veces más tareas de producción que Opus 4.6, con aumentos de dos dígitos tanto en calidad de código como en calidad de pruebas. En CursorBench, que mide flujos de trabajo reales integrados en el IDE y no la resolución sintética de problemas, Opus 4.7 salta de 58% (la puntuación de Opus 4.6) a 70% — una mejora de 12 puntos en el benchmark que más se parece al trabajo cotidiano de los desarrolladores.

Sin embargo, el benchmark más relevante para flujos de trabajo agenticos es SWE-bench Verified. Opus 4.6 obtuvo 80.8%. Opus 4.7 alcanza 87.6%. Esto representa una mejora de casi siete puntos en una tabla de líderes donde cada punto extra arriba del gráfico cuesta mucho, y coloca a Opus 4.7 por encima de Gemini 3.1 Pro (80.6%) y, de manera notable, por encima de GPT-5.4 en el mismo conjunto de tareas.

Hay un aspecto más que merece ser destacado, ya que es la señal más importante que debes conocer antes de configurar una Routine: Opus 4.7 viene con un nuevo nivel de esfuerzo llamado xhigh. No es “extra high”, ni “extended”, ni “high-plus”— el nombre literal del flag en la API y la CLI es xhigh. Es el valor por defecto recomendado para Opus 4.7 en razonamiento complejo y trabajo agentico, y está activado por defecto dentro de Claude Code para este modelo. Lo que xhigh hace, en resumen, es asignar más tokens al razonamiento interno y al bucle de exploración de herramientas del modelo antes de devolver una respuesta. Para un chat puntual, es excesivo. Para una Routine que debe capturar correos, categorizarlos, redactar respuestas y enviar un resumen a Slack sin tu supervisión directa, es exactamente el nivel que quieres.

Un matiz que los blogs no suelen destacar: xhigh es costoso. Sumado a un nuevo tokenizador en Opus 4.7 que contabiliza aproximadamente entre 1,0 y 1,35 veces más tokens que 4.6 para el mismo texto, y a la inflación natural de output que trae consigo un razonamiento interno más profundo, tus facturas de API pueden subir entre un 20% y un 50% por tarea equivalente respecto a la época de 4.6. El trabajo es mejor. El trabajo es más caro por ejecución. Ambas cosas son ciertas. Si vas a ejecutar Routines vía API en vez de dentro del uso incluido de Claude Code, haz cuentas con un trabajo de prueba de bajo riesgo antes de automatizar una Routine que se ejecute 25 veces al día.

Ahora que la funcionalidad y el modelo están claros, déjame contarte lo que realmente construí.

La rutina que implementé: Triaje matutino de correos electrónicos que realmente funciona

Construí la rutina de triaje de correo electrónico primero por la misma razón que lo hará cualquier otro usuario: la demo que Anthropic presentó en el lanzamiento era una rutina de triaje de correo, y la naturaleza del problema —entradas predecibles, salidas acotadas, fácil validación— la convierte en el primer proyecto más limpio para estrenar la funcionalidad. Lo que no esperaba era cuánto dependería la calidad del resultado de escribir el prompt como si estuviera delegando la tarea a un contratista desconocido.

Este es el prompt con el que me quedé después de tres iteraciones. Es largo, y esa es precisamente la idea.

Estás ejecutando un trabajo desatendido de triaje de correo electrónico a las 6:45 AM hora local.
No puedo responder preguntas mientras lo ejecutas. Toma la mejor decisión
posible en cada punto. En caso de duda, redacta pero no envíes.

PASO 1 — OBTENER
Extrae todos los mensajes no leídos de mi bandeja de entrada de Gmail recibidos en las últimas
24 horas. Excluye todo lo que esté en Promociones, Social o Actualizaciones.

PASO 2 — CATEGORIZAR
Clasifica cada mensaje en exactamente uno de estos tres grupos:
  - URGENTE — una persona concreta está bloqueada esperando mi respuesta, o hay
    un plazo en menos de 48 horas, o hay dinero/contratos involucrados
  - REQUIERE_RESPUESTA — se espera respuesta pero nada está bloqueado ni hay
    urgencia real
  - SIN_ACCIÓN — newsletters, recibos, información, no se espera respuesta

PASO 3 — REDACTAR
Para cada mensaje URGENTE y REQUIERE_RESPUESTA, redacta una respuesta y guárdala
en mi carpeta de borradores de Gmail. No la envíes. Imita mi estilo a partir de las
últimas diez respuestas en mi carpeta Enviados (frases cortas, nada de "Espero que estés bien," firma con "— M"). Si no puedes redactar con confianza por falta de contexto,
redacta una respuesta que indique exactamente qué información necesitas y marca el borrador con [NEEDS_CONTEXT] en el asunto.

PASO 4 — RESUMIR
Publica un mensaje en Slack en #morning-brief con este formato:
  URGENTE (N): una línea remitente + una línea asunto + tu veredicto de borrador
  REQUIERE_RESPUESTA (N): mismo formato
  SIN_ACCIÓN (N): solo el número total, sin detalles

PASO 5 — GESTIÓN DE ERRORES
Si algún paso falla, publica en Slack #morning-brief con @here y el
error. Un fallo silencioso es el peor resultado posible. Prefiero
un mensaje de error visible que no recibir nada.

PASO 6 — RECUPERACIÓN DE CONTEXTO DE EJECUCIONES ANTERIORES
Antes de iniciar el Paso 1, lee el mensaje fijado en #morning-brief
de la ejecución de ayer. Si algún elemento URGENTE de ayer sigue
sin resolverse en mi carpeta Enviados, destácalo en el resumen de hoy como
CARRIED_OVER.

Seis pasos numerados. Manejo explícito de errores. Instrucciones claras sobre cómo recuperar contexto de la ejecución anterior. No se presupone que Claude deducirá nada por sí mismo.

Ese último paso —recuperar contexto de ejecuciones anteriores— fue el que me obligó a reconstruir la rutina dos veces. Las rutinas no tienen memoria entre ejecuciones por defecto. Cada ejecución inicia con una sesión nueva. Si quieres que la rutina de ayer informe la de hoy, tienes que decirle a Claude exactamente dónde buscar: un canal de Slack, un Google Doc, un gist en GitHub, una página de Notion, cualquier lugar donde pueda leer y escribir a través de un conector. Si omites este paso, la rutina volverá a redactar la respuesta al mismo correo tres días seguidos, porque para ella, cada mañana es la primera.

La instrucción sobre gestión de errores fue la otra lección que me costó una reconstrucción. Mi primera rutina falló ante un solo mensaje MIME malformado y terminó sin avisar. No supe que había fallado hasta que noté que no recibí el resumen de Slack a las 7 AM. Cuando la reconstruí con el callback de error con @here, ya había perdido dos mensajes urgentes porque interpreté la mañana silenciosa como que no había nada pendiente por responder. Un fallo silencioso es el peor desenlace en cualquier flujo desatendido. Escribe la gestión de errores antes que la ruta feliz.

Resultados de la primera semana

Así lucieron los datos en la práctica durante siete días con esta rutina. Te doy lo que observé, no un caso seleccionado a medida.

Mensajes procesados: 294 correos no leídos en 7 días (aproximadamente 42 por día). Precisión de categorización, comprobada por mí a las 9 AM cada mañana: Coincidí con la clasificación de Claude el 91% de las veces. El 9% de desacuerdos casi siempre fue por una sobreclasificación como "URGENTE", generalmente porque el tono del remitente parecía urgente aunque el contenido real solo era una actualización de estado. Calidad de los borradores: 6 de cada 10 borradores los envié tras editar menos de 15 palabras. 2 de 10 los reescribí de forma sustancial. 1 de 10 lo descarté y redacté desde cero. 1 de 10 fue correctamente marcado como [NEEDS_CONTEXT] y lo respondí yo mismo. Fallos silenciosos: Ninguno después de añadir el callback. Uno (el fallo MIME) antes de eso. Tiempo ahorrado, estimado: Antes, el triaje diario me tomaba entre 25 y 35 minutos cada mañana. Con la rutina, la revisión y envío demora alrededor de 7 a 10 minutos. Es decir, recuperé unas tres horas a la semana.

Una advertencia que vale la pena subrayar: la rutina funciona tan bien solo porque el prompt es así de detallado. Probé una versión corta —"Haz triaje de mi correo, redacta respuestas, publica un resumen en Slack"— y funcionó aproximadamente un 60% tan bien. Prompts vagos generan rutinas vagas. Trata el prompt como un documento de especificaciones, no como un mensaje de chat.

La decisión entre Modo Confiable y Modo Completo que no puedes omitir

Antes de que cualquier Routine pueda acceder a tus herramientas, debes elegir uno de dos modos: confiable o completo. Esta es, sin duda, la decisión de seguridad más trascendental de toda la configuración, y merece mucha más atención de la que le dedican los dos párrafos de la documentación.

En modo confiable, la Routine solo puede usar las herramientas que tú mismo hayas aprobado explícitamente — Gmail, Slack, Google Drive, o cualquier otra que hayas activado individualmente. Si el prompt le pide a Claude hacer algo que requiere una herramienta no autorizada, la Routine simplemente rechazará el paso o fallará. Este es el modo predeterminado. También es el punto de partida adecuado para cualquier workflow que construyas.

En modo completo, la Routine puede utilizar cualquier herramienta que tenga un conector configurado para tu cuenta. Si a mitad de la ejecución decide que necesita buscar en la web, escribir un archivo o consultar una nueva API, puede hacerlo sin tu intervención. El modo completo es la llave para desbloquear los niveles más ambiciosos de autonomía. Pero también es como puedes, por accidente, otorgarle a un agente de IA desatendido la autoridad para enviar un correo a toda tu lista de clientes, simplemente porque el prompt era ambiguo y el modelo interpretó “reach out” de manera más amplia de lo que imaginabas.

Mi regla tras una semana: construye todas las Routines primero en modo confiable, ejecútalas al menos tres veces, audita las llamadas a herramientas, y solo cambia a modo completo si puedes identificar una capacidad específica que el modo confiable no pueda cubrir. Todas las Routines que tengo en producción hoy funcionan en modo confiable. La única Routine que probé en modo completo la eliminé, porque hizo exactamente eso que te hace no querer volver a correr un agente sin supervisión: decidió que la mejor forma de “dar seguimiento a leads inactivos” era mandar un correo a diecisiete personas con las que no hablaba desde hacía dos años.

No existe una solución técnica adecuada para la ambigüedad del prompt en modo completo. La única solución real es escribir prompts más precisos y ejecutar en modo confiable.

Si ya has construido agentes en producción con el Agent SDK, casi todo esto te resultará familiar — aquí aplica la misma disciplina de delimitar capacidades, solo que con menos código y una interfaz ligeramente diferente. Para un análisis más profundo de estos límites, consulta mi guía sobre el Anthropic Agent SDK.

Qué se rompió y qué tuve que reconstruir

No todo lo que intenté funcionó. Las dos Rutinas que fallaron de manera más rotunda son más útiles de analizar que las que salieron bien, porque los modos de fallo casi con total seguridad serán los mismos a los que se enfrentará cualquier otra persona en su primera semana.

Fallo 1: La Rutina de revisión de PR que se activaba demasiado frecuentemente. Configuré un trigger de GitHub en un repositorio Laravel de tamaño medio: cada vez que se abre un PR, cada push a un PR abierto, ejecutar una revisión de código y dejarla como comentario en el PR. Un martes ajetreado, realicé 11 commits a un solo PR en unos 90 minutos. La Rutina se disparó seis veces y luego se detuvo en silencio. Yo pensé que se había roto. Lo que realmente ocurrió fue que alcancé el límite horario por rutina para eventos de webhook de GitHub durante la vista previa de investigación, y los cinco eventos restantes simplemente se descartaron. Esto se menciona brevemente en la documentación; pasé por alto esa línea la primera vez que la leí. Mi solución: aplicar debouncing al trigger, para que solo se active con “abrir PR” y “PR listo para revisión” en vez de con cada push, lo que redujo la frecuencia de activación de seis por PR a una por PR y eliminó por completo la caída de eventos.

Fallo 2: La Rutina de reporte semanal que tomaba la ventana equivocada. Creé una Rutina para que se ejecutara cada lunes a las 8 AM, extrajera mis ingresos de Stripe y Fiverr de la semana anterior, resumiera la tendencia y la publicara en un canal privado de Slack. La primera vez devolvió un número aproximadamente 40% inferior al real. El modelo interpretó “la semana pasada” como “los últimos siete días desde ahora” en lugar de “la semana efectiva anterior de lunes a domingo del calendario”. Como cada ejecución de Rutina empieza desde cero sin memoria de qué significa “la semana pasada”, no tenía ningún punto de referencia claro. La solución fue ser explícito: “Extrae los datos de la semana del calendario comenzando el lunes [cálculo de fecha en ISO-8601] y terminando el domingo [cálculo de fecha en ISO-8601]. No de los últimos siete días. De la semana anterior del calendario”. A partir de ahí, los números coincidieron exactamente con mi dashboard de Stripe.

Ambos fracasos comparten un patrón. Ambos fueron fallos por asumir un contexto. En los dos casos, escribí un prompt que habría funcionado sin problemas para un colega humano que conoce mi manera de trabajar, pero habría resultado ambiguo para un colaborador completamente nuevo en su primer día. Las Rutinas siempre están en su primer día, cada vez que se ejecutan. Escribe prompts como si fueran para un colaborador nuevo y la mayoría de estos fallos desaparecerán antes de que ocurran.

Si ya diseñas workflows agénticos de larga duración y quieres un marco más profundo para la redacción de este tipo de prompts, el que utilicé esta semana es el que documenté en mi análisis práctico de Opus 4.6; los principios se trasladan perfectamente a 4.7, con el añadido de que 4.7 tolera más ambigüedad antes de desviarse. “Tolera más” no es “elimina”. Los prompts bien ceñidos siguen marcando la diferencia.

Donde las Rutinas Aún Se Quedan Cortas

Esta es la sección que la mayoría de las coberturas durante la semana de lanzamiento van a omitir, así que voy a dedicarle tiempo. Hay cuatro limitaciones reales que encontré en la primera semana y que vale la pena nombrar claramente, porque deberían influir en lo que construyas y en lo que decidas no hacer.

1. Sin memoria cruzada entre ejecuciones por defecto. Ya hablé de esto más arriba, pero merece repetirse. Cada ejecución de una Rutina es una sesión completamente nueva de Claude Code, sin memoria de su propio historial. La solución es la recuperación explícita de contexto: señalarle a Claude un canal de Slack, un documento de Google, una fila de base de datos, cualquier lugar donde pueda leer el resultado de ayer antes de comenzar el trabajo de hoy. Es solucionable, pero es manual, y olvidar hacerlo es cómo acabas con tres días seguidos de respuestas duplicadas.

2. Cadencia mínima de una hora. Si el trabajo real necesita ejecutarse cada cinco minutos —tareas de polling de estado, monitores de señales en vivo, cualquier operación en tiempos de trading—, las Rutinas no pueden hacerlo desde el disparador por horario. El atajo es usar un disparador webhook accionado por un programador externo, pero entonces vuelves a gestionar infraestructura en otro sitio, lo que contradice parcialmente la propuesta. Para una cadencia realmente inferior a una hora, las Rutinas aún no son la herramienta adecuada.

3. La postura de seguridad del modo completo no es madura. El modo completo es poderoso y peligroso en partes iguales. No existe un modo sandbox que simule una ejecución de modo completo antes de que toque herramientas de producción. No hay un límite de coste por herramienta que evite que un flujo de trabajo descontrolado consuma todos los tokens en un bucle erróneo. No puedes configurar un rate-limiter específico por conector. La única salvaguarda real es la calidad de tu prompt y empezar en modo de confianza. Los equipos profesionales que ejecuten Rutinas en modo completo con datos reales de clientes deberían esperar construir sus propias barreras alrededor de la Rutina —patrones de cola de aprobación, registros de auditoría por canal paralelo, interruptores automáticos ante gastos excesivos.

4. Vista previa de investigación significa que la API puede cambiar. Todo lo que he escrito en este post es cierto a 21 de abril de 2026. Anthropic ha advertido explícitamente que las formas de las peticiones y respuestas, los límites de velocidad y la semántica de los tokens pueden cambiar mientras las Rutinas estén en vista previa de investigación. Si construyes infraestructura crítica sobre Rutinas este mes, reserva tiempo para reescribir parte de ello en los próximos seis meses. Esto no es un defecto —es la consecuencia honesta de lanzar sobre una vista previa de investigación—, pero conviene mencionarlo porque he visto equipos tratar una vista previa de investigación como una API estable y perder varios días por un cambio en el formato que no notaron.

Ninguna de estas limitaciones es un factor excluyente. Todas son cosas que debes saber antes de comprometer un flujo de trabajo a Rutinas y prometer a alguien más que seguirá funcionando.

Si ya ejecutas automatizaciones programadas en la app de escritorio de Claude Code en vez de en Rutinas, puede que te sirva la comparación que hice entre ambos en la guía de tareas programadas de Claude CoWork —en superficie parecen similares, pero el modelo de ejecución es fundamentalmente distinto, y la elección importa dependiendo de si depende de que tu portátil esté encendido o no.

Las cinco rutinas que construiría a continuación

Si tuviera de vuelta el fin de semana y quisiera sacar el mayor provecho de Routines antes de que entre en vigor el límite, aquí está la lista, ordenada por retorno de inversión por minuto de configuración.

1. Clasificación matutina de emails + borradores. La que ya construí. Si no haces nada más, construye esta. El tiempo ahorrado es inmediato y los modos de fallo están acotados.

2. Reporte semanal de negocio. Stripe, Fiverr, cualquiera que sea tu fuente de ingresos, recopilada cada lunes por la mañana, resumida como una tendencia y publicada en un canal privado de Slack. El beneficio compuesto es que dejas de pensar “debería mirar los números” porque los números vienen a ti. Para operadores independientes esto es, posiblemente, más valioso que la clasificación de emails.

3. Clasificación automática de leads entrantes con borradores de primera respuesta personalizados. Trigger de webhook desde el formulario de contacto de tu sitio web. Claude toma el mensaje, investiga la empresa del remitente a través de su dominio en unos cuarenta segundos, redacta una respuesta que menciona algo real sobre su negocio, guarda el borrador y te avisa en Slack. Tú revisas y envías. Los tiempos de respuesta bajan de horas a minutos sin sacrificar el toque humano que cierra el lead.

4. Resumen diario del changelog para un repositorio público. Disparador de GitHub en cada merge a la rama principal. Claude toma el diff, escribe una entrada de changelog orientada al usuario en tu estilo, la agrega a CHANGELOG.md, y abre un PR. Tú revisas semanalmente. Horas de trabajo en documentación al mes, reducidas a minutos de revisión.

5. Informe de investigación para las reuniones de mañana. Trigger programado cada día a las 20:00. Claude lee tu calendario del día siguiente, extrae los titulares de LinkedIn de los asistentes, escritos públicos recientes y el último hilo de emails con cada uno, produce un briefing de una página por reunión y los coloca en un Google Doc. Llega a cada reunión del día siguiente con contexto que no tuviste que recopilar durante 30 minutos.

Ninguna de estas son ideas novedosas. Todas han sido técnicamente viables durante años usando cron más un modelo de lenguaje más un API wrapper. La razón por la que no había construido ninguna es que cada una requería una infraestructura que no quería mantener: un servidor para correr el cron, un wrapper para invocar el modelo, una cola para manejar fallos, un monitor para avisarme cuando la cola se rompía. Routines reduce toda esa pila a una configuración guardada que corre en la infraestructura de otro. El impedimento para lanzar no era la idea. El impedimento era el “yak-shave”.

Eso es lo realmente nuevo aquí. No la automatización. La ausencia del “yak-shave”. Para una lectura más a fondo sobre cómo luce el panorama de modelos en abril de 2026 en torno a este lanzamiento, mi resumen de modelos de IA de abril de 2026 tiene la imagen completa sobre Kimi K2.6, los rumores sobre GPT-5.5 Spud y cómo Opus 4.7 realmente se posiciona frente al resto en cargas de trabajo reales.

Preguntas Frecuentes

¿Qué son las Claude Routines y cómo funcionan?

Las Claude Routines son configuraciones guardadas de Claude Code —un prompt, repositorios, conectores y un disparador— que se ejecutan en la infraestructura en la nube de Anthropic cuando se activa una programación, una llamada API o un evento de GitHub. No es necesario que tu máquina local esté en línea. Cada ejecución inicia una sesión nueva de Claude Code sin memoria de ejecuciones previas, a menos que le indiques explícitamente al prompt dónde recuperar contexto anterior. Para la guía completa de configuración, consulta la sección de Triage matutino de correos arriba.

¿Cuál es el intervalo mínimo de programación para una Claude Routine?

Una hora. Los disparadores programados admiten cuatro preajustes —cada hora, diario, días laborables, semanal— y rechazan cualquier expresión cron que se ejecute con más frecuencia que una vez por hora. Para una cadencia menor a una hora, emplea un disparador webhook activado por un programador externo, aunque esto reintroduce el problema de infraestructura externa que las Routines buscan eliminar.

¿Es Opus 4.7 mejor que Opus 4.6 para trabajo agente?

Sí, de manera significativa. En evaluaciones de socios de Anthropic, Opus 4.7 realizó un 56% menos llamadas al modelo y un 50% menos llamadas a herramientas que Opus 4.6 para tareas equivalentes, resolvió aproximadamente tres veces más tareas de producción en el benchmark de codificación de Rakuten, y subió del 58% al 70% en CursorBench. El nuevo nivel de esfuerzo xhigh es el valor predeterminado en 4.7 dentro de Claude Code y es el nivel recomendado para tareas no supervisadas de varios pasos.

¿Qué es xhigh en Claude Opus 4.7?

xhigh es el nuevo nivel de esfuerzo de gama alta en Opus 4.7 —es el nombre de la bandera literal que se usa en la API y la CLI. Asigna más tokens a los bucles de razonamiento interno y de exploración de herramientas antes de que el modelo entregue resultados. Es el esfuerzo predeterminado para Opus 4.7 en Claude Code y se recomienda para razonamientos complejos y trabajo agente. Su costo por tarea es mayor debido a la profundidad del bucle de razonamiento y a un nuevo tokenizador, así que espera entre un 20% y un 50% de incremento en los costos por tarea respecto a 4.6.

¿Cuántas Routines puedo ejecutar por día en el plan Pro?

Cinco ejecuciones de Routines por día en Claude Pro. Los usuarios de Claude Max obtienen 15 diarias. Los usuarios de Team y Enterprise tienen 25 al día. Es posible habilitar facturación por exceso si necesitas más, pero los límites son totales por cuenta y aplican a todas tus Routines, no por Routine individual —por lo cual un usuario Pro con cinco Routines diarias ya está en el tope.

¿Debo usar el modo trusted o el modo full tool para una nueva Routine?

Siempre el modo trusted para una nueva Routine. El modo trusted limita a Claude a solo las herramientas que has aprobado individualmente para esa Routine. El modo full permite a Claude acceder a cualquier conector de tu cuenta durante la ejecución, lo cual es útil para los flujos más ambiciosos pero es también como los agentes sin supervisión terminan haciendo cosas que no pretendías. Comienza en modo trusted, ejecútalo tres veces de forma limpia, audita las llamadas a herramientas y promueve a modo full solo si puedes nombrar una capacidad específica a la que el modo trusted no pueda acceder.

Trabajemos Juntos

¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudarte.

• Fiverr (builds e integraciones personalizadas): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluciones empresariales): ramlit.com
• ColorPark (diseño y branding): colorpark.io
• xCyberSecurity (servicios de seguridad): xcybersecurity.io