Errors and retries are different
Status identifies failure. A retry is an adjacent repeated tool call, even when the final attempt succeeds.
same tool as previous event → retry attemptStatus identifies failure. A retry is an adjacent repeated tool call, even when the final attempt succeeds.
same tool as previous event → retry attemptThe rail width is proportional to supplied latency, making slow tests and repeated writes inspectable without a synthetic score.
Σ latency_ms = run latency evidenceThe audit cannot infer hidden thoughts, model quality, correctness, token use, or whether external side effects truly occurred.
event log ≠ model internalsThe bundled CSV contains eight timestamped events. After sorting by timestamp, retry attempts are counted whenever a nonempty tool name equals the previous event tool name. Three adjacent write file events therefore create two retries and a longest streak of three, even though the third write succeeds. Errors are counted independently from status; the sample contains two error events. The sample latencies sum to two thousand seven hundred forty milliseconds. The test event contributes eight hundred, the largest sample latency. The rail allocates width proportional to each latency but enforces a minimum rectangle width, so short rectangles are not perfectly proportional. Supplied latency is summed; timestamp gaps are not substituted for it. There is no evidence of provider tokens, hidden reasoning or actual external effects. Four sample rows have type action; two have status ok. Action success is therefore fifty percent, not six successful statuses divided by all eight events. Rows with any nonempty tool name count as tool calls, giving seven calls across five unique names. The metrics are calculated from the data, but the displayed write file finding and slowest test sentence contain fixed sample wording that can be misleading for different traces. Offline parser or chart libraries may be unavailable; this draft does not certify a live audit.
How does this client-side trace auditor calculate tool retry streaks, failure rates, and execution rail durations from raw event logs?
This interactive trace auditor parses comma-delimited event records in the browser to summarize autonomous agent runs into operational metrics and a latency timeline. It evaluates adjacent tool invocations to identify sequential retry streaks, computes action success percentages across action-tagged records, and maps individual stage durations onto a proportional D3 rail.
The retry calculation relies strictly on sequential matching of adjacent tool names (r.tool === prev) without validating whether the payload parameters or internal prompts actually differed. Furthermore, trace telemetry only audits user-provided log timestamps and declared latencies; it does not independently verify underlying model thoughts, sandbox states, network side-effects, or token consumption.
Click 'Load bundled trace' to insert the 8-event sample CSV and run the auditor. The output section populates with 8 events, 7 tool calls, 5 unique tools, 2 errors, 2 retry attempts, a 3-invocation maximum streak on 'write_file', a total latency of 2,740 ms, and a 50% action success rate (2 successful actions out of 4).
The auditor tracks execution order after sorting records by timestamp. A retry attempt is incremented whenever an event with a declared tool name matches the tool name of the immediate prior row. When identical tools execute consecutively, the tool streak counter increments, tracking the longest repeated tool streak regardless of whether individual attempts succeeded or failed.
The tool calculates action success strictly across events labeled with type 'action', dividing the count of 'ok' status actions by the total number of action events. The horizontal rail sums the cumulative latency across all events and scales individual event segment widths linearly using D3, positioning each block along the timeline to visualize latency distribution.