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 
