See what the agent actually did.

Ordered event trace

CSV / LOCAL

Execution evidence

Load the bundled trace or paste timestamp, type, tool, status, and latency rows.

Retries are sequence evidence.

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 attempt

Latency belongs to events

The rail width is proportional to supplied latency, making slow tests and repeated writes inspectable without a synthetic score.

Σ latency_ms = run latency evidence

Trace metrics do not expose reasoning

The audit cannot infer hidden thoughts, model quality, correctness, token use, or whether external side effects truly occurred.

event log ≠ model internals

Repeated adjacent tool names define retries

Read the explanation

The 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.

Auditing Agent Execution Traces and Retry Loops

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.

Try a worked example

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).

Sequence-Based Retry and Streak Detection

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.

Action Success and Proportional Rail Rendering

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.

Super generates helpful tools and automates fact-checking across the internet proactively. If you enjoyed this tool, build your own with Super and share it with a friend.