An agent takes twelve minutes to finish a task. The tool report shows twenty minutes of activity. One test command took three minutes, although the same command normally finishes in seconds.
Before changing the model or the test runner, check what the timer includes.
A duration needs a start, an end and a scope. Without those, “slowest tool” is an ambiguous label.
Separate elapsed time from accumulated tool time
Consider two calls that start together and each finish after thirty seconds.
The calls contribute sixty seconds to an accumulated duration. Only thirty seconds passed on the clock. If a parent tool waits for a child operation and both are recorded, summing their durations can count overlapping work again.
That total can help identify where activity concentrates. It does not tell you how much sooner the task would finish if you optimized one row.
For a single task, keep its start and finish alongside individual call intervals. Inspect which operations actually delayed completion.
Check the boundaries before blaming a command
These are different measurements:
| Measurement | Possible boundaries |
|---|---|
| Approval wait | Request displayed to permission granted |
| Command runtime | Process started to process exited |
| Agent-observed tool duration | Tool requested to result received |
| Task elapsed time | Task started to accepted result |
A tool duration may contain approval time, queueing, execution and result delivery. The boundaries depend on the recorder.
For an independent command measurement, use a monotonic elapsed-time clock around the process. Python's performance counter documentation explains that the counter includes elapsed sleep time; it is not a CPU-usage measurement. Record the working directory and relevant conditions privately so a second run is comparable.
Do not turn off permission checks to make a chart look better. First establish whether waiting accounts for the apparent slowdown.
Compare frequency, typical duration and outliers
Imagine this small report. These are invented numbers for illustration, not a benchmark:
| Operation | Calls | Median duration | Longest |
|---|---|---|---|
| Read | 300 | 0.04 s | 0.9 s |
| Test suite | 20 | 12 s | 180 s |
| Build | 4 | 45 s | 48 s |
The most frequent operation is not necessarily your largest delay. The long test run deserves a closer look, but the table alone cannot tell you whether it waited for permission, ran a larger test selection or encountered a slow dependency.
Group comparable commands together. A focused unit test and an integration suite can share an executable while doing very different work.
Investigate retries before removing them
Three searches for the same filename may indicate an unhelpful loop. They may also occur before an edit, after an edit and during verification.
Read the sequence around the repeated call. Ask what changed between attempts, what each result established, and whether the agent used that result.
Likewise, a failed test can be useful evidence. An intentionally failing regression test followed by a fix should not be treated like an authentication error retried without a change.
Record the denominator when discussing failures: two failures out of three calls deserve different scrutiny from two failures out of three thousand.
What a local activity report can establish
I build ccdeck. Its Tool activity guide describes counts, accumulated durations, median durations and failures for recorded Claude Code and Codex calls on one device.
Its documented timing includes approval waits. Concurrent calls each contribute to the total, and the two CLIs use different timing boundaries. Command chains can also contribute multiple rows sharing the same interval.
That makes the report a place to find a candidate for investigation, not a direct ranking of model speed. The stored aggregate history omits raw arguments and output, so diagnosing a particular call may require separate session evidence. Capture starts when recording begins; it does not reconstruct older sessions.
Change one cause and rerun the task
Choose a concrete intervention: correct a broken command, narrow an unnecessarily broad test run, or remove a retry that receives the same error without changing its input.
Repeat a comparable task and check both elapsed time and correctness. Fewer calls are useful only if the required work still happens.
Keep the original trace and your explanation of the change. That is more useful than a faster-looking chart whose measurement boundaries remain unknown.
Top comments (0)