I analysed 43 hours of my agents’ run history. The model took only 16% of it. The rest was tests, builds, deploys, polling and waiting for me.
I’ve been programming for more than 15 years, and I still pile up debt that I have to clean up later. Working with AI agents didn’t change that. It just made the debt harder to see.
Where did the time go?
For a few weeks my tasks kept taking longer and my estimates kept growing. I blamed the model. The real answer was simpler: on bigger tasks I had lost track of where the time went. All I saw was the final message.
So I measured it
Claude Code already keeps a timestamped transcript of every session on your machine. I built a skill, analyse-bottleneck, that reads them and sorts every second of agent time into one cause: tests, builds, deploys, polling, scripts, the model itself, or waiting for me. The counting is plain Python with no AI in it. Then it suggests fixes and shows how it got to each estimate.
The real report for Project 1. In the report, you pick a slice to see what ran and what to change.
43 hours of agent runs
I ran it on the history of my agent runs: 43 hours of sessions on projects for two clients, Project 1 and Project 2. It looks only at what the agents did in those hours, not at the projects as a whole.
- 43 h of agent run history analysed
- 16% went to the model thinking and writing
- ≈5 h a week saved by the fixes found
The model was the small part
Of the 36.5 hours of runs in Project 1, the model spent 5.3 thinking and writing. Tests, shell scripts, polling and deploys took 26.4. My own debt, in other words.
Tests ran too broad
While fixing something in Project 1, agents re-ran broad test suites: 87 runs and 3 hours in total. Running only related tests while iterating should save about 1.8 hours a week. Applying 51 migrations also took 6 to 9 seconds of every 16-second run, and caching the migrated database saves about another hour.
Deploys built things nobody used
Every deploy built a Docker stage the final image never used: 5.4 of a median 15.9 minutes. The fix is one line, DOCKER_BUILDKIT=1.
A loop waited for itself
One wait loop ran for 47 minutes because pgrep -f also matched the loop’s own shell. In Project 2, agents checked status 134 times for 12 deploys, and every check re-read the context: 16.6 million tokens spent on waiting. One blocking command that returns when the deploy ends fixes both.
And I was a bottleneck too
28 times an agent finished and sat waiting for my next message, a median of 5 minutes each. That one is on me. A phone notification when an agent stops (a Stop hook) and a short list in CLAUDE.md of decisions it may take alone should help.
What I gained
Project 2 has its fixes live. A background worker’s image build went from 20 to 24 minutes to under a minute, and a test run while fixing from 19 minutes to 35 seconds. Project 1’s fixes are going live now. I’ll run the same report again in a week and share the before and after.
AI is often not the bottleneck
A faster model wouldn’t have fixed any of this. The time went to the ordinary engineering around the agent, the same things that slow down human teams. Agents just hit them hundreds of times a week. If yours feel slow, measure before you buy a bigger plan or switch models.
I built analyse-bottleneck for myself and I am now looking for feedback from people with their own long Claude Code runs. Does the breakdown match what you see? Which causes or stack rules are missing? The repo is https://github.com/jindraregal/analyse-bottleneck (MIT). Comments here or GitHub issues both work.
claude plugin marketplace add jindraregal/analyse-bottleneck
claude plugin install analyse-bottleneck@jindraregal
Top comments (7)
The 16% model-time figure is a useful reminder that agent performance is often an infrastructure and workflow problem disguised as an LLM problem.
One thing I'd add is tracking the cost of repeated context loading alongside execution time. Polling, rerunning tests, and rebuilding environments are visible delays, but repeatedly sending the same logs, status output, or unchanged context can quietly inflate token usage too.
I'd also separate intentional verification from redundant work. Narrow test selection is useful during iteration, but the final validation should still cover the broader system before a change is promoted. Otherwise, optimizing the feedback loop can create a different reliability problem.
The most useful metric isn't simply how fast an agent finishes a task. It's how much time and compute it takes to produce a verified, deployable result.
Thanks, good points. The report already has a quota section for part of this (cache rebuilds, oversized tool outputs, repeated reads, sleep polling), and I agree the broad check should still run before a change ships.
The
pgrep -floop matching its own shell and 134 deploy polls burning 16.6M tokens trace back to the same pattern. Launching background work without an explicit PID file or blocking wait handle forces the agent to guess state across turns. Writing the child PID to a job file before polling stops self-matches, and swapping status checks for one blocking command with a hard wall-clock timeout cuts out the repeated context rebuilds.Yep, that's exactly what bit me:
pgrep -fmatched the loop's own shell. The skill already says to swap polling for one blocking wait, but it doesn't flagpgrep -floops specifically yet, so I'll add a rule that suggests a PID file instead.Measuring before buying a bigger plan is the right order. Your last two findings look like one problem from two sides: agents polling for a deploy, and an agent that finished waiting for you. Our rule is to wait for a completion message instead of spending model turns checking status: a plugin wakes each agent's session on an event addressed to it (a mention, a DM, an assigned card) in an agent-chat room, and a manager agent hands out the next task in the same reply where a worker reports done. Of those 28 waits, were most for a decision only you could make, or just for the next task?
the polling loop matching itself for 47 minutes is such a classic lol. does the tool hook into claude code or just read the session logs after?
Ha, yes, that one hurt to find. It only reads the logs afterwards: Claude Code already saves every session in ~/.claude/projects and the skill parses those locally, no hooks needed. There's an optional Stop hook if you want it to run after each session, but it's off unless you add it yourself.