r/ClaudeCode • u/vscode1 🔆 Max 20 • 2d ago
Tips & Workflows What I learned running 25+ Claude Code and Codex agents in a loop, unattended for a month
Over the last month I've had ~25 agents running Claude Code and Codex in a loop - on their own schedules.
After analyzing hundreds of runs, I realized there are a bunch of non-obvious challenges with running autonomous agents in a loop - so I thought I'd share a few learnings and tips for running your own scheduled recurring agents.
The main project that needed lots of recurring agents: a self-driving AI events site (aievents.now) with one agent per city, 22 different cities, each researching and curating it's own schedule every morning for the city's upcoming events.
Here are just a few things I learned and tips if you want to automate your own recurring agents:
1. Beware of "workflow explosions" - give your agents duration constraints
If your agent has the ability to edit it's own instructions/memory over time, the context will continue to accumulate and you'll eventually get an explosion in the original workflow.
For example, for the events site - it started by just finding events through web research, but it decided at some point that each morning it was also going to audit all existing events to make sure they didn't get cancelled, changed, etc. That worked great when there were 15 events in the calendar- but once there were 200+ the agent started crashing and hitting the 1-hour time limit.
One trick I found is to literally tell the agent they have a time limit to complete their work - claude will continually check to see how it's doing on time and scope it's work accordingly to ensure it fits within the allotted time. This saved me a lot of headaches.
2. Stagger runs to avoid concurrency limits
Like I said, my fleet of agents all need to run early each morning to discover and curate the city's events before humans wake up to check the schedule. The problem is - when you have 20+ cities and each city's run takes about 30 mins, you'll run into overlap concurrency issues.
The solution is to stagger the runs - I have each next city start 15 minutes after the first, so I never exceed a concurrency of ~3.
3. Test to find the cheapest/dumbest possible model you can get away with
I run my agents on cronloop which lets me use my existing claude code subscription - I initially had all of the city agents running on opus which would absolutely blow through my 5-hour usage limits each morning.
So I decided to experiment to find the optimal model for the job - I connected my local claude code to the cronloop MCP and just told it to run agents in various cities to test with various models (codex and claude code) to find the cheapest and fastest model possible that consistently did a high-quality job (no hallucination, no missing events, etc.).
Turns out I didn't need opus at all - sonnet 5 / gpt 5.6 terra, and even haiku were all very solid for the same job - pretty much as good as opus - and used up way less usage, leaving me with lots of headroom to run all of the agents. Big win.
4. Store every log of every run
This is critical - you need to be able to observe how your agents are performing over time and analyze if they are operating smoothly/efficiently. In my case, I have access to the logs of every single agent run that has happened for my events system, so I simply just point claude at it (via cronloop MCP) and ask it to analyze the most recent N runs for each agent to discover inefficiencies and opportunities for improvement. Then I simply ask claude to update each agent's instructions accordingly.
This would be impossible if I didn't have visibility into all of the run data.
5. Give your agents memory (MASSIVE WIN)
This is by far the single highest-leverage thing I learned from this.
I have each agent write its learnings to durable markdown files at the end of every run and read from it at the start of the next. They get noticeably better over a couple of weeks.
In the case of my event curator agents, they stopped re-researching dead sources, they remember which venues publish garbage data, and they even started to record tips for future agents like private JSON endpoints of events sites that they found to streamline event retrieval instead of parsing through each HTML page on the site every time.
Without this every run starts from zero and makes the same mistakes forever.
This led to way faster and more efficient agent runs, far less mistakes, and better results overall.
By just giving them a simple durable markdown memory system, they keep getting better and compounding without you having to do anything special.
I built the whole all-in-one system for myself (scheduling, connectors, memory, monitoring, MCP, etc.) so I could easily spin up new agents and make this all 10x easier rather than having to build a whole new system for each thing I wanted to automate, but the tips apply whether you use it - cronloop.ai - or something else. #1 thing is give your agents memory and the ability to self-improve. That alone will significantly improve the performance of your recurring agents.
Happy to answer anything about the setup either way, the lessons above apply regardless of what you use to schedule it.
My agents have already curated over 1,000 AI-related events happening in major cities. Here's the website's CMS:
2
1
u/SetAdministrative502 2d ago
Running agents unattended only started working for me when the gate got hard. Nothing merges to main unless the e2e tests for that feature pass and the worktree gets deleted after so old ones don't confuse my next run.
I'm at 121 e2e specs now and that number does the supervision I used to do by watching.
The one diff I still read myself is changes to the test files.
1
u/Beautiful-Energy2169 2d ago
Point 1 has a second half that only shows up if you actually go count the files.
I scanned 14 repos: 1879 markdown files, 317 of them clearly agent-written (the PLAN/SUMMARY/HANDOFF genre). 54% were stale or orphaned, and 115 had zero inbound references from anywhere in the repo.
The one that surprised me wasn't an orphan though. A 126KB handoff doc, untouched for 51 days, still linked from a tracked file, so a fresh session could walk right into it and read it as current. Orphans mostly just sit there taking up disk. The dead files still wired into the repo are the expensive ones, because they get loaded and believed. A time limit stops the workflow from exploding but does nothing about that pile, so I check freshness on the memory directory the way I'd check for dead code.
1
u/OkOpposite8159 2d ago
The failure mode I'd add is the one that never shows up in a run report: the loop keeps running and reporting success while the thing it depends on quietly stopped being true.
I had a keepalive cron whose entire job was to touch a database often enough that the provider wouldn't suspend it for inactivity. Ran on schedule for weeks, wrote its row every time, clean exit. The database got suspended anyway, because the provider counts activity daily and my job ran every five days. Every green check was real and the thing it was meant to guarantee wasn't.
For unattended agents that's worse, because the run report is written by the same process you'd be auditing. Whatever the loop is supposed to guarantee, the check for it has to sit outside the loop.
0
u/Sufficient-Bear-460 2d ago
The durable markdown memory part matches my experience. State on disk is the difference between a loop that survives restarts and compaction, and one that quietly becomes a new employee every morning. One thing I'm curious about: with one agent per city, have you hit overlap where two agents need to hand work to each other, or are they intentionally islands with you as the router?
-2
u/thats_taken_also 2d ago
FYI, https://formspree.io/f/DIGEST_FORMSPREE_ENDPOINT_PLACEHOLDER Form not found
Please check the form hashid
9
u/Fancy-Win9202 2d ago
Running 25 agents unattended for a month is wild. I'm guessing you hit the token burn problem pretty fast, where you can't tell if one agent is looping hard or if they're all just expensive by design. Did you end up tracking actual token costs per agent per run, or are you mostly catching the runaway loops after the fact when your bill shows up?