Your agent's clock is not the model's clock

A model finishes its reply. The tests keep running.

You can buy a faster reply and still wait for a change you can use.

The automation workflows I have shared publicly follow a longer chain: a prompt, shell steps, tests, then a pull request. The model sits inside that chain. Its reply can start work that has not finished when the call ends.

So when someone says "the agent took ten minutes," I want to know which part took ten minutes. The answer tells me whether to look at inference, tests, setup or something the trace has not captured.

I went back to the public GitHub Copilot trace behind my five-minute cache analysis. This time I read its schema and the authors' loader, not the corpus. This post reports no new timing analysis. The examples below are invented to explain what those records would let us measure.

Two tools do not mean two waits

Take an invented run with serial stages and two parallel tools.

The first model call takes ten seconds. Then two tools start together. Each runs for twenty seconds. Another ten seconds pass that we cannot account for. The second model call takes twenty seconds.

The observed window is sixty seconds. Add the individual tools, though, and you get forty seconds of tool work where the run waited only twenty.

The tool total is not wrong. It answers a different question. For elapsed time, both tools occupy the same stretch of the clock. Count that stretch once.

The model calls occupy thirty seconds. Suppose both became twice as fast, while tool time, the unknown interval, call count and output quality stayed fixed. The run would take forty-five seconds, not thirty. That is the lower panel's arithmetic, not an optimization result.

With overlapping branches, a faster call may not even move the finish. It could sit on a branch that already ends before the slowest one.

That is why I would measure elapsed shares by merging overlapping intervals within each class. If model and tool intervals overlap too, keep four parts visible: model-only, tool-only, both, and neither. Otherwise their totals can exceed the window.

Cumulative work and time to finish are different measurements.

What the clock actually measures

The public release covers sampled Copilot agentic sessions from non-enterprise users over June 1 to 7, 2026. Its dataset card reports 301,026 sessions and 9,310,255 LLM calls. Those are release totals, not a new study here.

The schema gives us the separation the example needs:

llm_calls[].duration_ms          end-to-end LLM call duration
tool_batches[].duration_ms       batch wall-clock duration
function_calls[].duration_ms     individual tool duration

But "end-to-end" is doing work in that first line. A model call can include network transit, queueing, prefill and decode. The field does not separate them. Thirty seconds of recorded model calls is not thirty seconds of GPU compute.

The records also carry timestamps, token counts and statuses. A batch's request_id matches an LLM message_id, linking the batch to a call. That link helps follow the run. It is not a complete dependency graph.

There is a catch before drawing a timeline. The authors' loader constructs an end column for calls, batches and exploded tool rows:

df["end"] = df["timestamp"] + pd.to_timedelta(df["duration_ms"], unit="ms")

That treats timestamp as a start. The schema does not say which end it marks.

My earlier cache analysis treated LLM timestamps as ends after checking consecutive-call overlap under both readings. That check belongs to the published cache study. It is an inferred convention, not a documented guarantee, and it does not settle tool-batch timestamps.

A timing analysis needs to state its reading, check event order and show whether the other reading changes its answer. Precision in the chart cannot fix ambiguity in the clock.

Individual tool starts need care too. The loader gives every tool row its batch timestamp. Sharing that value in a dataframe does not prove the tools started together. The synthetic figure knows its two starts because we defined them; the public layout does not supply those individual starts.

Use the batch duration for the batch's elapsed time. Do not reconstruct a per-tool schedule from fields that are not there.

The missing ten seconds are still missing

Our example starts at the first model call and ends at the last. That is a chosen window, not the whole software factory.

An environment may start before the first recorded call. CI may finish after the last. Review and deployment can sit outside both. A session ID groups records; it does not guarantee that every delivery stage was observed.

The ten unaccounted seconds might contain a handoff, an approval wait, missing instrumentation or something else. Subtracting known intervals does not make the remainder "orchestration overhead." It does not make it waste.

A person reading a diff is not a model defect either. For interactive response time, separate human pauses from active work. For request-to-validated-change time, retain them and label them. Those clocks serve different decisions.

If setup matters, measure environment creation, checkout and dependency preparation directly. Do not pull their durations out of an unnamed gap.

A tool wait can reach into the next call

The stages have separate clocks. They can still affect one another.

My cache analysis found a sharp drop around five minutes for several anonymized models. Agent calls after long tool batches showed it too. That was an association, not proof that a particular tool caused cache expiry.

Still, it changes how I think about a long test run. The test takes time, and the next call can arrive with less prompt reuse. To understand that sequence, I need the gap and token counts, not just the next call's duration.

That is a reason to inspect the loop, not to drop the checks.

Retries need more than a repeated name. A failed tool followed by the same tool could be a corrected command, a new input or different work. This schema has no tool arguments or proven action identities. It cannot tell those cases apart.

Seconds are not dollars, and calls are not changes

The release anonymizes model names. It does not supply provider prices, sandbox rates, CI bills or accepted patches. We cannot turn its durations into the price of a completed change. A successful tool status is not a passed task.

For a team deciding where to invest, I would put two measures side by side: elapsed time to a defined validation gate, and execution spend per change that clears it.

For the second, the proposed calculation is:

execution spend per validated change =
  measured execution spend across all attempts, including failed attempts
  / number of changes that meet the declared validation gate

That is a proposed operating metric, not a result from this trace. Name the gate: which checks, which revision, which acceptance rule. If no change passes, report the spend and zero successes rather than a finite cost per success.

Keep the work and gate fixed when comparing alternatives. Track validation rate alongside cost. A lower bill is not a win if it buys fewer useful changes. If review labor is outside the bill, call it execution spend, not the full cost of delivery.

A cheaper model might need more calls or repairs. It might work just as well. The schema does not establish either outcome.

Spend where the wait is

If model-call waits set the finish time, a faster endpoint is a candidate. First find out whether the wait is queueing, prompt processing or generation. Faster decode does not target all three.

If tool batches set the pace, look at build caches and safe parallelism. Test selection must preserve the validation gate. If separately measured setup dominates, look at environment reuse. These are conditional choices, not bottlenecks I measured in Copilot.

For a model change, compare complete attempts on the same work with the same checks. Keep failures in the bill. For a scheduling change, measure elapsed time and spend separately. More work at once can shorten a wait without reducing resource use.

Before buying a faster reply, check what happens after the reply ends.

Sources and scope: I inspected the public schema, dataset card, release documentation and loader at AzurePublicDataset commit 215becd, checked 7 November 2026. The release accompanies Liu et al., Agentic Coding in the Wild: Characterizing GitHub Copilot Traces at Production Scale, a vendor-authored study. No trace corpus was downloaded or reanalyzed for this post. The timeline and faster-call calculation are synthetic. This post establishes no runtime shares, dominant bottleneck, monetary savings or causal effect of a model change.