/loop: Turn Your AI Sessions into Self-Monitoring Workstations
Claude Code's /loop command runs prompts on recurring intervals. Here's how to use it for cost awareness, CI monitoring, and deploy watching.
If you run Claude Code sessions that stretch past an hour --- and data suggests 69% of power user sessions do --- you’ve probably lost track of what’s happening in the background. A CI pipeline failed 40 minutes ago. Your deploy is stuck. Your session cost just crossed $50.
Since v2.1.71, Claude Code has a command for exactly this problem: /loop.
What /loop Does
/loop runs a prompt on a recurring interval within your active session. It’s like cron for your AI session --- fire-and-forget background monitoring that runs alongside your main work.
/loop <interval> <prompt>
/loop 5m check deploy status
/loop "0 */2 * * *" run security scan
Intervals can be simple (5m, 30m, 1h) or full 5-field cron expressions in quotes. Tasks are session-scoped --- they stop when you /exit --- and expire after 3 days.
4 Use Cases Worth Setting Up
1. Cost Awareness (Session Hygiene)
The highest-impact use case. If your average session costs $33 and you want to bring it under $15, you need visibility:
/loop 30m report current session cost from the statusline data
Every 30 minutes, Claude reports your running total. When you see “$47 and climbing,” you know it’s time to wrap up and start fresh. This directly addresses the runaway session problem --- the #1 cost driver for power users.
2. CI Pipeline Monitoring
You pushed a commit and went back to coding. Did the build pass?
/loop 5m check if any forgejo actions failed for the current repo
Instead of context-switching to check your CI dashboard, the loop checks for you and only surfaces failures. For GitHub Actions users, swap in gh run list --limit 3.
3. Kubernetes Deploy Watching
Deploying to production and need to know when pods stabilize:
/loop 2m kubectl get pods -n production | grep -v Running
This shows only non-running pods. Once everything is Running, the output is empty --- a clean signal that the deploy succeeded. Set a tighter interval (1-2m) for deploys, wider (10-15m) for general health.
4. Service Health Checks
Running a homelab or monitoring internal services:
/loop 10m curl -s http://dashboard:8090/api/health | jq .status
Catch outages while coding instead of finding out hours later. Useful for services that don’t have external monitoring set up yet.
How It Interacts with Your Session
The loop runs in your session’s context, so it has access to your files, Git state, MCP servers, and environment. This is powerful but has implications:
- Token cost per iteration: Each loop execution consumes tokens. Simple curl checks are cheap (a few hundred tokens). Complex analysis prompts add up over many iterations.
- Context sharing: Loop results appear in your conversation, so they add to context usage. For long sessions, this compounds the context problem.
- Focus interruption: If you’re deep in thought, a loop result appearing can break flow. Use longer intervals for non-urgent checks.
When NOT to Use /loop
- Short sessions (<30 min): Not enough time for recurring checks to provide value.
- Simple, focused tasks: If you’re making a single edit and exiting, a loop adds overhead.
- When you need deep focus: A 5-minute loop on a complex prompt will interrupt your thinking regularly. Either use a longer interval or skip it.
The Sweet Spot
The ideal setup for most sessions:
/loop 30m report session cost
One loop, long interval, minimal distraction. It solves the biggest efficiency problem (runaway sessions) without creating new ones (focus interruption, token waste).
Add more loops only when you have a specific operational need --- a deploy to watch, a pipeline to monitor, a service to check. Don’t monitor for the sake of monitoring.
/loop was introduced in Claude Code v2.1.71. It supports simple intervals and full cron expressions. Tasks are session-scoped and expire after 3 days.